2017-11-07 16:30:07 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
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
|
|
|
*/
|
|
|
|
|
2018-07-08 13:34:59 +00:00
|
|
|
#include <linux/debugfs.h>
|
2005-03-21 18:52:54 +00:00
|
|
|
#include <linux/device.h>
|
2009-02-14 00:59:06 +00:00
|
|
|
#include <linux/delay.h>
|
2020-09-22 13:31:03 +00:00
|
|
|
#include <linux/dma-map-ops.h>
|
2017-07-25 23:31:59 +00:00
|
|
|
#include <linux/init.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>
|
drivers/pinctrl: grab default handles from device core
This makes the device core auto-grab the pinctrl handle and set
the "default" (PINCTRL_STATE_DEFAULT) state for every device
that is present in the device model right before probe. This will
account for the lion's share of embedded silicon devcies.
A modification of the semantics for pinctrl_get() is also done:
previously if the pinctrl handle for a certain device was already
taken, the pinctrl core would return an error. Now, since the
core may have already default-grabbed the handle and set its
state to "default", if the handle was already taken, this will
be disregarded and the located, previously instanitated handle
will be returned to the caller.
This way all code in drivers explicitly requesting their pinctrl
handlers will still be functional, and drivers that want to
explicitly retrieve and switch their handles can still do that.
But if the desired functionality is just boilerplate of this
type in the probe() function:
struct pinctrl *p;
p = devm_pinctrl_get_select_default(&dev);
if (IS_ERR(p)) {
if (PTR_ERR(p) == -EPROBE_DEFER)
return -EPROBE_DEFER;
dev_warn(&dev, "no pinctrl handle\n");
}
The discussion began with the addition of such boilerplate
to the omap4 keypad driver:
http://marc.info/?l=linux-input&m=135091157719300&w=2
A previous approach using notifiers was discussed:
http://marc.info/?l=linux-kernel&m=135263661110528&w=2
This failed because it could not handle deferred probes.
This patch alone does not solve the entire dilemma faced:
whether code should be distributed into the drivers or
if it should be centralized to e.g. a PM domain. But it
solves the immediate issue of the addition of boilerplate
to a lot of drivers that just want to grab the default
state. As mentioned, they can later explicitly retrieve
the handle and set different states, and this could as
well be done by e.g. PM domains as it is only related
to a certain struct device * pointer.
ChangeLog v4->v5 (Stephen):
- Simplified the devicecore grab code.
- Deleted a piece of documentation recommending that pins
be mapped to a device rather than hogged.
ChangeLog v3->v4 (Linus):
- Drop overzealous NULL checks.
- Move kref initialization to pinctrl_create().
- Seeking Tested-by from Stephen Warren so we do not disturb
the Tegra platform.
- Seeking ACK on this from Greg (and others who like it) so I
can merge it through the pinctrl subsystem.
ChangeLog v2->v3 (Linus):
- Abstain from using IS_ERR_OR_NULL() in the driver core,
Russell recently sent a patch to remove it. Handle the
NULL case explicitly even though it's a bogus case.
- Make sure we handle probe deferral correctly in the device
core file. devm_kfree() the container on error so we don't
waste memory for devices without pinctrl handles.
- Introduce reference counting into the pinctrl core using
<linux/kref.h> so that we don't release pinctrl handles
that have been obtained for two or more places.
ChangeLog v1->v2 (Linus):
- Only store a pointer in the device struct, and only allocate
this if it's really used by the device.
Cc: Felipe Balbi <balbi@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Mitch Bradley <wmb@firmworks.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Rickard Andersson <rickard.andersson@stericsson.com>
Cc: Russell King <linux@arm.linux.org.uk>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[swarren: fixed and simplified error-handling in pinctrl_bind_pins(), to
correctly handle deferred probe. Removed admonition from docs not to use
pinctrl hogs for devices]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-01-22 17:56:14 +00:00
|
|
|
#include <linux/pinctrl/devinfo.h>
|
2020-07-13 14:43:22 +00:00
|
|
|
#include <linux/slab.h>
|
2005-03-21 18:52:54 +00:00
|
|
|
|
|
|
|
#include "base.h"
|
|
|
|
#include "power/power.h"
|
|
|
|
|
2012-03-05 15:47:41 +00:00
|
|
|
/*
|
|
|
|
* Deferred Probe infrastructure.
|
|
|
|
*
|
|
|
|
* Sometimes driver probe order matters, but the kernel doesn't always have
|
|
|
|
* dependency information which means some drivers will get probed before a
|
|
|
|
* resource it depends on is available. For example, an SDHCI driver may
|
|
|
|
* first need a GPIO line from an i2c GPIO controller before it can be
|
|
|
|
* initialized. If a required resource is not available yet, a driver can
|
|
|
|
* request probing to be deferred by returning -EPROBE_DEFER from its probe hook
|
|
|
|
*
|
|
|
|
* Deferred probe maintains two lists of devices, a pending list and an active
|
|
|
|
* list. A driver returning -EPROBE_DEFER causes the device to be added to the
|
|
|
|
* pending list. A successful driver probe will trigger moving all devices
|
|
|
|
* from the pending to the active list so that the workqueue will eventually
|
|
|
|
* retry them.
|
|
|
|
*
|
|
|
|
* The deferred_probe_mutex must be held any time the deferred_probe_*_list
|
2012-03-08 20:17:22 +00:00
|
|
|
* of the (struct device*)->p->deferred_probe pointers are manipulated
|
2012-03-05 15:47:41 +00:00
|
|
|
*/
|
|
|
|
static DEFINE_MUTEX(deferred_probe_mutex);
|
|
|
|
static LIST_HEAD(deferred_probe_pending_list);
|
|
|
|
static LIST_HEAD(deferred_probe_active_list);
|
2014-04-29 11:05:22 +00:00
|
|
|
static atomic_t deferred_trigger_count = ATOMIC_INIT(0);
|
2018-07-09 15:41:48 +00:00
|
|
|
static bool initcalls_done;
|
2012-03-05 15:47:41 +00:00
|
|
|
|
2019-02-13 07:47:36 +00:00
|
|
|
/* Save the async probe drivers' name from kernel cmdline */
|
|
|
|
#define ASYNC_DRV_NAMES_MAX_LEN 256
|
|
|
|
static char async_probe_drv_names[ASYNC_DRV_NAMES_MAX_LEN];
|
driver core: Add "*" wildcard support to driver_async_probe cmdline param
There's currently no way to use driver_async_probe kernel cmdline param
to enable default async probe for all drivers. So, add support for "*"
to match with all driver names. When "*" is used, all other drivers
listed in driver_async_probe are drivers that will NOT match the "*".
For example:
* driver_async_probe=drvA,drvB,drvC
drvA, drvB and drvC do asynchronous probing.
* driver_async_probe=*
All drivers do asynchronous probing except those that have set
PROBE_FORCE_SYNCHRONOUS flag.
* driver_async_probe=*,drvA,drvB,drvC
All drivers do asynchronous probing except drvA, drvB, drvC and those
that have set PROBE_FORCE_SYNCHRONOUS flag.
Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Feng Tang <feng.tang@intel.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20220504005344.117803-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-04 00:53:43 +00:00
|
|
|
static bool async_probe_default;
|
2019-02-13 07:47:36 +00:00
|
|
|
|
2015-11-10 09:42:34 +00:00
|
|
|
/*
|
|
|
|
* In some cases, like suspend to RAM or hibernation, It might be reasonable
|
|
|
|
* to prohibit probing of devices as it could be unsafe.
|
|
|
|
* Once defer_all_probes is true all drivers probes will be forcibly deferred.
|
|
|
|
*/
|
|
|
|
static bool defer_all_probes;
|
|
|
|
|
2021-03-23 15:37:13 +00:00
|
|
|
static void __device_set_deferred_probe_reason(const struct device *dev, char *reason)
|
|
|
|
{
|
|
|
|
kfree(dev->p->deferred_probe_reason);
|
|
|
|
dev->p->deferred_probe_reason = reason;
|
|
|
|
}
|
|
|
|
|
2014-08-08 13:56:36 +00:00
|
|
|
/*
|
2012-03-05 15:47:41 +00:00
|
|
|
* deferred_probe_work_func() - Retry probing devices in the active list.
|
|
|
|
*/
|
|
|
|
static void deferred_probe_work_func(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct device *dev;
|
2012-03-08 20:17:22 +00:00
|
|
|
struct device_private *private;
|
2012-03-05 15:47:41 +00:00
|
|
|
/*
|
|
|
|
* This block processes every device in the deferred 'active' list.
|
|
|
|
* Each device is removed from the active list and passed to
|
|
|
|
* bus_probe_device() to re-attempt the probe. The loop continues
|
|
|
|
* until every device in the active list is removed and retried.
|
|
|
|
*
|
|
|
|
* Note: Once the device is removed from the list and the mutex is
|
|
|
|
* released, it is possible for the device get freed by another thread
|
|
|
|
* and cause a illegal pointer dereference. This code uses
|
|
|
|
* get/put_device() to ensure the device structure cannot disappear
|
|
|
|
* from under our feet.
|
|
|
|
*/
|
|
|
|
mutex_lock(&deferred_probe_mutex);
|
|
|
|
while (!list_empty(&deferred_probe_active_list)) {
|
2012-03-08 20:17:22 +00:00
|
|
|
private = list_first_entry(&deferred_probe_active_list,
|
|
|
|
typeof(*dev->p), deferred_probe);
|
|
|
|
dev = private->device;
|
|
|
|
list_del_init(&private->deferred_probe);
|
2012-03-05 15:47:41 +00:00
|
|
|
|
|
|
|
get_device(dev);
|
|
|
|
|
2021-03-23 15:37:13 +00:00
|
|
|
__device_set_deferred_probe_reason(dev, NULL);
|
2021-03-19 11:04:57 +00:00
|
|
|
|
2012-03-08 20:20:37 +00:00
|
|
|
/*
|
|
|
|
* Drop the mutex while probing each device; the probe path may
|
|
|
|
* manipulate the deferred list
|
|
|
|
*/
|
2012-03-05 15:47:41 +00:00
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
2012-07-05 13:04:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Force the device to the end of the dpm_list since
|
|
|
|
* the PM code assumes that the order we add things to
|
|
|
|
* the list is a good order for suspend but deferred
|
|
|
|
* probe makes that very unsafe.
|
|
|
|
*/
|
2018-04-10 23:57:06 +00:00
|
|
|
device_pm_move_to_tail(dev);
|
2012-07-05 13:04:44 +00:00
|
|
|
|
2012-03-05 15:47:41 +00:00
|
|
|
dev_dbg(dev, "Retrying from deferred list\n");
|
2018-06-21 00:35:56 +00:00
|
|
|
bus_probe_device(dev);
|
2012-03-05 15:47:41 +00:00
|
|
|
mutex_lock(&deferred_probe_mutex);
|
|
|
|
|
|
|
|
put_device(dev);
|
|
|
|
}
|
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
|
|
|
}
|
|
|
|
static DECLARE_WORK(deferred_probe_work, deferred_probe_work_func);
|
|
|
|
|
2019-02-01 00:59:42 +00:00
|
|
|
void driver_deferred_probe_add(struct device *dev)
|
2012-03-05 15:47:41 +00:00
|
|
|
{
|
2021-03-02 21:11:30 +00:00
|
|
|
if (!dev->can_match)
|
|
|
|
return;
|
|
|
|
|
2012-03-05 15:47:41 +00:00
|
|
|
mutex_lock(&deferred_probe_mutex);
|
2012-03-08 20:17:22 +00:00
|
|
|
if (list_empty(&dev->p->deferred_probe)) {
|
2012-03-05 15:47:41 +00:00
|
|
|
dev_dbg(dev, "Added to deferred list\n");
|
2012-05-30 01:46:06 +00:00
|
|
|
list_add_tail(&dev->p->deferred_probe, &deferred_probe_pending_list);
|
2012-03-05 15:47:41 +00:00
|
|
|
}
|
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
void driver_deferred_probe_del(struct device *dev)
|
|
|
|
{
|
|
|
|
mutex_lock(&deferred_probe_mutex);
|
2012-03-08 20:17:22 +00:00
|
|
|
if (!list_empty(&dev->p->deferred_probe)) {
|
2012-03-05 15:47:41 +00:00
|
|
|
dev_dbg(dev, "Removed from deferred list\n");
|
2012-03-08 20:17:22 +00:00
|
|
|
list_del_init(&dev->p->deferred_probe);
|
2021-03-23 15:37:13 +00:00
|
|
|
__device_set_deferred_probe_reason(dev, NULL);
|
2012-03-05 15:47:41 +00:00
|
|
|
}
|
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
|
|
|
}
|
|
|
|
|
2022-03-09 13:54:18 +00:00
|
|
|
static bool driver_deferred_probe_enable;
|
2012-03-05 15:47:41 +00:00
|
|
|
/**
|
|
|
|
* driver_deferred_probe_trigger() - Kick off re-probing deferred devices
|
|
|
|
*
|
|
|
|
* This functions moves all devices from the pending list to the active
|
|
|
|
* list and schedules the deferred probe workqueue to process them. It
|
|
|
|
* should be called anytime a driver is successfully bound to a device.
|
2014-04-29 11:05:22 +00:00
|
|
|
*
|
|
|
|
* Note, there is a race condition in multi-threaded probe. In the case where
|
|
|
|
* more than one device is probing at the same time, it is possible for one
|
|
|
|
* probe to complete successfully while another is about to defer. If the second
|
|
|
|
* depends on the first, then it will get put on the pending list after the
|
2015-05-25 18:16:11 +00:00
|
|
|
* trigger event has already occurred and will be stuck there.
|
2014-04-29 11:05:22 +00:00
|
|
|
*
|
|
|
|
* The atomic 'deferred_trigger_count' is used to determine if a successful
|
|
|
|
* trigger has occurred in the midst of probing a driver. If the trigger count
|
|
|
|
* changes in the midst of a probe, then deferred processing should be triggered
|
|
|
|
* again.
|
2012-03-05 15:47:41 +00:00
|
|
|
*/
|
|
|
|
static void driver_deferred_probe_trigger(void)
|
2020-11-21 02:02:18 +00:00
|
|
|
{
|
2020-11-21 02:02:19 +00:00
|
|
|
if (!driver_deferred_probe_enable)
|
|
|
|
return;
|
|
|
|
|
2012-03-08 20:20:37 +00:00
|
|
|
/*
|
|
|
|
* A successful probe means that all the devices in the pending list
|
2012-03-05 15:47:41 +00:00
|
|
|
* should be triggered to be reprobed. Move all the deferred devices
|
2012-03-08 20:20:37 +00:00
|
|
|
* into the active list so they can be retried by the workqueue
|
|
|
|
*/
|
2012-03-05 15:47:41 +00:00
|
|
|
mutex_lock(&deferred_probe_mutex);
|
2014-04-29 11:05:22 +00:00
|
|
|
atomic_inc(&deferred_trigger_count);
|
2012-03-05 15:47:41 +00:00
|
|
|
list_splice_tail_init(&deferred_probe_pending_list,
|
|
|
|
&deferred_probe_active_list);
|
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
|
|
|
|
2012-03-08 20:20:37 +00:00
|
|
|
/*
|
|
|
|
* Kick the re-probe thread. It may already be scheduled, but it is
|
|
|
|
* safe to kick it again.
|
|
|
|
*/
|
2021-03-24 11:01:38 +00:00
|
|
|
queue_work(system_unbound_wq, &deferred_probe_work);
|
2012-03-05 15:47:41 +00:00
|
|
|
}
|
|
|
|
|
2015-11-10 09:42:34 +00:00
|
|
|
/**
|
2018-11-06 07:41:27 +00:00
|
|
|
* device_block_probing() - Block/defer device's probes
|
2015-11-10 09:42:34 +00:00
|
|
|
*
|
|
|
|
* It will disable probing of devices and defer their probes instead.
|
|
|
|
*/
|
|
|
|
void device_block_probing(void)
|
|
|
|
{
|
|
|
|
defer_all_probes = true;
|
|
|
|
/* sync with probes to avoid races. */
|
|
|
|
wait_for_device_probe();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* device_unblock_probing() - Unblock/enable device's probes
|
|
|
|
*
|
|
|
|
* It will restore normal behavior and trigger re-probing of deferred
|
|
|
|
* devices.
|
|
|
|
*/
|
|
|
|
void device_unblock_probing(void)
|
|
|
|
{
|
|
|
|
defer_all_probes = false;
|
|
|
|
driver_deferred_probe_trigger();
|
|
|
|
}
|
|
|
|
|
2020-07-13 14:43:22 +00:00
|
|
|
/**
|
|
|
|
* device_set_deferred_probe_reason() - Set defer probe reason message for device
|
|
|
|
* @dev: the pointer to the struct device
|
|
|
|
* @vaf: the pointer to va_format structure with message
|
|
|
|
*/
|
|
|
|
void device_set_deferred_probe_reason(const struct device *dev, struct va_format *vaf)
|
|
|
|
{
|
|
|
|
const char *drv = dev_driver_string(dev);
|
2021-03-23 15:37:13 +00:00
|
|
|
char *reason;
|
2020-07-13 14:43:22 +00:00
|
|
|
|
|
|
|
mutex_lock(&deferred_probe_mutex);
|
|
|
|
|
2021-03-23 15:37:13 +00:00
|
|
|
reason = kasprintf(GFP_KERNEL, "%s: %pV", drv, vaf);
|
|
|
|
__device_set_deferred_probe_reason(dev, reason);
|
2020-07-13 14:43:22 +00:00
|
|
|
|
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
|
|
|
}
|
|
|
|
|
2018-07-08 13:34:59 +00:00
|
|
|
/*
|
|
|
|
* deferred_devs_show() - Show the devices in the deferred probe pending list.
|
|
|
|
*/
|
|
|
|
static int deferred_devs_show(struct seq_file *s, void *data)
|
|
|
|
{
|
|
|
|
struct device_private *curr;
|
|
|
|
|
|
|
|
mutex_lock(&deferred_probe_mutex);
|
|
|
|
|
|
|
|
list_for_each_entry(curr, &deferred_probe_pending_list, deferred_probe)
|
2020-07-13 14:43:22 +00:00
|
|
|
seq_printf(s, "%s\t%s", dev_name(curr->device),
|
|
|
|
curr->device->p->deferred_probe_reason ?: "\n");
|
2018-07-08 13:34:59 +00:00
|
|
|
|
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
DEFINE_SHOW_ATTRIBUTE(deferred_devs);
|
|
|
|
|
2022-04-29 22:09:32 +00:00
|
|
|
#ifdef CONFIG_MODULES
|
|
|
|
int driver_deferred_probe_timeout = 10;
|
|
|
|
#else
|
2020-04-22 20:32:43 +00:00
|
|
|
int driver_deferred_probe_timeout;
|
2022-04-29 22:09:32 +00:00
|
|
|
#endif
|
|
|
|
|
2020-02-25 05:08:27 +00:00
|
|
|
EXPORT_SYMBOL_GPL(driver_deferred_probe_timeout);
|
driver core: Ensure wait_for_device_probe() waits until the deferred_probe_timeout fires
In commit c8c43cee29f6 ("driver core: Fix
driver_deferred_probe_check_state() logic"), we set the default
driver_deferred_probe_timeout value to 30 seconds to allow for
drivers that are missing dependencies to have some time so that
the dependency may be loaded from userland after initcalls_done
is set.
However, Yoshihiro Shimoda reported that on his device that
expects to have unmet dependencies (due to "optional links" in
its devicetree), was failing to mount the NFS root.
In digging further, it seemed the problem was that while the
device properly probes after waiting 30 seconds for any missing
modules to load, the ip_auto_config() had already failed,
resulting in NFS to fail. This was due to ip_auto_config()
calling wait_for_device_probe() which doesn't wait for the
driver_deferred_probe_timeout to fire.
This patch tries to fix the issue by creating a waitqueue
for the driver_deferred_probe_timeout, and calling wait_event()
to make sure driver_deferred_probe_timeout is zero in
wait_for_device_probe() to make sure all the probing is
finished.
The downside to this solution is that kernel functionality that
uses wait_for_device_probe(), will block until the
driver_deferred_probe_timeout fires, regardless of if there is
any missing dependencies.
However, the previous patch reverts the default timeout value to
zero, so this side-effect will only affect users who specify a
driver_deferred_probe_timeout= value as a boot argument, where
the additional delay would be beneficial to allow modules to
load later during boot.
Thanks to Geert for chasing down that ip_auto_config was why NFS
was failing in this case!
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Rob Herring <robh@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: Basil Eljuse <Basil.Eljuse@arm.com>
Cc: Ferry Toth <fntoth@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Anders Roxell <anders.roxell@linaro.org>
Cc: linux-pm@vger.kernel.org
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Fixes: c8c43cee29f6 ("driver core: Fix driver_deferred_probe_check_state() logic")
Signed-off-by: John Stultz <john.stultz@linaro.org>
Link: https://lore.kernel.org/r/20200422203245.83244-4-john.stultz@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-22 20:32:45 +00:00
|
|
|
static DECLARE_WAIT_QUEUE_HEAD(probe_timeout_waitqueue);
|
2020-02-25 05:08:27 +00:00
|
|
|
|
2018-07-09 15:41:48 +00:00
|
|
|
static int __init deferred_probe_timeout_setup(char *str)
|
|
|
|
{
|
2018-10-28 06:39:11 +00:00
|
|
|
int timeout;
|
|
|
|
|
|
|
|
if (!kstrtoint(str, 10, &timeout))
|
2020-02-25 05:08:27 +00:00
|
|
|
driver_deferred_probe_timeout = timeout;
|
2018-07-09 15:41:48 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
__setup("deferred_probe_timeout=", deferred_probe_timeout_setup);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* driver_deferred_probe_check_state() - Check deferred probe state
|
|
|
|
* @dev: device to check
|
|
|
|
*
|
driver core: Fix driver_deferred_probe_check_state() logic
driver_deferred_probe_check_state() has some uninituitive behavior.
* From boot to late_initcall, it returns -EPROBE_DEFER
* From late_initcall to the deferred_probe_timeout (if set)
it returns -ENODEV
* If the deferred_probe_timeout it set, after it fires, it
returns -ETIMEDOUT
This is a bit confusing, as its useful to have the function
return -EPROBE_DEFER while the timeout is still running. This
behavior has resulted in the somwhat duplicative
driver_deferred_probe_check_state_continue() function being
added.
Thus this patch tries to improve the logic, so that it behaves
as such:
* If late_initcall has passed, and modules are not enabled
it returns -ENODEV
* If modules are enabled and deferred_probe_timeout is set,
it returns -EPROBE_DEFER until the timeout, afterwhich it
returns -ETIMEDOUT.
* In all other cases, it returns -EPROBE_DEFER
This will make the deferred_probe_timeout value much more
functional, and will allow us to consolidate the
driver_deferred_probe_check_state() and
driver_deferred_probe_check_state_continue() logic in a later
patch.
Cc: linux-pm@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Saravana Kannan <saravanak@google.com>
Cc: Todd Kjos <tkjos@google.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Kevin Hilman <khilman@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Link: https://lore.kernel.org/r/20200225050828.56458-2-john.stultz@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-25 05:08:23 +00:00
|
|
|
* Return:
|
2022-04-16 07:11:38 +00:00
|
|
|
* * -ENODEV if initcalls have completed and modules are disabled.
|
|
|
|
* * -ETIMEDOUT if the deferred probe timeout was set and has expired
|
|
|
|
* and modules are enabled.
|
|
|
|
* * -EPROBE_DEFER in other cases.
|
2018-07-09 15:41:48 +00:00
|
|
|
*
|
|
|
|
* Drivers or subsystems can opt-in to calling this function instead of directly
|
|
|
|
* returning -EPROBE_DEFER.
|
|
|
|
*/
|
|
|
|
int driver_deferred_probe_check_state(struct device *dev)
|
|
|
|
{
|
2020-02-25 05:08:26 +00:00
|
|
|
if (!IS_ENABLED(CONFIG_MODULES) && initcalls_done) {
|
2020-04-11 13:31:58 +00:00
|
|
|
dev_warn(dev, "ignoring dependency for device, assuming no driver\n");
|
2020-02-25 05:08:26 +00:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
driver: core: Allow subsystems to continue deferring probe
Some subsystems, such as pinctrl, allow continuing to defer probe
indefinitely. This is useful for devices that depend on resources
provided by devices that are only probed after the init stage.
One example of this can be seen on Tegra, where the DPAUX hardware
contains pinmuxing controls for pins that it shares with an I2C
controller. The I2C controller is typically used for communication
with a monitor over HDMI (DDC). However, other instances of the I2C
controller are used to access system critical components, such as a
PMIC. The I2C controller driver will therefore usually be a builtin
driver, whereas the DPAUX driver is part of the display driver that
is loaded from a module to avoid bloating the kernel image with all
of the DRM/KMS subsystem.
In this particular case the pins used by this I2C/DDC controller
become accessible very late in the boot process. However, since the
controller is only used in conjunction with display, that's not an
issue.
Unfortunately the driver core currently outputs a warning message
when a device fails to get the pinctrl before the end of the init
stage. That can be confusing for the user because it may sound like
an unwanted error occurred, whereas it's really an expected and
harmless situation.
In order to eliminate this warning, this patch allows callers of the
driver_deferred_probe_check_state() helper to specify that they want
to continue deferring probe, regardless of whether we're past the
init stage or not. All of the callers of that function are updated
for the new signature, but only the pinctrl subsystem passes a true
value in the new persist parameter if appropriate.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20190621151725.20414-1-thierry.reding@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-21 15:17:25 +00:00
|
|
|
|
2020-04-22 20:32:43 +00:00
|
|
|
if (!driver_deferred_probe_timeout && initcalls_done) {
|
2020-05-11 07:00:09 +00:00
|
|
|
dev_warn(dev, "deferred probe timeout, ignoring dependency\n");
|
2020-02-25 05:08:26 +00:00
|
|
|
return -ETIMEDOUT;
|
|
|
|
}
|
driver: core: Allow subsystems to continue deferring probe
Some subsystems, such as pinctrl, allow continuing to defer probe
indefinitely. This is useful for devices that depend on resources
provided by devices that are only probed after the init stage.
One example of this can be seen on Tegra, where the DPAUX hardware
contains pinmuxing controls for pins that it shares with an I2C
controller. The I2C controller is typically used for communication
with a monitor over HDMI (DDC). However, other instances of the I2C
controller are used to access system critical components, such as a
PMIC. The I2C controller driver will therefore usually be a builtin
driver, whereas the DPAUX driver is part of the display driver that
is loaded from a module to avoid bloating the kernel image with all
of the DRM/KMS subsystem.
In this particular case the pins used by this I2C/DDC controller
become accessible very late in the boot process. However, since the
controller is only used in conjunction with display, that's not an
issue.
Unfortunately the driver core currently outputs a warning message
when a device fails to get the pinctrl before the end of the init
stage. That can be confusing for the user because it may sound like
an unwanted error occurred, whereas it's really an expected and
harmless situation.
In order to eliminate this warning, this patch allows callers of the
driver_deferred_probe_check_state() helper to specify that they want
to continue deferring probe, regardless of whether we're past the
init stage or not. All of the callers of that function are updated
for the new signature, but only the pinctrl subsystem passes a true
value in the new persist parameter if appropriate.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20190621151725.20414-1-thierry.reding@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-21 15:17:25 +00:00
|
|
|
|
2018-07-09 15:41:48 +00:00
|
|
|
return -EPROBE_DEFER;
|
|
|
|
}
|
net: mdio: don't defer probe forever if PHY IRQ provider is missing
When a driver for an interrupt controller is missing, of_irq_get()
returns -EPROBE_DEFER ad infinitum, causing
fwnode_mdiobus_phy_device_register(), and ultimately, the entire
of_mdiobus_register() call, to fail. In turn, any phy_connect() call
towards a PHY on this MDIO bus will also fail.
This is not what is expected to happen, because the PHY library falls
back to poll mode when of_irq_get() returns a hard error code, and the
MDIO bus, PHY and attached Ethernet controller work fine, albeit
suboptimally, when the PHY library polls for link status. However,
-EPROBE_DEFER has special handling given the assumption that at some
point probe deferral will stop, and the driver for the supplier will
kick in and create the IRQ domain.
Reasons for which the interrupt controller may be missing:
- It is not yet written. This may happen if a more recent DT blob (with
an interrupt-parent for the PHY) is used to boot an old kernel where
the driver didn't exist, and that kernel worked with the
vintage-correct DT blob using poll mode.
- It is compiled out. Behavior is the same as above.
- It is compiled as a module. The kernel will wait for a number of
seconds specified in the "deferred_probe_timeout" boot parameter for
user space to load the required module. The current default is 0,
which times out at the end of initcalls. It is possible that this
might cause regressions unless users adjust this boot parameter.
The proposed solution is to use the driver_deferred_probe_check_state()
helper function provided by the driver core, which gives up after some
-EPROBE_DEFER attempts, taking "deferred_probe_timeout" into consideration.
The return code is changed from -EPROBE_DEFER into -ENODEV or
-ETIMEDOUT, depending on whether the kernel is compiled with support for
modules or not.
Fixes: 66bdede495c7 ("of_mdio: Fix broken PHY IRQ in case of probe deferral")
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20220407165538.4084809-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-04-07 16:55:38 +00:00
|
|
|
EXPORT_SYMBOL_GPL(driver_deferred_probe_check_state);
|
2018-07-09 15:41:48 +00:00
|
|
|
|
|
|
|
static void deferred_probe_timeout_work_func(struct work_struct *work)
|
|
|
|
{
|
2021-04-02 04:03:40 +00:00
|
|
|
struct device_private *p;
|
2018-07-09 15:41:48 +00:00
|
|
|
|
2021-04-02 04:03:41 +00:00
|
|
|
fw_devlink_drivers_done();
|
|
|
|
|
2020-02-25 05:08:27 +00:00
|
|
|
driver_deferred_probe_timeout = 0;
|
2018-07-09 15:41:48 +00:00
|
|
|
driver_deferred_probe_trigger();
|
|
|
|
flush_work(&deferred_probe_work);
|
|
|
|
|
2021-04-02 04:03:40 +00:00
|
|
|
mutex_lock(&deferred_probe_mutex);
|
|
|
|
list_for_each_entry(p, &deferred_probe_pending_list, deferred_probe)
|
|
|
|
dev_info(p->device, "deferred probe pending\n");
|
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
2020-07-13 02:12:54 +00:00
|
|
|
wake_up_all(&probe_timeout_waitqueue);
|
2018-07-09 15:41:48 +00:00
|
|
|
}
|
|
|
|
static DECLARE_DELAYED_WORK(deferred_probe_timeout_work, deferred_probe_timeout_work_func);
|
|
|
|
|
2022-04-29 22:09:32 +00:00
|
|
|
void deferred_probe_extend_timeout(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If the work hasn't been queued yet or if the work expired, don't
|
|
|
|
* start a new one.
|
|
|
|
*/
|
|
|
|
if (cancel_delayed_work(&deferred_probe_timeout_work)) {
|
|
|
|
schedule_delayed_work(&deferred_probe_timeout_work,
|
|
|
|
driver_deferred_probe_timeout * HZ);
|
|
|
|
pr_debug("Extended deferred probe timeout by %d secs\n",
|
|
|
|
driver_deferred_probe_timeout);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-03-05 15:47:41 +00:00
|
|
|
/**
|
|
|
|
* deferred_probe_initcall() - Enable probing of deferred devices
|
|
|
|
*
|
|
|
|
* We don't want to get in the way when the bulk of drivers are getting probed.
|
|
|
|
* Instead, this initcall makes sure that deferred probing is delayed until
|
|
|
|
* late_initcall time.
|
|
|
|
*/
|
|
|
|
static int deferred_probe_initcall(void)
|
|
|
|
{
|
2021-02-16 14:24:00 +00:00
|
|
|
debugfs_create_file("devices_deferred", 0444, NULL, NULL,
|
|
|
|
&deferred_devs_fops);
|
2018-07-08 13:34:59 +00:00
|
|
|
|
2012-03-05 15:47:41 +00:00
|
|
|
driver_deferred_probe_enable = true;
|
|
|
|
driver_deferred_probe_trigger();
|
2013-02-14 18:14:27 +00:00
|
|
|
/* Sort as many dependencies as possible before exiting initcalls */
|
2016-08-30 17:15:34 +00:00
|
|
|
flush_work(&deferred_probe_work);
|
2018-07-09 15:41:48 +00:00
|
|
|
initcalls_done = true;
|
|
|
|
|
2021-04-02 04:03:41 +00:00
|
|
|
if (!IS_ENABLED(CONFIG_MODULES))
|
|
|
|
fw_devlink_drivers_done();
|
|
|
|
|
2018-07-09 15:41:48 +00:00
|
|
|
/*
|
|
|
|
* Trigger deferred probe again, this time we won't defer anything
|
|
|
|
* that is optional
|
|
|
|
*/
|
|
|
|
driver_deferred_probe_trigger();
|
|
|
|
flush_work(&deferred_probe_work);
|
|
|
|
|
2020-02-25 05:08:27 +00:00
|
|
|
if (driver_deferred_probe_timeout > 0) {
|
2018-07-09 15:41:48 +00:00
|
|
|
schedule_delayed_work(&deferred_probe_timeout_work,
|
2020-02-25 05:08:27 +00:00
|
|
|
driver_deferred_probe_timeout * HZ);
|
2018-07-09 15:41:48 +00:00
|
|
|
}
|
2012-03-05 15:47:41 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
late_initcall(deferred_probe_initcall);
|
2005-03-21 18:52:54 +00:00
|
|
|
|
2018-07-08 13:34:59 +00:00
|
|
|
static void __exit deferred_probe_exit(void)
|
|
|
|
{
|
2021-02-16 14:24:00 +00:00
|
|
|
debugfs_remove_recursive(debugfs_lookup("devices_deferred", NULL));
|
2018-07-08 13:34:59 +00:00
|
|
|
}
|
|
|
|
__exitcall(deferred_probe_exit);
|
|
|
|
|
2016-01-07 15:46:12 +00:00
|
|
|
/**
|
|
|
|
* device_is_bound() - Check if device is bound to a driver
|
|
|
|
* @dev: device to check
|
|
|
|
*
|
|
|
|
* Returns true if passed device has already finished probing successfully
|
|
|
|
* against a driver.
|
|
|
|
*
|
|
|
|
* This function must be called with the device lock held.
|
|
|
|
*/
|
|
|
|
bool device_is_bound(struct device *dev)
|
|
|
|
{
|
2016-01-12 00:51:44 +00:00
|
|
|
return dev->p && klist_node_attached(&dev->p->knode_driver);
|
2016-01-07 15:46:12 +00:00
|
|
|
}
|
|
|
|
|
2006-10-07 19:55:55 +00:00
|
|
|
static void driver_bound(struct device *dev)
|
2005-03-21 18:52:54 +00:00
|
|
|
{
|
2016-01-07 15:46:12 +00:00
|
|
|
if (device_is_bound(dev)) {
|
2020-04-11 13:31:58 +00:00
|
|
|
pr_warn("%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
|
|
|
|
2014-04-17 00:12:30 +00:00
|
|
|
pr_debug("driver: '%s': %s: bound to device '%s'\n", dev->driver->name,
|
|
|
|
__func__, dev_name(dev));
|
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: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-30 16:32:16 +00:00
|
|
|
device_links_driver_bound(dev);
|
2010-03-06 16:50:14 +00:00
|
|
|
|
2016-01-07 15:46:14 +00:00
|
|
|
device_pm_check_callbacks(dev);
|
|
|
|
|
2012-03-08 20:20:37 +00:00
|
|
|
/*
|
|
|
|
* Make sure the device is no longer in one of the deferred lists and
|
|
|
|
* kick off retrying all pending devices
|
|
|
|
*/
|
2012-03-05 15:47:41 +00:00
|
|
|
driver_deferred_probe_del(dev);
|
|
|
|
driver_deferred_probe_trigger();
|
|
|
|
|
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);
|
2017-07-20 00:24:30 +00:00
|
|
|
|
|
|
|
kobject_uevent(&dev->kobj, KOBJ_BIND);
|
2006-10-07 19:55:55 +00:00
|
|
|
}
|
|
|
|
|
2018-01-11 08:36:38 +00:00
|
|
|
static ssize_t coredump_store(struct device *dev, struct device_attribute *attr,
|
|
|
|
const char *buf, size_t count)
|
|
|
|
{
|
|
|
|
device_lock(dev);
|
2018-03-15 09:55:25 +00:00
|
|
|
dev->driver->coredump(dev);
|
2018-01-11 08:36:38 +00:00
|
|
|
device_unlock(dev);
|
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_WO(coredump);
|
|
|
|
|
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,
|
2018-01-11 08:36:38 +00:00
|
|
|
kobject_name(&dev->kobj));
|
|
|
|
if (ret)
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
ret = sysfs_create_link(&dev->kobj, &dev->driver->p->kobj,
|
|
|
|
"driver");
|
|
|
|
if (ret)
|
|
|
|
goto rm_dev;
|
|
|
|
|
2021-03-24 02:34:05 +00:00
|
|
|
if (!IS_ENABLED(CONFIG_DEV_COREDUMP) || !dev->driver->coredump)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
ret = device_create_file(dev, &dev_attr_coredump);
|
|
|
|
if (!ret)
|
2018-01-11 08:36:38 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
sysfs_remove_link(&dev->kobj, "driver");
|
|
|
|
|
|
|
|
rm_dev:
|
|
|
|
sysfs_remove_link(&dev->driver->p->kobj,
|
2005-03-21 18:52:54 +00:00
|
|
|
kobject_name(&dev->kobj));
|
2018-01-11 08:36:38 +00:00
|
|
|
|
|
|
|
fail:
|
2006-08-15 05:43:20 +00:00
|
|
|
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) {
|
2018-01-11 08:36:38 +00:00
|
|
|
if (drv->coredump)
|
|
|
|
device_remove_file(dev, &dev_attr_coredump);
|
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
|
|
|
*
|
2020-07-08 12:12:22 +00:00
|
|
|
* Note that this does not modify the bus reference count.
|
|
|
|
* Please verify that is 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.
|
2021-06-17 14:22:13 +00:00
|
|
|
*
|
|
|
|
* Callers should prefer to use device_driver_attach() instead.
|
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);
|
2021-03-02 21:11:31 +00:00
|
|
|
if (!ret) {
|
|
|
|
device_links_force_bind(dev);
|
2006-11-27 09:35:12 +00:00
|
|
|
driver_bound(dev);
|
2021-03-02 21:11:31 +00:00
|
|
|
}
|
2015-12-04 21:49:17 +00:00
|
|
|
else if (dev->bus)
|
|
|
|
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
|
|
|
|
BUS_NOTIFY_DRIVER_NOT_BOUND, dev);
|
2006-11-27 09:35:12 +00:00
|
|
|
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);
|
|
|
|
|
2020-05-21 19:17:59 +00:00
|
|
|
static ssize_t state_synced_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
bool val;
|
|
|
|
|
|
|
|
device_lock(dev);
|
|
|
|
val = dev->state_synced;
|
|
|
|
device_unlock(dev);
|
2020-09-16 20:40:42 +00:00
|
|
|
|
drivers core: Use sysfs_emit and sysfs_emit_at for show(device *...) functions
Convert the various sprintf fmaily calls in sysfs device show functions
to sysfs_emit and sysfs_emit_at for PAGE_SIZE buffer safety.
Done with:
$ spatch -sp-file sysfs_emit_dev.cocci --in-place --max-width=80 .
And cocci script:
$ cat sysfs_emit_dev.cocci
@@
identifier d_show;
identifier dev, attr, buf;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
return
- sprintf(buf,
+ sysfs_emit(buf,
...);
...>
}
@@
identifier d_show;
identifier dev, attr, buf;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
return
- snprintf(buf, PAGE_SIZE,
+ sysfs_emit(buf,
...);
...>
}
@@
identifier d_show;
identifier dev, attr, buf;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
return
- scnprintf(buf, PAGE_SIZE,
+ sysfs_emit(buf,
...);
...>
}
@@
identifier d_show;
identifier dev, attr, buf;
expression chr;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
return
- strcpy(buf, chr);
+ sysfs_emit(buf, chr);
...>
}
@@
identifier d_show;
identifier dev, attr, buf;
identifier len;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
len =
- sprintf(buf,
+ sysfs_emit(buf,
...);
...>
return len;
}
@@
identifier d_show;
identifier dev, attr, buf;
identifier len;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
len =
- snprintf(buf, PAGE_SIZE,
+ sysfs_emit(buf,
...);
...>
return len;
}
@@
identifier d_show;
identifier dev, attr, buf;
identifier len;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
len =
- scnprintf(buf, PAGE_SIZE,
+ sysfs_emit(buf,
...);
...>
return len;
}
@@
identifier d_show;
identifier dev, attr, buf;
identifier len;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
- len += scnprintf(buf + len, PAGE_SIZE - len,
+ len += sysfs_emit_at(buf, len,
...);
...>
return len;
}
@@
identifier d_show;
identifier dev, attr, buf;
expression chr;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
...
- strcpy(buf, chr);
- return strlen(buf);
+ return sysfs_emit(buf, chr);
}
Signed-off-by: Joe Perches <joe@perches.com>
Link: https://lore.kernel.org/r/3d033c33056d88bbe34d4ddb62afd05ee166ab9a.1600285923.git.joe@perches.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16 20:40:39 +00:00
|
|
|
return sysfs_emit(buf, "%u\n", val);
|
2020-05-21 19:17:59 +00:00
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(state_synced);
|
|
|
|
|
2022-02-23 22:52:56 +00:00
|
|
|
static void device_unbind_cleanup(struct device *dev)
|
|
|
|
{
|
|
|
|
devres_release_all(dev);
|
|
|
|
arch_teardown_dma_ops(dev);
|
|
|
|
kfree(dev->dma_range_map);
|
|
|
|
dev->dma_range_map = NULL;
|
|
|
|
dev->driver = NULL;
|
|
|
|
dev_set_drvdata(dev, NULL);
|
|
|
|
if (dev->pm_domain && dev->pm_domain->dismiss)
|
|
|
|
dev->pm_domain->dismiss(dev);
|
|
|
|
pm_runtime_reinit(dev);
|
|
|
|
dev_pm_set_driver_flags(dev, 0);
|
|
|
|
}
|
2021-06-17 14:22:10 +00:00
|
|
|
|
2022-02-23 22:52:57 +00:00
|
|
|
static void device_remove(struct device *dev)
|
|
|
|
{
|
|
|
|
device_remove_file(dev, &dev_attr_state_synced);
|
|
|
|
device_remove_groups(dev, dev->driver->dev_groups);
|
|
|
|
|
|
|
|
if (dev->bus && dev->bus->remove)
|
|
|
|
dev->bus->remove(dev);
|
|
|
|
else if (dev->driver->remove)
|
|
|
|
dev->driver->remove(dev);
|
|
|
|
}
|
|
|
|
|
2021-06-17 14:22:10 +00:00
|
|
|
static int call_driver_probe(struct device *dev, struct device_driver *drv)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (dev->bus->probe)
|
|
|
|
ret = dev->bus->probe(dev);
|
|
|
|
else if (drv->probe)
|
|
|
|
ret = drv->probe(dev);
|
|
|
|
|
|
|
|
switch (ret) {
|
|
|
|
case 0:
|
|
|
|
break;
|
|
|
|
case -EPROBE_DEFER:
|
|
|
|
/* Driver requested deferred probing */
|
|
|
|
dev_dbg(dev, "Driver %s requests probe deferral\n", drv->name);
|
|
|
|
break;
|
|
|
|
case -ENODEV:
|
|
|
|
case -ENXIO:
|
|
|
|
pr_debug("%s: probe of %s rejects match %d\n",
|
|
|
|
drv->name, dev_name(dev), ret);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
/* driver matched but the probe failed */
|
|
|
|
pr_warn("%s: probe of %s failed with error %d\n",
|
|
|
|
drv->name, dev_name(dev), ret);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
{
|
2016-10-11 18:41:02 +00:00
|
|
|
bool test_remove = IS_ENABLED(CONFIG_DEBUG_TEST_DRIVER_REMOVE) &&
|
|
|
|
!drv->suppress_bind_attrs;
|
2021-06-17 14:22:12 +00:00
|
|
|
int ret;
|
2005-03-21 18:52:54 +00:00
|
|
|
|
2015-11-10 09:42:34 +00:00
|
|
|
if (defer_all_probes) {
|
|
|
|
/*
|
|
|
|
* Value of defer_all_probes can be set only by
|
2018-11-06 07:41:27 +00:00
|
|
|
* device_block_probing() which, in turn, will call
|
2015-11-10 09:42:34 +00:00
|
|
|
* wait_for_device_probe() right after that to avoid any races.
|
|
|
|
*/
|
|
|
|
dev_dbg(dev, "Driver %s force probe deferral\n", drv->name);
|
2021-06-17 14:22:12 +00:00
|
|
|
return -EPROBE_DEFER;
|
2015-11-10 09:42:34 +00:00
|
|
|
}
|
|
|
|
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-30 16:32:16 +00:00
|
|
|
ret = device_links_check_suppliers(dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
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));
|
2019-12-06 13:22:19 +00:00
|
|
|
if (!list_empty(&dev->devres_head)) {
|
|
|
|
dev_crit(dev, "Resources present before probing\n");
|
2020-07-13 02:12:54 +00:00
|
|
|
ret = -EBUSY;
|
|
|
|
goto done;
|
2019-12-06 13:22:19 +00:00
|
|
|
}
|
2005-03-21 18:52:54 +00:00
|
|
|
|
2016-08-11 15:20:58 +00:00
|
|
|
re_probe:
|
2005-03-21 18:52:54 +00:00
|
|
|
dev->driver = drv;
|
drivers/pinctrl: grab default handles from device core
This makes the device core auto-grab the pinctrl handle and set
the "default" (PINCTRL_STATE_DEFAULT) state for every device
that is present in the device model right before probe. This will
account for the lion's share of embedded silicon devcies.
A modification of the semantics for pinctrl_get() is also done:
previously if the pinctrl handle for a certain device was already
taken, the pinctrl core would return an error. Now, since the
core may have already default-grabbed the handle and set its
state to "default", if the handle was already taken, this will
be disregarded and the located, previously instanitated handle
will be returned to the caller.
This way all code in drivers explicitly requesting their pinctrl
handlers will still be functional, and drivers that want to
explicitly retrieve and switch their handles can still do that.
But if the desired functionality is just boilerplate of this
type in the probe() function:
struct pinctrl *p;
p = devm_pinctrl_get_select_default(&dev);
if (IS_ERR(p)) {
if (PTR_ERR(p) == -EPROBE_DEFER)
return -EPROBE_DEFER;
dev_warn(&dev, "no pinctrl handle\n");
}
The discussion began with the addition of such boilerplate
to the omap4 keypad driver:
http://marc.info/?l=linux-input&m=135091157719300&w=2
A previous approach using notifiers was discussed:
http://marc.info/?l=linux-kernel&m=135263661110528&w=2
This failed because it could not handle deferred probes.
This patch alone does not solve the entire dilemma faced:
whether code should be distributed into the drivers or
if it should be centralized to e.g. a PM domain. But it
solves the immediate issue of the addition of boilerplate
to a lot of drivers that just want to grab the default
state. As mentioned, they can later explicitly retrieve
the handle and set different states, and this could as
well be done by e.g. PM domains as it is only related
to a certain struct device * pointer.
ChangeLog v4->v5 (Stephen):
- Simplified the devicecore grab code.
- Deleted a piece of documentation recommending that pins
be mapped to a device rather than hogged.
ChangeLog v3->v4 (Linus):
- Drop overzealous NULL checks.
- Move kref initialization to pinctrl_create().
- Seeking Tested-by from Stephen Warren so we do not disturb
the Tegra platform.
- Seeking ACK on this from Greg (and others who like it) so I
can merge it through the pinctrl subsystem.
ChangeLog v2->v3 (Linus):
- Abstain from using IS_ERR_OR_NULL() in the driver core,
Russell recently sent a patch to remove it. Handle the
NULL case explicitly even though it's a bogus case.
- Make sure we handle probe deferral correctly in the device
core file. devm_kfree() the container on error so we don't
waste memory for devices without pinctrl handles.
- Introduce reference counting into the pinctrl core using
<linux/kref.h> so that we don't release pinctrl handles
that have been obtained for two or more places.
ChangeLog v1->v2 (Linus):
- Only store a pointer in the device struct, and only allocate
this if it's really used by the device.
Cc: Felipe Balbi <balbi@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Mitch Bradley <wmb@firmworks.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Rickard Andersson <rickard.andersson@stericsson.com>
Cc: Russell King <linux@arm.linux.org.uk>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[swarren: fixed and simplified error-handling in pinctrl_bind_pins(), to
correctly handle deferred probe. Removed admonition from docs not to use
pinctrl hogs for devices]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-01-22 17:56:14 +00:00
|
|
|
|
|
|
|
/* If using pinctrl, bind pins now before probing */
|
|
|
|
ret = pinctrl_bind_pins(dev);
|
|
|
|
if (ret)
|
2015-12-04 21:49:17 +00:00
|
|
|
goto pinctrl_bind_failed;
|
drivers/pinctrl: grab default handles from device core
This makes the device core auto-grab the pinctrl handle and set
the "default" (PINCTRL_STATE_DEFAULT) state for every device
that is present in the device model right before probe. This will
account for the lion's share of embedded silicon devcies.
A modification of the semantics for pinctrl_get() is also done:
previously if the pinctrl handle for a certain device was already
taken, the pinctrl core would return an error. Now, since the
core may have already default-grabbed the handle and set its
state to "default", if the handle was already taken, this will
be disregarded and the located, previously instanitated handle
will be returned to the caller.
This way all code in drivers explicitly requesting their pinctrl
handlers will still be functional, and drivers that want to
explicitly retrieve and switch their handles can still do that.
But if the desired functionality is just boilerplate of this
type in the probe() function:
struct pinctrl *p;
p = devm_pinctrl_get_select_default(&dev);
if (IS_ERR(p)) {
if (PTR_ERR(p) == -EPROBE_DEFER)
return -EPROBE_DEFER;
dev_warn(&dev, "no pinctrl handle\n");
}
The discussion began with the addition of such boilerplate
to the omap4 keypad driver:
http://marc.info/?l=linux-input&m=135091157719300&w=2
A previous approach using notifiers was discussed:
http://marc.info/?l=linux-kernel&m=135263661110528&w=2
This failed because it could not handle deferred probes.
This patch alone does not solve the entire dilemma faced:
whether code should be distributed into the drivers or
if it should be centralized to e.g. a PM domain. But it
solves the immediate issue of the addition of boilerplate
to a lot of drivers that just want to grab the default
state. As mentioned, they can later explicitly retrieve
the handle and set different states, and this could as
well be done by e.g. PM domains as it is only related
to a certain struct device * pointer.
ChangeLog v4->v5 (Stephen):
- Simplified the devicecore grab code.
- Deleted a piece of documentation recommending that pins
be mapped to a device rather than hogged.
ChangeLog v3->v4 (Linus):
- Drop overzealous NULL checks.
- Move kref initialization to pinctrl_create().
- Seeking Tested-by from Stephen Warren so we do not disturb
the Tegra platform.
- Seeking ACK on this from Greg (and others who like it) so I
can merge it through the pinctrl subsystem.
ChangeLog v2->v3 (Linus):
- Abstain from using IS_ERR_OR_NULL() in the driver core,
Russell recently sent a patch to remove it. Handle the
NULL case explicitly even though it's a bogus case.
- Make sure we handle probe deferral correctly in the device
core file. devm_kfree() the container on error so we don't
waste memory for devices without pinctrl handles.
- Introduce reference counting into the pinctrl core using
<linux/kref.h> so that we don't release pinctrl handles
that have been obtained for two or more places.
ChangeLog v1->v2 (Linus):
- Only store a pointer in the device struct, and only allocate
this if it's really used by the device.
Cc: Felipe Balbi <balbi@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Mitch Bradley <wmb@firmworks.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Rickard Andersson <rickard.andersson@stericsson.com>
Cc: Russell King <linux@arm.linux.org.uk>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[swarren: fixed and simplified error-handling in pinctrl_bind_pins(), to
correctly handle deferred probe. Removed admonition from docs not to use
pinctrl hogs for devices]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-01-22 17:56:14 +00:00
|
|
|
|
2018-08-24 07:40:24 +00:00
|
|
|
if (dev->bus->dma_configure) {
|
|
|
|
ret = dev->bus->dma_configure(dev);
|
|
|
|
if (ret)
|
2021-12-31 03:39:01 +00:00
|
|
|
goto pinctrl_bind_failed;
|
2018-08-24 07:40:24 +00:00
|
|
|
}
|
2017-04-10 11:21:01 +00:00
|
|
|
|
2021-07-07 07:43:01 +00:00
|
|
|
ret = driver_sysfs_add(dev);
|
|
|
|
if (ret) {
|
2020-04-11 13:31:58 +00:00
|
|
|
pr_err("%s: driver_sysfs_add(%s) failed\n",
|
|
|
|
__func__, dev_name(dev));
|
2021-12-31 03:39:00 +00:00
|
|
|
goto sysfs_failed;
|
2006-10-07 19:55:55 +00:00
|
|
|
}
|
|
|
|
|
driver core / PM: Add PM domain callbacks for device setup/cleanup
If PM domains are in use, it may be necessary to prepare the code
handling a PM domain for driver probing. For example, in some
cases device drivers rely on the ability to power on the devices
with the help of the IO runtime PM framework and the PM domain
code needs to be ready for that. Also, if that code has not been
fully initialized yet, the driver probing should be deferred.
Moreover, after the probing is complete, it may be necessary to
put the PM domain in question into the state reflecting the current
needs of the devices in it, for example, so that power is not drawn
in vain. The same should be done after removing a driver from
a device, as the PM domain state may need to be changed to reflect
the new situation.
For these reasons, introduce new PM domain callbacks, ->activate,
->sync and ->dismiss called, respectively, before probing for a
device driver, after the probing has completed successfully and
if the probing has failed or the driver has been removed.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-20 12:59:27 +00:00
|
|
|
if (dev->pm_domain && dev->pm_domain->activate) {
|
|
|
|
ret = dev->pm_domain->activate(dev);
|
|
|
|
if (ret)
|
|
|
|
goto probe_failed;
|
|
|
|
}
|
|
|
|
|
2021-06-17 14:22:12 +00:00
|
|
|
ret = call_driver_probe(dev, drv);
|
|
|
|
if (ret) {
|
2021-06-17 14:22:10 +00:00
|
|
|
/*
|
2021-06-17 14:22:11 +00:00
|
|
|
* Return probe errors as positive values so that the callers
|
|
|
|
* can distinguish them from other errors.
|
2021-06-17 14:22:10 +00:00
|
|
|
*/
|
2021-06-17 14:22:12 +00:00
|
|
|
ret = -ret;
|
2021-06-17 14:22:10 +00:00
|
|
|
goto probe_failed;
|
2006-08-15 05:43:20 +00:00
|
|
|
}
|
2006-10-07 19:55:55 +00:00
|
|
|
|
2021-07-07 07:43:01 +00:00
|
|
|
ret = device_add_groups(dev, drv->dev_groups);
|
|
|
|
if (ret) {
|
2019-07-31 12:43:40 +00:00
|
|
|
dev_err(dev, "device_add_groups() failed\n");
|
|
|
|
goto dev_groups_failed;
|
|
|
|
}
|
|
|
|
|
2021-07-07 07:43:01 +00:00
|
|
|
if (dev_has_sync_state(dev)) {
|
|
|
|
ret = device_create_file(dev, &dev_attr_state_synced);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "state_synced sysfs add failed\n");
|
|
|
|
goto dev_sysfs_state_synced_failed;
|
|
|
|
}
|
2020-05-21 19:17:59 +00:00
|
|
|
}
|
|
|
|
|
2016-08-11 15:20:58 +00:00
|
|
|
if (test_remove) {
|
|
|
|
test_remove = false;
|
|
|
|
|
2022-02-23 22:52:57 +00:00
|
|
|
device_remove(dev);
|
2016-08-11 15:20:58 +00:00
|
|
|
driver_sysfs_remove(dev);
|
2022-02-23 22:52:56 +00:00
|
|
|
device_unbind_cleanup(dev);
|
2016-08-11 15:20:58 +00:00
|
|
|
|
|
|
|
goto re_probe;
|
|
|
|
}
|
|
|
|
|
2015-10-21 04:15:06 +00:00
|
|
|
pinctrl_init_done(dev);
|
|
|
|
|
driver core / PM: Add PM domain callbacks for device setup/cleanup
If PM domains are in use, it may be necessary to prepare the code
handling a PM domain for driver probing. For example, in some
cases device drivers rely on the ability to power on the devices
with the help of the IO runtime PM framework and the PM domain
code needs to be ready for that. Also, if that code has not been
fully initialized yet, the driver probing should be deferred.
Moreover, after the probing is complete, it may be necessary to
put the PM domain in question into the state reflecting the current
needs of the devices in it, for example, so that power is not drawn
in vain. The same should be done after removing a driver from
a device, as the PM domain state may need to be changed to reflect
the new situation.
For these reasons, introduce new PM domain callbacks, ->activate,
->sync and ->dismiss called, respectively, before probing for a
device driver, after the probing has completed successfully and
if the probing has failed or the driver has been removed.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-20 12:59:27 +00:00
|
|
|
if (dev->pm_domain && dev->pm_domain->sync)
|
|
|
|
dev->pm_domain->sync(dev);
|
|
|
|
|
2006-10-07 19:55:55 +00:00
|
|
|
driver_bound(dev);
|
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
|
|
|
|
2020-05-21 19:17:59 +00:00
|
|
|
dev_sysfs_state_synced_failed:
|
2019-07-31 12:43:40 +00:00
|
|
|
dev_groups_failed:
|
2022-02-23 22:52:57 +00:00
|
|
|
device_remove(dev);
|
2006-07-18 17:59:59 +00:00
|
|
|
probe_failed:
|
2021-12-31 03:39:00 +00:00
|
|
|
driver_sysfs_remove(dev);
|
|
|
|
sysfs_failed:
|
2015-12-04 21:49:17 +00:00
|
|
|
if (dev->bus)
|
|
|
|
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
|
|
|
|
BUS_NOTIFY_DRIVER_NOT_BOUND, dev);
|
|
|
|
pinctrl_bind_failed:
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-30 16:32:16 +00:00
|
|
|
device_links_no_driver(dev);
|
2022-02-23 22:52:56 +00:00
|
|
|
device_unbind_cleanup(dev);
|
2006-07-18 17:59:59 +00:00
|
|
|
done:
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2018-06-21 00:35:56 +00:00
|
|
|
/*
|
|
|
|
* For initcall_debug, show the driver probe time.
|
|
|
|
*/
|
|
|
|
static int really_probe_debug(struct device *dev, struct device_driver *drv)
|
|
|
|
{
|
2020-08-03 03:33:43 +00:00
|
|
|
ktime_t calltime, rettime;
|
2018-06-21 00:35:56 +00:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
calltime = ktime_get();
|
|
|
|
ret = really_probe(dev, drv);
|
|
|
|
rettime = ktime_get();
|
2020-04-11 13:31:58 +00:00
|
|
|
pr_debug("probe of %s returned %d after %lld usecs\n",
|
2020-08-03 03:33:43 +00:00
|
|
|
dev_name(dev), ret, ktime_us_delta(rettime, calltime));
|
2018-06-21 00:35:56 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2006-07-18 17:59:59 +00:00
|
|
|
/**
|
|
|
|
* 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)
|
|
|
|
{
|
2020-03-24 12:20:22 +00:00
|
|
|
int local_probe_count = atomic_read(&probe_count);
|
|
|
|
|
|
|
|
pr_debug("%s: probe_count = %d\n", __func__, local_probe_count);
|
|
|
|
if (local_probe_count)
|
2006-07-18 17:59:59 +00:00
|
|
|
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
|
|
|
{
|
driver core: Ensure wait_for_device_probe() waits until the deferred_probe_timeout fires
In commit c8c43cee29f6 ("driver core: Fix
driver_deferred_probe_check_state() logic"), we set the default
driver_deferred_probe_timeout value to 30 seconds to allow for
drivers that are missing dependencies to have some time so that
the dependency may be loaded from userland after initcalls_done
is set.
However, Yoshihiro Shimoda reported that on his device that
expects to have unmet dependencies (due to "optional links" in
its devicetree), was failing to mount the NFS root.
In digging further, it seemed the problem was that while the
device properly probes after waiting 30 seconds for any missing
modules to load, the ip_auto_config() had already failed,
resulting in NFS to fail. This was due to ip_auto_config()
calling wait_for_device_probe() which doesn't wait for the
driver_deferred_probe_timeout to fire.
This patch tries to fix the issue by creating a waitqueue
for the driver_deferred_probe_timeout, and calling wait_event()
to make sure driver_deferred_probe_timeout is zero in
wait_for_device_probe() to make sure all the probing is
finished.
The downside to this solution is that kernel functionality that
uses wait_for_device_probe(), will block until the
driver_deferred_probe_timeout fires, regardless of if there is
any missing dependencies.
However, the previous patch reverts the default timeout value to
zero, so this side-effect will only affect users who specify a
driver_deferred_probe_timeout= value as a boot argument, where
the additional delay would be beneficial to allow modules to
load later during boot.
Thanks to Geert for chasing down that ip_auto_config was why NFS
was failing in this case!
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Rob Herring <robh@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: Basil Eljuse <Basil.Eljuse@arm.com>
Cc: Ferry Toth <fntoth@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Anders Roxell <anders.roxell@linaro.org>
Cc: linux-pm@vger.kernel.org
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Fixes: c8c43cee29f6 ("driver core: Fix driver_deferred_probe_check_state() logic")
Signed-off-by: John Stultz <john.stultz@linaro.org>
Link: https://lore.kernel.org/r/20200422203245.83244-4-john.stultz@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-22 20:32:45 +00:00
|
|
|
/* wait for probe timeout */
|
|
|
|
wait_event(probe_timeout_waitqueue, !driver_deferred_probe_timeout);
|
|
|
|
|
2015-11-10 09:42:34 +00:00
|
|
|
/* wait for the deferred probe workqueue to finish */
|
2016-08-30 17:15:34 +00:00
|
|
|
flush_work(&deferred_probe_work);
|
2015-11-10 09:42:34 +00:00
|
|
|
|
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
|
|
|
|
2021-06-17 14:22:12 +00:00
|
|
|
static int __driver_probe_device(struct device_driver *drv, struct device *dev)
|
2006-07-18 17:59:59 +00:00
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
2021-06-17 14:22:09 +00:00
|
|
|
if (dev->p->dead || !device_is_registered(dev))
|
2006-09-18 20:22:34 +00:00
|
|
|
return -ENODEV;
|
2021-06-17 14:22:09 +00:00
|
|
|
if (dev->driver)
|
|
|
|
return -EBUSY;
|
2006-07-18 17:59:59 +00:00
|
|
|
|
2021-03-02 21:11:30 +00:00
|
|
|
dev->can_match = true;
|
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
|
|
|
|
2018-06-12 08:24:13 +00:00
|
|
|
pm_runtime_get_suppliers(dev);
|
2015-07-27 15:03:58 +00:00
|
|
|
if (dev->parent)
|
|
|
|
pm_runtime_get_sync(dev->parent);
|
|
|
|
|
2009-08-18 21:38:32 +00:00
|
|
|
pm_runtime_barrier(dev);
|
2018-06-21 00:35:56 +00:00
|
|
|
if (initcall_debug)
|
|
|
|
ret = really_probe_debug(dev, drv);
|
|
|
|
else
|
|
|
|
ret = really_probe(dev, drv);
|
2013-04-10 15:00:48 +00:00
|
|
|
pm_request_idle(dev);
|
2006-07-18 17:59:59 +00:00
|
|
|
|
2015-07-27 15:03:58 +00:00
|
|
|
if (dev->parent)
|
|
|
|
pm_runtime_put(dev->parent);
|
|
|
|
|
2018-06-12 08:24:13 +00:00
|
|
|
pm_runtime_put_suppliers(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-21 18:52:54 +00:00
|
|
|
}
|
|
|
|
|
2021-06-17 14:22:12 +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
|
|
|
|
*
|
|
|
|
* This function returns -ENODEV if the device is not registered, -EBUSY if it
|
|
|
|
* already has a driver, 0 if the device is bound successfully and a positive
|
|
|
|
* (inverted) error code for failures from the ->probe method.
|
|
|
|
*
|
|
|
|
* This function must be called with @dev lock held. When called for a
|
|
|
|
* USB interface, @dev->parent lock must be held as well.
|
|
|
|
*
|
|
|
|
* If the device has a parent, runtime-resume the parent before driver probing.
|
|
|
|
*/
|
|
|
|
static int driver_probe_device(struct device_driver *drv, struct device *dev)
|
|
|
|
{
|
|
|
|
int trigger_count = atomic_read(&deferred_trigger_count);
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
atomic_inc(&probe_count);
|
|
|
|
ret = __driver_probe_device(drv, dev);
|
|
|
|
if (ret == -EPROBE_DEFER || ret == EPROBE_DEFER) {
|
|
|
|
driver_deferred_probe_add(dev);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Did a trigger occur while probing? Need to re-trigger if yes
|
|
|
|
*/
|
|
|
|
if (trigger_count != atomic_read(&deferred_trigger_count) &&
|
|
|
|
!defer_all_probes)
|
|
|
|
driver_deferred_probe_trigger();
|
|
|
|
}
|
|
|
|
atomic_dec(&probe_count);
|
|
|
|
wake_up_all(&probe_waitqueue);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-02-13 07:47:36 +00:00
|
|
|
static inline bool cmdline_requested_async_probing(const char *drv_name)
|
|
|
|
{
|
driver core: Add "*" wildcard support to driver_async_probe cmdline param
There's currently no way to use driver_async_probe kernel cmdline param
to enable default async probe for all drivers. So, add support for "*"
to match with all driver names. When "*" is used, all other drivers
listed in driver_async_probe are drivers that will NOT match the "*".
For example:
* driver_async_probe=drvA,drvB,drvC
drvA, drvB and drvC do asynchronous probing.
* driver_async_probe=*
All drivers do asynchronous probing except those that have set
PROBE_FORCE_SYNCHRONOUS flag.
* driver_async_probe=*,drvA,drvB,drvC
All drivers do asynchronous probing except drvA, drvB, drvC and those
that have set PROBE_FORCE_SYNCHRONOUS flag.
Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Feng Tang <feng.tang@intel.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20220504005344.117803-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-04 00:53:43 +00:00
|
|
|
bool async_drv;
|
|
|
|
|
|
|
|
async_drv = parse_option_str(async_probe_drv_names, drv_name);
|
|
|
|
|
|
|
|
return (async_probe_default != async_drv);
|
2019-02-13 07:47:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* The option format is "driver_async_probe=drv_name1,drv_name2,..." */
|
|
|
|
static int __init save_async_options(char *buf)
|
|
|
|
{
|
|
|
|
if (strlen(buf) >= ASYNC_DRV_NAMES_MAX_LEN)
|
2020-04-11 13:31:58 +00:00
|
|
|
pr_warn("Too long list of driver names for 'driver_async_probe'!\n");
|
2019-02-13 07:47:36 +00:00
|
|
|
|
|
|
|
strlcpy(async_probe_drv_names, buf, ASYNC_DRV_NAMES_MAX_LEN);
|
driver core: Add "*" wildcard support to driver_async_probe cmdline param
There's currently no way to use driver_async_probe kernel cmdline param
to enable default async probe for all drivers. So, add support for "*"
to match with all driver names. When "*" is used, all other drivers
listed in driver_async_probe are drivers that will NOT match the "*".
For example:
* driver_async_probe=drvA,drvB,drvC
drvA, drvB and drvC do asynchronous probing.
* driver_async_probe=*
All drivers do asynchronous probing except those that have set
PROBE_FORCE_SYNCHRONOUS flag.
* driver_async_probe=*,drvA,drvB,drvC
All drivers do asynchronous probing except drvA, drvB, drvC and those
that have set PROBE_FORCE_SYNCHRONOUS flag.
Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Feng Tang <feng.tang@intel.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20220504005344.117803-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-04 00:53:43 +00:00
|
|
|
async_probe_default = parse_option_str(async_probe_drv_names, "*");
|
|
|
|
|
2022-03-01 04:18:29 +00:00
|
|
|
return 1;
|
2019-02-13 07:47:36 +00:00
|
|
|
}
|
|
|
|
__setup("driver_async_probe=", save_async_options);
|
|
|
|
|
2015-03-30 23:20:04 +00:00
|
|
|
bool driver_allows_async_probing(struct device_driver *drv)
|
2005-03-24 18:50:24 +00:00
|
|
|
{
|
2015-03-30 23:20:06 +00:00
|
|
|
switch (drv->probe_type) {
|
|
|
|
case PROBE_PREFER_ASYNCHRONOUS:
|
2015-03-30 23:20:05 +00:00
|
|
|
return true;
|
|
|
|
|
2015-03-30 23:20:06 +00:00
|
|
|
case PROBE_FORCE_SYNCHRONOUS:
|
|
|
|
return false;
|
|
|
|
|
|
|
|
default:
|
2019-02-13 07:47:36 +00:00
|
|
|
if (cmdline_requested_async_probing(drv->name))
|
|
|
|
return true;
|
|
|
|
|
2015-05-21 22:49:37 +00:00
|
|
|
if (module_requested_async_probing(drv->owner))
|
2015-03-30 23:20:06 +00:00
|
|
|
return true;
|
2015-03-30 23:20:05 +00:00
|
|
|
|
2015-03-30 23:20:06 +00:00
|
|
|
return false;
|
|
|
|
}
|
2015-03-30 23:20:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
struct device_attach_data {
|
|
|
|
struct device *dev;
|
|
|
|
|
|
|
|
/*
|
2022-02-12 14:32:33 +00:00
|
|
|
* Indicates whether we are considering asynchronous probing or
|
2015-03-30 23:20:04 +00:00
|
|
|
* not. Only initial binding after device or driver registration
|
|
|
|
* (including deferral processing) may be done asynchronously, the
|
|
|
|
* rest is always synchronous, as we expect it is being done by
|
|
|
|
* request from userspace.
|
|
|
|
*/
|
|
|
|
bool check_async;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Indicates if we are binding synchronous or asynchronous drivers.
|
|
|
|
* When asynchronous probing is enabled we'll execute 2 passes
|
|
|
|
* over drivers: first pass doing synchronous probing and second
|
|
|
|
* doing asynchronous probing (if synchronous did not succeed -
|
|
|
|
* most likely because there was no driver requiring synchronous
|
|
|
|
* probing - and we found asynchronous driver during first pass).
|
|
|
|
* The 2 passes are done because we can't shoot asynchronous
|
|
|
|
* probe for given device and driver from bus_for_each_drv() since
|
|
|
|
* driver pointer is not guaranteed to stay valid once
|
|
|
|
* bus_for_each_drv() iterates to the next driver on the bus.
|
|
|
|
*/
|
|
|
|
bool want_async;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We'll set have_async to 'true' if, while scanning for matching
|
|
|
|
* driver, we'll encounter one that requests asynchronous probing.
|
|
|
|
*/
|
|
|
|
bool have_async;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int __device_attach_driver(struct device_driver *drv, void *_data)
|
|
|
|
{
|
|
|
|
struct device_attach_data *data = _data;
|
|
|
|
struct device *dev = data->dev;
|
|
|
|
bool async_allowed;
|
2016-02-15 08:25:06 +00:00
|
|
|
int ret;
|
2015-03-30 23:20:04 +00:00
|
|
|
|
2016-02-15 08:25:06 +00:00
|
|
|
ret = driver_match_device(drv, dev);
|
|
|
|
if (ret == 0) {
|
|
|
|
/* no match */
|
2009-01-21 15:27:47 +00:00
|
|
|
return 0;
|
2016-02-15 08:25:06 +00:00
|
|
|
} else if (ret == -EPROBE_DEFER) {
|
|
|
|
dev_dbg(dev, "Device match requests probe deferral\n");
|
2021-03-02 21:11:30 +00:00
|
|
|
dev->can_match = true;
|
2016-02-15 08:25:06 +00:00
|
|
|
driver_deferred_probe_add(dev);
|
|
|
|
} else if (ret < 0) {
|
2020-04-11 13:31:58 +00:00
|
|
|
dev_dbg(dev, "Bus failed to match device: %d\n", ret);
|
2016-02-15 08:25:06 +00:00
|
|
|
return ret;
|
|
|
|
} /* ret > 0 means positive match */
|
2009-01-21 15:27:47 +00:00
|
|
|
|
2015-03-30 23:20:04 +00:00
|
|
|
async_allowed = driver_allows_async_probing(drv);
|
|
|
|
|
|
|
|
if (async_allowed)
|
|
|
|
data->have_async = true;
|
|
|
|
|
|
|
|
if (data->check_async && async_allowed != data->want_async)
|
|
|
|
return 0;
|
|
|
|
|
2021-06-17 14:22:11 +00:00
|
|
|
/*
|
|
|
|
* Ignore errors returned by ->probe so that the next driver can try
|
|
|
|
* its luck.
|
|
|
|
*/
|
|
|
|
ret = driver_probe_device(drv, dev);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
return ret == 0;
|
2005-03-24 18:50:24 +00:00
|
|
|
}
|
|
|
|
|
2015-03-30 23:20:04 +00:00
|
|
|
static void __device_attach_async_helper(void *_dev, async_cookie_t cookie)
|
|
|
|
{
|
|
|
|
struct device *dev = _dev;
|
|
|
|
struct device_attach_data data = {
|
|
|
|
.dev = dev,
|
|
|
|
.check_async = true,
|
|
|
|
.want_async = true,
|
|
|
|
};
|
|
|
|
|
|
|
|
device_lock(dev);
|
|
|
|
|
2019-01-22 18:39:10 +00:00
|
|
|
/*
|
|
|
|
* Check if device has already been removed or claimed. This may
|
|
|
|
* happen with driver loading, device discovery/registration,
|
|
|
|
* and deferred probe processing happens all at once with
|
|
|
|
* multiple threads.
|
|
|
|
*/
|
|
|
|
if (dev->p->dead || dev->driver)
|
|
|
|
goto out_unlock;
|
|
|
|
|
2015-07-27 15:03:58 +00:00
|
|
|
if (dev->parent)
|
|
|
|
pm_runtime_get_sync(dev->parent);
|
|
|
|
|
2015-03-30 23:20:04 +00:00
|
|
|
bus_for_each_drv(dev->bus, NULL, &data, __device_attach_driver);
|
|
|
|
dev_dbg(dev, "async probe completed\n");
|
|
|
|
|
|
|
|
pm_request_idle(dev);
|
|
|
|
|
2015-07-27 15:03:58 +00:00
|
|
|
if (dev->parent)
|
|
|
|
pm_runtime_put(dev->parent);
|
2019-01-22 18:39:10 +00:00
|
|
|
out_unlock:
|
2015-03-30 23:20:04 +00:00
|
|
|
device_unlock(dev);
|
|
|
|
|
|
|
|
put_device(dev);
|
|
|
|
}
|
|
|
|
|
2015-05-20 23:36:31 +00:00
|
|
|
static int __device_attach(struct device *dev, bool allow_async)
|
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);
|
2020-07-08 13:27:01 +00:00
|
|
|
if (dev->p->dead) {
|
|
|
|
goto out_unlock;
|
|
|
|
} else if (dev->driver) {
|
2016-01-07 15:46:12 +00:00
|
|
|
if (device_is_bound(dev)) {
|
2011-04-12 17:05:37 +00:00
|
|
|
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 {
|
2015-03-30 23:20:04 +00:00
|
|
|
struct device_attach_data data = {
|
|
|
|
.dev = dev,
|
|
|
|
.check_async = allow_async,
|
|
|
|
.want_async = false,
|
|
|
|
};
|
|
|
|
|
2015-07-27 15:03:58 +00:00
|
|
|
if (dev->parent)
|
|
|
|
pm_runtime_get_sync(dev->parent);
|
|
|
|
|
2015-03-30 23:20:04 +00:00
|
|
|
ret = bus_for_each_drv(dev->bus, NULL, &data,
|
|
|
|
__device_attach_driver);
|
|
|
|
if (!ret && allow_async && data.have_async) {
|
|
|
|
/*
|
|
|
|
* If we could not find appropriate driver
|
|
|
|
* synchronously and we are allowed to do
|
|
|
|
* async probes and there are drivers that
|
|
|
|
* want to probe asynchronously, we'll
|
|
|
|
* try them.
|
|
|
|
*/
|
|
|
|
dev_dbg(dev, "scheduling asynchronous probe\n");
|
|
|
|
get_device(dev);
|
2019-01-22 18:39:37 +00:00
|
|
|
async_schedule_dev(__device_attach_async_helper, dev);
|
2015-03-30 23:20:04 +00:00
|
|
|
} else {
|
|
|
|
pm_request_idle(dev);
|
|
|
|
}
|
2015-07-27 15:03:58 +00:00
|
|
|
|
|
|
|
if (dev->parent)
|
|
|
|
pm_runtime_put(dev->parent);
|
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
|
|
|
}
|
2015-03-30 23:20:04 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* device_attach - try to attach device to a driver.
|
|
|
|
* @dev: device.
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*
|
|
|
|
* Returns 1 if the device was bound to a driver;
|
|
|
|
* 0 if no matching driver was found;
|
|
|
|
* -ENODEV if the device is not registered.
|
|
|
|
*
|
|
|
|
* When called for a USB interface, @dev->parent lock must be held.
|
|
|
|
*/
|
|
|
|
int device_attach(struct device *dev)
|
|
|
|
{
|
|
|
|
return __device_attach(dev, false);
|
|
|
|
}
|
2008-01-25 06:50:12 +00:00
|
|
|
EXPORT_SYMBOL_GPL(device_attach);
|
2005-03-24 18:50:24 +00:00
|
|
|
|
2015-03-30 23:20:04 +00:00
|
|
|
void device_initial_probe(struct device *dev)
|
|
|
|
{
|
|
|
|
__device_attach(dev, true);
|
|
|
|
}
|
|
|
|
|
2019-01-22 18:39:16 +00:00
|
|
|
/*
|
|
|
|
* __device_driver_lock - acquire locks needed to manipulate dev->drv
|
|
|
|
* @dev: Device we will update driver info for
|
|
|
|
* @parent: Parent device. Needed if the bus requires parent lock
|
|
|
|
*
|
|
|
|
* This function will take the required locks for manipulating dev->drv.
|
|
|
|
* Normally this will just be the @dev lock, but when called for a USB
|
|
|
|
* interface, @parent lock will be held as well.
|
|
|
|
*/
|
|
|
|
static void __device_driver_lock(struct device *dev, struct device *parent)
|
|
|
|
{
|
|
|
|
if (parent && dev->bus->need_parent_lock)
|
|
|
|
device_lock(parent);
|
|
|
|
device_lock(dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* __device_driver_unlock - release locks needed to manipulate dev->drv
|
|
|
|
* @dev: Device we will update driver info for
|
|
|
|
* @parent: Parent device. Needed if the bus requires parent lock
|
|
|
|
*
|
|
|
|
* This function will release the required locks for manipulating dev->drv.
|
2022-02-12 14:32:33 +00:00
|
|
|
* Normally this will just be the @dev lock, but when called for a
|
2019-01-22 18:39:16 +00:00
|
|
|
* USB interface, @parent lock will be released as well.
|
|
|
|
*/
|
|
|
|
static void __device_driver_unlock(struct device *dev, struct device *parent)
|
|
|
|
{
|
|
|
|
device_unlock(dev);
|
|
|
|
if (parent && dev->bus->need_parent_lock)
|
|
|
|
device_unlock(parent);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* device_driver_attach - attach a specific driver to a specific device
|
|
|
|
* @drv: Driver to attach
|
|
|
|
* @dev: Device to attach it to
|
|
|
|
*
|
|
|
|
* Manually attach driver to a device. Will acquire both @dev lock and
|
2021-06-17 14:22:11 +00:00
|
|
|
* @dev->parent lock if needed. Returns 0 on success, -ERR on failure.
|
2019-01-22 18:39:16 +00:00
|
|
|
*/
|
|
|
|
int device_driver_attach(struct device_driver *drv, struct device *dev)
|
|
|
|
{
|
2021-06-17 14:22:09 +00:00
|
|
|
int ret;
|
2019-01-22 18:39:16 +00:00
|
|
|
|
|
|
|
__device_driver_lock(dev, dev->parent);
|
2021-06-17 14:22:12 +00:00
|
|
|
ret = __driver_probe_device(drv, dev);
|
2019-01-22 18:39:16 +00:00
|
|
|
__device_driver_unlock(dev, dev->parent);
|
|
|
|
|
2021-06-17 14:22:11 +00:00
|
|
|
/* also return probe errors as normal negative errnos */
|
|
|
|
if (ret > 0)
|
|
|
|
ret = -ret;
|
2021-06-17 14:22:12 +00:00
|
|
|
if (ret == -EPROBE_DEFER)
|
|
|
|
return -EAGAIN;
|
2019-01-22 18:39:16 +00:00
|
|
|
return ret;
|
|
|
|
}
|
2021-06-17 14:22:13 +00:00
|
|
|
EXPORT_SYMBOL_GPL(device_driver_attach);
|
2019-01-22 18:39:16 +00:00
|
|
|
|
2019-01-22 18:39:21 +00:00
|
|
|
static void __driver_attach_async_helper(void *_dev, async_cookie_t cookie)
|
|
|
|
{
|
|
|
|
struct device *dev = _dev;
|
|
|
|
struct device_driver *drv;
|
2021-06-17 14:22:09 +00:00
|
|
|
int ret;
|
2019-01-22 18:39:21 +00:00
|
|
|
|
|
|
|
__device_driver_lock(dev, dev->parent);
|
|
|
|
drv = dev->p->async_driver;
|
2022-03-16 07:43:28 +00:00
|
|
|
dev->p->async_driver = NULL;
|
2021-06-17 14:22:09 +00:00
|
|
|
ret = driver_probe_device(drv, dev);
|
2019-01-22 18:39:21 +00:00
|
|
|
__device_driver_unlock(dev, dev->parent);
|
|
|
|
|
|
|
|
dev_dbg(dev, "driver %s async attach completed: %d\n", drv->name, ret);
|
|
|
|
|
|
|
|
put_device(dev);
|
|
|
|
}
|
|
|
|
|
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;
|
2016-02-15 08:25:06 +00:00
|
|
|
int 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
|
|
|
|
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
|
2016-02-15 08:25:06 +00:00
|
|
|
ret = driver_match_device(drv, dev);
|
|
|
|
if (ret == 0) {
|
|
|
|
/* no match */
|
2008-09-14 15:32:06 +00:00
|
|
|
return 0;
|
2016-02-15 08:25:06 +00:00
|
|
|
} else if (ret == -EPROBE_DEFER) {
|
|
|
|
dev_dbg(dev, "Device match requests probe deferral\n");
|
2021-03-02 21:11:30 +00:00
|
|
|
dev->can_match = true;
|
2016-02-15 08:25:06 +00:00
|
|
|
driver_deferred_probe_add(dev);
|
|
|
|
} else if (ret < 0) {
|
2020-04-11 13:31:58 +00:00
|
|
|
dev_dbg(dev, "Bus failed to match device: %d\n", ret);
|
2016-02-15 08:25:06 +00:00
|
|
|
return ret;
|
|
|
|
} /* ret > 0 means positive match */
|
2008-09-14 15:32:06 +00:00
|
|
|
|
2019-01-22 18:39:21 +00:00
|
|
|
if (driver_allows_async_probing(drv)) {
|
|
|
|
/*
|
|
|
|
* Instead of probing the device synchronously we will
|
|
|
|
* probe it asynchronously to allow for more parallelism.
|
|
|
|
*
|
|
|
|
* We only take the device lock here in order to guarantee
|
|
|
|
* that the dev->driver and async_driver fields are protected
|
|
|
|
*/
|
|
|
|
dev_dbg(dev, "probing driver %s asynchronously\n", drv->name);
|
|
|
|
device_lock(dev);
|
2022-03-16 07:43:28 +00:00
|
|
|
if (!dev->driver && !dev->p->async_driver) {
|
2019-01-22 18:39:21 +00:00
|
|
|
get_device(dev);
|
|
|
|
dev->p->async_driver = drv;
|
2019-01-22 18:39:37 +00:00
|
|
|
async_schedule_dev(__driver_attach_async_helper, dev);
|
2019-01-22 18:39:21 +00:00
|
|
|
}
|
|
|
|
device_unlock(dev);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-06-17 14:22:11 +00:00
|
|
|
__device_driver_lock(dev, dev->parent);
|
|
|
|
driver_probe_device(drv, dev);
|
|
|
|
__device_driver_unlock(dev, 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
|
|
|
*/
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-30 16:32:16 +00:00
|
|
|
static void __device_release_driver(struct device *dev, struct device *parent)
|
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) {
|
2020-10-22 15:38:22 +00:00
|
|
|
pm_runtime_get_sync(dev);
|
|
|
|
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-30 16:32:16 +00:00
|
|
|
while (device_links_busy(dev)) {
|
2019-01-22 18:39:16 +00:00
|
|
|
__device_driver_unlock(dev, parent);
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-30 16:32:16 +00:00
|
|
|
|
|
|
|
device_links_unbind_consumers(dev);
|
|
|
|
|
2019-01-22 18:39:16 +00:00
|
|
|
__device_driver_lock(dev, parent);
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-30 16:32:16 +00:00
|
|
|
/*
|
|
|
|
* A concurrent invocation of the same function might
|
|
|
|
* have released the driver successfully while this one
|
|
|
|
* was waiting, so check for that.
|
|
|
|
*/
|
2020-10-22 15:38:22 +00:00
|
|
|
if (dev->driver != drv) {
|
|
|
|
pm_runtime_put(dev);
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-30 16:32:16 +00:00
|
|
|
return;
|
2020-10-22 15:38:22 +00:00
|
|
|
}
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-30 16:32:16 +00:00
|
|
|
}
|
|
|
|
|
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);
|
|
|
|
|
2013-11-07 00:51:15 +00:00
|
|
|
pm_runtime_put_sync(dev);
|
2011-04-28 22:33:45 +00:00
|
|
|
|
2022-02-23 22:52:57 +00:00
|
|
|
device_remove(dev);
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-30 16:32:16 +00:00
|
|
|
|
|
|
|
device_links_driver_cleanup(dev);
|
2022-02-23 22:52:56 +00:00
|
|
|
device_unbind_cleanup(dev);
|
driver core / PM: Add PM domain callbacks for device setup/cleanup
If PM domains are in use, it may be necessary to prepare the code
handling a PM domain for driver probing. For example, in some
cases device drivers rely on the ability to power on the devices
with the help of the IO runtime PM framework and the PM domain
code needs to be ready for that. Also, if that code has not been
fully initialized yet, the driver probing should be deferred.
Moreover, after the probing is complete, it may be necessary to
put the PM domain in question into the state reflecting the current
needs of the devices in it, for example, so that power is not drawn
in vain. The same should be done after removing a driver from
a device, as the PM domain state may need to be changed to reflect
the new situation.
For these reasons, introduce new PM domain callbacks, ->activate,
->sync and ->dismiss called, respectively, before probing for a
device driver, after the probing has completed successfully and
if the probing has failed or the driver has been removed.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-20 12:59:27 +00:00
|
|
|
|
2008-12-16 20:25:49 +00:00
|
|
|
klist_remove(&dev->p->knode_driver);
|
2016-01-07 15:46:14 +00:00
|
|
|
device_pm_check_callbacks(dev);
|
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);
|
2017-07-20 00:24:30 +00:00
|
|
|
|
|
|
|
kobject_uevent(&dev->kobj, KOBJ_UNBIND);
|
[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
|
|
|
}
|
|
|
|
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-30 16:32:16 +00:00
|
|
|
void device_release_driver_internal(struct device *dev,
|
|
|
|
struct device_driver *drv,
|
|
|
|
struct device *parent)
|
2016-10-10 12:37:56 +00:00
|
|
|
{
|
2019-01-22 18:39:16 +00:00
|
|
|
__device_driver_lock(dev, parent);
|
2016-10-10 12:37:56 +00:00
|
|
|
|
|
|
|
if (!drv || drv == dev->driver)
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-30 16:32:16 +00:00
|
|
|
__device_release_driver(dev, parent);
|
2016-10-10 12:37:56 +00:00
|
|
|
|
2019-01-22 18:39:16 +00:00
|
|
|
__device_driver_unlock(dev, parent);
|
2016-10-10 12:37:56 +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.
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-30 16:32:16 +00:00
|
|
|
*
|
|
|
|
* If this function is to be called with @dev->parent lock held, ensure that
|
|
|
|
* the device's consumers are unbound in advance or that their locks can be
|
|
|
|
* acquired under the @dev->parent lock.
|
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.
|
|
|
|
*/
|
2016-10-10 12:37:56 +00:00
|
|
|
device_release_driver_internal(dev, NULL, NULL);
|
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
|
|
|
|
2019-01-22 18:39:16 +00:00
|
|
|
/**
|
|
|
|
* device_driver_detach - detach driver from a specific device
|
|
|
|
* @dev: device to detach driver from
|
|
|
|
*
|
|
|
|
* Detach driver from device. Will acquire both @dev lock and @dev->parent
|
|
|
|
* lock if needed.
|
|
|
|
*/
|
|
|
|
void device_driver_detach(struct device *dev)
|
|
|
|
{
|
|
|
|
device_release_driver_internal(dev, NULL, dev->parent);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
2018-11-29 00:32:11 +00:00
|
|
|
if (driver_allows_async_probing(drv))
|
|
|
|
async_synchronize_full();
|
|
|
|
|
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;
|
|
|
|
}
|
2020-03-24 12:20:23 +00:00
|
|
|
dev_prv = list_last_entry(&drv->p->klist_devices.k_list,
|
2008-12-16 20:25:49 +00:00
|
|
|
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);
|
2016-10-10 12:37:56 +00:00
|
|
|
device_release_driver_internal(dev, drv, dev->parent);
|
2005-05-06 19:38:33 +00:00
|
|
|
put_device(dev);
|
|
|
|
}
|
2005-03-21 18:52:54 +00:00
|
|
|
}
|