linux.git/drivers/base/dd.c, branch v4.9-rc2

device core: Remove deprecated create_singlethread_workqueue

2016-09-02T13:08:02+00:00

The workqueue "deferred_wq" queues a single work item
&deferred_probe_work and hence doesn't require ordering.
It is involved in probing devices and is not being used on a memory
reclaim path. Hence, it has been converted to use system_wq.

System workqueues have been able to handle high level of concurrency
for a long time now and hence it's not required to have a singlethreaded
workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
created with create_singlethread_workqueue(), system_wq allows multiple
work items to overlap executions even on the same CPU; however, a
per-cpu workqueue doesn't have any CPU locality or global ordering
guarantee unless the target CPU is explicitly specified and thus the
increase of local concurrency shouldn't make any difference.

The work item has been flushed in driver_probe_done() to ensure that
there are no pending tasks while disconnecting the driver.

Signed-off-by: Bhaktipriya Shridhar 
Acked-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

driver core: add test of driver remove calls during probe

2016-08-31T13:13:55+00:00

In recent discussions on ksummit-discuss[1], it was suggested to do a
sequence of probe, remove, probe for testing driver remove paths. This
adds a kconfig option for said test.

[1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html

Suggested-by: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman

ARM: 8524/1: driver cohandle -EPROBE_DEFER from bus_type.match()

2016-02-16T16:28:51+00:00

Allow implementations of the match() callback in struct bus_type to
return errors and if it's -EPROBE_DEFER then queue the device for
deferred probing.

This is useful to buses such as AMBA in which devices are registered
before their matching information can be retrieved from the HW
(typically because a clock driver hasn't probed yet).

[changed if-else code structure, adjusted documentation to match the code,
extended comments]

Signed-off-by: Tomeu Vizoso 
Signed-off-by: Marek Szyprowski 
Reviewed-by: Ulf Hansson 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Russell King

driver core: Avoid NULL pointer dereferences in device_is_bound()

2016-01-12T00:51:44+00:00

If device_is_bound() is called on a device that's not been registered
yet, it will attepmt to dereference dev->p which is NULL, so avoid
that by checking dev->p in there against NULL.

Fixes: 6b9cb42752da "device core: add device_is_bound()"
Reported-and-tested-by: Guenter Roeck 
Tested-by: Tony Lindgren 
Signed-off-by: Rafael J. Wysocki

PM / sleep: Go direct_complete if driver has no callbacks

2016-01-08T00:12:06+00:00

If a suitable prepare callback cannot be found for a given device and
its driver has no PM callbacks at all, assume that it can go direct to
complete when the system goes to sleep.

The reason for this is that there's lots of devices in a system that do
no PM at all and there's no reason for them to prevent their ancestors
to do direct_complete if they can support it.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Ulf Hansson 
Signed-off-by: Rafael J. Wysocki

device core: add device_is_bound()

2016-01-08T00:12:06+00:00

Adds a function that tells whether a device is already bound to a
driver.

This is needed to warn when there is an attempt to change the PM domain
of a device that has finished probing already. The reason why we want to
enforce that is because in the general case that can cause problems and
also that we can simplify code quite a bit if we can always assume that.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Ulf Hansson 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Rafael J. Wysocki

Merge branch 'acpi-soc' into pm-core

2016-01-08T00:11:49+00:00

device core: add BUS_NOTIFY_DRIVER_NOT_BOUND notification

2015-12-09T00:25:01+00:00

The users of BUS_NOTIFY_BIND_DRIVER have no chance to do any cleanup in case of
a probe failure. In the result there might be problems, such as some resources
that had been allocated will continue to be allocated and therefore lead to a
resource leak.

Introduce a new notification to inform the subscriber that ->probe() failed. Do
the same in case of failed device_bind_driver() call.

Signed-off-by: Andy Shevchenko 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Rafael J. Wysocki

Merge branches 'pm-sleep' and 'pm-runtime' into pm-core

2015-12-07T01:17:17+00:00

PM / runtime: Re-init runtime PM states at probe error and driver unbind

2015-11-30T13:50:05+00:00

There are two common expectations among several subsystems/drivers that
deploys runtime PM support, but which isn't met by the driver core.

Expectation 1)
At ->probe() the subsystem/driver expects the runtime PM status of the
device to be RPM_SUSPENDED, which is the initial status being assigned at
device registration.

This expectation is especially common among some of those subsystems/
drivers that manages devices with an attached PM domain, as those requires
the ->runtime_resume() callback at the PM domain level to be invoked
during ->probe().

Moreover these subsystems/drivers entirely relies on runtime PM resources
being managed at the PM domain level, thus don't implement their own set
of runtime PM callbacks.

These are two scenarios that suffers from this unmet expectation.

i) A failed ->probe() sequence requests probe deferral:

->probe()
  ...
  pm_runtime_enable()
  pm_runtime_get_sync()
  ...

err:
  pm_runtime_put()
  pm_runtime_disable()
  ...

As there are no guarantees that such sequence turns the runtime PM status
of the device into RPM_SUSPENDED, the re-trying ->probe() may start with
the status in RPM_ACTIVE.

In such case the runtime PM core won't invoke the ->runtime_resume()
callback because of a pm_runtime_get_sync(), as it considers the device to
be already runtime resumed.

ii) A driver re-bind sequence:

At driver unbind, the subsystem/driver's >remove() callback invokes a
sequence of runtime PM APIs, to undo actions during ->probe() and to put
the device into low power state.

->remove()
  ...
  pm_runtime_put()
  pm_runtime_disable()
  ...

Similar as in the failing ->probe() case, this sequence don't guarantee
the runtime PM status of the device to turn into RPM_SUSPENDED.

Trying to re-bind the driver thus causes the same issue as when re-trying
->probe(), in the probe deferral scenario.

Expectation 2)
Drivers that invokes the pm_runtime_irq_safe() API during ->probe(),
triggers the runtime PM core to increase the usage count for the device's
parent and permanently make it runtime resumed.

The usage count is only dropped at device removal, which also allows it to
be runtime suspended again.

A re-trying ->probe() repeats the call to pm_runtime_irq_safe() and thus
once more triggers the usage count of the device's parent to be increased.

This leads to not only an imbalance issue of the usage count of the
device's parent, but also to keep it runtime resumed permanently even if
->probe() fails.

To address these issues, let's change the policy of the driver core to
meet these expectations. More precisely, at ->probe() failures and driver
unbind, restore the initial states of runtime PM.

Although to still allow subsystem's to control PM for devices that doesn't
->probe() successfully, don't restore the initial states unless runtime PM
is disabled.

Signed-off-by: Ulf Hansson 
Reviewed-by: Kevin Hilman 
Signed-off-by: Rafael J. Wysocki