---

yaml --- r: 57519 b: refs/heads/master c: b6cedb3 h: refs/heads/master i: 57517: 4d2ba57 57515: 6a76d7c 57511: 29c49ad 57503: 4e800dc v: v3
git-mirror · Jun 7, 2007 · 3056145 · 3056145
1 parent af22efd
commit 3056145
Show file tree

Hide file tree

Showing 232 changed files with 2,603 additions and 3,758 deletions.
diff --git a/[refs] b/[refs]
@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 5212c555be332fc95982077e6cdc7bb6cb5fff5f
+refs/heads/master: b6cedb38613d41367839df9d2181df3c81fb25c4
diff --git a/trunk/Documentation/SubmittingPatches b/trunk/Documentation/SubmittingPatches
@@ -340,32 +340,8 @@ now, but you can do this to mark internal company procedures or just
 point out some special detail about the sign-off. 
 
 
-13) When to use Acked-by:
 
-The Signed-off-by: tag indicates that the signer was involved in the
-development of the patch, or that he/she was in the patch's delivery path.
-
-If a person was not directly involved in the preparation or handling of a
-patch but wishes to signify and record their approval of it then they can
-arrange to have an Acked-by: line added to the patch's changelog.
-
-Acked-by: is often used by the maintainer of the affected code when that
-maintainer neither contributed to nor forwarded the patch.
-
-Acked-by: is not as formal as Signed-off-by:.  It is a record that the acker
-has at least reviewed the patch and has indicated acceptance.  Hence patch
-mergers will sometimes manually convert an acker's "yep, looks good to me"
-into an Acked-by:.
-
-Acked-by: does not necessarily indicate acknowledgement of the entire patch.
-For example, if a patch affects multiple subsystems and has an Acked-by: from
-one subsystem maintainer then this usually indicates acknowledgement of just
-the part which affects that maintainer's code.  Judgement should be used here.
- When in doubt people should refer to the original discussion in the mailing
-list archives.
-
-
-14) The canonical patch format
+13) The canonical patch format
 
 The canonical patch subject line is:
 

diff --git a/trunk/Documentation/atomic_ops.txt b/trunk/Documentation/atomic_ops.txt
@@ -149,7 +149,7 @@ defined which accomplish this:
 	void smp_mb__before_atomic_dec(void);
 	void smp_mb__after_atomic_dec(void);
 	void smp_mb__before_atomic_inc(void);
-	void smp_mb__after_atomic_inc(void);
+	void smp_mb__after_atomic_dec(void);
 
 For example, smp_mb__before_atomic_dec() can be used like so:
 

diff --git a/trunk/Documentation/driver-model/platform.txt b/trunk/Documentation/driver-model/platform.txt
@@ -96,46 +96,6 @@ System setup also associates those clocks with the device, so that that
 calls to clk_get(&pdev->dev, clock_name) return them as needed.
 
 
-Legacy Drivers:  Device Probing
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Some drivers are not fully converted to the driver model, because they take
-on a non-driver role:  the driver registers its platform device, rather than
-leaving that for system infrastructure.  Such drivers can't be hotplugged
-or coldplugged, since those mechanisms require device creation to be in a
-different system component than the driver.
-
-The only "good" reason for this is to handle older system designs which, like
-original IBM PCs, rely on error-prone "probe-the-hardware" models for hardware
-configuration.  Newer systems have largely abandoned that model, in favor of
-bus-level support for dynamic configuration (PCI, USB), or device tables
-provided by the boot firmware (e.g. PNPACPI on x86).  There are too many
-conflicting options about what might be where, and even educated guesses by
-an operating system will be wrong often enough to make trouble.
-
-This style of driver is discouraged.  If you're updating such a driver,
-please try to move the device enumeration to a more appropriate location,
-outside the driver.  This will usually be cleanup, since such drivers
-tend to already have "normal" modes, such as ones using device nodes that
-were created by PNP or by platform device setup.
-
-None the less, there are some APIs to support such legacy drivers.  Avoid
-using these calls except with such hotplug-deficient drivers.
-
-	struct platform_device *platform_device_alloc(
-			char *name, unsigned id);
-
-You can use platform_device_alloc() to dynamically allocate a device, which
-you will then initialize with resources and platform_device_register().
-A better solution is usually:
-
-	struct platform_device *platform_device_register_simple(
-			char *name, unsigned id,
-			struct resource *res, unsigned nres);
-
-You can use platform_device_register_simple() as a one-step call to allocate
-and register a device.
-
-
 Device Naming and Driver Binding
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 The platform_device.dev.bus_id is the canonical name for the devices.

diff --git a/trunk/Documentation/feature-removal-schedule.txt b/trunk/Documentation/feature-removal-schedule.txt
@@ -104,7 +104,6 @@ Who:	Dominik Brodowski <linux@brodo.de>
 What:	remove EXPORT_SYMBOL(kernel_thread)
 When:	August 2006
 Files:	arch/*/kernel/*_ksyms.c
-Funcs:	kernel_thread
 Why:	kernel_thread is a low-level implementation detail.  Drivers should
         use the <linux/kthread.h> API instead which shields them from
 	implementation details and provides a higherlevel interface that

diff --git a/trunk/Documentation/filesystems/tmpfs.txt b/trunk/Documentation/filesystems/tmpfs.txt
@@ -94,10 +94,10 @@ largest node numbers in the range.  For example, mpol=bind:0-3,5,7,9-15
 
 Note that trying to mount a tmpfs with an mpol option will fail if the
 running kernel does not support NUMA; and will fail if its nodelist
-specifies a node which is not online.  If your system relies on that
-tmpfs being mounted, but from time to time runs a kernel built without
-NUMA capability (perhaps a safe recovery kernel), or with fewer nodes
-online, then it is advisable to omit the mpol option from automatic
+specifies a node >= MAX_NUMNODES.  If your system relies on that tmpfs
+being mounted, but from time to time runs a kernel built without NUMA
+capability (perhaps a safe recovery kernel), or configured to support
+fewer nodes, then it is advisable to omit the mpol option from automatic
 mount options.  It can be added later, when the tmpfs is already mounted
 on MountPoint, by 'mount -o remount,mpol=Policy:NodeList MountPoint'.
 
@@ -121,4 +121,4 @@ RAM/SWAP in 10240 inodes and it is only accessible by root.
 Author:
    Christoph Rohland <cr@sap.com>, 1.12.01
 Updated:
-   Hugh Dickins <hugh@veritas.com>, 4 June 2007
+   Hugh Dickins <hugh@veritas.com>, 19 February 2006
diff --git a/trunk/Documentation/firmware_class/README b/trunk/Documentation/firmware_class/README
@@ -1,7 +1,7 @@
 
  request_firmware() hotplug interface:
  ------------------------------------
-	Copyright (C) 2003 Manuel Estrada Sainz
+	Copyright (C) 2003 Manuel Estrada Sainz <ranty@debian.org>
 
  Why:
  ---

diff --git a/trunk/Documentation/firmware_class/firmware_sample_driver.c b/trunk/Documentation/firmware_class/firmware_sample_driver.c
@@ -1,7 +1,7 @@
 /*
  * firmware_sample_driver.c -
  *
- * Copyright (c) 2003 Manuel Estrada Sainz
+ * Copyright (c) 2003 Manuel Estrada Sainz <ranty@debian.org>
  *
  * Sample code on how to use request_firmware() from drivers.
  *

diff --git a/trunk/Documentation/firmware_class/firmware_sample_firmware_class.c b/trunk/Documentation/firmware_class/firmware_sample_firmware_class.c
@@ -1,7 +1,7 @@
 /*
  * firmware_sample_firmware_class.c -
  *
- * Copyright (c) 2003 Manuel Estrada Sainz
+ * Copyright (c) 2003 Manuel Estrada Sainz <ranty@debian.org>
  *
  * NOTE: This is just a probe of concept, if you think that your driver would
  * be well served by this mechanism please contact me first.
@@ -19,7 +19,7 @@
 #include <linux/firmware.h>
 
 
-MODULE_AUTHOR("Manuel Estrada Sainz");
+MODULE_AUTHOR("Manuel Estrada Sainz <ranty@debian.org>");
 MODULE_DESCRIPTION("Hackish sample for using firmware class directly");
 MODULE_LICENSE("GPL");
 

diff --git a/trunk/Documentation/networking/00-INDEX b/trunk/Documentation/networking/00-INDEX
@@ -32,8 +32,6 @@ cops.txt
 	- info on the COPS LocalTalk Linux driver
 cs89x0.txt
 	- the Crystal LAN (CS8900/20-based) Ethernet ISA adapter driver
-cxacru.txt
-	- Conexant AccessRunner USB ADSL Modem
 de4x5.txt
 	- the Digital EtherWORKS DE4?? and DE5?? PCI Ethernet driver
 decnet.txt

diff --git a/trunk/Documentation/networking/cxacru.txt b/trunk/Documentation/networking/cxacru.txt
diff --git a/trunk/Documentation/powerpc/booting-without-of.txt b/trunk/Documentation/powerpc/booting-without-of.txt
@@ -1,69 +1,14 @@
            Booting the Linux/ppc kernel without Open Firmware
            --------------------------------------------------
 
+
 (c) 2005 Benjamin Herrenschmidt <benh at kernel.crashing.org>,
     IBM Corp.
 (c) 2005 Becky Bruce <becky.bruce at freescale.com>,
     Freescale Semiconductor, FSL SOC and 32-bit additions
 (c) 2006 MontaVista Software, Inc.
     Flash chip node definition
 
-Table of Contents
-=================
-
-  I - Introduction
-    1) Entry point for arch/powerpc
-    2) Board support
-
-  II - The DT block format
-    1) Header
-    2) Device tree generalities
-    3) Device tree "structure" block
-    4) Device tree "strings" block
-
-  III - Required content of the device tree
-    1) Note about cells and address representation
-    2) Note about "compatible" properties
-    3) Note about "name" properties
-    4) Note about node and property names and character set
-    5) Required nodes and properties
-      a) The root node
-      b) The /cpus node
-      c) The /cpus/* nodes
-      d) the /memory node(s)
-      e) The /chosen node
-      f) the /soc<SOCname> node
-
-  IV - "dtc", the device tree compiler
-
-  V - Recommendations for a bootloader
-
-  VI - System-on-a-chip devices and nodes
-    1) Defining child nodes of an SOC
-    2) Representing devices without a current OF specification
-      a) MDIO IO device
-      c) PHY nodes
-      b) Gianfar-compatible ethernet nodes
-      d) Interrupt controllers
-      e) I2C
-      f) Freescale SOC USB controllers
-      g) Freescale SOC SEC Security Engines
-      h) Board Control and Status (BCSR)
-      i) Freescale QUICC Engine module (QE)
-      g) Flash chip nodes
-
-  VII - Specifying interrupt information for devices
-    1) interrupts property
-    2) interrupt-parent property
-    3) OpenPIC Interrupt Controllers
-    4) ISA Interrupt Controllers
-
-  Appendix A - Sample SOC node for MPC8540
-
-
-Revision Information
-====================
-
    May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet.
 
    May 19, 2005: Rev 0.2 - Add chapter III and bits & pieces here or
@@ -1742,7 +1687,7 @@ platforms are moved over to use the flattened-device-tree model.
 		};
 	};
 
-    j) Flash chip nodes
+    g) Flash chip nodes
 
     Flash chips (Memory Technology Devices) are often used for solid state
     file systems on embedded devices.

diff --git a/trunk/MAINTAINERS b/trunk/MAINTAINERS
@@ -782,6 +782,11 @@ M:	rathamahata@php4.ru
 L:	linux-kernel@vger.kernel.org
 S:	Maintained
 
+BERKSHIRE PRODUCTS PC WATCHDOG DRIVER
+P:	Kenji Hollis
+W:	http://ftp.bitgate.com/pcwd/
+S:	Maintained
+
 BFS FILE SYSTEM
 P:	Tigran A. Aivazian
 M:	tigran@aivazian.fsnet.co.uk
@@ -3020,7 +3025,7 @@ S:	Maintained
 REISERFS FILE SYSTEM
 P:	Hans Reiser
 M:	reiserfs-dev@namesys.com
-L:	reiserfs-devel@vger.kernel.org
+L:	reiserfs-list@namesys.com
 W:	http://www.namesys.com
 S:	Supported
 
@@ -3899,6 +3904,10 @@ S:	Maintained
 
 UCLINUX FOR NEC V850
 P:	Miles Bader
+M:	uclinux-v850@lsi.nec.co.jp
+W:	http://www.ic.nec.co.jp/micro/uclinux/eng/
+W:	http://www.ee.nec.de/uclinux/
+S:	Supported
 
 UCLINUX FOR RENESAS H8/300
 P:	Yoshinori Sato
@@ -3907,10 +3916,10 @@ W:	http://uclinux-h8.sourceforge.jp/
 S:	Supported
 
 UFS FILESYSTEM
-P:	Evgeniy Dushistov
-M:	dushistov@mail.ru
-L:	linux-kernel@vger.kernel.org
-S:	Maintained
+P: Evgeniy Dushistov
+M: dushistov@mail.ru
+L: linux-kernel@vger.kernel.org
+S: Maintained
 
 USB DIAMOND RIO500 DRIVER
 P:	Cesar Miquel