linux-toradex.git/drivers/base/base.h, branch v5.9-rc6

driver core: add deferring probe reason to devices_deferred property

2020-07-30T07:03:43+00:00

/sys/kernel/debug/devices_deferred property contains list of deferred devices.
This list does not contain reason why the driver deferred probe, the patch
improves it.
The natural place to set the reason is dev_err_probe function introduced
recently, ie. if dev_err_probe will be called with -EPROBE_DEFER instead of
printk the message will be attached to a deferred device and printed when user
reads devices_deferred property.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Mark Brown 
Reviewed-by: Javier Martinez Canillas 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Rafael J. Wysocki 
Link: https://lore.kernel.org/r/20200713144324.23654-3-a.hajda@samsung.com
Signed-off-by: Greg Kroah-Hartman

driver core: Don't do deferred probe in parallel with kernel_init thread

2020-07-10T13:20:38+00:00

The current deferred probe implementation can mess up suspend/resume
ordering if deferred probe thread is kicked off in parallel with the
main initcall thread (kernel_init thread) [1].

For example:

Say device-B is a consumer of device-A.

Initcall thread					Deferred probe thread
===============					=====================
1. device-A is added.
2. device-B is added.
3. dpm_list is now [device-A, device-B].
4. driver-A defers probe of device-A.
						5. device-A is moved to
						   end of dpm_list
						6. dpm_list is now
						   [device-B, device-A]
7. driver-B is registereed and probes device-B.
8. dpm_list stays as [device-B, device-A].

The reverse order of dpm_list is used for suspend. So in this case
device-A would incorrectly get suspended before device-B.

Commit 716a7a259690 ("driver core: fw_devlink: Add support for batching
fwnode parsing") kicked off the deferred probe thread early during boot
to run in parallel with the initcall thread and caused suspend/resume
regressions.  This patch removes the parallel run of the deferred probe
thread to avoid the suspend/resume regressions.

[1] - https://lore.kernel.org/lkml/CAGETcx8W96KAw-d_siTX4qHB_-7ddk0miYRDQeHE6E0_8qx-6Q@mail.gmail.com/

Fixes: 716a7a259690 ("driver core: fw_devlink: Add support for batching fwnode parsing")
Signed-off-by: Saravana Kannan 
Tested-by: Geert Uytterhoeven 
Link: https://lore.kernel.org/r/20200701194259.3337652-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman

driver core: fw_devlink: Add support for batching fwnode parsing

2020-05-15T14:34:52+00:00

The amount of time spent parsing fwnodes of devices can become really
high if the devices are added in an non-ideal order. Worst case can be
O(N^2) when N devices are added. But this can be optimized to O(N) by
adding all the devices and then parsing all their fwnodes in one batch.

This commit adds fw_devlink_pause() and fw_devlink_resume() to allow
doing this.

Signed-off-by: Saravana Kannan 
Link: https://lore.kernel.org/r/20200515053500.215929-4-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman

device.h: move devtmpfs prototypes out of the file

2019-12-16T09:10:18+00:00

The devtmpfs functions do not need to be in device.h as only the driver
core uses them, so move them to the private .h file for the driver core.

Cc: "Rafael J. Wysocki" 
Cc: Suzuki K Poulose 
Cc: Saravana Kannan 
Cc: Heikki Krogerus 
Link: https://lore.kernel.org/r/20191209193303.1694546-3-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman

drivers/base: base.h: add proper copyright and header info

2019-12-12T10:33:39+00:00

base.h didn't have any copyright information in it, so update it with
the correct information.

Cc: "Rafael J. Wysocki" 
Link: https://lore.kernel.org/r/20191209193303.1694546-2-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman

driver/core: Convert to use built-in RCU list checking

2019-08-13T21:28:47+00:00

This commit applies the consolidated hlist_for_each_entry_rcu() support
for lockdep conditions.

Acked-by: Greg Kroah-Hartman 
Signed-off-by: Joel Fernandes (Google) 
Signed-off-by: Paul E. McKenney

driver core: Probe devices asynchronously instead of the driver

2019-01-31T13:20:53+00:00

Probe devices asynchronously instead of the driver. This results in us
seeing the same behavior if the device is registered before the driver or
after. This way we can avoid serializing the initialization should the
driver not be loaded until after the devices have already been added.

The motivation behind this is that if we have a set of devices that
take a significant amount of time to load we can greatly reduce the time to
load by processing them in parallel instead of one at a time. In addition,
each device can exist on a different node so placing a single thread on one
CPU to initialize all of the devices for a given driver can result in poor
performance on a system with multiple nodes.

This approach can reduce the time needed to scan SCSI LUNs significantly.
The only way to realize that speedup is by enabling more concurrency which
is what is achieved with this patch.

To achieve this it was necessary to add a new member "async_driver" to the
device_private structure to store the driver pointer while we wait on the
deferred probe call.

Reviewed-by: Bart Van Assche 
Reviewed-by: Dan Williams 
Signed-off-by: Alexander Duyck 
Reviewed-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

device core: Consolidate locking and unlocking of parent and device

2019-01-31T13:20:53+00:00

Try to consolidate all of the locking and unlocking of both the parent and
device when attaching or removing a driver from a given device.

To do that I first consolidated the lock pattern into two functions
__device_driver_lock and __device_driver_unlock. After doing that I then
created functions specific to attaching and detaching the driver while
acquiring these locks. By doing this I was able to reduce the number of
spots where we touch need_parent_lock from 12 down to 4.

This patch should produce no functional changes, it is meant to be a code
clean-up/consolidation only.

Reviewed-by: Luis Chamberlain 
Reviewed-by: Bart Van Assche 
Reviewed-by: Dan Williams 
Reviewed-by: Rafael J. Wysocki 
Signed-off-by: Alexander Duyck 
Signed-off-by: Greg Kroah-Hartman

driver core: Establish order of operations for device_add and device_del via bitflag

2019-01-31T13:20:53+00:00

Add an additional bit flag to the device_private struct named "dead".

This additional flag provides a guarantee that when a device_del is
executed on a given interface an async worker will not attempt to attach
the driver following the earlier device_del call. Previously this
guarantee was not present and could result in the device_del call
attempting to remove a driver from an interface only to have the async
worker attempt to probe the driver later when it finally completes the
asynchronous probe call.

One additional change added was that I pulled the check for dev->driver
out of the __device_attach_driver call and instead placed it in the
__device_attach_async_helper call. This was motivated by the fact that the
only other caller of this, __device_attach, had already taken the
device_lock() and checked for dev->driver. Instead of testing for this
twice in this path it makes more sense to just consolidate the dev->dead
and dev->driver checks together into one set of checks.

Reviewed-by: Dan Williams 
Reviewed-by: Rafael J. Wysocki 
Signed-off-by: Alexander Duyck 
Signed-off-by: Greg Kroah-Hartman

driver core: move device->knode_class to device_private

2019-01-18T15:55:48+00:00

As the description of struct device_private says, it stores data which
is private to driver core. And it already has similar fields like:
knode_parent, knode_driver, knode_driver and knode_bus. This look it is
more proper to put knode_class together with those fields to make it
private to driver core.

This patch move device->knode_class to device_private to make it comply
with code convention.

Signed-off-by: Wei Yang 
Reviewed-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman