---

yaml
---
r: 100721
b: refs/heads/master
c: b0bfcce
h: refs/heads/master
i:
  100719: ba5792a
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: f7def13ed0775ee506c62a8612a124dce1776ac2
+refs/heads/master: b0bfcce930bca38af056662e598991cb393eaa4a

trunk/Documentation/DocBook/kgdb.tmpl

@@ -84,9 +84,10 @@
     runs an instance of gdb against the vmlinux file which contains
     the symbols (not boot image such as bzImage, zImage, uImage...).
     In gdb the developer specifies the connection parameters and
-    connects to kgdb.  The type of connection a developer makes with
-    gdb depends on the availability of kgdb I/O modules compiled as
-    builtin's or kernel modules in the test machine's kernel.
+    connects to kgdb.  Depending on which kgdb I/O modules exist in
+    the kernel for a given architecture, it may be possible to debug
+    the test machine's kernel with the development machine using a
+    rs232 or ethernet connection.
     </para>
   </chapter>
   <chapter id="CompilingAKernel">
@@ -222,7 +223,7 @@
   </para>
   <para>
   IMPORTANT NOTE: Using this option with kgdb over the console
-  (kgdboc) is not supported.
+  (kgdboc) or kgdb over ethernet (kgdboe) is not supported.
   </para>
   </sect1>
   </chapter>
@@ -248,11 +249,18 @@
     (gdb) target remote /dev/ttyS0
     </programlisting>
     <para>
-    Example (kgdb to a terminal server on tcp port 2012):
+    Example (kgdb to a terminal server):
     </para>
     <programlisting>
     % gdb ./vmlinux
-    (gdb) target remote 192.168.2.2:2012
+    (gdb) target remote udp:192.168.2.2:6443
+    </programlisting>
+    <para>
+    Example (kgdb over ethernet):
+    </para>
+    <programlisting>
+    % gdb ./vmlinux
+    (gdb) target remote udp:192.168.2.2:6443
     </programlisting>
     <para>
     Once connected, you can debug a kernel the way you would debug an

trunk/Documentation/hwmon/sysfs-interface

@@ -2,12 +2,17 @@ Naming and data format standards for sysfs files
 ------------------------------------------------
 
 The libsensors library offers an interface to the raw sensors data
-through the sysfs interface. Since lm-sensors 3.0.0, libsensors is
-completely chip-independent. It assumes that all the kernel drivers
-implement the standard sysfs interface described in this document.
-This makes adding or updating support for any given chip very easy, as
-libsensors, and applications using it, do not need to be modified.
-This is a major improvement compared to lm-sensors 2.
+through the sysfs interface. See libsensors documentation and source for
+further information. As of writing this document, libsensors
+(from lm_sensors 2.8.3) is heavily chip-dependent. Adding or updating
+support for any given chip requires modifying the library's code.
+This is because libsensors was written for the procfs interface
+older kernel modules were using, which wasn't standardized enough.
+Recent versions of libsensors (from lm_sensors 2.8.2 and later) have
+support for the sysfs interface, though.
+
+The new sysfs interface was designed to be as chip-independent as
+possible.
 
 Note that motherboards vary widely in the connections to sensor chips.
 There is no standard that ensures, for example, that the second
@@ -30,17 +35,19 @@ access this data in a simple and consistent way. That said, such programs
 will have to implement conversion, labeling and hiding of inputs. For
 this reason, it is still not recommended to bypass the library.
 
+If you are developing a userspace application please send us feedback on
+this standard.
+
+Note that this standard isn't completely established yet, so it is subject
+to changes. If you are writing a new hardware monitoring driver those
+features can't seem to fit in this interface, please contact us with your
+extension proposal. Keep in mind that backward compatibility must be
+preserved.
+
 Each chip gets its own directory in the sysfs /sys/devices tree.  To
 find all sensor chips, it is easier to follow the device symlinks from
 /sys/class/hwmon/hwmon*.
 
-Up to lm-sensors 3.0.0, libsensors looks for hardware monitoring attributes
-in the "physical" device directory. Since lm-sensors 3.0.1, attributes found
-in the hwmon "class" device directory are also supported. Complex drivers
-(e.g. drivers for multifunction chips) may want to use this possibility to
-avoid namespace pollution. The only drawback will be that older versions of
-libsensors won't support the driver in question.
-
 All sysfs values are fixed point numbers.
 
 There is only one value per file, unlike the older /proc specification.

trunk/MAINTAINERS

@@ -4431,10 +4431,10 @@ M:	johnpol@2ka.mipt.ru
 S:	Maintained
 
 W83791D HARDWARE MONITORING DRIVER
-P:	Marc Hulsman
-M:	m.hulsman@tudelft.nl
+P:	Charles Spirakis
+M:	bezaur@gmail.com
 L:	lm-sensors@lm-sensors.org
-S:	Maintained
+S:	Odd Fixes
 
 W83793 HARDWARE MONITORING DRIVER
 P:	Rudolf Marek

trunk/Makefile

@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 26
-EXTRAVERSION = -rc8
+EXTRAVERSION = -rc7
 NAME = Rotary Wombat
 
 # *DOCUMENTATION*

trunk/arch/alpha/Makefile

@@ -13,7 +13,6 @@ NM := $(NM) -B
 LDFLAGS_vmlinux	:= -static -N #-relax
 CHECKFLAGS	+= -D__alpha__ -m64
 cflags-y	:= -pipe -mno-fp-regs -ffixed-8 -msmall-data
-cflags-y	+= $(call cc-option, -fno-jump-tables)
 
 cpuflags-$(CONFIG_ALPHA_EV4)		:= -mcpu=ev4
 cpuflags-$(CONFIG_ALPHA_EV5)		:= -mcpu=ev5

trunk/arch/alpha/kernel/core_t2.c

@@ -74,8 +74,6 @@
 # define DBG(args)
 #endif
 
-DEFINE_SPINLOCK(t2_hae_lock);
-
 static volatile unsigned int t2_mcheck_any_expected;
 static volatile unsigned int t2_mcheck_last_taken;
 

trunk/arch/alpha/kernel/pci.c

@@ -71,23 +71,6 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82378, quirk_i
 static void __init
 quirk_cypress(struct pci_dev *dev)
 {
-	/* The Notorious Cy82C693 chip.  */
-
-	/* The generic legacy mode IDE fixup in drivers/pci/probe.c
-	   doesn't work correctly with the Cypress IDE controller as
-	   it has non-standard register layout.  Fix that.  */
-	if (dev->class >> 8 == PCI_CLASS_STORAGE_IDE) {
-		dev->resource[2].start = dev->resource[3].start = 0;
-		dev->resource[2].end = dev->resource[3].end = 0;
-		dev->resource[2].flags = dev->resource[3].flags = 0;
-		if (PCI_FUNC(dev->devfn) == 2) {
-			dev->resource[0].start = 0x170;
-			dev->resource[0].end = 0x177;
-			dev->resource[1].start = 0x376;
-			dev->resource[1].end = 0x376;
-		}
-	}
-
 	/* The Cypress bridge responds on the PCI bus in the address range
 	   0xffff0000-0xffffffff (conventional x86 BIOS ROM).  There is no
 	   way to turn this off.  The bridge also supports several extended

trunk/arch/alpha/kernel/traps.c

@@ -447,7 +447,7 @@ struct unaligned_stat {
 
 
 /* Macro for exception fixup code to access integer registers.  */
-#define una_reg(r)  (_regs[(r) >= 16 && (r) <= 18 ? (r)+19 : (r)])
+#define una_reg(r)  (regs->regs[(r) >= 16 && (r) <= 18 ? (r)+19 : (r)])
 
 
 asmlinkage void
@@ -456,7 +456,6 @@ do_entUna(void * va, unsigned long opcode, unsigned long reg,
 {
 	long error, tmp1, tmp2, tmp3, tmp4;
 	unsigned long pc = regs->pc - 4;
-	unsigned long *_regs = regs->regs;
 	const struct exception_table_entry *fixup;
 
 	unaligned[0].count++;

trunk/arch/arm/Kconfig

@@ -147,10 +147,6 @@ config FIQ
 config ARCH_MTD_XIP
 	bool
 
-config GENERIC_HARDIRQS_NO__DO_IRQ
-	bool
-	def_bool y
-
 if OPROFILE
 
 config OPROFILE_ARMV6

trunk/arch/arm/Makefile

@@ -190,6 +190,8 @@ core-$(CONFIG_PLAT_S3C24XX)		+= arch/arm/plat-s3c24xx/
 core-$(CONFIG_ARCH_MXC)		+= arch/arm/plat-mxc/
 
 drivers-$(CONFIG_OPROFILE)      += arch/arm/oprofile/
+drivers-$(CONFIG_ARCH_CLPS7500)	+= drivers/acorn/char/
+drivers-$(CONFIG_ARCH_L7200)	+= drivers/acorn/char/
 
 libs-y				:= arch/arm/lib/ $(libs-y)