linux-stable.git/drivers/base/dd.c, branch linux-3.8.y

drivercore: Fix ordering between deferred_probe and exiting initcalls

2013-02-28T13:38:32+00:00

commit d72cca1eee5b26e313da2a380d4862924e271031 upstream.

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 
Tested-by: Haojian Zhuang 
Cc: Arnd Bergmann 
Cc: Russell King 
Cc: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

PM / Runtime: Do not increment device usage counts before probing

2012-07-17T02:25:49+00:00

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 
Reviewed-by: Kevin Hilman 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

driver core: Move deferred devices to the end of dpm_list before probing

2012-07-17T01:05:45+00:00

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 
Acked-by: Rafael J. Wysocki 
Cc: Grant Likely ,
Signed-off-by: Greg Kroah-Hartman

Merge v3.5-rc5 into driver-core-next

2012-07-05T15:25:34+00:00

This picks up the big printk fixes, and resolves a merge issue with:
	drivers/extcon/extcon_gpio.c

Signed-off-by: Greg Kroah-Hartman

device-core: Ensure drvdata = NULL when no driver is bound

2012-06-13T23:40:41+00:00

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 
Signed-off-by: Greg Kroah-Hartman

driver core: fixup reversed deferred probe order

2012-06-13T20:42:39+00:00

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 
Signed-off-by: Greg Kroah-Hartman

driver core: minor comment formatting cleanups

2012-03-08T20:20:37+00:00

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 
Signed-off-by: Greg Kroah-Hartman

driver core: move the deferred probe pointer into the private area

2012-03-08T20:17:22+00:00

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 
Signed-off-by: Greg Kroah-Hartman

drivercore: Add driver probe deferral mechanism

2012-03-08T19:53:13+00:00

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 
Cc: Mark Brown 
Cc: Arnd Bergmann 
Cc: Dilan Lee 
Cc: Manjunath GKondaiah 
Cc: Alan Stern 
Cc: Tony Lindgren 
Cc: Alan Cox 
Reviewed-by: Mark Brown 
Acked-by: David Daney 
Reviewed-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

drivers: base: print rejected matches with DEBUG_DRIVER

2011-09-26T23:21:15+00:00

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 
Signed-off-by: Greg Kroah-Hartman