Documentation/driver-model/binding.txt:28: ERROR: trailing whitespace Documentation/driver-model/binding.txt:39: ERROR: trailing whitespace Documentation/driver-model/binding.txt:46: ERROR: trailing whitespace Documentation/driver-model/binding.txt:53: ERROR: trailing whitespace Documentation/driver-model/binding.txt:60: ERROR: trailing whitespace Documentation/driver-model/binding.txt:74: ERROR: trailing whitespace Documentation/driver-model/binding.txt:79: ERROR: trailing whitespace Documentation/driver-model/binding.txt:85: ERROR: trailing whitespace Documentation/driver-model/binding.txt:101: ERROR: trailing whitespace Signed-off-by: Andrea Gelmini <andrea.gelmini@xxxxxxxxx> --- Documentation/driver-model/binding.txt | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/Documentation/driver-model/binding.txt b/Documentation/driver-model/binding.txt index f7ec9d6..ee01c97 100644 --- a/Documentation/driver-model/binding.txt +++ b/Documentation/driver-model/binding.txt @@ -25,7 +25,7 @@ device_register When a new device is added, the bus's list of drivers is iterated over to find one that supports it. In order to determine that, the device ID of the device must match one of the device IDs that the driver -supports. The format and semantics for comparing IDs is bus-specific. +supports. The format and semantics for comparing IDs is bus-specific. Instead of trying to derive a complex state machine and matching algorithm, it is up to the bus driver to provide a callback to compare a device against the IDs of a driver. The bus returns 1 if a match was @@ -36,28 +36,28 @@ int match(struct device * dev, struct device_driver * drv); If a match is found, the device's driver field is set to the driver and the driver's probe callback is called. This gives the driver a chance to verify that it really does support the hardware, and that -it's in a working state. +it's in a working state. Device Class ~~~~~~~~~~~~ Upon the successful completion of probe, the device is registered with the class to which it belongs. Device drivers belong to one and only one -class, and that is set in the driver's devclass field. +class, and that is set in the driver's devclass field. devclass_add_device is called to enumerate the device within the class and actually register it with the class, which happens with the class's register_dev callback. NOTE: The device class structures and core routines to manipulate them are not in the mainline kernel, so the discussion is still a bit -speculative. +speculative. Driver ~~~~~~ When a driver is attached to a device, the device is inserted into the -driver's list of devices. +driver's list of devices. sysfs @@ -71,18 +71,18 @@ to the device's directory in the physical hierarchy. A directory for the device is created in the class's directory. A symlink is created in that directory that points to the device's -physical location in the sysfs tree. +physical location in the sysfs tree. A symlink can be created (though this isn't done yet) in the device's physical directory to either its class directory, or the class's top-level directory. One can also be created to point to its driver's -directory also. +directory also. driver_register ~~~~~~~~~~~~~~~ -The process is almost identical for when a new driver is added. +The process is almost identical for when a new driver is added. The bus's list of devices is iterated over to find a match. Devices that already have a driver are skipped. All the devices are iterated over, to bind as many devices as possible to the driver. @@ -98,5 +98,5 @@ of the driver is decremented. All symlinks between the two are removed. When a driver is removed, the list of devices that it supports is iterated over, and the driver's remove callback is called for each -one. The device is removed from that list and the symlinks removed. +one. The device is removed from that list and the symlinks removed. -- 1.7.1.251.gf80a2 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
