kernel/linux.git/drivers/base/bus.c, branch linux-2.6.16.y

[PATCH] drivers/base/bus.c warning fixes

2006-02-08T00:12:31+00:00

drivers/base/bus.c:166: warning: `driver_attr_unbind' defined but not used drivers/base/bus.c:194: warning: `driver_attr_bind' defined but not used Looks like these two attributes and supporting functions want to be #ifdef HOTPLUG'd Signed-off-by: Russell King Cc: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Driver core: only all userspace bind/unbind if CONFIG_HOTPLUG is enabled

2006-01-05T00:18:09+00:00

Thanks to drivers making their id tables __devinit, we can't allow userspace to bind or unbind drivers from devices manually through sysfs. So we only allow this if CONFIG_HOTPLUG is enabled. Cc: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

[PATCH] Hold the device's parent's lock during probe and remove

2006-01-05T00:18:08+00:00

This patch (as604) makes the driver core hold a device's parent's lock as well as the device's lock during calls to the probe and remove methods in a driver. This facility is needed by USB device drivers, owing to the peculiar way USB devices work: A device provides multiple interfaces, and drivers are bound to interfaces rather than to devices; Nevertheless a reset, reset-configuration, suspend, or resume affects the entire device and requires the caller to hold the lock for the device, not just a lock for one of the interfaces. Since a USB driver's probe method is always called with the interface lock held, the locking order rules (always lock parent before child) prevent these methods from acquiring the device lock. The solution provided here is to call all probe and remove methods, for all devices (not just USB), with the parent lock already acquired. Although currently only the USB subsystem requires these changes, people have mentioned in prior discussion that the overhead of acquiring an extra semaphore in all the prove/remove sequences is not overly large. Up to now, the USB core has been using its own set of private semaphores. A followup patch will remove them, relying entirely on the device semaphores provided by the driver core. The code paths affected by this patch are: device_add and device_del: The USB core already holds the parent lock, so no actual change is needed. driver_register and driver_unregister: The driver core will now lock both the parent and the device before probing or removing. driver_bind and driver_unbind (in sysfs): These routines will now lock both the parent and the device before binding or unbinding. bus_rescan_devices: The helper routine will lock the parent before probing a device. I have not tested this patch for conflicts with other subsystems. As far as I can see, the only possibility of conflict would lie in the bus_rescan_devices pathway, and it seems pretty remote. Nevertheless, it would be good for this to get a lot of testing in -mm. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

[PATCH] Small fixes to driver core

2005-11-24T07:03:06+00:00

This patch (as603) makes a few small fixes to the driver core: Change spin_lock_irq for a klist lock to spin_lock; Fix reference count leaks; Minor spelling and formatting changes. Signed-off-by: Alan Stern Acked-by Patrick Mochel Signed-off-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds

[PATCH] fix klist semantics for lists which have elements removed on traversal

2005-09-08T01:26:54+00:00

The problem is that klists claim to provide semantics for safe traversal of lists which are being modified. The failure case is when traversal of a list causes element removal (a fairly common case). The issue is that although the list node is refcounted, if it is embedded in an object (which is universally the case), then the object will be freed regardless of the klist refcount leading to slab corruption because the klist iterator refers to the prior element to get the next. The solution is to make the klist take and release references to the embedding object meaning that the embedding object won't be released until the list relinquishes the reference to it. (akpm: fast-track this because it's needed for the 2.6.13 scsi merge) Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] klist: fix klist to have the same klist_add semantics as list_head

2005-09-05T23:03:13+00:00

at the moment, the list_head semantics are list_add(node, head) whereas current klist semantics are klist_add(head, node) This is bound to cause confusion, and since klist is the newcomer, it should follow the list_head semantics. I also added missing include guards to klist.h Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

[PATCH] Fix manual binding infinite loop

2005-09-05T23:03:09+00:00

Fix for manual binding of drivers to devices. Problem is if you pass in a valid device id, but the driver refuses to bind. Infinite loop as write() tries to resubmit the data it just sent. Thanks to Michal Ostrowski for pointing the problem out. Signed-off-by: Greg Kroah-Hartman

[PATCH] Fix manual binding infinite loop

2005-08-18T05:02:25+00:00

[PATCH] driver core: change bus_rescan_devices to return void

2005-06-30T05:48:04+00:00

No one was looking at the return value of bus_rescan_devices, and it really wasn't anything that anyone in the kernel would ever care about. So change it which enabled some counting code to be removed also. Signed-off-by: Greg Kroah-Hartman

[PATCH] driver core: Add the ability to bind drivers to devices from userspace

2005-06-30T05:48:04+00:00

This adds a single file, "bind", to the sysfs directory of every driver registered with the driver core. To bind a device to a driver, write the bus id of the device you wish to bind to that specific driver to the "bind" file (remember to not add a trailing \n). If that bus id matches a device on that bus, and it does not currently have a driver bound to it, the probe sequence will be initiated with that driver and device. Note, this requires that the driver itself be willing and able to accept that device (usually through a device id type table). This patch does not make it possible to override the driver's id table. Signed-off-by: Greg Kroah-Hartman