---

yaml
---
r: 87876
b: refs/heads/master
c: 5c29934
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 3085354de635179d70c240e6d942bcbd1d93056c
+refs/heads/master: 5c29934de29ddd7ecd913d83cad28e872f2e8c78

trunk/Documentation/hw_random.txt

@@ -1,26 +1,33 @@
+	Hardware driver for Intel/AMD/VIA Random Number Generators (RNG)
+	Copyright 2000,2001 Jeff Garzik <jgarzik@pobox.com>
+	Copyright 2000,2001 Philipp Rumpf <prumpf@mandrakesoft.com>
+
 Introduction:
 
-	The hw_random framework is software that makes use of a
+	The hw_random device driver is software that makes use of a
 	special hardware feature on your CPU or motherboard,
-	a Random Number Generator (RNG).  The software has two parts:
-	a core providing the /dev/hw_random character device and its
-	sysfs support, plus a hardware-specific driver that plugs
-	into that core.
+	a Random Number Generator (RNG).
 
-	To make the most effective use of these mechanisms, you
+	In order to make effective use of this device driver, you
 	should download the support software as well.  Download the
 	latest version of the "rng-tools" package from the
 	hw_random driver's official Web site:
 
 		http://sourceforge.net/projects/gkernel/
 
-	Those tools use /dev/hw_random to fill the kernel entropy pool,
-	which is used internally and exported by the /dev/urandom and
-	/dev/random special files.
+About the Intel RNG hardware, from the firmware hub datasheet:
+
+	The Firmware Hub integrates a Random Number Generator (RNG)
+	using thermal noise generated from inherently random quantum
+	mechanical properties of silicon. When not generating new random
+	bits the RNG circuitry will enter a low power state. Intel will
+	provide a binary software driver to give third party software
+	access to our RNG for use as a security feature. At this time,
+	the RNG is only to be used with a system in an OS-present state.
 
 Theory of operation:
 
-	CHARACTER DEVICE.  Using the standard open()
+	Character driver.  Using the standard open()
 	and read() system calls, you can read random data from
 	the hardware RNG device.  This data is NOT CHECKED by any
 	fitness tests, and could potentially be bogus (if the
@@ -29,37 +36,9 @@ Theory of operation:
 	a security-conscious person would run fitness tests on the
 	data before assuming it is truly random.
 
-	The rng-tools package uses such tests in "rngd", and lets you
-	run them by hand with a "rngtest" utility.
-
-	/dev/hw_random is char device major 10, minor 183.
-
-	CLASS DEVICE.  There is a /sys/class/misc/hw_random node with
-	two unique attributes, "rng_available" and "rng_current".  The
-	"rng_available" attribute lists the hardware-specific drivers
-	available, while "rng_current" lists the one which is currently
-	connected to /dev/hw_random.  If your system has more than one
-	RNG available, you may change the one used by writing a name from
-	the list in "rng_available" into "rng_current".
-
-==========================================================================
-
-	Hardware driver for Intel/AMD/VIA Random Number Generators (RNG)
-	Copyright 2000,2001 Jeff Garzik <jgarzik@pobox.com>
-	Copyright 2000,2001 Philipp Rumpf <prumpf@mandrakesoft.com>
-
-
-About the Intel RNG hardware, from the firmware hub datasheet:
-
-	The Firmware Hub integrates a Random Number Generator (RNG)
-	using thermal noise generated from inherently random quantum
-	mechanical properties of silicon. When not generating new random
-	bits the RNG circuitry will enter a low power state. Intel will
-	provide a binary software driver to give third party software
-	access to our RNG for use as a security feature. At this time,
-	the RNG is only to be used with a system in an OS-present state.
+	/dev/hwrandom is char device major 10, minor 183.
 
-Intel RNG Driver notes:
+Driver notes:
 
 	* FIXME: support poll(2)
 

trunk/Documentation/i386/IO-APIC.txt

@@ -70,7 +70,7 @@ Every PCI card emits a PCI IRQ, which can be INTA, INTB, INTC or INTD:
 
 These INTA-D PCI IRQs are always 'local to the card', their real meaning
 depends on which slot they are in. If you look at the daisy chaining diagram,
-a card in slot4, issuing INTA IRQ, it will end up as a signal on PIRQ4 of
+a card in slot4, issuing INTA IRQ, it will end up as a signal on PIRQ2 of
 the PCI chipset. Most cards issue INTA, this creates optimal distribution
 between the PIRQ lines. (distributing IRQ sources properly is not a
 necessity, PCI IRQs can be shared at will, but it's a good for performance

trunk/Documentation/kernel-parameters.txt

@@ -1130,10 +1130,6 @@ and is between 256 and 4096 characters. It is defined in the file
 	memmap=nn[KMG]$ss[KMG]
 			[KNL,ACPI] Mark specific memory as reserved.
 			Region of memory to be used, from ss to ss+nn.
-			Example: Exclude memory from 0x18690000-0x1869ffff
-			         memmap=64K$0x18690000
-			         or
-			         memmap=0x10000$0x18690000
 
 	meye.*=		[HW] Set MotionEye Camera parameters
 			See Documentation/video4linux/meye.txt.

trunk/Documentation/nmi_watchdog.txt

@@ -23,7 +23,8 @@ kernel debugging options, such as Kernel Stack Meter or Kernel Tracer,
 may implicitly disable the NMI watchdog.]
 
 For x86-64, the needed APIC is always compiled in, and the NMI watchdog is
-always enabled with I/O-APIC mode (nmi_watchdog=1).
+always enabled with I/O-APIC mode (nmi_watchdog=1). Currently, local APIC
+mode (nmi_watchdog=2) does not work on x86-64.
 
 Using local APIC (nmi_watchdog=2) needs the first performance register, so
 you can't use it for other purposes (such as high precision performance

trunk/MAINTAINERS

@@ -2110,7 +2110,7 @@ M:	reinette.chatre@intel.com
 L:	linux-wireless@vger.kernel.org
 L:	ipw3945-devel@lists.sourceforge.net
 W:	http://intellinuxwireless.org
-T:	git git://git.kernel.org/pub/scm/linux/kernel/git/rchatre/iwlwifi-2.6.git
+T:	git git://intellinuxwireless.org/repos/iwlwifi
 S:	Supported
 
 IOC3 ETHERNET DRIVER
@@ -2322,8 +2322,6 @@ P:	Anil S Keshavamurthy
 M:	anil.s.keshavamurthy@intel.com
 P:	David S. Miller
 M:	davem@davemloft.net
-P:	Masami Hiramatsu
-M:	mhiramat@redhat.com
 L:	linux-kernel@vger.kernel.org
 S:	Maintained
 

trunk/Makefile

@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 25
-EXTRAVERSION = -rc7
+EXTRAVERSION = -rc6
 NAME = Funky Weasel is Jiggy wit it
 
 # *DOCUMENTATION*
@@ -189,7 +189,7 @@ SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
 # Alternatively CROSS_COMPILE can be set in the environment.
 # Default value for CROSS_COMPILE is not to prefix executables
 # Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile
-export KBUILD_BUILDHOST := $(SUBARCH)
+
 ARCH		?= $(SUBARCH)
 CROSS_COMPILE	?=
 

trunk/arch/avr32/kernel/setup.c

@@ -163,7 +163,6 @@ add_reserved_region(resource_size_t start, resource_size_t end,
 	new->start = start;
 	new->end = end;
 	new->name = name;
-	new->sibling = next;
 	new->flags = IORESOURCE_MEM;
 
 	*pprev = new;

trunk/arch/avr32/kernel/traps.c

@@ -178,7 +178,6 @@ static int do_cop_absent(u32 insn)
 	return 0;
 }
 
-#ifdef CONFIG_BUG
 int is_valid_bugaddr(unsigned long pc)
 {
 	unsigned short opcode;
@@ -190,7 +189,6 @@ int is_valid_bugaddr(unsigned long pc)
 
 	return opcode == AVR32_BUG_OPCODE;
 }
-#endif
 
 asmlinkage void do_illegal_opcode(unsigned long ecr, struct pt_regs *regs)
 {
@@ -199,7 +197,6 @@ asmlinkage void do_illegal_opcode(unsigned long ecr, struct pt_regs *regs)
 	void __user *pc;
 	long code;
 
-#ifdef CONFIG_BUG
 	if (!user_mode(regs) && (ecr == ECR_ILLEGAL_OPCODE)) {
 		enum bug_trap_type type;
 
@@ -214,7 +211,6 @@ asmlinkage void do_illegal_opcode(unsigned long ecr, struct pt_regs *regs)
 			die("Kernel BUG", regs, SIGKILL);
 		}
 	}
-#endif
 
 	local_irq_enable();