linux.git/drivers/base/bus.c, branch v2.6.17

[PATCH] driver core: driver_bind attribute returns incorrect value

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

The manual driver <-> device binding attribute in sysfs doesn't return
the correct value on failure or success of driver_probe_device.
driver_probe_device returns 1 on success (the driver accepted the
device) or 0 on probe failure (when the driver didn't accept the
device but no real error occured). However, the attribute can't just
return 0 or 1, it must return the number of bytes consumed from buf
or an error value. Returning 0 indicates to userspace that nothing
was written (even though the kernel has tried to do the bind/probe and
failed). Returning 1 indicates that only one character was accepted in
which case userspace will re-try the write with a partial string.

A more correct version of driver_bind would return count (to indicate
the entire string was consumed) when driver_probe_device returns 1
and -ENODEV when driver_probe_device returns 0. This patch makes that
change.

Signed-off-by: Ryan Wilson 
Signed-off-by: Greg Kroah-Hartman

[SCSI] drivers/base/bus.c - export reprobe

2006-03-14T18:50:44+00:00

Adding support for exposing hidden raid components for sg
interface. The sdev->no_uld_attach flag will set set accordingly.

The sas module supports adding/removing raid volumes using online
storage management application interface.

This patch was provided to me by Christoph Hellwig.

Signed-off-by: Eric Moore 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: James Bottomley

[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

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 
Signed-off-by: Linus Torvalds