History log of /drivers/base/dd.c
Revision Date Author Comments
41575335ed026339e07f265ede3a21e995bee8e6 08-Aug-2014 Thierry Reding <treding@nvidia.com> driver core: Remove kerneldoc from local function

The deferred_probe_work_func() function is locally scoped, therefore an
associated kerneldoc comment isn't very useful. Replace the kerneldoc
opening marker (/**) with a regular block comment marker (/*) to avoid
the comment from being parsed by kerneldoc. This gets rid of a warning
caused by a missing description for the "work" argument.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
a996d010b648788b615938f6a26be6cf08d96aaf 14-Apr-2014 Jean Delvare <jdelvare@suse.de> driver core: Inline dev_set/get_drvdata

dev_set_drvdata and dev_get_drvdata are now simple enough again that
we can inline them as they used to be before commit b40284378.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
d4332013919aa87dbdede67d677e4cf2cd32e898 14-Apr-2014 Jean Delvare <jdelvare@suse.de> driver core: dev_get_drvdata: Don't check for NULL dev

There is no point in calling dev_get_drvdata without a valid device.
So checking for dev == NULL is pointless. If such a check is ever
needed - which I doubt - the driver should do it before calling
dev_get_drvdata.

We were returning NULL if dev was NULL, which the caller certainly did
not expect anyway, so that was only delaying the crash if the caller
is not paying attention.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2c1f1ff0f0d9e0df8c9b6d3697ac250900091541 14-Apr-2014 Jean Delvare <jdelvare@suse.de> driver core: dev_set_drvdata returns void

dev_set_drvdata can no longer fail, so it could return void.

All callers have hopefully been updated to no longer check for the
return value.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1bb6c08abfb653ce6e65d8ab4ddef403227afedf 14-Apr-2014 Jean Delvare <jdelvare@suse.de> driver core: Move driver_data back to struct device

Having to allocate memory as part of dev_set_drvdata() is a problem
because that memory may never get freed if the device itself is not
created. So move driver_data back to struct device.

This is a partial revert of commit b4028437.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
58b116bce13612e5aa6fcd49ecbd4cf8bb59e835 29-Apr-2014 Grant Likely <grant.likely@linaro.org> drivercore: deferral race condition fix

When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
when all modules loaded but some driver still stuck in the deferred list
and there is a need for external event to kick the deferred queue to probe
these drivers.

The issue has been observed on embedded systems with CONFIG_PREEMPT enabled,
audio support built as modules and using nfsroot for root filesystem.

The following log fragment shows such sequence when all audio modules
were loaded but the sound card is not present since the machine driver has
failed to probe due to missing dependency during it's probe.
The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm
machine driver:

...
[ 12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER
[ 12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER
[ 12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card
[ 12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component
[ 12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE
[ 12.950839] davinci_evm sound.3: ASoC: platform (null) not registered
[ 12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517)
[ 13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list
[ 13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2
[ 13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517)
[ 13.346755] davinci_mcasp_driver_init: LEAVE
[ 13.377446] platform sound.3: Driver davinci_evm requests probe deferral
[ 13.592527] platform sound.3: really_probe: probe_count = 0

In the log the machine driver enters it's probe at 12.719969 (this point it
has been removed from the deferred lists). McASP driver already executing
it's probing (since 12.615118).
The machine driver tries to construct the sound card (12.950839) but did
not found one of the components so it fails. After this McASP driver
registers all the ASoC components (the machine driver still in it's probe
function after it failed to construct the card) and the deferred work is
prepared at 13.099026 (note that this time the machine driver is not in the
lists so it is not going to be handled when the work is executing).
Lastly the machine driver exit from it's probe and the core places it to
the deferred list but there will be no other driver going to load and the
deferred queue is not going to be kicked again - till we have external event
like connecting USB stick, etc.

The proposed solution is to try the deferred queue once more when the last
driver is asking for deferring and we had drivers loaded while this last
driver was probing.

This way we can avoid drivers stuck in the deferred queue.

Signed-off-by: Grant Likely <grant.likely@linaro.org>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Stable <stable@vger.kernel.org> # v3.4+
94f8cc0eea03648e5cc5de1a4e7dc464de92cc74 17-Apr-2014 Frank Rowand <frowand.list@gmail.com> drivers/base/dd.c incorrect pr_debug() parameters

pr_debug() parameters are reverse order of format string

Signed-off-by: Frank Rowand <frank.rowand@sonymobile.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
baab52ded242c35a2290e1fa82e0cc147d0d8c1a 07-Nov-2013 Rafael J. Wysocki <rafael.j.wysocki@intel.com> PM / runtime: Use pm_runtime_put_sync() in __device_release_driver()

Commit fa180eb448fa (PM / Runtime: Idle devices asynchronously after
probe|release) modified __device_release_driver() to call
pm_runtime_put(dev) instead of pm_runtime_put_sync(dev) before
detaching the driver from the device. However, that was a mistake,
because pm_runtime_put(dev) causes rpm_idle() to be queued up and
the driver may be gone already when that function is executed.
That breaks the assumptions the drivers have the right to make
about the core's behavior on the basis of the existing documentation
and actually causes problems to happen, so revert that part of
commit fa180eb448fa and restore the previous behavior of
__device_release_driver().

Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Fixes: fa180eb448fa (PM / Runtime: Idle devices asynchronously after probe|release)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
fa180eb448fa263cf18dd930143b515d27d70d7b 10-Apr-2013 Ulf Hansson <ulf.hansson@linaro.org> PM / Runtime: Idle devices asynchronously after probe|release

Putting devices into idle|suspend in a synchronous manner means we are
waiting for each device to become idle|suspended before the probe|release
is fully done.

This patch switch to use the asynchronous runtime PM API:s instead and
thus improves the parallelism since we can move on and handle the next
device in queue in an earlier phase.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
d72cca1eee5b26e313da2a380d4862924e271031 14-Feb-2013 Grant Likely <grant.likely@secretlab.ca> drivercore: Fix ordering between deferred_probe and exiting initcalls

One of the side effects of deferred probe is that some drivers which
used to be probed before initcalls completed are now happening slightly
later. This causes two problems.
- If a console driver gets deferred, then it may not be ready when
userspace starts. For example, if a uart depends on pinctrl, then the
uart will get deferred and /dev/console will not be available
- __init sections will be discarded before built-in drivers are probed.
Strictly speaking, __init functions should not be called in a drivers
__probe path, but there are a lot of drivers (console stuff again)
that do anyway. In the past it was perfectly safe to do so because all
built-in drivers got probed before the end of initcalls.

This patch fixes the problem by forcing the first pass of the deferred
list to complete at late_initcall time. This is late enough to catch the
drivers that are known to have the above issues.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Tested-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable <stable@vger.kernel.org> # 3.4+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ab78029ecc347debbd737f06688d788bd9d60c1d 22-Jan-2013 Linus Walleij <linus.walleij@linaro.org> 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>
492d542273a4859f8bf8cc7744cdf71ef50b39ea 10-Jul-2012 Dan Williams <dan.j.williams@intel.com> [SCSI] cleanup usages of scsi_complete_async_scans

Now that scsi registers its async scan work with the async subsystem,
wait_for_device_probe() is sufficient for ensuring all scanning is
complete.

[jejb: fix merge problems with eea03c20ae38 Make wait_for_device_probe() also do scsi_complete_async_scans()]
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Eldad Zack <eldad@fogrefinery.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
eea03c20ae38a55405c0865ed9adfccc400e4c8e 19-Jul-2012 Linus Torvalds <torvalds@linux-foundation.org> Make wait_for_device_probe() also do scsi_complete_async_scans()

Commit a7a20d103994 ("sd: limit the scope of the async probe domain")
make the SCSI device probing run device discovery in it's own async
domain.

However, as a result, the partition detection was no longer synchronized
by async_synchronize_full() (which, despite the name, only synchronizes
the global async space, not all of them). Which in turn meant that
"wait_for_device_probe()" would not wait for the SCSI partitions to be
parsed.

And "wait_for_device_probe()" was what the boot time init code relied on
for mounting the root filesystem.

Now, most people never noticed this, because not only is it
timing-dependent, but modern distributions all use initrd. So the root
filesystem isn't actually on a disk at all. And then before they
actually mount the final disk filesystem, they will have loaded the
scsi-wait-scan module, which not only does the expected
wait_for_device_probe(), but also does scsi_complete_async_scans().

[ Side note: scsi_complete_async_scans() had also been partially broken,
but that was fixed in commit 43a8d39d0137 ("fix async probe
regression"), so that same commit a7a20d103994 had actually broken
setups even if you used scsi-wait-scan explicitly ]

Solve this problem by just moving the scsi_complete_async_scans() call
into wait_for_device_probe(). Everybody who wants to wait for device
probing to finish really wants the SCSI probing to complete, so there's
no reason not to do this.

So now "wait_for_device_probe()" really does what the name implies, and
properly waits for device probing to finish. This also removes the now
unnecessary extra calls to scsi_complete_async_scans().

Reported-and-tested-by: Artem S. Tashkinov <t.artem@mailcity.com>
Cc: Dan Williams <dan.j.williams@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: James Bottomley <jbottomley@parallels.com>
Cc: Borislav Petkov <bp@amd64.org>
Cc: linux-scsi <linux-scsi@vger.kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
eed5d2150752bd08b22333d739f3120151773d28 12-Jul-2012 Rafael J. Wysocki <rjw@sisk.pl> PM / Runtime: Do not increment device usage counts before probing

The pm_runtime_get_noresume() calls before really_probe() and
before executing __device_attach() for each driver on the
device's bus cause problems to happen if probing fails and if the
driver has enabled runtime PM for the device in its .probe()
callback. Namely, in that case, if the device has been resumed
by the driver after enabling its runtime PM and if it turns out that
.probe() should return an error, the driver is supposed to suspend
the device and disable its runtime PM before exiting .probe().
However, because the device's runtime PM usage counter was
incremented by the core before calling .probe(), the driver's attempt
to suspend the device will not succeed and the device will remain in
the full-power state after the failing .probe() has returned.

To fix this issue, remove the pm_runtime_get_noresume() calls from
driver_probe_device() and from device_attach() and replace the
corresponding pm_runtime_put_sync() calls with pm_runtime_idle()
to preserve the existing behavior (which is to check if the device
is idle and to suspend it eventually in that case after probing).

Reported-and-tested-by: Kevin Hilman <khilman@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8153584e3fdf78753bf653d5f583b6ecb86e5e70 05-Jul-2012 Mark Brown <broonie@opensource.wolfsonmicro.com> driver core: Move deferred devices to the end of dpm_list before probing

When deferred probe was originally added the idea was that devices which
defer their probes would move themselves to the end of dpm_list in order
to try to keep the assumptions that we're making about the list being in
roughly the order things should be suspended correct. However this hasn't
been what's been happening and doing it requires a lot of duplicated code
to do the moves.

Instead take a simple, brute force solution and have the deferred probe
code push devices to the end of dpm_list before it retries the probe. This
does mean we lock the dpm_list a bit more often but it's very simple and
the code shouldn't be a fast path. We do the move with the deferred mutex
dropped since doing things with fewer locks held simultaneously seems like
a good idea.

This approach was most recently suggested by Grant Likely.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Grant Likely <grant.likely@secretlab.ca>,
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
0998d0631001288a5974afc0b2a5f568bcdecb4d 23-May-2012 Hans de Goede <hdegoede@redhat.com> device-core: Ensure drvdata = NULL when no driver is bound

1) drvdata is for a driver to store a pointer to driver specific data
2) If no driver is bound, there is no driver specific data associated with
the device
3) Thus logically drvdata should be NULL if no driver is bound.

But many drivers don't clear drvdata on device_release, or set drvdata
early on in probe and leave it set on probe error. Both of which results
in a dangling pointer in drvdata.

This patch enforce for drvdata to be NULL after device_release or on probe
failure.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1d29cfa57471a5e4b8a7c2a7433eeba170d3ad92 30-May-2012 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> driver core: fixup reversed deferred probe order

If driver requests probe deferral,
it will be added to deferred_probe_pending_list
by driver_deferred_probe_add(), but, it used list_add().
Because of that, deferred probe will be run as reversed order.
This patch uses list_add_tail(), and solved this issue.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8b0372a258e6bd0e9e5ea3f3d5f05a6bf3972fee 08-Mar-2012 Greg Kroah-Hartman <gregkh@linuxfoundation.org> driver core: minor comment formatting cleanups

Came in in the deferred probe patch, quick, clean them up before a
kernel janitor finds them and sends me 4 individual patches to fix them
up...

Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ef8a3fd6e5e12e8989dae97ba5491c2e39369af9 08-Mar-2012 Greg Kroah-Hartman <gregkh@linuxfoundation.org> driver core: move the deferred probe pointer into the private area

Nothing outside of the driver core needs to get to the deferred probe
pointer, so move it inside the private area of 'struct device' so no one
tries to mess around with it.

Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
d1c3414c2a9d10ef7f0f7665f5d2947cd088c093 05-Mar-2012 Grant Likely <grant.likely@secretlab.ca> drivercore: Add driver probe deferral mechanism

Allow drivers to report at probe time that they cannot get all the resources
required by the device, and should be retried at a later time.

This should completely solve the problem of getting devices
initialized in the right order. Right now this is mostly handled by
mucking about with initcall ordering which is a complete hack, and
doesn't even remotely handle the case where device drivers are in
modules. This approach completely sidesteps the issues by allowing
driver registration to occur in any order, and any driver can request
to be retried after a few more other drivers get probed.

v4: - Integrate Manjunath's addition of a separate workqueue
- Change -EAGAIN to -EPROBE_DEFER for drivers to trigger deferral
- Update comment blocks to reflect how the code really works
v3: - Hold off workqueue scheduling until late_initcall so that the bulk
of driver probes are complete before we start retrying deferred devices.
- Tested with simple use cases. Still needs more testing though.
Using it to get rid of the gpio early_initcall madness, or to replace
the ASoC internal probe deferral code would be ideal.
v2: - added locking so it should no longer be utterly broken in that regard
- remove device from deferred list at device_del time.
- Still completely untested with any real use case, but has been
boot tested.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dilan Lee <dilee@nvidia.com>
Cc: Manjunath GKondaiah <manjunath.gkondaiah@linaro.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: David Daney <david.daney@cavium.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
bcbe4f94d15ae1c985336bb3c35605e595fdde0d 20-Sep-2011 Wolfram Sang <w.sang@pengutronix.de> drivers: base: print rejected matches with DEBUG_DRIVER

When DEBUG_DRIVER is activated, be verbose and explicitly state when a
device<->driver match was rejected by the probe-function of the driver.
Now all code-paths report what is currently happening which helps
debugging, because you don't have to remember that no printout means
the match is rejected (and then you still don't know if it was because
of ENODEV or ENXIO).

Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
e1866b33b1e89f077b7132daae3dfd9a594e9a1a 29-Apr-2011 Rafael J. Wysocki <rjw@sisk.pl> PM / Runtime: Rework runtime PM handling during driver removal

The driver core tries to prevent race conditions between runtime PM
and driver removal from happening by incrementing the runtime PM
usage counter of the device and executing pm_runtime_barrier() before
running the bus notifier and the ->remove() callbacks provided by the
device's subsystem or driver. This guarantees that, if a future
runtime suspend of the device has been scheduled or a runtime resume
or idle request has been queued up right before the driver removal,
it will be canceled or waited for to complete and no other
asynchronous runtime suspend or idle requests for the device will be
put into the PM workqueue until the ->remove() callback returns.
However, it doesn't prevent resume requests from being queued up
after pm_runtime_barrier() has been called and it doesn't prevent
pm_runtime_resume() from executing the device subsystem's runtime
resume callback. Morever, it prevents the device's subsystem or
driver from putting the device into the suspended state by calling
pm_runtime_suspend() from its ->remove() routine. This turns out to
be a major inconvenience for some subsystems and drivers that want to
leave the devices they handle in the suspended state.

To really prevent runtime PM callbacks from racing with the bus
notifier callback in __device_release_driver(), which is necessary,
because the notifier is used by some subsystems to carry out
operations affecting the runtime PM functionality, use
pm_runtime_get_sync() instead of the combination of
pm_runtime_get_noresume() and pm_runtime_barrier(). This will resume
the device if it's in the suspended state and will prevent it from
being suspended again until pm_runtime_put_*() is called.

To allow subsystems and drivers to put devices into the suspended
state by calling pm_runtime_suspend() from their ->remove() routines,
execute pm_runtime_put_sync() after running the bus notifier in
__device_release_driver(). This will require subsystems and drivers
to make their ->remove() callbacks avoid races with runtime PM
directly, but it will allow of more flexibility in the handling of
devices during the removal of their drivers.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
c8705082404823a5bb3e02a32ba0764399b9e6f2 20-Apr-2011 Uwe Kleine-König <u.kleine-koenig@pengutronix.de> driver core: let dev_set_drvdata return int instead of void as it can fail

Before commit

b402843 (Driver core: move dev_get/set_drvdata to drivers/base/dd.c)

calling dev_set_drvdata with dev=NULL was an unchecked error. After some
discussion about what to return in this case removing the check (and so
producing a null pointer exception) seems fine.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8497d6a21c4b17052e868bd53a74c82b557a6c46 12-Apr-2011 Sebastian Ott <sebott@linux.vnet.ibm.com> driver-core: fix race between device_register and driver_register

When a device is registered to a bus it will be a) added to the list
of devices of the bus and b) bind to a driver (if one matches). As a
result of a driver being registered at this bus between a) and b) this
device could already be bound to a driver. This leads to a warning
and incorrect refcounting.
To fix this add a check to device_attach to identify an already bound
device.

Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
45daef0fdcc44f6af86fdebc4fc7eb7c79375398 23-Jul-2010 Magnus Damm <damm@opensource.se> Driver core: Add BUS_NOTIFY_BIND_DRIVER

Add BUS_NOTIFY_BIND_DRIVER as a bus notifier event.

For driver binding/unbinding we with this in
place have the following bus notifier events:
- BUS_NOTIFY_BIND_DRIVER - before ->probe()
- BUS_NOTIFY_BOUND_DRIVER - after ->probe()
- BUS_NOTIFY_UNBIND_DRIVER - before ->remove()
- BUS_NOTIFY_UNBOUND_DRIVER - after ->remove()

The event BUS_NOTIFY_BIND_DRIVER allows bus code
to be notified that ->probe() is about to be called.

Useful for bus code that needs to setup hardware before
the driver gets to run. With this in place platform
drivers can be loaded and unloaded as modules and the
new BIND event allows bus code to control for instance
device clocks that must be enabled before the driver
can be executed.

Without this patch there is no way for the bus code to
get notified that a modular driver is about to be probed.

Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
fbb88fadf7dc2dd6d0d1aa88ff521b2f8552996a 06-Mar-2010 Stefani Seibold <stefani@seibold.net> driver-core: fix potential race condition in drivers/base/dd.c

This patch fix a potential race condition in the driver_bound() function
in the file driver/base/dd.c.

The broadcast of the BUS_NOTIFY_BOUND_DRIVER notifier should be done
after adding the new device to the driver list. Otherwise notifier
listener will fail if they use functions like usb_find_interface().

The patch is against kernel 2.6.33. Please merge it.

Signed-off-by: Stefani Seibold <stefani@seibold.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8e9394ce2412254ec69fd2a4f3e44a66eade2297 17-Feb-2010 Greg Kroah-Hartman <gregkh@suse.de> Driver core: create lock/unlock functions for struct device

In the future, we are going to be changing the lock type for struct
device (once we get the lockdep infrastructure properly worked out) To
make that changeover easier, and to possibly burry the lock in a
different part of struct device, let's create some functions to lock and
unlock a device so that no out-of-core code needs to be changed in the
future.

This patch creates the device_lock/unlock/trylock() functions, and
converts all in-tree users to them.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Dave Young <hidave.darkstar@gmail.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Phil Carmody <ext-phil.2.carmody@nokia.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Len Brown <len.brown@intel.com>
Cc: Magnus Damm <damm@igel.co.jp>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Alex Chiang <achiang@hp.com>
Cc: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrew Patterson <andrew.patterson@hp.com>
Cc: Yu Zhao <yu.zhao@intel.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Wolfram Sang <w.sang@pengutronix.de>
Cc: CHENG Renquan <rqcheng@smu.edu.sg>
Cc: Oliver Neukum <oliver@neukum.org>
Cc: Frans Pop <elendil@planet.nl>
Cc: David Vrabel <david.vrabel@csr.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
af901ca181d92aac3a7dc265144a9081a86d8f39 14-Nov-2009 André Goddard Rosa <andre.goddard@gmail.com> tree-wide: fix assorted typos all over the place

That is "success", "unknown", "through", "performance", "[re|un]mapping"
, "access", "default", "reasonable", "[con]currently", "temperature"
, "channel", "[un]used", "application", "example","hierarchy", "therefore"
, "[over|under]flow", "contiguous", "threshold", "enough" and others.

Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
b4028437876866aba4747a655ede00f892089e14 11-May-2009 Greg Kroah-Hartman <gregkh@suse.de> Driver core: move dev_get/set_drvdata to drivers/base/dd.c

No one should directly access the driver_data field, so remove the field
and make it private. We dynamically create the private field now if it
is needed, to handle drivers that call get/set before they are
registered with the driver core.

Also update the copyright notices on these files while we are there.

Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
5e928f77a09a07f9dd595bb8a489965d69a83458 18-Aug-2009 Rafael J. Wysocki <rjw@sisk.pl> PM: Introduce core framework for run-time PM of I/O devices (rev. 17)

Introduce a core framework for run-time power management of I/O
devices. Add device run-time PM fields to 'struct dev_pm_info'
and device run-time PM callbacks to 'struct dev_pm_ops'. Introduce
a run-time PM workqueue and define some device run-time PM helper
functions at the core level. Document all these things.

Special thanks to Alan Stern for his help with the design and
multiple detailed reviews of the pereceding versions of this patch
and to Magnus Damm for testing feedback.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Magnus Damm <damm@igel.co.jp>
59a3cd7f9da60ac4ba8ae5a4cddc48fe4a450129 06-May-2009 Dmitry Torokhov <dmitry.torokhov@gmail.com> Driver core: fix comment for device_attach()

We are looking for matching drivers, not devices.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
309b7d60a345f402bec3cf9caadb53de4028e2aa 24-Apr-2009 Joerg Roedel <joerg.roedel@amd.com> driver core: add BUS_NOTIFY_UNBOUND_DRIVER event

This patch adds a new bus notifier event which is emitted _after_ a
device is removed from its driver. This event will be used by the
dma-api debug code to check if a driver has released all dma allocations
for that device.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
d4d5291c8cd499b1b590336059d5cc3e24c1ced6 21-Apr-2009 Arjan van de Ven <arjan@linux.intel.com> driver synchronization: make scsi_wait_scan more advanced

There is currently only one way for userspace to say "wait for my storage
device to get ready for the modules I just loaded": to load the
scsi_wait_scan module. Expectations of userspace are that once this
module is loaded, all the (storage) devices for which the drivers
were loaded before the module load are present.

Now, there are some issues with the implementation, and the async
stuff got caught in the middle of this: The existing code only
waits for the scsy async probing to finish, but it did not take
into account at all that probing might not have begun yet.
(Russell ran into this problem on his computer and the fix works for him)

This patch fixes this more thoroughly than the previous "fix", which
had some bad side effects (namely, for kernel code that wanted to wait for
the scsi scan it would also do an async sync, which would deadlock if you did
it from async context already.. there's a report about that on lkml):
The patch makes the module first wait for all device driver probes, and then it
will wait for the scsi parallel scan to finish.

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
8940b4f312dced51b45004819b776ec3aa7fcd5d 16-Dec-2008 Greg Kroah-Hartman <gregkh@suse.de> driver core: move knode_driver into private structure

Nothing outside of the driver core should ever touch knode_driver, so
move it out of the public eye.

Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
b23530ebc339c4092ae2c9f37341a5398fea8b89 21-Feb-2009 Ming Lei <tom.leiming@gmail.com> driver core: remove polling for driver_probe_done(v5)

This patch removes 100ms polling for driver_probe_done in
wait_for_device_probe(), and uses wait_event() instead.
Removing polling in fs initialization may lead to
a faster boot.

This patch also changes the return type of wait_for_device_done()
from int to void.

This patch is against Arjan's patch in linux-next tree.

Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
49b420a13ff95b449947181190b08367348e3e1b 21-Jan-2009 Ming Lei <tom.leiming@gmail.com> driver core: check bus->match without holding device lock

This patch moves bus->match out from driver_probe_device and
does not hold device lock to check the match between a device
and a driver.

The idea has been verified by the commit 6cd495860901,
which leads to a faster boot. But the commit 6cd495860901 has
the following drawbacks: 1),only does the quick check in
the path of __driver_attach->driver_probe_device, not in other
paths; 2),for a matched device and driver, check the same match
twice. It is a waste of cpu ,especially for some drivers with long
device id table (eg. usb-storage driver).

This patch adds a helper of driver_match_device to check the match
in all paths, and testes the match only once.

Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
216773a787c3c46ef26bf1742c1fdba37d26be45 14-Feb-2009 Arjan van de Ven <arjan@linux.intel.com> Consolidate driver_probe_done() loops into one place

there's a few places that currently loop over driver_probe_done(), and
I'm about to add another one. This patch abstracts it into a helper
to reduce duplication.

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Len Brown <lenb@kernel.org>
Acked-by: Greg KH <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
cda5e83fdea476dce9c0a9b1152cd6ca46832cc4 09-Jan-2009 Greg Kroah-Hartman <gregkh@suse.de> Revert "driver core: move knode_driver into private structure"

This reverts commit 93e746db183b3bdbbda67900f79b5835f9cb388f.

Turns out that device_initialize shouldn't fail silently.
This series needs to be reworked in order to get into proper
shape.

Reported-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
7232800ba8aca1c070d43a81cc49991f230b5da1 17-Dec-2008 Ming Lei <tom.leiming@gmail.com> driver core:fix duplicate removing driver link in __device_release_driver

In __device_release_driver(),driver_sysfs_remove() has removed the
driver link under device dir in sysfs, but sysfs_remove_link() is
called again to do such thing. Remove the duplicate call to
sys_remove_link().

Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
93e746db183b3bdbbda67900f79b5835f9cb388f 16-Dec-2008 Greg Kroah-Hartman <gregkh@suse.de> driver core: move knode_driver into private structure

Nothing outside of the driver core should ever touch knode_driver, so
move it out of the public eye.

Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
1e0b2cf933ebf32494eba3f668859ba57f06a951 30-Oct-2008 Kay Sievers <kay.sievers@vrfy.org> driver core: struct device - replace bus_id with dev_name(), dev_set_name()

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
6cd49586090187a2a145bb6570fb2392f121aa22 14-Sep-2008 Arjan van de Ven <arjan@linux.intel.com> device model: Do a quickcheck for driver binding before doing an expensive check

This patch adds a quick check for the driver<->device match before
taking the locks and doin gthe expensive checks. Taking the lock hurts
in asynchronous boot context where the device lock gets hit; one of the
init functions takes the lock and goes to do an expensive hardware init;
the other init functions walk the same PCI list and get stuck on the
lock as a result.

For the common case, we can know there's no chance whatsoever of a match
if the device isn't in the drivers ID table... so this patch does that
check as a best-effort-avoid-the-lock approach.

Bootcharts for before and after can be seen at
http://www.fenrus.org/before.svg
http://www.fenrus.org/after.svg

Note the long time "agp_ali_init" takes in the first graph; my laptop
doesn't even have an ALI chip in it! (the bootgraphs look a bit
dissimilar, but that's the point, the first one has a bunch of arbitrary
delays in it that cause it to look very different)

This reduces my kernel boot time by about 20%

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2b3a302a09735276e13421db56c20045a48eb06d 05-Mar-2008 Harvey Harrison <harvey.harrison@gmail.com> driver core: replace remaining __FUNCTION__ occurrences

__FUNCTION__ is gcc-specific, use __func__

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
4a3ad20ccd8f4d2a0535cf98fa83f7b561ba59a9 25-Jan-2008 Greg Kroah-Hartman <gregkh@suse.de> Driver core: coding style fixes

Fix up a number of coding style issues in the drivers/base/ directory
that have annoyed me over the years. checkpatch.pl is now very happy.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ef2c51746dc89c2326ce522f8fb8a57695780e75 16-Nov-2007 Alan Stern <stern@rowland.harvard.edu> Driver core: fix race in __device_release_driver

This patch (as1013) was suggested by David Woodhouse; it fixes a race
in the driver core. If a device is unregistered at the same time as
its driver is unloaded, the driver's code pages may be unmapped while
the remove method is still running. The calls to get_driver() and
put_driver() were intended to prevent this, but they don't work if the
driver's module count has already dropped to 0.

Instead, the patch keeps the device on the driver's list until after
the remove method has returned. This forces the necessary
synchronization to occur.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
7dc72b2842381684b864750af31a5fb168dec764 29-Nov-2007 Greg Kroah-Hartman <gregkh@suse.de> Driver core: clean up debugging messages

The driver core debugging messages are a mess. This provides a unified
message that makes them actually useful.

The format for new kobject debug messages should be:
driver/bus/class: 'OBJECT_NAME': FUNCTION_NAME: message.\n

Note, the class code is not changed in this patch due to pending patches
in my queue that this would conflict with. A later patch will clean
them up.

Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
e5dd12784617f0f1fae5f96a7fac1ec4c49fadbe 29-Nov-2007 Greg Kroah-Hartman <gregkh@suse.de> Driver core: move the static kobject out of struct driver

This patch removes the kobject, and a few other driver-core-only fields
out of struct driver and into the driver core only. Now drivers can be
safely create on the stack or statically (like they currently are.)

Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
c6f7e72a3f4641095ade9ded287d910c980c6148 02-Nov-2007 Greg Kroah-Hartman <gregkh@suse.de> driver core: remove fields from struct bus_type

struct bus_type is static everywhere in the kernel. This moves the
kobject in the structure out of it, and a bunch of other private only to
the driver core fields are now moved to a private structure. This lets
us dynamically create the backing kobject properly and gives us the
chance to be able to document to users exactly how to use the struct
bus_type as there are no fields they can improperly access.

Thanks to Kay for the build fixes on this patch.

Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ab71c6f0767bcbc618f3db51f668d5b951c00b60 17-Jun-2007 Stefan Richter <stefanr@s5r6.in-berlin.de> driver core: fix kernel doc of device_release_driver

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
1f5681aae8feadd113644c9e077152416c12b75c 17-Jun-2007 Stefan Richter <stefanr@s5r6.in-berlin.de> driver core: properly get driver in device_release_driver

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
475c5a1518477f0301fc50dc59e690032fad1fef 08-May-2007 Stephen Hemminger <shemminger@linux-foundation.org> Driver core: kill unused code

CC drivers/base/dd.o
drivers/base/dd.c:211: warning: =E2=80=98device_probe_drivers=E2=80=99 defi=
ned but not used

Looks like the following is dead.

Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
5adc55da4a7758021bcc374904b0f8b076508a11 27-Mar-2007 Adrian Bunk <bunk@stusta.de> PCI: remove the broken PCI_MULTITHREAD_PROBE option

This patch removes the PCI_MULTITHREAD_PROBE option that had already
been marked as broken.

Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
c6a46696f97ff260a4ecce5e287f8de4b9d7fe14 06-Feb-2007 Cornelia Huck <cornelia.huck@de.ibm.com> driver core: don't fail attaching the device if it cannot be bound

Don't fail bus_attach_device() if the device cannot be bound.

If dev->driver has been specified, reset it to NULL if device_bind_driver()
failed and add the device as an unbound device. As a result,
bus_attach_device() now cannot fail, and we can remove some checking from
device_add().

Also remove an unneeded check in bus_rescan_devices_helper().

Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
21c7f30b1d3f8a3de3128478daca3ce203fc8733 06-Feb-2007 Cornelia Huck <cornelia.huck@de.ibm.com> driver core: per-subsystem multithreaded probing

Make multithreaded probing work per subsystem instead of per driver.

It doesn't make much sense to probe the same device for multiple drivers in
parallel (after all, only one driver can bind to the device). Instead, create
a probing thread for each device that probes the drivers one after another.
Also make the decision to use multi-threaded probe per bus instead of per
device and adapt the pci code.

Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
9ac7849e35f705830f7b016ff272b0ff1f7ff759 20-Jan-2007 Tejun Heo <htejun@gmail.com> devres: device resource management

Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.

devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.

devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).

This patch adds devres core including documentation and the following
managed interfaces.

* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()

Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
cb986b749c7178422bfbc982cd30e04d5db54bbc 27-Nov-2006 Cornelia Huck <cornelia.huck@de.ibm.com> driver core: Change function call order in device_bind_driver().

Change function call order in device_bind_driver().

If we create symlinks (which might fail) before adding the device to the list
we don't have to clean up afterwards (which we didn't).

Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
c578abbc20762aa58e390e55252959853eeea17e 27-Nov-2006 Cornelia Huck <cornelia.huck@de.ibm.com> driver core: Don't stop probing on ->probe errors.

Don't stop on the first ->probe error that is not -ENODEV/-ENXIO.

There might be a driver registered returning an unresonable return code, and
this stops probing completely even though it may make sense to try the next
possible driver. At worst, we may end up with an unbound device.

Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
1901fb2604fbcd53201f38725182ea807581159e 07-Oct-2006 Kay Sievers <kay.sievers@novell.com> Driver core: fix "driver" symlink timing

Create the "driver" link before the child device may be created by
the probing logic. This makes it possible for userspace (udev), to
determine the driver property of the parent device, at the time the
child device is created.

Signed-off-by: Kay Sievers <kay.sievers@novell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
116af378201ef793424cd10508ccf18b06d8a021 25-Oct-2006 Benjamin Herrenschmidt <benh@kernel.crashing.org> 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>
735a7ffb739b6efeaeb1e720306ba308eaaeb20e 27-Oct-2006 Andrew Morton <akpm@osdl.org> [PATCH] drivers: wait for threaded probes between initcall levels

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

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

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

Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
4d664238207a82c4018757e2d87cf2a780462dcd 09-Oct-2006 Akinobu Mita <akinobu.mita@gmail.com> driver core: kmalloc() failure check in driver_probe_device

driver_probe_device() is missing kmalloc() failure check.

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
0fbf116d120a2dc5d808204c7d86ad35f7d7846f 27-Sep-2006 Duncan Sands <duncan.sands@free.fr> Driver core: plug device probe memory leak

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

Signed-off-by: Duncan Sands <baldrick@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
f2eaae197f4590c4d96f31b09b0ee9067421a95c 18-Sep-2006 Alan Stern <stern@rowland.harvard.edu> Driver core: Fix potential deadlock in driver core

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

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

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

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
d779249ed4cb3b50690de6de8448829d65a1cd08 18-Jul-2006 Greg Kroah-Hartman <gregkh@suse.de> Driver Core: add ability for drivers to do a threaded probe

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

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

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

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
f86db396ff455ed586751d21816a1ebd431264e5 15-Aug-2006 Andrew Morton <akpm@osdl.org> drivers/base: check errors

Add lots of return-value checking.

<pcornelia.huck@de.ibm.com>: fix bus_rescan_devices()]
Cc: "Randy.Dunlap" <rdunlap@xenotime.net>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
0f836ca4c122f4ef096110d652a6326fe34e6961 31-Mar-2006 Alan Stern <stern@rowland.harvard.edu> [PATCH] driver core: safely unbind drivers for devices not on a bus

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

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
594c8281f90560faf9632d91bb9d402cbe560e63 05-Jan-2006 Russell King <rmk@arm.linux.org.uk> [PATCH] Add bus_type probe, remove, shutdown methods.

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

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

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

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
bf74ad5bc41727d5f2f1c6bedb2c1fac394de731 17-Nov-2005 Alan Stern <stern@rowland.harvard.edu> [PATCH] Hold the device's parent's lock during probe and remove

This patch (as604) makes the driver core hold a device's parent's lock
as well as the device's lock during calls to the probe and remove
methods in a driver. This facility is needed by USB device drivers,
owing to the peculiar way USB devices work:

A device provides multiple interfaces, and drivers are bound
to interfaces rather than to devices;

Nevertheless a reset, reset-configuration, suspend, or resume
affects the entire device and requires the caller to hold the
lock for the device, not just a lock for one of the interfaces.

Since a USB driver's probe method is always called with the interface
lock held, the locking order rules (always lock parent before child)
prevent these methods from acquiring the device lock. The solution
provided here is to call all probe and remove methods, for all devices
(not just USB), with the parent lock already acquired.

Although currently only the USB subsystem requires these changes, people
have mentioned in prior discussion that the overhead of acquiring an
extra semaphore in all the prove/remove sequences is not overly large.

Up to now, the USB core has been using its own set of private
semaphores. A followup patch will remove them, relying entirely on the
device semaphores provided by the driver core.

The code paths affected by this patch are:

device_add and device_del: The USB core already holds the parent
lock, so no actual change is needed.

driver_register and driver_unregister: The driver core will now
lock both the parent and the device before probing or removing.

driver_bind and driver_unbind (in sysfs): These routines will
now lock both the parent and the device before binding or
unbinding.

bus_rescan_devices: The helper routine will lock the parent
before probing a device.

I have not tested this patch for conflicts with other subsystems. As
far as I can see, the only possibility of conflict would lie in the
bus_rescan_devices pathway, and it seems pretty remote. Nevertheless,
it would be good for this to get a lot of testing in -mm.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2b08c8d0468866f86da97f836c6ac14338cb81a9 24-Nov-2005 Alan Stern <stern@rowland.harvard.edu> [PATCH] Small fixes to driver core

This patch (as603) makes a few small fixes to the driver core:

Change spin_lock_irq for a klist lock to spin_lock;

Fix reference count leaks;

Minor spelling and formatting changes.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by Patrick Mochel <mochel@digitalimplant.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
4c898c7f2f286b204fefc5dddb568f755d195d0c 22-Sep-2005 Daniel Ritz <daniel.ritz@gmx.ch> [PATCH] Driver Core: fis bus rescan devices race

bus_rescan_devices_helper() does not hold the dev->sem when it checks for
!dev->driver(). device_attach() holds the sem, but calls again
device_bind_driver() even when dev->driver is set.

What happens is that a first device_attach() call (module insertion time)
is on the way binding the device to a driver. Another thread calls
bus_rescan_devices(). Now when bus_rescan_devices_helper() checks for
dev->driver it is still NULL 'cos the the prior device_attach() is not yet
finished. But as soon as the first one releases the dev->sem the second
device_attach() tries to rebind the already bound device again.
device_bind_driver() does this blindly which leads to a corrupt
driver->klist_devices list (the device links itself, the head points to the
device). Later a call to device_release_driver() sets dev->driver to NULL
and breaks the link it has to itself on knode_driver. Rmmoding the driver
later calls driver_detach() which leads to an endless loop 'cos the list
head in klist_devices still points to the device. And since dev->driver is
NULL it's stuck with the same device forever. Boom. And rmmod hangs.

Very easy to reproduce with new-style pcmcia and a 16bit card. Just loop
modprobe <pcmcia-modules> ;cardctl eject; rmmod <card driver, pcmcia
modules>.

Easiest fix is to check if the device is already bound to a driver in
device_bind_driver(). This avoids the double binding.

Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
d856f1e337782326c638c70c0b4df2b909350dec 19-Aug-2005 James Bottomley <James.Bottomley@SteelEye.com> [PATCH] klist: fix klist to have the same klist_add semantics as list_head

at the moment, the list_head semantics are

list_add(node, head)

whereas current klist semantics are

klist_add(head, node)

This is bound to cause confusion, and since klist is the newcomer, it
should follow the list_head semantics.

I also added missing include guards to klist.h

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
afdce75f1eaebcf358b7594ba7969aade105c3b0 23-Jun-2005 Greg Kroah-Hartman <gregkh@suse.de> [PATCH] driver core: Add the ability to bind drivers to devices from userspace

This adds a single file, "bind", to the sysfs directory of every driver
registered with the driver core. To bind a device to a driver, write
the bus id of the device you wish to bind to that specific driver to the
"bind" file (remember to not add a trailing \n). If that bus id matches
a device on that bus, and it does not currently have a driver bound to
it, the probe sequence will be initiated with that driver and device.

Note, this requires that the driver itself be willing and able to accept
that device (usually through a device id type table). This patch does
not make it possible to override the driver's id table.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ca2b94ba12f3c36fd3d6ed9d38b3798d4dad0d8b 18-May-2005 Hannes Reinecke <hare@suse.de> [PATCH] driver core: fix error handling in bus_add_device

The error handling in bus_add_device() and device_attach() is simply
non-existing. This patch propagates any error from device_attach to
the upper layers to allow for a proper recovery.

From: Hannes Reinecke <hare@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
c95a6b057b108c2b7add35cba1354f9af921349e 06-May-2005 Alan Stern <stern@rowland.harvard.edu> [PATCH] driver core: Fix races in driver_detach()

This patch is intended for your "driver" tree. It fixes several subtle
races in driver_detach() and device_release_driver() in the driver-model
core.

The major change is to use klist_remove() rather than klist_del() when
taking a device off its driver's list. There's no other way to guarantee
that the list pointers will be updated before some other driver binds to
the device. For this to work driver_detach() can't use a klist iterator,
so the loop over the devices must be written out in full. In addition the
patch protects against the possibility that, when a driver and a device
are unregistered at the same time, one may be unloaded from memory before
the other is finished using it.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
0d3e5a2e39b6ba2974e9e7c2a429018c45de8e76 06-Apr-2005 Patrick Mochel <mochel@digitalimplant.org> [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>
b86c1df1f98d16c999423a3907eb40a9423f481e 31-Mar-2005 gregkh@suse.de <gregkh@suse.de> [PATCH] Driver core: Fix up the driver and device iterators to be quieter

Also stops looping over the lists when a match is found.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de
0956af53afea290c5676c75249fc2c180d831375 25-Mar-2005 mochel@digitalimplant.org <mochel@digitalimplant.org> [PATCH] Call klist_del() instead of klist_remove().

- Can't wait on removing the current item in the list (the positive refcount *because*
we are using it causes it to deadlock).

Signed-off-by: Patrick Mochel <mochel@digitalimplant.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2287c322b61fced7e0c326a1a9606aa73147e3df 24-Mar-2005 mochel@digitalimplant.org <mochel@digitalimplant.org> [PATCH] Use bus_for_each_{dev,drv} for driver binding.

- Now possible, since the lists are locked using the klist lock and not the
global rwsem.

Signed-off-by: Patrick Mochel <mochel@digitalimplant.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
94e7b1c5ff2055571703e38b059afffe17658432 21-Mar-2005 mochel@digitalimplant.org <mochel@digitalimplant.org> [PATCH] Add a klist to struct device_driver for the devices bound to it.

- Use it in driver_for_each_device() instead of the regular list_head and stop using
the bus's rwsem for protection.
- Use driver_for_each_device() in driver_detach() so we don't deadlock on the
bus's rwsem.
- Remove ->devices.
- Move klist access and sysfs link access out from under device's semaphore, since
they're synchronized through other means.

Signed-off-by: Patrick Mochel <mochel@digitalimplant.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
07e4a3e27fe414980ddc85a358e5a56abc48b363 21-Mar-2005 mochel@digitalimplant.org <mochel@digitalimplant.org> [PATCH] Move device/driver code to drivers/base/dd.c

This relocates the driver binding/unbinding code to drivers/base/dd.c. This is done
for two reasons: One, it's not code related to the bus_type itself; it uses some from
that, some from devices, and some from drivers. And Two, it will make it easier to do
some of the upcoming lock removal on that code..

Signed-off-by: Patrick Mochel <mochel@digitalimplant.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>