linux-toradex.git/drivers/base/dd.c, branch v4.9.121

driver core: Partially revert "driver core: correct device's shutdown order"

2018-07-28T05:49:13+00:00

commit 722e5f2b1eec7de61117b7c0a7914761e3da2eda upstream.

Commit 52cdbdd49853 (driver core: correct device's shutdown order)
introduced a regression by breaking device shutdown on some systems.

Namely, the devices_kset_move_last() call in really_probe() added by
that commit is a mistake as it may cause parents to follow children
in the devices_kset list which then causes shutdown to fail.  For
example, if a device has children before really_probe() is called
for it (which is not uncommon), that call will cause it to be
reordered after the children in the devices_kset list and the
ordering of that list will not reflect the correct device shutdown
order any more.

Also it causes the devices_kset list to be constantly reordered
until all drivers have been probed which is totally pointless
overhead in the majority of cases and it only covered an issue
with system shutdown, while system-wide suspend/resume potentially
had the same issue on the affected platforms (which was not covered).

Moreover, the shutdown issue originally addressed by the change in
really_probe() made by commit 52cdbdd49853 is not present in 4.18-rc
any more, since dra7 started to use the sdhci-omap driver which
doesn't disable any regulators during shutdown, so the really_probe()
part of commit 52cdbdd49853 can be safely reverted.  [The original
issue was related to the omap_hsmmc driver used by dra7 previously.]

For the above reasons, revert the really_probe() modifications made
by commit 52cdbdd49853.

The other code changes made by commit 52cdbdd49853 are useful and
they need not be reverted.

Fixes: 52cdbdd49853 (driver core: correct device's shutdown order)
Link: https://lore.kernel.org/lkml/CAFgQCTt7VfqM=UyCnvNFxrSw8Z6cUtAi3HUwR4_xPAc03SgHjQ@mail.gmail.com/
Reported-by: Pingfan Liu 
Tested-by: Pingfan Liu 
Reviewed-by: Kishon Vijay Abraham I 
Signed-off-by: Rafael J. Wysocki 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

driver core: fix smatch warning on dev->bus check

2016-10-31T15:15:22+00:00

Commit d42a09802174 (driver core: skip removal test for non-removable
drivers) introduced a smatch warning:

drivers/base/dd.c:386 really_probe()
         warn: variable dereferenced before check 'dev->bus' (see line 373)

Fix the warning by removing the dev->bus NULL check. dev->bus will never
be NULL, so the check was unnecessary.

Reported-by: Dan Carpenter 
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman

driver core: skip removal test for non-removable drivers

2016-10-31T15:15:22+00:00

Some drivers do not support removal/unbinding. These drivers should have
drv->suppress_bind_attrs set to true, so use that to skip the removal
test.

This doesn't fix anything reported so far, but should prevent some other
cases. Some drivers will need fixes to set suppress_bind_attrs to avoid
this test.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177021
Fixes: bea5b158ff0d ("driver core: add test of driver remove calls during probe")
Reported-by: Laszlo Ersek 
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman

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