linux.git/drivers/base/dd.c, branch v2.6.19

[PATCH] drivers: wait for threaded probes between initcall levels

2006-10-27T22:34:51+00:00

The multithreaded-probing code has a problem: after one initcall level (eg,
core_initcall) has been processed, we will then start processing the next
level (postcore_initcall) while the kernel threads which are handling
core_initcall are still executing.  This breaks the guarantees which the
layered initcalls previously gave us.

IOW, we want to be multithreaded _within_ an initcall level, but not between
different levels.

Fix that up by causing the probing code to wait for all outstanding probes at
one level to complete before we start processing the next level.

Cc: Greg KH 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

driver core: kmalloc() failure check in driver_probe_device

2006-10-18T19:49:56+00:00

driver_probe_device() is missing kmalloc() failure check.

Signed-off-by: Akinobu Mita 
Signed-off-by: Greg Kroah-Hartman

Driver core: plug device probe memory leak

2006-10-18T19:49:54+00:00

Make sure data is freed if the kthread fails to start.

Signed-off-by: Duncan Sands 
Signed-off-by: Greg Kroah-Hartman

Driver core: Fix potential deadlock in driver core

2006-09-26T04:08:40+00:00

There is a potential deadlock in the driver core.  It boils down to
the fact that bus_remove_device() calls klist_remove() instead of
klist_del(), thereby waiting until the reference count of the
klist_node in the bus's klist of devices drops to 0.  The refcount
can't reach 0 so long as a modprobe process is trying to bind a new
driver to the device being removed, by calling __driver_attach().  The
problem is that __driver_attach() tries to acquire the device's
parent's semaphore, but the caller of bus_remove_device() is quite
likely to own that semaphore already.

It isn't sufficient just to replace klist_remove() with klist_del().
Doing so runs the risk that the device would remain on the bus's klist
of devices for some time, and so could be bound to another driver even
after it was unregistered.  What's needed is a new way to distinguish
whether or not a device is registered, based on a criterion other than
whether its klist_node is linked into the bus's klist of devices.  That
way driver binding can fail when the device is unregistered, even if
it is still linked into the klist.

This patch (as782) implements the solution, by adding a new bitflag to
indiate when a struct device is registered, by testing the flag before
allowing a driver to bind a device, and by changing the definition of
the device_is_registered() inline.

Signed-off-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

Driver Core: add ability for drivers to do a threaded probe

2006-09-26T04:08:40+00:00

This adds the infrastructure for drivers to do a threaded probe, and
waits at init time for all currently outstanding probes to complete.

A new kernel thread will be created when the probe() function for the
driver is called, if the multithread_probe bit is set in the driver
saying it can support this kind of operation.

I have tested this with USB and PCI, and it works, and shaves off a lot
of time in the boot process, but there are issues with finding root boot
disks, and some USB drivers assume that this can never happen, so it is
currently not enabled for any bus type.  Individual drivers can enable
this right now if they wish, and bus authors can selectivly turn it on
as well, once they determine that their subsystem will work properly
with it.

Signed-off-by: Greg Kroah-Hartman

drivers/base: check errors

2006-09-26T04:08:39+00:00

Add lots of return-value checking.

: fix bus_rescan_devices()]
Cc: "Randy.Dunlap" 
Signed-off-by: Cornelia Huck 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

[PATCH] driver core: safely unbind drivers for devices not on a bus

2006-04-14T18:41:24+00:00

This patch (as667) changes the __device_release_driver() routine to
prevent it from crashing when it runs across a device not on any bus.
This seems logical, inasmuch as the corresponding bus_add_device()
routine has an explicit check allowing it to accept such devices.

Signed-off-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

[PATCH] Add bus_type probe, remove, shutdown methods.

2006-01-13T19:26:04+00:00

Add bus_type probe, remove and shutdown methods to replace the
corresponding methods in struct device_driver.  This matches
the way we handle the suspend/resume methods.

Since the bus methods override the device_driver methods, warn
if a device driver is registered whose methods will not be
called.

The long-term idea is to remove the device_driver methods entirely.

Signed-off-by: Russell King 
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