2017-11-08 00:30:07 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2005-03-22 02:52:54 +08:00
|
|
|
/*
|
2008-01-25 14:50:12 +08:00
|
|
|
* drivers/base/dd.c - The core device/driver interactions.
|
2005-03-22 02:52:54 +08:00
|
|
|
*
|
2008-01-25 14:50:12 +08: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-22 02:52:54 +08:00
|
|
|
*
|
2008-01-25 14:50:12 +08: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-22 02:52:54 +08:00
|
|
|
*
|
2008-01-25 14:50:12 +08:00
|
|
|
* Copyright (c) 2002-5 Patrick Mochel
|
|
|
|
* Copyright (c) 2002-3 Open Source Development Labs
|
2009-05-12 05:16:57 +08:00
|
|
|
* Copyright (c) 2007-2009 Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
* Copyright (c) 2007-2009 Novell Inc.
|
2005-03-22 02:52:54 +08:00
|
|
|
*/
|
|
|
|
|
2018-07-08 21:34:59 +08:00
|
|
|
#include <linux/debugfs.h>
|
2005-03-22 02:52:54 +08:00
|
|
|
#include <linux/device.h>
|
2009-02-14 08:59:06 +08:00
|
|
|
#include <linux/delay.h>
|
2020-09-22 21:31:03 +08:00
|
|
|
#include <linux/dma-map-ops.h>
|
2017-07-26 07:31:59 +08:00
|
|
|
#include <linux/init.h>
|
2005-03-22 02:52:54 +08:00
|
|
|
#include <linux/module.h>
|
2006-07-19 01:59:59 +08:00
|
|
|
#include <linux/kthread.h>
|
2006-10-28 02:42:37 +08:00
|
|
|
#include <linux/wait.h>
|
2009-02-14 08:59:06 +08:00
|
|
|
#include <linux/async.h>
|
2009-08-19 05:38:32 +08: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-23 01:56:14 +08:00
|
|
|
#include <linux/pinctrl/devinfo.h>
|
2020-07-13 22:43:22 +08:00
|
|
|
#include <linux/slab.h>
|
2005-03-22 02:52:54 +08:00
|
|
|
|
|
|
|
#include "base.h"
|
|
|
|
#include "power/power.h"
|
|
|
|
|
2012-03-05 23:47:41 +08: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-09 04:17:22 +08:00
|
|
|
* of the (struct device*)->p->deferred_probe pointers are manipulated
|
2012-03-05 23:47:41 +08:00
|
|
|
*/
|
|
|
|
static DEFINE_MUTEX(deferred_probe_mutex);
|
|
|
|
static LIST_HEAD(deferred_probe_pending_list);
|
|
|
|
static LIST_HEAD(deferred_probe_active_list);
|
2014-04-29 19:05:22 +08:00
|
|
|
static atomic_t deferred_trigger_count = ATOMIC_INIT(0);
|
2018-07-09 23:41:48 +08:00
|
|
|
static bool initcalls_done;
|
2012-03-05 23:47:41 +08:00
|
|
|
|
2019-02-13 15:47:36 +08: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 08:53:43 +08:00
|
|
|
static bool async_probe_default;
|
2019-02-13 15:47:36 +08:00
|
|
|
|
2015-11-10 17:42:34 +08: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 23:37:13 +08: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 21:56:36 +08:00
|
|
|
/*
|
2012-03-05 23:47:41 +08: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-09 04:17:22 +08:00
|
|
|
struct device_private *private;
|
2012-03-05 23:47:41 +08: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-09 04:17:22 +08: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 23:47:41 +08:00
|
|
|
|
|
|
|
get_device(dev);
|
|
|
|
|
2021-03-23 23:37:13 +08:00
|
|
|
__device_set_deferred_probe_reason(dev, NULL);
|
2021-03-19 19:04:57 +08:00
|
|
|
|
2012-03-09 04:20:37 +08:00
|
|
|
/*
|
|
|
|
* Drop the mutex while probing each device; the probe path may
|
|
|
|
* manipulate the deferred list
|
|
|
|
*/
|
2012-03-05 23:47:41 +08:00
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
2012-07-05 21:04:44 +08: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-11 07:57:06 +08:00
|
|
|
device_pm_move_to_tail(dev);
|
2012-07-05 21:04:44 +08:00
|
|
|
|
2012-03-05 23:47:41 +08:00
|
|
|
dev_dbg(dev, "Retrying from deferred list\n");
|
2018-06-21 08:35:56 +08:00
|
|
|
bus_probe_device(dev);
|
2012-03-05 23:47:41 +08: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 08:59:42 +08:00
|
|
|
void driver_deferred_probe_add(struct device *dev)
|
2012-03-05 23:47:41 +08:00
|
|
|
{
|
2021-03-03 05:11:30 +08:00
|
|
|
if (!dev->can_match)
|
|
|
|
return;
|
|
|
|
|
2012-03-05 23:47:41 +08:00
|
|
|
mutex_lock(&deferred_probe_mutex);
|
2012-03-09 04:17:22 +08:00
|
|
|
if (list_empty(&dev->p->deferred_probe)) {
|
2012-03-05 23:47:41 +08:00
|
|
|
dev_dbg(dev, "Added to deferred list\n");
|
2012-05-30 09:46:06 +08:00
|
|
|
list_add_tail(&dev->p->deferred_probe, &deferred_probe_pending_list);
|
2012-03-05 23:47:41 +08:00
|
|
|
}
|
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
void driver_deferred_probe_del(struct device *dev)
|
|
|
|
{
|
|
|
|
mutex_lock(&deferred_probe_mutex);
|
2012-03-09 04:17:22 +08:00
|
|
|
if (!list_empty(&dev->p->deferred_probe)) {
|
2012-03-05 23:47:41 +08:00
|
|
|
dev_dbg(dev, "Removed from deferred list\n");
|
2012-03-09 04:17:22 +08:00
|
|
|
list_del_init(&dev->p->deferred_probe);
|
2021-03-23 23:37:13 +08:00
|
|
|
__device_set_deferred_probe_reason(dev, NULL);
|
2012-03-05 23:47:41 +08:00
|
|
|
}
|
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
|
|
|
}
|
|
|
|
|
2022-03-09 21:54:18 +08:00
|
|
|
static bool driver_deferred_probe_enable;
|
2012-03-05 23:47:41 +08: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 19:05:22 +08: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-26 02:16:11 +08:00
|
|
|
* trigger event has already occurred and will be stuck there.
|
2014-04-29 19:05:22 +08: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 23:47:41 +08:00
|
|
|
*/
|
2022-06-01 15:07:00 +08:00
|
|
|
void driver_deferred_probe_trigger(void)
|
2020-11-21 10:02:18 +08:00
|
|
|
{
|
2020-11-21 10:02:19 +08:00
|
|
|
if (!driver_deferred_probe_enable)
|
|
|
|
return;
|
|
|
|
|
2012-03-09 04:20:37 +08:00
|
|
|
/*
|
|
|
|
* A successful probe means that all the devices in the pending list
|
2012-03-05 23:47:41 +08:00
|
|
|
* should be triggered to be reprobed. Move all the deferred devices
|
2012-03-09 04:20:37 +08:00
|
|
|
* into the active list so they can be retried by the workqueue
|
|
|
|
*/
|
2012-03-05 23:47:41 +08:00
|
|
|
mutex_lock(&deferred_probe_mutex);
|
2014-04-29 19:05:22 +08:00
|
|
|
atomic_inc(&deferred_trigger_count);
|
2012-03-05 23:47:41 +08:00
|
|
|
list_splice_tail_init(&deferred_probe_pending_list,
|
|
|
|
&deferred_probe_active_list);
|
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
|
|
|
|
2012-03-09 04:20:37 +08:00
|
|
|
/*
|
|
|
|
* Kick the re-probe thread. It may already be scheduled, but it is
|
|
|
|
* safe to kick it again.
|
|
|
|
*/
|
2021-03-24 19:01:38 +08:00
|
|
|
queue_work(system_unbound_wq, &deferred_probe_work);
|
2012-03-05 23:47:41 +08:00
|
|
|
}
|
|
|
|
|
2015-11-10 17:42:34 +08:00
|
|
|
/**
|
2018-11-06 15:41:27 +08:00
|
|
|
* device_block_probing() - Block/defer device's probes
|
2015-11-10 17:42:34 +08: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 22:43:22 +08: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 23:37:13 +08:00
|
|
|
char *reason;
|
2020-07-13 22:43:22 +08:00
|
|
|
|
|
|
|
mutex_lock(&deferred_probe_mutex);
|
|
|
|
|
2021-03-23 23:37:13 +08:00
|
|
|
reason = kasprintf(GFP_KERNEL, "%s: %pV", drv, vaf);
|
|
|
|
__device_set_deferred_probe_reason(dev, reason);
|
2020-07-13 22:43:22 +08:00
|
|
|
|
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
|
|
|
}
|
|
|
|
|
2018-07-08 21:34:59 +08: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 22:43:22 +08:00
|
|
|
seq_printf(s, "%s\t%s", dev_name(curr->device),
|
|
|
|
curr->device->p->deferred_probe_reason ?: "\n");
|
2018-07-08 21:34:59 +08:00
|
|
|
|
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
DEFINE_SHOW_ATTRIBUTE(deferred_devs);
|
|
|
|
|
2022-06-01 15:07:02 +08:00
|
|
|
#ifdef CONFIG_MODULES
|
|
|
|
int driver_deferred_probe_timeout = 10;
|
|
|
|
#else
|
2020-04-23 04:32:43 +08:00
|
|
|
int driver_deferred_probe_timeout;
|
2022-06-01 15:07:02 +08:00
|
|
|
#endif
|
|
|
|
|
2020-02-25 13:08:27 +08:00
|
|
|
EXPORT_SYMBOL_GPL(driver_deferred_probe_timeout);
|
|
|
|
|
2018-07-09 23:41:48 +08:00
|
|
|
static int __init deferred_probe_timeout_setup(char *str)
|
|
|
|
{
|
2018-10-28 14:39:11 +08:00
|
|
|
int timeout;
|
|
|
|
|
|
|
|
if (!kstrtoint(str, 10, &timeout))
|
2020-02-25 13:08:27 +08:00
|
|
|
driver_deferred_probe_timeout = timeout;
|
2018-07-09 23:41:48 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
__setup("deferred_probe_timeout=", deferred_probe_timeout_setup);
|
|
|
|
|
2022-08-20 06:16:11 +08:00
|
|
|
/**
|
|
|
|
* driver_deferred_probe_check_state() - Check deferred probe state
|
|
|
|
* @dev: device to check
|
|
|
|
*
|
|
|
|
* Return:
|
|
|
|
* * -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.
|
|
|
|
*
|
|
|
|
* 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)
|
|
|
|
{
|
|
|
|
if (!IS_ENABLED(CONFIG_MODULES) && initcalls_done) {
|
|
|
|
dev_warn(dev, "ignoring dependency for device, assuming no driver\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!driver_deferred_probe_timeout && initcalls_done) {
|
|
|
|
dev_warn(dev, "deferred probe timeout, ignoring dependency\n");
|
|
|
|
return -ETIMEDOUT;
|
|
|
|
}
|
|
|
|
|
|
|
|
return -EPROBE_DEFER;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(driver_deferred_probe_check_state);
|
|
|
|
|
2018-07-09 23:41:48 +08:00
|
|
|
static void deferred_probe_timeout_work_func(struct work_struct *work)
|
|
|
|
{
|
2021-04-02 12:03:40 +08:00
|
|
|
struct device_private *p;
|
2018-07-09 23:41:48 +08:00
|
|
|
|
2021-04-02 12:03:41 +08:00
|
|
|
fw_devlink_drivers_done();
|
|
|
|
|
2022-08-20 06:16:11 +08:00
|
|
|
driver_deferred_probe_timeout = 0;
|
2018-07-09 23:41:48 +08:00
|
|
|
driver_deferred_probe_trigger();
|
|
|
|
flush_work(&deferred_probe_work);
|
|
|
|
|
2021-04-02 12:03:40 +08: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);
|
2018-07-09 23:41:48 +08:00
|
|
|
}
|
|
|
|
static DECLARE_DELAYED_WORK(deferred_probe_timeout_work, deferred_probe_timeout_work_func);
|
|
|
|
|
2022-04-30 06:09:32 +08: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 23:47:41 +08: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 22:24:00 +08:00
|
|
|
debugfs_create_file("devices_deferred", 0444, NULL, NULL,
|
|
|
|
&deferred_devs_fops);
|
2018-07-08 21:34:59 +08:00
|
|
|
|
2012-03-05 23:47:41 +08:00
|
|
|
driver_deferred_probe_enable = true;
|
|
|
|
driver_deferred_probe_trigger();
|
2013-02-15 02:14:27 +08:00
|
|
|
/* Sort as many dependencies as possible before exiting initcalls */
|
2016-08-31 01:15:34 +08:00
|
|
|
flush_work(&deferred_probe_work);
|
2018-07-09 23:41:48 +08:00
|
|
|
initcalls_done = true;
|
|
|
|
|
2021-04-02 12:03:41 +08:00
|
|
|
if (!IS_ENABLED(CONFIG_MODULES))
|
|
|
|
fw_devlink_drivers_done();
|
|
|
|
|
2018-07-09 23:41:48 +08: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 13:08:27 +08:00
|
|
|
if (driver_deferred_probe_timeout > 0) {
|
2018-07-09 23:41:48 +08:00
|
|
|
schedule_delayed_work(&deferred_probe_timeout_work,
|
2020-02-25 13:08:27 +08:00
|
|
|
driver_deferred_probe_timeout * HZ);
|
2018-07-09 23:41:48 +08:00
|
|
|
}
|
2012-03-05 23:47:41 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
late_initcall(deferred_probe_initcall);
|
2005-03-22 02:52:54 +08:00
|
|
|
|
2018-07-08 21:34:59 +08:00
|
|
|
static void __exit deferred_probe_exit(void)
|
|
|
|
{
|
2021-02-16 22:24:00 +08:00
|
|
|
debugfs_remove_recursive(debugfs_lookup("devices_deferred", NULL));
|
2018-07-08 21:34:59 +08:00
|
|
|
}
|
|
|
|
__exitcall(deferred_probe_exit);
|
|
|
|
|
2016-01-07 23:46:12 +08: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 08:51:44 +08:00
|
|
|
return dev->p && klist_node_attached(&dev->p->knode_driver);
|
2016-01-07 23:46:12 +08:00
|
|
|
}
|
|
|
|
|
2006-10-08 03:55:55 +08:00
|
|
|
static void driver_bound(struct device *dev)
|
2005-03-22 02:52:54 +08:00
|
|
|
{
|
2016-01-07 23:46:12 +08:00
|
|
|
if (device_is_bound(dev)) {
|
2020-04-11 21:31:58 +08:00
|
|
|
pr_warn("%s: device %s already bound\n",
|
2008-03-05 08:41:05 +08:00
|
|
|
__func__, kobject_name(&dev->kobj));
|
2006-10-08 03:55:55 +08:00
|
|
|
return;
|
2006-08-15 13:43:20 +08:00
|
|
|
}
|
2005-09-22 15:47:11 +08:00
|
|
|
|
2014-04-17 08:12:30 +08: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 11:44:59 +08:00
|
|
|
|
2010-03-07 00:50:14 +08: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-31 00:32:16 +08:00
|
|
|
device_links_driver_bound(dev);
|
2010-03-07 00:50:14 +08:00
|
|
|
|
2016-01-07 23:46:14 +08:00
|
|
|
device_pm_check_callbacks(dev);
|
|
|
|
|
2012-03-09 04:20:37 +08:00
|
|
|
/*
|
|
|
|
* Make sure the device is no longer in one of the deferred lists and
|
|
|
|
* kick off retrying all pending devices
|
|
|
|
*/
|
2012-03-05 23:47:41 +08: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 11:44:59 +08:00
|
|
|
if (dev->bus)
|
2007-11-02 10:41:16 +08: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 11:44:59 +08:00
|
|
|
BUS_NOTIFY_BOUND_DRIVER, dev);
|
2017-07-20 08:24:30 +08:00
|
|
|
|
|
|
|
kobject_uevent(&dev->kobj, KOBJ_BIND);
|
2006-10-08 03:55:55 +08:00
|
|
|
}
|
|
|
|
|
2018-01-11 16:36:38 +08: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 17:55:25 +08:00
|
|
|
dev->driver->coredump(dev);
|
2018-01-11 16:36:38 +08:00
|
|
|
device_unlock(dev);
|
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_WO(coredump);
|
|
|
|
|
2006-10-08 03:55:55 +08:00
|
|
|
static int driver_sysfs_add(struct device *dev)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2010-07-23 18:56:18 +08:00
|
|
|
if (dev->bus)
|
|
|
|
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
|
|
|
|
BUS_NOTIFY_BIND_DRIVER, dev);
|
|
|
|
|
2007-11-29 07:59:15 +08:00
|
|
|
ret = sysfs_create_link(&dev->driver->p->kobj, &dev->kobj,
|
2018-01-11 16:36:38 +08: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 10:34:05 +08: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 16:36:38 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
sysfs_remove_link(&dev->kobj, "driver");
|
|
|
|
|
|
|
|
rm_dev:
|
|
|
|
sysfs_remove_link(&dev->driver->p->kobj,
|
2005-03-22 02:52:54 +08:00
|
|
|
kobject_name(&dev->kobj));
|
2018-01-11 16:36:38 +08:00
|
|
|
|
|
|
|
fail:
|
2006-08-15 13:43:20 +08:00
|
|
|
return ret;
|
2005-03-22 02:52:54 +08:00
|
|
|
}
|
|
|
|
|
2006-10-08 03:55:55 +08:00
|
|
|
static void driver_sysfs_remove(struct device *dev)
|
|
|
|
{
|
|
|
|
struct device_driver *drv = dev->driver;
|
|
|
|
|
|
|
|
if (drv) {
|
2018-01-11 16:36:38 +08:00
|
|
|
if (drv->coredump)
|
|
|
|
device_remove_file(dev, &dev_attr_coredump);
|
2007-11-29 07:59:15 +08:00
|
|
|
sysfs_remove_link(&drv->p->kobj, kobject_name(&dev->kobj));
|
2006-10-08 03:55:55 +08:00
|
|
|
sysfs_remove_link(&dev->kobj, "driver");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2008-01-25 14:50:12 +08:00
|
|
|
* device_bind_driver - bind a driver to one device.
|
|
|
|
* @dev: device.
|
2006-10-08 03:55:55 +08:00
|
|
|
*
|
2008-01-25 14:50:12 +08:00
|
|
|
* Allow manual attachment of a driver to a device.
|
|
|
|
* Caller must have already set @dev->driver.
|
2006-10-08 03:55:55 +08:00
|
|
|
*
|
2020-07-08 20:12:22 +08: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-08 03:55:55 +08:00
|
|
|
*
|
2010-02-18 02:57:05 +08:00
|
|
|
* This function must be called with the device lock held.
|
2021-06-17 22:22:13 +08:00
|
|
|
*
|
|
|
|
* Callers should prefer to use device_driver_attach() instead.
|
2006-10-08 03:55:55 +08:00
|
|
|
*/
|
|
|
|
int device_bind_driver(struct device *dev)
|
|
|
|
{
|
2006-11-27 17:35:12 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = driver_sysfs_add(dev);
|
2021-03-03 05:11:31 +08:00
|
|
|
if (!ret) {
|
|
|
|
device_links_force_bind(dev);
|
2006-11-27 17:35:12 +08:00
|
|
|
driver_bound(dev);
|
2021-03-03 05:11:31 +08:00
|
|
|
}
|
2015-12-05 05:49:17 +08:00
|
|
|
else if (dev->bus)
|
|
|
|
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
|
|
|
|
BUS_NOTIFY_DRIVER_NOT_BOUND, dev);
|
2006-11-27 17:35:12 +08:00
|
|
|
return ret;
|
2006-10-08 03:55:55 +08:00
|
|
|
}
|
2008-01-25 14:50:12 +08:00
|
|
|
EXPORT_SYMBOL_GPL(device_bind_driver);
|
2006-10-08 03:55:55 +08:00
|
|
|
|
2006-07-19 01:59:59 +08:00
|
|
|
static atomic_t probe_count = ATOMIC_INIT(0);
|
2006-10-28 02:42:37 +08:00
|
|
|
static DECLARE_WAIT_QUEUE_HEAD(probe_waitqueue);
|
|
|
|
|
2020-05-22 03:17:59 +08: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-17 04:40:42 +08: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-17 04:40:39 +08:00
|
|
|
return sysfs_emit(buf, "%u\n", val);
|
2020-05-22 03:17:59 +08:00
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(state_synced);
|
|
|
|
|
2022-02-24 06:52:56 +08: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 22:22:10 +08:00
|
|
|
|
2022-02-24 06:52:57 +08: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 22:22:10 +08: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 08:15:25 +08:00
|
|
|
static int really_probe(struct device *dev, struct device_driver *drv)
|
2005-03-22 02:52:54 +08:00
|
|
|
{
|
2016-10-12 02:41:02 +08:00
|
|
|
bool test_remove = IS_ENABLED(CONFIG_DEBUG_TEST_DRIVER_REMOVE) &&
|
|
|
|
!drv->suppress_bind_attrs;
|
2022-06-01 15:07:00 +08:00
|
|
|
int ret, link_ret;
|
2005-03-22 02:52:54 +08:00
|
|
|
|
2015-11-10 17:42:34 +08:00
|
|
|
if (defer_all_probes) {
|
|
|
|
/*
|
|
|
|
* Value of defer_all_probes can be set only by
|
2018-11-06 15:41:27 +08:00
|
|
|
* device_block_probing() which, in turn, will call
|
2015-11-10 17:42:34 +08: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 22:22:12 +08:00
|
|
|
return -EPROBE_DEFER;
|
2015-11-10 17:42:34 +08:00
|
|
|
}
|
|
|
|
|
2022-06-01 15:07:00 +08:00
|
|
|
link_ret = device_links_check_suppliers(dev);
|
|
|
|
if (link_ret == -EPROBE_DEFER)
|
|
|
|
return link_ret;
|
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-31 00:32:16 +08:00
|
|
|
|
2007-11-29 15:49:41 +08:00
|
|
|
pr_debug("bus: '%s': %s: probing driver %s with device %s\n",
|
2008-10-30 08:36:48 +08:00
|
|
|
drv->bus->name, __func__, drv->name, dev_name(dev));
|
2019-12-06 21:22:19 +08:00
|
|
|
if (!list_empty(&dev->devres_head)) {
|
|
|
|
dev_crit(dev, "Resources present before probing\n");
|
2020-07-13 10:12:54 +08:00
|
|
|
ret = -EBUSY;
|
|
|
|
goto done;
|
2019-12-06 21:22:19 +08:00
|
|
|
}
|
2005-03-22 02:52:54 +08:00
|
|
|
|
2016-08-11 23:20:58 +08:00
|
|
|
re_probe:
|
2005-03-22 02:52:54 +08: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-23 01:56:14 +08:00
|
|
|
|
|
|
|
/* If using pinctrl, bind pins now before probing */
|
|
|
|
ret = pinctrl_bind_pins(dev);
|
|
|
|
if (ret)
|
2015-12-05 05:49:17 +08: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-23 01:56:14 +08:00
|
|
|
|
2018-08-24 15:40:24 +08:00
|
|
|
if (dev->bus->dma_configure) {
|
|
|
|
ret = dev->bus->dma_configure(dev);
|
|
|
|
if (ret)
|
2021-12-31 11:39:01 +08:00
|
|
|
goto pinctrl_bind_failed;
|
2018-08-24 15:40:24 +08:00
|
|
|
}
|
2017-04-10 19:21:01 +08:00
|
|
|
|
2021-07-07 15:43:01 +08:00
|
|
|
ret = driver_sysfs_add(dev);
|
|
|
|
if (ret) {
|
2020-04-11 21:31:58 +08:00
|
|
|
pr_err("%s: driver_sysfs_add(%s) failed\n",
|
|
|
|
__func__, dev_name(dev));
|
2021-12-31 11:39:00 +08:00
|
|
|
goto sysfs_failed;
|
2006-10-08 03:55:55 +08: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 20:59:27 +08:00
|
|
|
if (dev->pm_domain && dev->pm_domain->activate) {
|
|
|
|
ret = dev->pm_domain->activate(dev);
|
|
|
|
if (ret)
|
|
|
|
goto probe_failed;
|
|
|
|
}
|
|
|
|
|
2021-06-17 22:22:12 +08:00
|
|
|
ret = call_driver_probe(dev, drv);
|
|
|
|
if (ret) {
|
2022-06-01 15:07:00 +08:00
|
|
|
/*
|
|
|
|
* If fw_devlink_best_effort is active (denoted by -EAGAIN), the
|
|
|
|
* device might actually probe properly once some of its missing
|
|
|
|
* suppliers have probed. So, treat this as if the driver
|
|
|
|
* returned -EPROBE_DEFER.
|
|
|
|
*/
|
|
|
|
if (link_ret == -EAGAIN)
|
|
|
|
ret = -EPROBE_DEFER;
|
|
|
|
|
2021-06-17 22:22:10 +08:00
|
|
|
/*
|
2021-06-17 22:22:11 +08:00
|
|
|
* Return probe errors as positive values so that the callers
|
|
|
|
* can distinguish them from other errors.
|
2021-06-17 22:22:10 +08:00
|
|
|
*/
|
2021-06-17 22:22:12 +08:00
|
|
|
ret = -ret;
|
2021-06-17 22:22:10 +08:00
|
|
|
goto probe_failed;
|
2006-08-15 13:43:20 +08:00
|
|
|
}
|
2006-10-08 03:55:55 +08:00
|
|
|
|
2021-07-07 15:43:01 +08:00
|
|
|
ret = device_add_groups(dev, drv->dev_groups);
|
|
|
|
if (ret) {
|
2019-07-31 20:43:40 +08:00
|
|
|
dev_err(dev, "device_add_groups() failed\n");
|
|
|
|
goto dev_groups_failed;
|
|
|
|
}
|
|
|
|
|
2021-07-07 15:43:01 +08: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-22 03:17:59 +08:00
|
|
|
}
|
|
|
|
|
2016-08-11 23:20:58 +08:00
|
|
|
if (test_remove) {
|
|
|
|
test_remove = false;
|
|
|
|
|
2022-02-24 06:52:57 +08:00
|
|
|
device_remove(dev);
|
2016-08-11 23:20:58 +08:00
|
|
|
driver_sysfs_remove(dev);
|
2022-02-24 06:52:56 +08:00
|
|
|
device_unbind_cleanup(dev);
|
2016-08-11 23:20:58 +08:00
|
|
|
|
|
|
|
goto re_probe;
|
|
|
|
}
|
|
|
|
|
2015-10-21 12:15:06 +08: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 20:59:27 +08:00
|
|
|
if (dev->pm_domain && dev->pm_domain->sync)
|
|
|
|
dev->pm_domain->sync(dev);
|
|
|
|
|
2006-10-08 03:55:55 +08:00
|
|
|
driver_bound(dev);
|
2007-11-29 15:49:41 +08:00
|
|
|
pr_debug("bus: '%s': %s: bound device %s to driver %s\n",
|
2008-10-30 08:36:48 +08:00
|
|
|
drv->bus->name, __func__, dev_name(dev), drv->name);
|
2006-07-19 01:59:59 +08: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 14:46:33 +08:00
|
|
|
|
2020-05-22 03:17:59 +08:00
|
|
|
dev_sysfs_state_synced_failed:
|
2019-07-31 20:43:40 +08:00
|
|
|
dev_groups_failed:
|
2022-02-24 06:52:57 +08:00
|
|
|
device_remove(dev);
|
2006-07-19 01:59:59 +08:00
|
|
|
probe_failed:
|
2021-12-31 11:39:00 +08:00
|
|
|
driver_sysfs_remove(dev);
|
|
|
|
sysfs_failed:
|
2015-12-05 05:49:17 +08:00
|
|
|
if (dev->bus)
|
|
|
|
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
|
|
|
|
BUS_NOTIFY_DRIVER_NOT_BOUND, dev);
|
2022-04-18 08:49:51 +08:00
|
|
|
if (dev->bus && dev->bus->dma_cleanup)
|
|
|
|
dev->bus->dma_cleanup(dev);
|
2015-12-05 05:49:17 +08:00
|
|
|
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-31 00:32:16 +08:00
|
|
|
device_links_no_driver(dev);
|
2022-02-24 06:52:56 +08:00
|
|
|
device_unbind_cleanup(dev);
|
2006-07-19 01:59:59 +08:00
|
|
|
done:
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2018-06-21 08:35:56 +08:00
|
|
|
/*
|
|
|
|
* For initcall_debug, show the driver probe time.
|
|
|
|
*/
|
|
|
|
static int really_probe_debug(struct device *dev, struct device_driver *drv)
|
|
|
|
{
|
2020-08-03 11:33:43 +08:00
|
|
|
ktime_t calltime, rettime;
|
2018-06-21 08:35:56 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
calltime = ktime_get();
|
|
|
|
ret = really_probe(dev, drv);
|
|
|
|
rettime = ktime_get();
|
2020-04-11 21:31:58 +08:00
|
|
|
pr_debug("probe of %s returned %d after %lld usecs\n",
|
2020-08-03 11:33:43 +08:00
|
|
|
dev_name(dev), ret, ktime_us_delta(rettime, calltime));
|
2018-06-21 08:35:56 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2006-07-19 01:59:59 +08: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 20:20:22 +08: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-19 01:59:59 +08:00
|
|
|
return -EBUSY;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-02-14 08:59:06 +08:00
|
|
|
/**
|
|
|
|
* wait_for_device_probe
|
|
|
|
* Wait for device probing to be completed.
|
|
|
|
*/
|
2009-02-21 16:45:07 +08:00
|
|
|
void wait_for_device_probe(void)
|
2009-02-14 08:59:06 +08:00
|
|
|
{
|
2015-11-10 17:42:34 +08:00
|
|
|
/* wait for the deferred probe workqueue to finish */
|
2016-08-31 01:15:34 +08:00
|
|
|
flush_work(&deferred_probe_work);
|
2015-11-10 17:42:34 +08:00
|
|
|
|
2009-02-14 08:59:06 +08:00
|
|
|
/* wait for the known devices to complete their probing */
|
2009-02-21 16:45:07 +08:00
|
|
|
wait_event(probe_waitqueue, atomic_read(&probe_count) == 0);
|
2009-02-14 08:59:06 +08:00
|
|
|
async_synchronize_full();
|
|
|
|
}
|
2009-04-22 04:32:54 +08:00
|
|
|
EXPORT_SYMBOL_GPL(wait_for_device_probe);
|
2009-02-14 08:59:06 +08:00
|
|
|
|
2021-06-17 22:22:12 +08:00
|
|
|
static int __driver_probe_device(struct device_driver *drv, struct device *dev)
|
2006-07-19 01:59:59 +08:00
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
2021-06-17 22:22:09 +08:00
|
|
|
if (dev->p->dead || !device_is_registered(dev))
|
2006-09-19 04:22:34 +08:00
|
|
|
return -ENODEV;
|
2021-06-17 22:22:09 +08:00
|
|
|
if (dev->driver)
|
|
|
|
return -EBUSY;
|
2006-07-19 01:59:59 +08:00
|
|
|
|
2021-03-03 05:11:30 +08:00
|
|
|
dev->can_match = true;
|
2007-11-29 15:49:41 +08:00
|
|
|
pr_debug("bus: '%s': %s: matched device %s with driver %s\n",
|
2008-10-30 08:36:48 +08:00
|
|
|
drv->bus->name, __func__, dev_name(dev), drv->name);
|
2006-07-19 01:59:59 +08:00
|
|
|
|
2018-06-12 16:24:13 +08:00
|
|
|
pm_runtime_get_suppliers(dev);
|
2015-07-27 23:03:58 +08:00
|
|
|
if (dev->parent)
|
|
|
|
pm_runtime_get_sync(dev->parent);
|
|
|
|
|
2009-08-19 05:38:32 +08:00
|
|
|
pm_runtime_barrier(dev);
|
2018-06-21 08:35:56 +08:00
|
|
|
if (initcall_debug)
|
|
|
|
ret = really_probe_debug(dev, drv);
|
|
|
|
else
|
|
|
|
ret = really_probe(dev, drv);
|
2013-04-10 23:00:48 +08:00
|
|
|
pm_request_idle(dev);
|
2006-07-19 01:59:59 +08:00
|
|
|
|
2015-07-27 23:03:58 +08:00
|
|
|
if (dev->parent)
|
|
|
|
pm_runtime_put(dev->parent);
|
|
|
|
|
2018-06-12 16:24:13 +08: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 14:46:33 +08:00
|
|
|
return ret;
|
2005-03-22 02:52:54 +08:00
|
|
|
}
|
|
|
|
|
2021-06-17 22:22:12 +08: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 15:47:36 +08: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 08:53:43 +08:00
|
|
|
bool async_drv;
|
|
|
|
|
|
|
|
async_drv = parse_option_str(async_probe_drv_names, drv_name);
|
|
|
|
|
|
|
|
return (async_probe_default != async_drv);
|
2019-02-13 15:47:36 +08: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 21:31:58 +08:00
|
|
|
pr_warn("Too long list of driver names for 'driver_async_probe'!\n");
|
2019-02-13 15:47:36 +08:00
|
|
|
|
2022-08-19 04:59:56 +08:00
|
|
|
strscpy(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 08:53:43 +08:00
|
|
|
async_probe_default = parse_option_str(async_probe_drv_names, "*");
|
|
|
|
|
2022-03-01 12:18:29 +08:00
|
|
|
return 1;
|
2019-02-13 15:47:36 +08:00
|
|
|
}
|
|
|
|
__setup("driver_async_probe=", save_async_options);
|
|
|
|
|
2015-03-31 07:20:04 +08:00
|
|
|
bool driver_allows_async_probing(struct device_driver *drv)
|
2005-03-25 02:50:24 +08:00
|
|
|
{
|
2015-03-31 07:20:06 +08:00
|
|
|
switch (drv->probe_type) {
|
|
|
|
case PROBE_PREFER_ASYNCHRONOUS:
|
2015-03-31 07:20:05 +08:00
|
|
|
return true;
|
|
|
|
|
2015-03-31 07:20:06 +08:00
|
|
|
case PROBE_FORCE_SYNCHRONOUS:
|
|
|
|
return false;
|
|
|
|
|
|
|
|
default:
|
2019-02-13 15:47:36 +08:00
|
|
|
if (cmdline_requested_async_probing(drv->name))
|
|
|
|
return true;
|
|
|
|
|
2015-05-22 06:49:37 +08:00
|
|
|
if (module_requested_async_probing(drv->owner))
|
2015-03-31 07:20:06 +08:00
|
|
|
return true;
|
2015-03-31 07:20:05 +08:00
|
|
|
|
2015-03-31 07:20:06 +08:00
|
|
|
return false;
|
|
|
|
}
|
2015-03-31 07:20:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
struct device_attach_data {
|
|
|
|
struct device *dev;
|
|
|
|
|
|
|
|
/*
|
2022-02-12 22:32:33 +08:00
|
|
|
* Indicates whether we are considering asynchronous probing or
|
2015-03-31 07:20:04 +08: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 16:25:06 +08:00
|
|
|
int ret;
|
2015-03-31 07:20:04 +08:00
|
|
|
|
2016-02-15 16:25:06 +08:00
|
|
|
ret = driver_match_device(drv, dev);
|
|
|
|
if (ret == 0) {
|
|
|
|
/* no match */
|
2009-01-21 23:27:47 +08:00
|
|
|
return 0;
|
2016-02-15 16:25:06 +08:00
|
|
|
} else if (ret == -EPROBE_DEFER) {
|
|
|
|
dev_dbg(dev, "Device match requests probe deferral\n");
|
2021-03-03 05:11:30 +08:00
|
|
|
dev->can_match = true;
|
2016-02-15 16:25:06 +08:00
|
|
|
driver_deferred_probe_add(dev);
|
2022-08-18 02:40:26 +08:00
|
|
|
/*
|
|
|
|
* Device can't match with a driver right now, so don't attempt
|
|
|
|
* to match or bind with other drivers on the bus.
|
|
|
|
*/
|
|
|
|
return ret;
|
2016-02-15 16:25:06 +08:00
|
|
|
} else if (ret < 0) {
|
2020-04-11 21:31:58 +08:00
|
|
|
dev_dbg(dev, "Bus failed to match device: %d\n", ret);
|
2016-02-15 16:25:06 +08:00
|
|
|
return ret;
|
|
|
|
} /* ret > 0 means positive match */
|
2009-01-21 23:27:47 +08:00
|
|
|
|
2015-03-31 07:20:04 +08: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 22:22:11 +08: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-25 02:50:24 +08:00
|
|
|
}
|
|
|
|
|
2015-03-31 07:20:04 +08: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-23 02:39:10 +08: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 23:03:58 +08:00
|
|
|
if (dev->parent)
|
|
|
|
pm_runtime_get_sync(dev->parent);
|
|
|
|
|
2015-03-31 07:20:04 +08: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 23:03:58 +08:00
|
|
|
if (dev->parent)
|
|
|
|
pm_runtime_put(dev->parent);
|
2019-01-23 02:39:10 +08:00
|
|
|
out_unlock:
|
2015-03-31 07:20:04 +08:00
|
|
|
device_unlock(dev);
|
|
|
|
|
|
|
|
put_device(dev);
|
|
|
|
}
|
|
|
|
|
2015-05-21 07:36:31 +08:00
|
|
|
static int __device_attach(struct device *dev, bool allow_async)
|
2005-03-22 02:52:54 +08: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 14:46:33 +08:00
|
|
|
int ret = 0;
|
driver core: fix deadlock in __device_attach
In __device_attach function, The lock holding logic is as follows:
...
__device_attach
device_lock(dev) // get lock dev
async_schedule_dev(__device_attach_async_helper, dev); // func
async_schedule_node
async_schedule_node_domain(func)
entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
/* when fail or work limit, sync to execute func, but
__device_attach_async_helper will get lock dev as
well, which will lead to A-A deadlock. */
if (!entry || atomic_read(&entry_count) > MAX_WORK) {
func;
else
queue_work_node(node, system_unbound_wq, &entry->work)
device_unlock(dev)
As shown above, when it is allowed to do async probes, because of
out of memory or work limit, async work is not allowed, to do
sync execute instead. it will lead to A-A deadlock because of
__device_attach_async_helper getting lock dev.
To fix the deadlock, move the async_schedule_dev outside device_lock,
as we can see, in async_schedule_node_domain, the parameter of
queue_work_node is system_unbound_wq, so it can accept concurrent
operations. which will also not change the code logic, and will
not lead to deadlock.
Fixes: 765230b5f084 ("driver-core: add asynchronous probing support for drivers")
Signed-off-by: Zhang Wensheng <zhangwensheng5@huawei.com>
Link: https://lore.kernel.org/r/20220518074516.1225580-1-zhangwensheng5@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-18 15:45:16 +08:00
|
|
|
bool async = false;
|
[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 14:46:33 +08:00
|
|
|
|
2010-02-18 02:57:05 +08:00
|
|
|
device_lock(dev);
|
2020-07-08 21:27:01 +08:00
|
|
|
if (dev->p->dead) {
|
|
|
|
goto out_unlock;
|
|
|
|
} else if (dev->driver) {
|
2016-01-07 23:46:12 +08:00
|
|
|
if (device_is_bound(dev)) {
|
2011-04-13 01:05:37 +08:00
|
|
|
ret = 1;
|
|
|
|
goto out_unlock;
|
|
|
|
}
|
2006-08-15 13:43:20 +08:00
|
|
|
ret = device_bind_driver(dev);
|
|
|
|
if (ret == 0)
|
|
|
|
ret = 1;
|
2007-02-06 08:15:26 +08:00
|
|
|
else {
|
|
|
|
dev->driver = NULL;
|
|
|
|
ret = 0;
|
|
|
|
}
|
2007-02-06 08:15:25 +08:00
|
|
|
} else {
|
2015-03-31 07:20:04 +08:00
|
|
|
struct device_attach_data data = {
|
|
|
|
.dev = dev,
|
|
|
|
.check_async = allow_async,
|
|
|
|
.want_async = false,
|
|
|
|
};
|
|
|
|
|
2015-07-27 23:03:58 +08:00
|
|
|
if (dev->parent)
|
|
|
|
pm_runtime_get_sync(dev->parent);
|
|
|
|
|
2015-03-31 07:20:04 +08: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);
|
driver core: fix deadlock in __device_attach
In __device_attach function, The lock holding logic is as follows:
...
__device_attach
device_lock(dev) // get lock dev
async_schedule_dev(__device_attach_async_helper, dev); // func
async_schedule_node
async_schedule_node_domain(func)
entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
/* when fail or work limit, sync to execute func, but
__device_attach_async_helper will get lock dev as
well, which will lead to A-A deadlock. */
if (!entry || atomic_read(&entry_count) > MAX_WORK) {
func;
else
queue_work_node(node, system_unbound_wq, &entry->work)
device_unlock(dev)
As shown above, when it is allowed to do async probes, because of
out of memory or work limit, async work is not allowed, to do
sync execute instead. it will lead to A-A deadlock because of
__device_attach_async_helper getting lock dev.
To fix the deadlock, move the async_schedule_dev outside device_lock,
as we can see, in async_schedule_node_domain, the parameter of
queue_work_node is system_unbound_wq, so it can accept concurrent
operations. which will also not change the code logic, and will
not lead to deadlock.
Fixes: 765230b5f084 ("driver-core: add asynchronous probing support for drivers")
Signed-off-by: Zhang Wensheng <zhangwensheng5@huawei.com>
Link: https://lore.kernel.org/r/20220518074516.1225580-1-zhangwensheng5@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-18 15:45:16 +08:00
|
|
|
async = true;
|
2015-03-31 07:20:04 +08:00
|
|
|
} else {
|
|
|
|
pm_request_idle(dev);
|
|
|
|
}
|
2015-07-27 23:03:58 +08:00
|
|
|
|
|
|
|
if (dev->parent)
|
|
|
|
pm_runtime_put(dev->parent);
|
2007-02-06 08:15:25 +08:00
|
|
|
}
|
2011-04-13 01:05:37 +08:00
|
|
|
out_unlock:
|
2010-02-18 02:57:05 +08:00
|
|
|
device_unlock(dev);
|
driver core: fix deadlock in __device_attach
In __device_attach function, The lock holding logic is as follows:
...
__device_attach
device_lock(dev) // get lock dev
async_schedule_dev(__device_attach_async_helper, dev); // func
async_schedule_node
async_schedule_node_domain(func)
entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
/* when fail or work limit, sync to execute func, but
__device_attach_async_helper will get lock dev as
well, which will lead to A-A deadlock. */
if (!entry || atomic_read(&entry_count) > MAX_WORK) {
func;
else
queue_work_node(node, system_unbound_wq, &entry->work)
device_unlock(dev)
As shown above, when it is allowed to do async probes, because of
out of memory or work limit, async work is not allowed, to do
sync execute instead. it will lead to A-A deadlock because of
__device_attach_async_helper getting lock dev.
To fix the deadlock, move the async_schedule_dev outside device_lock,
as we can see, in async_schedule_node_domain, the parameter of
queue_work_node is system_unbound_wq, so it can accept concurrent
operations. which will also not change the code logic, and will
not lead to deadlock.
Fixes: 765230b5f084 ("driver-core: add asynchronous probing support for drivers")
Signed-off-by: Zhang Wensheng <zhangwensheng5@huawei.com>
Link: https://lore.kernel.org/r/20220518074516.1225580-1-zhangwensheng5@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-18 15:45:16 +08:00
|
|
|
if (async)
|
|
|
|
async_schedule_dev(__device_attach_async_helper, 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 14:46:33 +08:00
|
|
|
return ret;
|
2005-03-25 02:50:24 +08:00
|
|
|
}
|
2015-03-31 07:20:04 +08: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 14:50:12 +08:00
|
|
|
EXPORT_SYMBOL_GPL(device_attach);
|
2005-03-25 02:50:24 +08:00
|
|
|
|
2015-03-31 07:20:04 +08:00
|
|
|
void device_initial_probe(struct device *dev)
|
|
|
|
{
|
|
|
|
__device_attach(dev, true);
|
|
|
|
}
|
|
|
|
|
2019-01-23 02:39:16 +08: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 22:32:33 +08:00
|
|
|
* Normally this will just be the @dev lock, but when called for a
|
2019-01-23 02:39:16 +08: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 22:22:11 +08:00
|
|
|
* @dev->parent lock if needed. Returns 0 on success, -ERR on failure.
|
2019-01-23 02:39:16 +08:00
|
|
|
*/
|
|
|
|
int device_driver_attach(struct device_driver *drv, struct device *dev)
|
|
|
|
{
|
2021-06-17 22:22:09 +08:00
|
|
|
int ret;
|
2019-01-23 02:39:16 +08:00
|
|
|
|
|
|
|
__device_driver_lock(dev, dev->parent);
|
2021-06-17 22:22:12 +08:00
|
|
|
ret = __driver_probe_device(drv, dev);
|
2019-01-23 02:39:16 +08:00
|
|
|
__device_driver_unlock(dev, dev->parent);
|
|
|
|
|
2021-06-17 22:22:11 +08:00
|
|
|
/* also return probe errors as normal negative errnos */
|
|
|
|
if (ret > 0)
|
|
|
|
ret = -ret;
|
2021-06-17 22:22:12 +08:00
|
|
|
if (ret == -EPROBE_DEFER)
|
|
|
|
return -EAGAIN;
|
2019-01-23 02:39:16 +08:00
|
|
|
return ret;
|
|
|
|
}
|
2021-06-17 22:22:13 +08:00
|
|
|
EXPORT_SYMBOL_GPL(device_driver_attach);
|
2019-01-23 02:39:16 +08:00
|
|
|
|
2019-01-23 02:39:21 +08:00
|
|
|
static void __driver_attach_async_helper(void *_dev, async_cookie_t cookie)
|
|
|
|
{
|
|
|
|
struct device *dev = _dev;
|
|
|
|
struct device_driver *drv;
|
2021-06-17 22:22:09 +08:00
|
|
|
int ret;
|
2019-01-23 02:39:21 +08:00
|
|
|
|
|
|
|
__device_driver_lock(dev, dev->parent);
|
|
|
|
drv = dev->p->async_driver;
|
2022-03-16 15:43:28 +08:00
|
|
|
dev->p->async_driver = NULL;
|
2021-06-17 22:22:09 +08:00
|
|
|
ret = driver_probe_device(drv, dev);
|
2019-01-23 02:39:21 +08: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 14:50:12 +08:00
|
|
|
static int __driver_attach(struct device *dev, void *data)
|
2005-03-25 02:50:24 +08:00
|
|
|
{
|
2008-01-25 14:50:12 +08:00
|
|
|
struct device_driver *drv = data;
|
driver core: fix potential deadlock in __driver_attach
In __driver_attach function, There are also AA deadlock problem,
like the commit b232b02bf3c2 ("driver core: fix deadlock in
__device_attach").
stack like commit b232b02bf3c2 ("driver core: fix deadlock in
__device_attach").
list below:
In __driver_attach function, The lock holding logic is as follows:
...
__driver_attach
if (driver_allows_async_probing(drv))
device_lock(dev) // get lock dev
async_schedule_dev(__driver_attach_async_helper, dev); // func
async_schedule_node
async_schedule_node_domain(func)
entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
/* when fail or work limit, sync to execute func, but
__driver_attach_async_helper will get lock dev as
will, which will lead to A-A deadlock. */
if (!entry || atomic_read(&entry_count) > MAX_WORK) {
func;
else
queue_work_node(node, system_unbound_wq, &entry->work)
device_unlock(dev)
As above show, when it is allowed to do async probes, because of
out of memory or work limit, async work is not be allowed, to do
sync execute instead. it will lead to A-A deadlock because of
__driver_attach_async_helper getting lock dev.
Reproduce:
and it can be reproduce by make the condition
(if (!entry || atomic_read(&entry_count) > MAX_WORK)) untenable, like
below:
[ 370.785650] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[ 370.787154] task:swapper/0 state:D stack: 0 pid: 1 ppid:
0 flags:0x00004000
[ 370.788865] Call Trace:
[ 370.789374] <TASK>
[ 370.789841] __schedule+0x482/0x1050
[ 370.790613] schedule+0x92/0x1a0
[ 370.791290] schedule_preempt_disabled+0x2c/0x50
[ 370.792256] __mutex_lock.isra.0+0x757/0xec0
[ 370.793158] __mutex_lock_slowpath+0x1f/0x30
[ 370.794079] mutex_lock+0x50/0x60
[ 370.794795] __device_driver_lock+0x2f/0x70
[ 370.795677] ? driver_probe_device+0xd0/0xd0
[ 370.796576] __driver_attach_async_helper+0x1d/0xd0
[ 370.797318] ? driver_probe_device+0xd0/0xd0
[ 370.797957] async_schedule_node_domain+0xa5/0xc0
[ 370.798652] async_schedule_node+0x19/0x30
[ 370.799243] __driver_attach+0x246/0x290
[ 370.799828] ? driver_allows_async_probing+0xa0/0xa0
[ 370.800548] bus_for_each_dev+0x9d/0x130
[ 370.801132] driver_attach+0x22/0x30
[ 370.801666] bus_add_driver+0x290/0x340
[ 370.802246] driver_register+0x88/0x140
[ 370.802817] ? virtio_scsi_init+0x116/0x116
[ 370.803425] scsi_register_driver+0x1a/0x30
[ 370.804057] init_sd+0x184/0x226
[ 370.804533] do_one_initcall+0x71/0x3a0
[ 370.805107] kernel_init_freeable+0x39a/0x43a
[ 370.805759] ? rest_init+0x150/0x150
[ 370.806283] kernel_init+0x26/0x230
[ 370.806799] ret_from_fork+0x1f/0x30
To fix the deadlock, move the async_schedule_dev outside device_lock,
as we can see, in async_schedule_node_domain, the parameter of
queue_work_node is system_unbound_wq, so it can accept concurrent
operations. which will also not change the code logic, and will
not lead to deadlock.
Fixes: ef0ff68351be ("driver core: Probe devices asynchronously instead of the driver")
Signed-off-by: Zhang Wensheng <zhangwensheng5@huawei.com>
Link: https://lore.kernel.org/r/20220622074327.497102-1-zhangwensheng5@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-22 15:43:27 +08:00
|
|
|
bool async = false;
|
2016-02-15 16:25:06 +08: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 14:46:33 +08: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 16:25:06 +08:00
|
|
|
ret = driver_match_device(drv, dev);
|
|
|
|
if (ret == 0) {
|
|
|
|
/* no match */
|
2008-09-14 23:32:06 +08:00
|
|
|
return 0;
|
2016-02-15 16:25:06 +08:00
|
|
|
} else if (ret == -EPROBE_DEFER) {
|
|
|
|
dev_dbg(dev, "Device match requests probe deferral\n");
|
2021-03-03 05:11:30 +08:00
|
|
|
dev->can_match = true;
|
2016-02-15 16:25:06 +08:00
|
|
|
driver_deferred_probe_add(dev);
|
2022-08-18 02:40:26 +08:00
|
|
|
/*
|
|
|
|
* Driver could not match with device, but may match with
|
|
|
|
* another device on the bus.
|
|
|
|
*/
|
|
|
|
return 0;
|
2016-02-15 16:25:06 +08:00
|
|
|
} else if (ret < 0) {
|
2020-04-11 21:31:58 +08:00
|
|
|
dev_dbg(dev, "Bus failed to match device: %d\n", ret);
|
2016-02-15 16:25:06 +08:00
|
|
|
return ret;
|
|
|
|
} /* ret > 0 means positive match */
|
2008-09-14 23:32:06 +08:00
|
|
|
|
2019-01-23 02:39:21 +08: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 15:43:28 +08:00
|
|
|
if (!dev->driver && !dev->p->async_driver) {
|
2019-01-23 02:39:21 +08:00
|
|
|
get_device(dev);
|
|
|
|
dev->p->async_driver = drv;
|
driver core: fix potential deadlock in __driver_attach
In __driver_attach function, There are also AA deadlock problem,
like the commit b232b02bf3c2 ("driver core: fix deadlock in
__device_attach").
stack like commit b232b02bf3c2 ("driver core: fix deadlock in
__device_attach").
list below:
In __driver_attach function, The lock holding logic is as follows:
...
__driver_attach
if (driver_allows_async_probing(drv))
device_lock(dev) // get lock dev
async_schedule_dev(__driver_attach_async_helper, dev); // func
async_schedule_node
async_schedule_node_domain(func)
entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
/* when fail or work limit, sync to execute func, but
__driver_attach_async_helper will get lock dev as
will, which will lead to A-A deadlock. */
if (!entry || atomic_read(&entry_count) > MAX_WORK) {
func;
else
queue_work_node(node, system_unbound_wq, &entry->work)
device_unlock(dev)
As above show, when it is allowed to do async probes, because of
out of memory or work limit, async work is not be allowed, to do
sync execute instead. it will lead to A-A deadlock because of
__driver_attach_async_helper getting lock dev.
Reproduce:
and it can be reproduce by make the condition
(if (!entry || atomic_read(&entry_count) > MAX_WORK)) untenable, like
below:
[ 370.785650] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[ 370.787154] task:swapper/0 state:D stack: 0 pid: 1 ppid:
0 flags:0x00004000
[ 370.788865] Call Trace:
[ 370.789374] <TASK>
[ 370.789841] __schedule+0x482/0x1050
[ 370.790613] schedule+0x92/0x1a0
[ 370.791290] schedule_preempt_disabled+0x2c/0x50
[ 370.792256] __mutex_lock.isra.0+0x757/0xec0
[ 370.793158] __mutex_lock_slowpath+0x1f/0x30
[ 370.794079] mutex_lock+0x50/0x60
[ 370.794795] __device_driver_lock+0x2f/0x70
[ 370.795677] ? driver_probe_device+0xd0/0xd0
[ 370.796576] __driver_attach_async_helper+0x1d/0xd0
[ 370.797318] ? driver_probe_device+0xd0/0xd0
[ 370.797957] async_schedule_node_domain+0xa5/0xc0
[ 370.798652] async_schedule_node+0x19/0x30
[ 370.799243] __driver_attach+0x246/0x290
[ 370.799828] ? driver_allows_async_probing+0xa0/0xa0
[ 370.800548] bus_for_each_dev+0x9d/0x130
[ 370.801132] driver_attach+0x22/0x30
[ 370.801666] bus_add_driver+0x290/0x340
[ 370.802246] driver_register+0x88/0x140
[ 370.802817] ? virtio_scsi_init+0x116/0x116
[ 370.803425] scsi_register_driver+0x1a/0x30
[ 370.804057] init_sd+0x184/0x226
[ 370.804533] do_one_initcall+0x71/0x3a0
[ 370.805107] kernel_init_freeable+0x39a/0x43a
[ 370.805759] ? rest_init+0x150/0x150
[ 370.806283] kernel_init+0x26/0x230
[ 370.806799] ret_from_fork+0x1f/0x30
To fix the deadlock, move the async_schedule_dev outside device_lock,
as we can see, in async_schedule_node_domain, the parameter of
queue_work_node is system_unbound_wq, so it can accept concurrent
operations. which will also not change the code logic, and will
not lead to deadlock.
Fixes: ef0ff68351be ("driver core: Probe devices asynchronously instead of the driver")
Signed-off-by: Zhang Wensheng <zhangwensheng5@huawei.com>
Link: https://lore.kernel.org/r/20220622074327.497102-1-zhangwensheng5@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-22 15:43:27 +08:00
|
|
|
async = true;
|
2019-01-23 02:39:21 +08:00
|
|
|
}
|
|
|
|
device_unlock(dev);
|
driver core: fix potential deadlock in __driver_attach
In __driver_attach function, There are also AA deadlock problem,
like the commit b232b02bf3c2 ("driver core: fix deadlock in
__device_attach").
stack like commit b232b02bf3c2 ("driver core: fix deadlock in
__device_attach").
list below:
In __driver_attach function, The lock holding logic is as follows:
...
__driver_attach
if (driver_allows_async_probing(drv))
device_lock(dev) // get lock dev
async_schedule_dev(__driver_attach_async_helper, dev); // func
async_schedule_node
async_schedule_node_domain(func)
entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
/* when fail or work limit, sync to execute func, but
__driver_attach_async_helper will get lock dev as
will, which will lead to A-A deadlock. */
if (!entry || atomic_read(&entry_count) > MAX_WORK) {
func;
else
queue_work_node(node, system_unbound_wq, &entry->work)
device_unlock(dev)
As above show, when it is allowed to do async probes, because of
out of memory or work limit, async work is not be allowed, to do
sync execute instead. it will lead to A-A deadlock because of
__driver_attach_async_helper getting lock dev.
Reproduce:
and it can be reproduce by make the condition
(if (!entry || atomic_read(&entry_count) > MAX_WORK)) untenable, like
below:
[ 370.785650] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[ 370.787154] task:swapper/0 state:D stack: 0 pid: 1 ppid:
0 flags:0x00004000
[ 370.788865] Call Trace:
[ 370.789374] <TASK>
[ 370.789841] __schedule+0x482/0x1050
[ 370.790613] schedule+0x92/0x1a0
[ 370.791290] schedule_preempt_disabled+0x2c/0x50
[ 370.792256] __mutex_lock.isra.0+0x757/0xec0
[ 370.793158] __mutex_lock_slowpath+0x1f/0x30
[ 370.794079] mutex_lock+0x50/0x60
[ 370.794795] __device_driver_lock+0x2f/0x70
[ 370.795677] ? driver_probe_device+0xd0/0xd0
[ 370.796576] __driver_attach_async_helper+0x1d/0xd0
[ 370.797318] ? driver_probe_device+0xd0/0xd0
[ 370.797957] async_schedule_node_domain+0xa5/0xc0
[ 370.798652] async_schedule_node+0x19/0x30
[ 370.799243] __driver_attach+0x246/0x290
[ 370.799828] ? driver_allows_async_probing+0xa0/0xa0
[ 370.800548] bus_for_each_dev+0x9d/0x130
[ 370.801132] driver_attach+0x22/0x30
[ 370.801666] bus_add_driver+0x290/0x340
[ 370.802246] driver_register+0x88/0x140
[ 370.802817] ? virtio_scsi_init+0x116/0x116
[ 370.803425] scsi_register_driver+0x1a/0x30
[ 370.804057] init_sd+0x184/0x226
[ 370.804533] do_one_initcall+0x71/0x3a0
[ 370.805107] kernel_init_freeable+0x39a/0x43a
[ 370.805759] ? rest_init+0x150/0x150
[ 370.806283] kernel_init+0x26/0x230
[ 370.806799] ret_from_fork+0x1f/0x30
To fix the deadlock, move the async_schedule_dev outside device_lock,
as we can see, in async_schedule_node_domain, the parameter of
queue_work_node is system_unbound_wq, so it can accept concurrent
operations. which will also not change the code logic, and will
not lead to deadlock.
Fixes: ef0ff68351be ("driver core: Probe devices asynchronously instead of the driver")
Signed-off-by: Zhang Wensheng <zhangwensheng5@huawei.com>
Link: https://lore.kernel.org/r/20220622074327.497102-1-zhangwensheng5@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-22 15:43:27 +08:00
|
|
|
if (async)
|
|
|
|
async_schedule_dev(__driver_attach_async_helper, dev);
|
2019-01-23 02:39:21 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-06-17 22:22:11 +08: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 14:46:33 +08:00
|
|
|
|
2005-03-22 02:52:54 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2008-01-25 14:50:12 +08:00
|
|
|
* driver_attach - try to bind driver to devices.
|
|
|
|
* @drv: driver.
|
2005-03-22 02:52:54 +08:00
|
|
|
*
|
2008-01-25 14:50:12 +08: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-22 02:52:54 +08:00
|
|
|
*/
|
2008-01-25 14:50:12 +08:00
|
|
|
int driver_attach(struct device_driver *drv)
|
2005-03-22 02:52:54 +08:00
|
|
|
{
|
2006-08-15 13:43:20 +08:00
|
|
|
return bus_for_each_dev(drv->bus, NULL, drv, __driver_attach);
|
2005-03-22 02:52:54 +08:00
|
|
|
}
|
2008-01-25 14:50:12 +08:00
|
|
|
EXPORT_SYMBOL_GPL(driver_attach);
|
2005-03-22 02:52:54 +08:00
|
|
|
|
2007-06-17 17:02:12 +08:00
|
|
|
/*
|
2010-02-18 02:57:05 +08: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-22 02:52:54 +08: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-31 00:32:16 +08:00
|
|
|
static void __device_release_driver(struct device *dev, struct device *parent)
|
2005-03-22 02:52:54 +08:00
|
|
|
{
|
2008-01-25 14:50:12 +08:00
|
|
|
struct device_driver *drv;
|
2005-03-22 02:52:54 +08:00
|
|
|
|
2007-11-17 00:57:28 +08:00
|
|
|
drv = dev->driver;
|
2005-05-07 03:38:33 +08:00
|
|
|
if (drv) {
|
2020-10-22 23:38:22 +08: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-31 00:32:16 +08:00
|
|
|
while (device_links_busy(dev)) {
|
2019-01-23 02:39:16 +08: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-31 00:32:16 +08:00
|
|
|
|
|
|
|
device_links_unbind_consumers(dev);
|
|
|
|
|
2019-01-23 02:39:16 +08: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-31 00:32:16 +08: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 23:38:22 +08: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-31 00:32:16 +08:00
|
|
|
return;
|
2020-10-22 23:38:22 +08: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-31 00:32:16 +08:00
|
|
|
}
|
|
|
|
|
2006-10-08 03:55:55 +08: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 14:46:33 +08: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 11:44:59 +08:00
|
|
|
if (dev->bus)
|
2007-11-02 10:41:16 +08: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 11:44:59 +08:00
|
|
|
BUS_NOTIFY_UNBIND_DRIVER,
|
|
|
|
dev);
|
|
|
|
|
2013-11-07 08:51:15 +08:00
|
|
|
pm_runtime_put_sync(dev);
|
2011-04-29 06:33:45 +08:00
|
|
|
|
2022-02-24 06:52:57 +08: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-31 00:32:16 +08:00
|
|
|
|
2022-04-18 08:49:51 +08:00
|
|
|
if (dev->bus && dev->bus->dma_cleanup)
|
|
|
|
dev->bus->dma_cleanup(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-31 00:32:16 +08:00
|
|
|
device_links_driver_cleanup(dev);
|
2022-02-24 06:52:56 +08: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 20:59:27 +08:00
|
|
|
|
2008-12-17 04:25:49 +08:00
|
|
|
klist_remove(&dev->p->knode_driver);
|
2016-01-07 23:46:14 +08:00
|
|
|
device_pm_check_callbacks(dev);
|
2009-04-24 20:57:00 +08:00
|
|
|
if (dev->bus)
|
|
|
|
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
|
|
|
|
BUS_NOTIFY_UNBOUND_DRIVER,
|
|
|
|
dev);
|
2017-07-20 08:24:30 +08: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 14:46:33 +08:00
|
|
|
}
|
2005-03-22 02:52:54 +08: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-31 00:32:16 +08:00
|
|
|
void device_release_driver_internal(struct device *dev,
|
|
|
|
struct device_driver *drv,
|
|
|
|
struct device *parent)
|
2016-10-10 20:37:56 +08:00
|
|
|
{
|
2019-01-23 02:39:16 +08:00
|
|
|
__device_driver_lock(dev, parent);
|
2016-10-10 20:37:56 +08: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-31 00:32:16 +08:00
|
|
|
__device_release_driver(dev, parent);
|
2016-10-10 20:37:56 +08:00
|
|
|
|
2019-01-23 02:39:16 +08:00
|
|
|
__device_driver_unlock(dev, parent);
|
2016-10-10 20:37:56 +08:00
|
|
|
}
|
|
|
|
|
2007-06-17 17:02:12 +08:00
|
|
|
/**
|
2008-01-25 14:50:12 +08:00
|
|
|
* device_release_driver - manually detach device from driver.
|
|
|
|
* @dev: device.
|
2007-06-17 17:02:12 +08:00
|
|
|
*
|
2008-01-25 14:50:12 +08:00
|
|
|
* Manually detach device from driver.
|
2010-02-18 02:57:05 +08: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-31 00:32:16 +08: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 17:02:12 +08:00
|
|
|
*/
|
2008-01-25 14:50:12 +08:00
|
|
|
void device_release_driver(struct device *dev)
|
2005-03-22 04:25:36 +08:00
|
|
|
{
|
2005-05-07 03:38:33 +08: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 20:37:56 +08:00
|
|
|
device_release_driver_internal(dev, NULL, NULL);
|
2005-03-22 04:25:36 +08:00
|
|
|
}
|
2008-01-25 14:50:12 +08:00
|
|
|
EXPORT_SYMBOL_GPL(device_release_driver);
|
2005-05-07 03:38:33 +08:00
|
|
|
|
2019-01-23 02:39:16 +08: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-22 02:52:54 +08:00
|
|
|
/**
|
|
|
|
* driver_detach - detach driver from all devices it controls.
|
|
|
|
* @drv: driver.
|
|
|
|
*/
|
2008-01-25 14:50:12 +08:00
|
|
|
void driver_detach(struct device_driver *drv)
|
2005-03-22 02:52:54 +08:00
|
|
|
{
|
2008-12-17 04:25:49 +08:00
|
|
|
struct device_private *dev_prv;
|
2008-01-25 14:50:12 +08:00
|
|
|
struct device *dev;
|
2005-05-07 03:38:33 +08:00
|
|
|
|
2018-11-29 08:32:11 +08:00
|
|
|
if (driver_allows_async_probing(drv))
|
|
|
|
async_synchronize_full();
|
|
|
|
|
2005-05-07 03:38:33 +08:00
|
|
|
for (;;) {
|
2007-11-29 07:59:15 +08: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-07 03:38:33 +08:00
|
|
|
break;
|
|
|
|
}
|
2020-03-24 20:20:23 +08:00
|
|
|
dev_prv = list_last_entry(&drv->p->klist_devices.k_list,
|
2008-12-17 04:25:49 +08:00
|
|
|
struct device_private,
|
|
|
|
knode_driver.n_node);
|
|
|
|
dev = dev_prv->device;
|
2005-05-07 03:38:33 +08:00
|
|
|
get_device(dev);
|
2007-11-29 07:59:15 +08:00
|
|
|
spin_unlock(&drv->p->klist_devices.k_lock);
|
2016-10-10 20:37:56 +08:00
|
|
|
device_release_driver_internal(dev, drv, dev->parent);
|
2005-05-07 03:38:33 +08:00
|
|
|
put_device(dev);
|
|
|
|
}
|
2005-03-22 02:52:54 +08:00
|
|
|
}
|