2005-03-21 18:52:54 +00:00
|
|
|
/*
|
2008-01-25 06:50:12 +00:00
|
|
|
* drivers/base/dd.c - The core device/driver interactions.
|
2005-03-21 18:52:54 +00:00
|
|
|
*
|
2008-01-25 06:50:12 +00:00
|
|
|
* This file contains the (sometimes tricky) code that controls the
|
|
|
|
* interactions between devices and drivers, which primarily includes
|
|
|
|
* driver binding and unbinding.
|
2005-03-21 18:52:54 +00:00
|
|
|
*
|
2008-01-25 06:50:12 +00:00
|
|
|
* All of this code used to exist in drivers/base/bus.c, but was
|
|
|
|
* relocated to here in the name of compartmentalization (since it wasn't
|
|
|
|
* strictly code just for the 'struct bus_type'.
|
2005-03-21 18:52:54 +00:00
|
|
|
*
|
2008-01-25 06:50:12 +00:00
|
|
|
* Copyright (c) 2002-5 Patrick Mochel
|
|
|
|
* Copyright (c) 2002-3 Open Source Development Labs
|
2009-05-11 21:16:57 +00:00
|
|
|
* Copyright (c) 2007-2009 Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
* Copyright (c) 2007-2009 Novell Inc.
|
2005-03-21 18:52:54 +00:00
|
|
|
*
|
2008-01-25 06:50:12 +00:00
|
|
|
* This file is released under the GPLv2
|
2005-03-21 18:52:54 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/device.h>
|
2009-02-14 00:59:06 +00:00
|
|
|
#include <linux/delay.h>
|
2005-03-21 18:52:54 +00:00
|
|
|
#include <linux/module.h>
|
2006-07-18 17:59:59 +00:00
|
|
|
#include <linux/kthread.h>
|
2006-10-27 18:42:37 +00:00
|
|
|
#include <linux/wait.h>
|
2009-02-14 00:59:06 +00:00
|
|
|
#include <linux/async.h>
|
2009-08-18 21:38:32 +00:00
|
|
|
#include <linux/pm_runtime.h>
|
2005-03-21 18:52:54 +00:00
|
|
|
|
|
|
|
#include "base.h"
|
|
|
|
#include "power/power.h"
|
|
|
|
|
|
|
|
|
2006-10-07 19:55:55 +00:00
|
|
|
static void driver_bound(struct device *dev)
|
2005-03-21 18:52:54 +00:00
|
|
|
{
|
2008-12-16 20:25:49 +00:00
|
|
|
if (klist_node_attached(&dev->p->knode_driver)) {
|
2006-08-15 05:43:20 +00:00
|
|
|
printk(KERN_WARNING "%s: device %s already bound\n",
|
2008-03-05 00:41:05 +00:00
|
|
|
__func__, kobject_name(&dev->kobj));
|
2006-10-07 19:55:55 +00:00
|
|
|
return;
|
2006-08-15 05:43:20 +00:00
|
|
|
}
|
2005-09-22 07:47:11 +00:00
|
|
|
|
2008-10-30 00:36:48 +00:00
|
|
|
pr_debug("driver: '%s': %s: bound to device '%s'\n", dev_name(dev),
|
2008-03-05 00:41:05 +00:00
|
|
|
__func__, dev->driver->name);
|
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 03:44:59 +00:00
|
|
|
|
2010-03-06 16:50:14 +00:00
|
|
|
klist_add_tail(&dev->p->knode_driver, &dev->driver->p->klist_devices);
|
|
|
|
|
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 03:44:59 +00:00
|
|
|
if (dev->bus)
|
2007-11-02 02:41:16 +00:00
|
|
|
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
|
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 03:44:59 +00:00
|
|
|
BUS_NOTIFY_BOUND_DRIVER, dev);
|
2006-10-07 19:55:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int driver_sysfs_add(struct device *dev)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2010-07-23 10:56:18 +00:00
|
|
|
if (dev->bus)
|
|
|
|
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
|
|
|
|
BUS_NOTIFY_BIND_DRIVER, dev);
|
|
|
|
|
2007-11-28 23:59:15 +00:00
|
|
|
ret = sysfs_create_link(&dev->driver->p->kobj, &dev->kobj,
|
2005-03-21 18:52:54 +00:00
|
|
|
kobject_name(&dev->kobj));
|
2006-08-15 05:43:20 +00:00
|
|
|
if (ret == 0) {
|
2007-11-28 23:59:15 +00:00
|
|
|
ret = sysfs_create_link(&dev->kobj, &dev->driver->p->kobj,
|
2006-08-15 05:43:20 +00:00
|
|
|
"driver");
|
|
|
|
if (ret)
|
2007-11-28 23:59:15 +00:00
|
|
|
sysfs_remove_link(&dev->driver->p->kobj,
|
2006-08-15 05:43:20 +00:00
|
|
|
kobject_name(&dev->kobj));
|
|
|
|
}
|
|
|
|
return ret;
|
2005-03-21 18:52:54 +00:00
|
|
|
}
|
|
|
|
|
2006-10-07 19:55:55 +00:00
|
|
|
static void driver_sysfs_remove(struct device *dev)
|
|
|
|
{
|
|
|
|
struct device_driver *drv = dev->driver;
|
|
|
|
|
|
|
|
if (drv) {
|
2007-11-28 23:59:15 +00:00
|
|
|
sysfs_remove_link(&drv->p->kobj, kobject_name(&dev->kobj));
|
2006-10-07 19:55:55 +00:00
|
|
|
sysfs_remove_link(&dev->kobj, "driver");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2008-01-25 06:50:12 +00:00
|
|
|
* device_bind_driver - bind a driver to one device.
|
|
|
|
* @dev: device.
|
2006-10-07 19:55:55 +00:00
|
|
|
*
|
2008-01-25 06:50:12 +00:00
|
|
|
* Allow manual attachment of a driver to a device.
|
|
|
|
* Caller must have already set @dev->driver.
|
2006-10-07 19:55:55 +00:00
|
|
|
*
|
2008-01-25 06:50:12 +00:00
|
|
|
* Note that this does not modify the bus reference count
|
|
|
|
* nor take the bus's rwsem. Please verify those are accounted
|
|
|
|
* for before calling this. (It is ok to call with no other effort
|
|
|
|
* from a driver's probe() method.)
|
2006-10-07 19:55:55 +00:00
|
|
|
*
|
2010-02-17 18:57:05 +00:00
|
|
|
* This function must be called with the device lock held.
|
2006-10-07 19:55:55 +00:00
|
|
|
*/
|
|
|
|
int device_bind_driver(struct device *dev)
|
|
|
|
{
|
2006-11-27 09:35:12 +00:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = driver_sysfs_add(dev);
|
|
|
|
if (!ret)
|
|
|
|
driver_bound(dev);
|
|
|
|
return ret;
|
2006-10-07 19:55:55 +00:00
|
|
|
}
|
2008-01-25 06:50:12 +00:00
|
|
|
EXPORT_SYMBOL_GPL(device_bind_driver);
|
2006-10-07 19:55:55 +00:00
|
|
|
|
2006-07-18 17:59:59 +00:00
|
|
|
static atomic_t probe_count = ATOMIC_INIT(0);
|
2006-10-27 18:42:37 +00:00
|
|
|
static DECLARE_WAIT_QUEUE_HEAD(probe_waitqueue);
|
|
|
|
|
2007-02-06 00:15:25 +00:00
|
|
|
static int really_probe(struct device *dev, struct device_driver *drv)
|
2005-03-21 18:52:54 +00:00
|
|
|
{
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 06:46:33 +00:00
|
|
|
int ret = 0;
|
2005-03-21 18:52:54 +00:00
|
|
|
|
2006-07-18 17:59:59 +00:00
|
|
|
atomic_inc(&probe_count);
|
2007-11-29 07:49:41 +00:00
|
|
|
pr_debug("bus: '%s': %s: probing driver %s with device %s\n",
|
2008-10-30 00:36:48 +00:00
|
|
|
drv->bus->name, __func__, drv->name, dev_name(dev));
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
WARN_ON(!list_empty(&dev->devres_head));
|
2005-03-21 18:52:54 +00:00
|
|
|
|
|
|
|
dev->driver = drv;
|
2006-10-07 19:55:55 +00:00
|
|
|
if (driver_sysfs_add(dev)) {
|
|
|
|
printk(KERN_ERR "%s: driver_sysfs_add(%s) failed\n",
|
2008-10-30 00:36:48 +00:00
|
|
|
__func__, dev_name(dev));
|
2006-10-07 19:55:55 +00:00
|
|
|
goto probe_failed;
|
|
|
|
}
|
|
|
|
|
2006-01-05 14:29:51 +00:00
|
|
|
if (dev->bus->probe) {
|
|
|
|
ret = dev->bus->probe(dev);
|
2006-10-07 19:55:55 +00:00
|
|
|
if (ret)
|
2006-07-18 17:59:59 +00:00
|
|
|
goto probe_failed;
|
2006-01-05 14:29:51 +00:00
|
|
|
} else if (drv->probe) {
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 06:46:33 +00:00
|
|
|
ret = drv->probe(dev);
|
2006-10-07 19:55:55 +00:00
|
|
|
if (ret)
|
2006-07-18 17:59:59 +00:00
|
|
|
goto probe_failed;
|
2006-08-15 05:43:20 +00:00
|
|
|
}
|
2006-10-07 19:55:55 +00:00
|
|
|
|
|
|
|
driver_bound(dev);
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 06:46:33 +00:00
|
|
|
ret = 1;
|
2007-11-29 07:49:41 +00:00
|
|
|
pr_debug("bus: '%s': %s: bound device %s to driver %s\n",
|
2008-10-30 00:36:48 +00:00
|
|
|
drv->bus->name, __func__, dev_name(dev), drv->name);
|
2006-07-18 17:59:59 +00:00
|
|
|
goto done;
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 06:46:33 +00:00
|
|
|
|
2006-07-18 17:59:59 +00:00
|
|
|
probe_failed:
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
devres_release_all(dev);
|
2006-10-07 19:55:55 +00:00
|
|
|
driver_sysfs_remove(dev);
|
|
|
|
dev->driver = NULL;
|
|
|
|
|
2006-11-27 09:35:10 +00:00
|
|
|
if (ret != -ENODEV && ret != -ENXIO) {
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 06:46:33 +00:00
|
|
|
/* driver matched but the probe failed */
|
|
|
|
printk(KERN_WARNING
|
|
|
|
"%s: probe of %s failed with error %d\n",
|
2008-10-30 00:36:48 +00:00
|
|
|
drv->name, dev_name(dev), ret);
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 06:46:33 +00:00
|
|
|
}
|
2006-11-27 09:35:10 +00:00
|
|
|
/*
|
|
|
|
* Ignore errors returned by ->probe so that the next driver can try
|
|
|
|
* its luck.
|
|
|
|
*/
|
|
|
|
ret = 0;
|
2006-07-18 17:59:59 +00:00
|
|
|
done:
|
|
|
|
atomic_dec(&probe_count);
|
2006-10-27 18:42:37 +00:00
|
|
|
wake_up(&probe_waitqueue);
|
2006-07-18 17:59:59 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* driver_probe_done
|
|
|
|
* Determine if the probe sequence is finished or not.
|
|
|
|
*
|
|
|
|
* Should somehow figure out how to use a semaphore, not an atomic variable...
|
|
|
|
*/
|
|
|
|
int driver_probe_done(void)
|
|
|
|
{
|
2008-03-05 00:41:05 +00:00
|
|
|
pr_debug("%s: probe_count = %d\n", __func__,
|
2006-07-18 17:59:59 +00:00
|
|
|
atomic_read(&probe_count));
|
|
|
|
if (atomic_read(&probe_count))
|
|
|
|
return -EBUSY;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-02-14 00:59:06 +00:00
|
|
|
/**
|
|
|
|
* wait_for_device_probe
|
|
|
|
* Wait for device probing to be completed.
|
|
|
|
*/
|
2009-02-21 08:45:07 +00:00
|
|
|
void wait_for_device_probe(void)
|
2009-02-14 00:59:06 +00:00
|
|
|
{
|
|
|
|
/* wait for the known devices to complete their probing */
|
2009-02-21 08:45:07 +00:00
|
|
|
wait_event(probe_waitqueue, atomic_read(&probe_count) == 0);
|
2009-02-14 00:59:06 +00:00
|
|
|
async_synchronize_full();
|
|
|
|
}
|
2009-04-21 20:32:54 +00:00
|
|
|
EXPORT_SYMBOL_GPL(wait_for_device_probe);
|
2009-02-14 00:59:06 +00:00
|
|
|
|
2006-07-18 17:59:59 +00:00
|
|
|
/**
|
|
|
|
* driver_probe_device - attempt to bind device & driver together
|
|
|
|
* @drv: driver to bind a device to
|
|
|
|
* @dev: device to try to bind to the driver
|
|
|
|
*
|
2009-01-21 15:27:47 +00:00
|
|
|
* This function returns -ENODEV if the device is not registered,
|
tree-wide: fix assorted typos all over the place
That is "success", "unknown", "through", "performance", "[re|un]mapping"
, "access", "default", "reasonable", "[con]currently", "temperature"
, "channel", "[un]used", "application", "example","hierarchy", "therefore"
, "[over|under]flow", "contiguous", "threshold", "enough" and others.
Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-11-14 15:09:05 +00:00
|
|
|
* 1 if the device is bound successfully and 0 otherwise.
|
2006-07-18 17:59:59 +00:00
|
|
|
*
|
2010-02-17 18:57:05 +00:00
|
|
|
* This function must be called with @dev lock held. When called for a
|
|
|
|
* USB interface, @dev->parent lock must be held as well.
|
2006-07-18 17:59:59 +00:00
|
|
|
*/
|
2008-01-25 06:50:12 +00:00
|
|
|
int driver_probe_device(struct device_driver *drv, struct device *dev)
|
2006-07-18 17:59:59 +00:00
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
2006-09-18 20:22:34 +00:00
|
|
|
if (!device_is_registered(dev))
|
|
|
|
return -ENODEV;
|
2006-07-18 17:59:59 +00:00
|
|
|
|
2007-11-29 07:49:41 +00:00
|
|
|
pr_debug("bus: '%s': %s: matched device %s with driver %s\n",
|
2008-10-30 00:36:48 +00:00
|
|
|
drv->bus->name, __func__, dev_name(dev), drv->name);
|
2006-07-18 17:59:59 +00:00
|
|
|
|
2009-08-18 21:38:32 +00:00
|
|
|
pm_runtime_get_noresume(dev);
|
|
|
|
pm_runtime_barrier(dev);
|
2007-02-06 00:15:25 +00:00
|
|
|
ret = really_probe(dev, drv);
|
2009-08-18 21:38:32 +00:00
|
|
|
pm_runtime_put_sync(dev);
|
2006-07-18 17:59:59 +00:00
|
|
|
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 06:46:33 +00:00
|
|
|
return ret;
|
2005-03-21 18:52:54 +00:00
|
|
|
}
|
|
|
|
|
2008-01-25 06:50:12 +00:00
|
|
|
static int __device_attach(struct device_driver *drv, void *data)
|
2005-03-24 18:50:24 +00:00
|
|
|
{
|
2008-01-25 06:50:12 +00:00
|
|
|
struct device *dev = data;
|
2009-01-21 15:27:47 +00:00
|
|
|
|
|
|
|
if (!driver_match_device(drv, dev))
|
|
|
|
return 0;
|
|
|
|
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 06:46:33 +00:00
|
|
|
return driver_probe_device(drv, dev);
|
2005-03-24 18:50:24 +00:00
|
|
|
}
|
|
|
|
|
2005-03-21 18:52:54 +00:00
|
|
|
/**
|
2008-01-25 06:50:12 +00:00
|
|
|
* device_attach - try to attach device to a driver.
|
|
|
|
* @dev: device.
|
2005-03-21 18:52:54 +00:00
|
|
|
*
|
2008-01-25 06:50:12 +00:00
|
|
|
* Walk the list of drivers that the bus has and call
|
|
|
|
* driver_probe_device() for each pair. If a compatible
|
|
|
|
* pair is found, break out and return.
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 06:46:33 +00:00
|
|
|
*
|
2008-01-25 06:50:12 +00:00
|
|
|
* Returns 1 if the device was bound to a driver;
|
2009-05-06 03:38:28 +00:00
|
|
|
* 0 if no matching driver was found;
|
2008-01-25 06:50:12 +00:00
|
|
|
* -ENODEV if the device is not registered.
|
[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 21:54:12 +00:00
|
|
|
*
|
2010-02-17 18:57:05 +00:00
|
|
|
* When called for a USB interface, @dev->parent lock must be held.
|
2005-03-21 18:52:54 +00:00
|
|
|
*/
|
2008-01-25 06:50:12 +00:00
|
|
|
int device_attach(struct device *dev)
|
2005-03-21 18:52:54 +00:00
|
|
|
{
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 06:46:33 +00:00
|
|
|
int ret = 0;
|
|
|
|
|
2010-02-17 18:57:05 +00:00
|
|
|
device_lock(dev);
|
2005-03-21 18:52:54 +00:00
|
|
|
if (dev->driver) {
|
2011-04-12 17:05:37 +00:00
|
|
|
if (klist_node_attached(&dev->p->knode_driver)) {
|
|
|
|
ret = 1;
|
|
|
|
goto out_unlock;
|
|
|
|
}
|
2006-08-15 05:43:20 +00:00
|
|
|
ret = device_bind_driver(dev);
|
|
|
|
if (ret == 0)
|
|
|
|
ret = 1;
|
2007-02-06 00:15:26 +00:00
|
|
|
else {
|
|
|
|
dev->driver = NULL;
|
|
|
|
ret = 0;
|
|
|
|
}
|
2007-02-06 00:15:25 +00:00
|
|
|
} else {
|
2009-08-18 21:38:32 +00:00
|
|
|
pm_runtime_get_noresume(dev);
|
2007-03-27 01:02:51 +00:00
|
|
|
ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
|
2009-08-18 21:38:32 +00:00
|
|
|
pm_runtime_put_sync(dev);
|
2007-02-06 00:15:25 +00:00
|
|
|
}
|
2011-04-12 17:05:37 +00:00
|
|
|
out_unlock:
|
2010-02-17 18:57:05 +00:00
|
|
|
device_unlock(dev);
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 06:46:33 +00:00
|
|
|
return ret;
|
2005-03-24 18:50:24 +00:00
|
|
|
}
|
2008-01-25 06:50:12 +00:00
|
|
|
EXPORT_SYMBOL_GPL(device_attach);
|
2005-03-24 18:50:24 +00:00
|
|
|
|
2008-01-25 06:50:12 +00:00
|
|
|
static int __driver_attach(struct device *dev, void *data)
|
2005-03-24 18:50:24 +00:00
|
|
|
{
|
2008-01-25 06:50:12 +00:00
|
|
|
struct device_driver *drv = data;
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 06:46:33 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Lock device and try to bind to it. We drop the error
|
|
|
|
* here and always return 0, because we need to keep trying
|
|
|
|
* to bind to devices and some drivers will return an error
|
|
|
|
* simply if it didn't support the device.
|
|
|
|
*
|
|
|
|
* driver_probe_device() will spit a warning if there
|
|
|
|
* is an error.
|
|
|
|
*/
|
|
|
|
|
2009-01-21 15:27:47 +00:00
|
|
|
if (!driver_match_device(drv, dev))
|
2008-09-14 15:32:06 +00:00
|
|
|
return 0;
|
|
|
|
|
[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 21:54:12 +00:00
|
|
|
if (dev->parent) /* Needed for USB */
|
2010-02-17 18:57:05 +00:00
|
|
|
device_lock(dev->parent);
|
|
|
|
device_lock(dev);
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 06:46:33 +00:00
|
|
|
if (!dev->driver)
|
|
|
|
driver_probe_device(drv, dev);
|
2010-02-17 18:57:05 +00:00
|
|
|
device_unlock(dev);
|
[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 21:54:12 +00:00
|
|
|
if (dev->parent)
|
2010-02-17 18:57:05 +00:00
|
|
|
device_unlock(dev->parent);
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 06:46:33 +00:00
|
|
|
|
2005-03-21 18:52:54 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2008-01-25 06:50:12 +00:00
|
|
|
* driver_attach - try to bind driver to devices.
|
|
|
|
* @drv: driver.
|
2005-03-21 18:52:54 +00:00
|
|
|
*
|
2008-01-25 06:50:12 +00:00
|
|
|
* Walk the list of devices that the bus has on it and try to
|
|
|
|
* match the driver with each one. If driver_probe_device()
|
|
|
|
* returns 0 and the @dev->driver is set, we've found a
|
|
|
|
* compatible pair.
|
2005-03-21 18:52:54 +00:00
|
|
|
*/
|
2008-01-25 06:50:12 +00:00
|
|
|
int driver_attach(struct device_driver *drv)
|
2005-03-21 18:52:54 +00:00
|
|
|
{
|
2006-08-15 05:43:20 +00:00
|
|
|
return bus_for_each_dev(drv->bus, NULL, drv, __driver_attach);
|
2005-03-21 18:52:54 +00:00
|
|
|
}
|
2008-01-25 06:50:12 +00:00
|
|
|
EXPORT_SYMBOL_GPL(driver_attach);
|
2005-03-21 18:52:54 +00:00
|
|
|
|
2007-06-17 09:02:12 +00:00
|
|
|
/*
|
2010-02-17 18:57:05 +00:00
|
|
|
* __device_release_driver() must be called with @dev lock held.
|
|
|
|
* When called for a USB interface, @dev->parent lock must be held as well.
|
2005-03-21 18:52:54 +00:00
|
|
|
*/
|
2008-01-25 06:50:12 +00:00
|
|
|
static void __device_release_driver(struct device *dev)
|
2005-03-21 18:52:54 +00:00
|
|
|
{
|
2008-01-25 06:50:12 +00:00
|
|
|
struct device_driver *drv;
|
2005-03-21 18:52:54 +00:00
|
|
|
|
2007-11-16 16:57:28 +00:00
|
|
|
drv = dev->driver;
|
2005-05-06 19:38:33 +00:00
|
|
|
if (drv) {
|
2009-08-18 21:38:32 +00:00
|
|
|
pm_runtime_get_noresume(dev);
|
|
|
|
pm_runtime_barrier(dev);
|
|
|
|
|
2006-10-07 19:55:55 +00:00
|
|
|
driver_sysfs_remove(dev);
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 06:46:33 +00: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 03:44:59 +00:00
|
|
|
if (dev->bus)
|
2007-11-02 02:41:16 +00:00
|
|
|
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
|
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 03:44:59 +00:00
|
|
|
BUS_NOTIFY_UNBIND_DRIVER,
|
|
|
|
dev);
|
|
|
|
|
2006-03-31 16:52:25 +00:00
|
|
|
if (dev->bus && dev->bus->remove)
|
2006-01-05 14:29:51 +00:00
|
|
|
dev->bus->remove(dev);
|
|
|
|
else if (drv->remove)
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 06:46:33 +00:00
|
|
|
drv->remove(dev);
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
devres_release_all(dev);
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 06:46:33 +00:00
|
|
|
dev->driver = NULL;
|
2008-12-16 20:25:49 +00:00
|
|
|
klist_remove(&dev->p->knode_driver);
|
2009-04-24 12:57:00 +00:00
|
|
|
if (dev->bus)
|
|
|
|
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
|
|
|
|
BUS_NOTIFY_UNBOUND_DRIVER,
|
|
|
|
dev);
|
2009-08-18 21:38:32 +00:00
|
|
|
|
|
|
|
pm_runtime_put_sync(dev);
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 06:46:33 +00:00
|
|
|
}
|
2005-03-21 18:52:54 +00:00
|
|
|
}
|
|
|
|
|
2007-06-17 09:02:12 +00:00
|
|
|
/**
|
2008-01-25 06:50:12 +00:00
|
|
|
* device_release_driver - manually detach device from driver.
|
|
|
|
* @dev: device.
|
2007-06-17 09:02:12 +00:00
|
|
|
*
|
2008-01-25 06:50:12 +00:00
|
|
|
* Manually detach device from driver.
|
2010-02-17 18:57:05 +00:00
|
|
|
* When called for a USB interface, @dev->parent lock must be held.
|
2007-06-17 09:02:12 +00:00
|
|
|
*/
|
2008-01-25 06:50:12 +00:00
|
|
|
void device_release_driver(struct device *dev)
|
2005-03-21 20:25:36 +00:00
|
|
|
{
|
2005-05-06 19:38:33 +00:00
|
|
|
/*
|
|
|
|
* If anyone calls device_release_driver() recursively from
|
|
|
|
* within their ->remove callback for the same device, they
|
|
|
|
* will deadlock right here.
|
|
|
|
*/
|
2010-02-17 18:57:05 +00:00
|
|
|
device_lock(dev);
|
2005-05-06 19:38:33 +00:00
|
|
|
__device_release_driver(dev);
|
2010-02-17 18:57:05 +00:00
|
|
|
device_unlock(dev);
|
2005-03-21 20:25:36 +00:00
|
|
|
}
|
2008-01-25 06:50:12 +00:00
|
|
|
EXPORT_SYMBOL_GPL(device_release_driver);
|
2005-05-06 19:38:33 +00:00
|
|
|
|
2005-03-21 18:52:54 +00:00
|
|
|
/**
|
|
|
|
* driver_detach - detach driver from all devices it controls.
|
|
|
|
* @drv: driver.
|
|
|
|
*/
|
2008-01-25 06:50:12 +00:00
|
|
|
void driver_detach(struct device_driver *drv)
|
2005-03-21 18:52:54 +00:00
|
|
|
{
|
2008-12-16 20:25:49 +00:00
|
|
|
struct device_private *dev_prv;
|
2008-01-25 06:50:12 +00:00
|
|
|
struct device *dev;
|
2005-05-06 19:38:33 +00:00
|
|
|
|
|
|
|
for (;;) {
|
2007-11-28 23:59:15 +00:00
|
|
|
spin_lock(&drv->p->klist_devices.k_lock);
|
|
|
|
if (list_empty(&drv->p->klist_devices.k_list)) {
|
|
|
|
spin_unlock(&drv->p->klist_devices.k_lock);
|
2005-05-06 19:38:33 +00:00
|
|
|
break;
|
|
|
|
}
|
2008-12-16 20:25:49 +00:00
|
|
|
dev_prv = list_entry(drv->p->klist_devices.k_list.prev,
|
|
|
|
struct device_private,
|
|
|
|
knode_driver.n_node);
|
|
|
|
dev = dev_prv->device;
|
2005-05-06 19:38:33 +00:00
|
|
|
get_device(dev);
|
2007-11-28 23:59:15 +00:00
|
|
|
spin_unlock(&drv->p->klist_devices.k_lock);
|
2005-05-06 19:38:33 +00: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 21:54:12 +00:00
|
|
|
if (dev->parent) /* Needed for USB */
|
2010-02-17 18:57:05 +00:00
|
|
|
device_lock(dev->parent);
|
|
|
|
device_lock(dev);
|
2005-05-06 19:38:33 +00:00
|
|
|
if (dev->driver == drv)
|
|
|
|
__device_release_driver(dev);
|
2010-02-17 18:57:05 +00:00
|
|
|
device_unlock(dev);
|
[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 21:54:12 +00:00
|
|
|
if (dev->parent)
|
2010-02-17 18:57:05 +00:00
|
|
|
device_unlock(dev->parent);
|
2005-05-06 19:38:33 +00:00
|
|
|
put_device(dev);
|
|
|
|
}
|
2005-03-21 18:52:54 +00:00
|
|
|
}
|
2009-05-11 21:16:57 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* These exports can't be _GPL due to .h files using this within them, and it
|
|
|
|
* might break something that was previously working...
|
|
|
|
*/
|
|
|
|
void *dev_get_drvdata(const struct device *dev)
|
|
|
|
{
|
|
|
|
if (dev && dev->p)
|
|
|
|
return dev->p->driver_data;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(dev_get_drvdata);
|
|
|
|
|
|
|
|
void dev_set_drvdata(struct device *dev, void *data)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
|
|
|
if (!dev)
|
|
|
|
return;
|
|
|
|
if (!dev->p) {
|
|
|
|
error = device_private_init(dev);
|
|
|
|
if (error)
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
dev->p->driver_data = data;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(dev_set_drvdata);
|