---

yaml
---
r: 2600
b: refs/heads/master
c: b74e215
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 990a8baf568ca1d0ae65e59783ff821794118d07
+refs/heads/master: b74e2159c9849fb97659c6dc47ad706f702b22b9

trunk/CREDITS

@@ -1880,13 +1880,6 @@ S: Schlehenweg 9
 S: D-91080 Uttenreuth
 S: Germany
 
-N: Jaya Kumar
-E: jayalk@intworks.biz
-W: http://www.intworks.biz
-D: Arc monochrome LCD framebuffer driver, x86 reboot fixups
-S: Gurgaon, India
-S: Kuala Lumpur, Malaysia
-
 N: Gabor Kuti
 M: seasons@falcon.sch.bme.hu
 M: seasons@makosteszta.sote.hu

trunk/Documentation/DocBook/kernel-api.tmpl

@@ -338,6 +338,7 @@ X!Earch/i386/kernel/mca.c
 X!Iinclude/linux/device.h
 -->
 !Edrivers/base/driver.c
+!Edrivers/base/class_simple.c
 !Edrivers/base/core.c
 !Edrivers/base/firmware_class.c
 !Edrivers/base/transport_class.c

trunk/Documentation/driver-model/device.txt

@@ -76,14 +76,6 @@ driver_data:   Driver-specific data.
 
 platform_data: Platform data specific to the device.
 
-	       Example:  for devices on custom boards, as typical of embedded
-	       and SOC based hardware, Linux often uses platform_data to point
-	       to board-specific structures describing devices and how they
-	       are wired.  That can include what ports are available, chip
-	       variants, which GPIO pins act in what additional roles, and so
-	       on.  This shrinks the "Board Support Packages" (BSPs) and
-	       minimizes board-specific #ifdefs in drivers.
-
 current_state: Current power state of the device.
 
 saved_state:   Pointer to saved state of the device. This is usable by

trunk/Documentation/driver-model/driver.txt

@@ -5,17 +5,21 @@ struct device_driver {
         char                    * name;
         struct bus_type         * bus;
 
-        struct completion	unloaded;
-        struct kobject		kobj;
+        rwlock_t                lock;
+        atomic_t                refcount;
+
+        list_t                  bus_list;
         list_t                  devices;
 
-        struct module		*owner;
+        struct driver_dir_entry dir;
 
         int     (*probe)        (struct device * dev);
         int     (*remove)       (struct device * dev);
 
         int     (*suspend)      (struct device * dev, pm_message_t state, u32 level);
         int     (*resume)       (struct device * dev, u32 level);
+
+        void    (*release)      (struct device_driver * drv);
 };
 
 
@@ -47,6 +51,7 @@ being converted completely to the new model.
 static struct device_driver eepro100_driver = {
        .name		= "eepro100",
        .bus		= &pci_bus_type,
+       .devclass	= &ethernet_devclass,	/* when it's implemented */
 
        .probe		= eepro100_probe,
        .remove		= eepro100_remove,
@@ -80,6 +85,7 @@ static struct pci_driver eepro100_driver = {
        .driver	       = {
 		.name		= "eepro100",
 		.bus		= &pci_bus_type,
+		.devclass	= &ethernet_devclass,	/* when it's implemented */
 		.probe		= eepro100_probe,
 		.remove		= eepro100_remove,
 		.suspend	= eepro100_suspend,
@@ -160,32 +166,27 @@ Callbacks
 
 	int	(*probe)	(struct device * dev);
 
-The probe() entry is called in task context, with the bus's rwsem locked
-and the driver partially bound to the device.  Drivers commonly use
-container_of() to convert "dev" to a bus-specific type, both in probe()
-and other routines.  That type often provides device resource data, such
-as pci_dev.resource[] or platform_device.resources, which is used in
-addition to dev->platform_data to initialize the driver.
-
-This callback holds the driver-specific logic to bind the driver to a
-given device.  That includes verifying that the device is present, that
-it's a version the driver can handle, that driver data structures can
-be allocated and initialized, and that any hardware can be initialized.
-Drivers often store a pointer to their state with dev_set_drvdata().
-When the driver has successfully bound itself to that device, then probe()
-returns zero and the driver model code will finish its part of binding
-the driver to that device.
-
-A driver's probe() may return a negative errno value to indicate that
-the driver did not bind to this device, in which case it should have
-released all reasources it allocated.
+probe is called to verify the existence of a certain type of
+hardware. This is called during the driver binding process, after the
+bus has verified that the device ID of a device matches one of the
+device IDs supported by the driver. 
+
+This callback only verifies that there actually is supported hardware
+present. It may allocate a driver-specific structure, but it should
+not do any initialization of the hardware itself. The device-specific
+structure may be stored in the device's driver_data field. 
+
+	int	(*init)		(struct device * dev);
+
+init is called during the binding stage. It is called after probe has
+successfully returned and the device has been registered with its
+class. It is responsible for initializing the hardware.
 
 	int 	(*remove)	(struct device * dev);
 
-remove is called to unbind a driver from a device. This may be
+remove is called to dissociate a driver with a device. This may be
 called if a device is physically removed from the system, if the
-driver module is being unloaded, during a reboot sequence, or
-in other cases.
+driver module is being unloaded, or during a reboot sequence. 
 
 It is up to the driver to determine if the device is present or
 not. It should free any resources allocated specifically for the

trunk/Documentation/filesystems/isofs.txt

@@ -26,11 +26,7 @@ Mount options unique to the isofs filesystem.
   mode=xxx      Sets the permissions on files to xxx
   nojoliet      Ignore Joliet extensions if they are present.
   norock        Ignore Rock Ridge extensions if they are present.
-  hide		Completely strip hidden files from the file system.
-  showassoc	Show files marked with the 'associated' bit
-  unhide	Deprecated; showing hidden files is now default;
-		If given, it is a synonym for 'showassoc' which will
-		recreate previous unhide behavior
+  unhide        Show hidden files.
   session=x     Select number of session on multisession CD
   sbsector=xxx  Session begins from sector xxx
 

trunk/Documentation/filesystems/sysfs.txt

@@ -214,7 +214,7 @@ Other notes:
 
 A very simple (and naive) implementation of a device attribute is:
 
-static ssize_t show_name(struct device *dev, struct device_attribute *attr, char *buf)
+static ssize_t show_name(struct device * dev, char * buf)
 {
         return sprintf(buf,"%s\n",dev->name);
 }

trunk/Documentation/filesystems/tmpfs.txt

@@ -71,8 +71,8 @@ can be changed on remount.  The size parameter also accepts a suffix %
 to limit this tmpfs instance to that percentage of your physical RAM:
 the default, when neither size nor nr_blocks is specified, is size=50%
 
-If nr_blocks=0 (or size=0), blocks will not be limited in that instance;
-if nr_inodes=0, inodes will not be limited.  It is generally unwise to
+If both nr_blocks (or size) and nr_inodes are set to 0, neither blocks
+nor inodes will be limited in that instance.  It is generally unwise to
 mount with such options, since it allows any user with write access to
 use up all the memory on the machine; but enhances the scalability of
 that instance in a system with many cpus making intensive use of it.
@@ -97,4 +97,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>, 13 March 2005
+   Hugh Dickins <hugh@veritas.com>, 01 September 2004

trunk/Documentation/s390/CommonIO

@@ -30,7 +30,7 @@ Command line parameters
   device numbers (0xabcd or abcd, for 2.4 backward compatibility).
   You can use the 'all' keyword to ignore all devices.
   The '!' operator will cause the I/O-layer to _not_ ignore a device.
-  The command line is parsed from left to right.
+  The order on the command line is not important.
 
   For example, 
 	cio_ignore=0.0.0023-0.0.0042,0.0.4711
@@ -72,14 +72,13 @@ Command line parameters
   /proc/cio_ignore; "add <device range>, <device range>, ..." will ignore the
   specified devices.
 
-  Note: While already known devices can be added to the list of devices to be
-        ignored, there will be no effect on then. However, if such a device
-        disappears and then reappeares, it will then be ignored.
+  Note: Already known devices cannot be ignored.
 
-  For example,
+  For example, if device 0.0.abcd is already known and all other devices
+  0.0.a000-0.0.afff are not known,
 	"echo add 0.0.a000-0.0.accc, 0.0.af00-0.0.afff > /proc/cio_ignore"
-  will add 0.0.a000-0.0.accc and 0.0.af00-0.0.afff to the list of ignored
-  devices.
+  will add 0.0.a000-0.0.abcc, 0.0.abce-0.0.accc and 0.0.af00-0.0.afff to the
+  list of ignored devices and skip 0.0.abcd.
 
   The devices can be specified either by bus id (0.0.abcd) or, for 2.4 backward
   compatibilty, by the device number in hexadecimal (0xabcd or abcd).
@@ -99,8 +98,7 @@ Command line parameters
 
   - /proc/s390dbf/cio_trace/hex_ascii
     Logs the calling of functions in the common I/O-layer and, if applicable, 
-    which subchannel they were called for, as well as dumps of some data
-    structures (like irb in an error case).
+    which subchannel they were called for.
 
   The level of logging can be changed to be more or less verbose by piping to 
   /proc/s390dbf/cio_*/level a number between 0 and 6; see the documentation on