2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-29 01:23:47 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-29 01:23:47 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 22:26:56 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-02-07 12:58:20 -08:00
|
|
|
|
|
|
|
|
|
2005-11-23 15:43:50 -08:00
|
|
|
|
2005-06-22 16:09:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-23 15:43:50 -08:00
|
|
|
|
[PATCH] Hold the device's parent's lock during probe and remove
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 <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-17 16:54:12 -05:00
|
|
|
|
|
|
|
|
|
2005-06-22 16:09:05 -07:00
|
|
|
|
[PATCH] Hold the device's parent's lock during probe and remove
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 <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-17 16:54:12 -05:00
|
|
|
|
|
|
|
|
|
2005-06-22 16:09:05 -07:00
|
|
|
|
|
|
|
|
|
2005-11-23 15:43:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-22 16:09:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-22 16:09:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-23 15:43:50 -08:00
|
|
|
|
[PATCH] Hold the device's parent's lock during probe and remove
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 <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-17 16:54:12 -05:00
|
|
|
|
|
|
|
|
|
2005-06-22 16:09:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[PATCH] Hold the device's parent's lock during probe and remove
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 <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-17 16:54:12 -05:00
|
|
|
|
|
|
|
|
|
2006-03-22 16:26:25 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-22 16:09:05 -07:00
|
|
|
|
2005-11-23 15:43:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-22 16:09:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-02-07 12:58:20 -08:00
|
|
|
|
2005-06-22 16:09:05 -07:00
|
|
|
|
2005-03-21 11:49:14 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-03-21 11:49:14 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-03-21 11:49:14 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-06-22 16:59:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-03-21 12:00:18 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-03-21 12:00:18 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-03-21 12:00:18 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-13 22:39:26 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-13 22:39:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-14 11:23:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-04 20:42:26 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-22 16:09:05 -07:00
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
2006-09-22 11:37:08 +02:00
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-22 11:37:08 +02:00
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-22 11:37:08 +02:00
|
|
|
|
2006-09-14 11:23:28 +02:00
|
|
|
|
2006-09-22 11:37:08 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-09-22 11:37:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-04 20:42:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-18 16:22:34 -04:00
|
|
|
|
2006-04-04 20:42:26 +02:00
|
|
|
|
|
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
2006-04-04 20:42:26 +02:00
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
|
|
|
|
|
2006-04-04 20:42:26 +02:00
|
|
|
|
|
|
|
|
|
2006-09-18 16:22:34 -04:00
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-18 16:22:34 -04:00
|
|
|
|
|
|
|
|
|
2006-04-04 20:42:26 +02:00
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
2006-04-04 20:42:26 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-15 15:31:56 +02:00
|
|
|
|
2006-09-14 11:23:28 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-10-05 17:03:24 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-12-13 15:17:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
2005-12-13 15:17:34 -08:00
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-12-13 15:17:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-15 01:30:11 +09:00
|
|
|
|
2005-12-13 15:17:34 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-04 07:48:03 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-10-04 07:48:03 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-04 07:48:03 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
|
|
|
|
|
[PATCH] Hold the device's parent's lock during probe and remove
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 <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-17 16:54:12 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
[PATCH] Hold the device's parent's lock during probe and remove
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 <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-17 16:54:12 -05:00
|
|
|
|
|
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
|
|
|
|
|
[PATCH] Hold the device's parent's lock during probe and remove
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 <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-17 16:54:12 -05:00
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-22 16:09:05 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-06-22 16:09:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-03-14 09:18:18 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
2006-03-14 09:18:18 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
2006-03-14 09:18:18 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-08-14 22:43:20 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 22:26:56 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 22:26:56 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-06 16:56:51 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Driver core: add notification of bus events
I finally did as you suggested and added the notifier to the struct
bus_type itself. There are still problems to be expected is something
attaches to a bus type where the code can hook in different struct
device sub-classes (which is imho a big bogosity but I won't even try to
argue that case now) but it will solve nicely a number of issues I've
had so far.
That also means that clients interested in registering for such
notifications have to do it before devices are added and after bus types
are registered. Fortunately, most bus types that matter for the various
usage scenarios I have in mind are registerd at postcore_initcall time,
which means I have a really nice spot at arch_initcall time to add my
notifiers.
There are 4 notifications provided. Device being added (before hooked to
the bus) and removed (failure of previous case or after being unhooked
from the bus), along with driver being bound to a device and about to be
unbound.
The usage I have for these are:
- The 2 first ones are used to maintain a struct device_ext that is
hooked to struct device.firmware_data. This structure contains for now a
pointer to the Open Firmware node related to the device (if any), the
NUMA node ID (for quick access to it) and the DMA operations pointers &
iommu table instance for DMA to/from this device. For bus types I own
(like IBM VIO or EBUS), I just maintain that structure directly from the
bus code when creating the devices. But for bus types managed by generic
code like PCI or platform (actually, of_platform which is a variation of
platform linked to Open Firmware device-tree), I need this notifier.
- The other two ones have a completely different usage scenario. I have
cases where multiple devices and their drivers depend on each other. For
example, the IBM EMAC network driver needs to attach to a MAL DMA engine
which is a separate device, and a PHY interface which is also a separate
device. They are all of_platform_device's (well, about to be with my
upcoming patches) but there is no say in what precise order the core
will "probe" them and instanciate the various modules. The solution I
found for that is to have the drivers for emac to use multithread_probe,
and wait for a driver to be bound to the target MAL and PHY control
devices (the device-tree contains reference to the MAL and PHY interface
nodes, which I can then match to of_platform_devices). Right now, I've
been polling, but with that notifier, I can more cleanly wait (with a
timeout of course).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-25 13:44:59 +10:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-03-21 11:49:14 -08:00
|
|
|
|
2005-09-06 16:56:51 -07:00
|
|
|
|
2006-09-18 16:24:28 -04:00
|
|
|
|
2006-09-22 11:37:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-22 11:37:04 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Driver core: add notification of bus events
I finally did as you suggested and added the notifier to the struct
bus_type itself. There are still problems to be expected is something
attaches to a bus type where the code can hook in different struct
device sub-classes (which is imho a big bogosity but I won't even try to
argue that case now) but it will solve nicely a number of issues I've
had so far.
That also means that clients interested in registering for such
notifications have to do it before devices are added and after bus types
are registered. Fortunately, most bus types that matter for the various
usage scenarios I have in mind are registerd at postcore_initcall time,
which means I have a really nice spot at arch_initcall time to add my
notifiers.
There are 4 notifications provided. Device being added (before hooked to
the bus) and removed (failure of previous case or after being unhooked
from the bus), along with driver being bound to a device and about to be
unbound.
The usage I have for these are:
- The 2 first ones are used to maintain a struct device_ext that is
hooked to struct device.firmware_data. This structure contains for now a
pointer to the Open Firmware node related to the device (if any), the
NUMA node ID (for quick access to it) and the DMA operations pointers &
iommu table instance for DMA to/from this device. For bus types I own
(like IBM VIO or EBUS), I just maintain that structure directly from the
bus code when creating the devices. But for bus types managed by generic
code like PCI or platform (actually, of_platform which is a variation of
platform linked to Open Firmware device-tree), I need this notifier.
- The other two ones have a completely different usage scenario. I have
cases where multiple devices and their drivers depend on each other. For
example, the IBM EMAC network driver needs to attach to a MAL DMA engine
which is a separate device, and a PHY interface which is also a separate
device. They are all of_platform_device's (well, about to be with my
upcoming patches) but there is no say in what precise order the core
will "probe" them and instanciate the various modules. The solution I
found for that is to have the drivers for emac to use multithread_probe,
and wait for a driver to be bound to the target MAL and PHY control
devices (the device-tree contains reference to the MAL and PHY interface
nodes, which I can then match to of_platform_devices). Right now, I've
been polling, but with that notifier, I can more cleanly wait (with a
timeout of course).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-25 13:44:59 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-22 16:59:51 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|