linux/drivers/base/base.h, branch v5.14

driver core: Export device_driver_attach()

2021-06-21T21:29:24Z

This is intended as a replacement API for device_bind_driver(). It has at least the following benefits: - Internal locking. Few of the users of device_bind_driver() follow the locking rules - Calls device driver probe() internally. Notably this means that devm support for probe works correctly as probe() error will call devres_release_all() - struct device_driver -> dev_groups is supported - Simplified calling convention, no need to manually call probe(). The general usage is for situations that already know what driver to bind and need to ensure the bind is synchronized with other logic. Call device_driver_attach() after device_add(). If probe() returns a failure then this will be preserved up through to the error return of device_driver_attach(). Signed-off-by: Jason Gunthorpe Signed-off-by: Christoph Hellwig Reviewed-by: Cornelia Huck Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20210617142218.1877096-6-hch@lst.de Signed-off-by: Alex Williamson

driver core: Improve fw_devlink & deferred_probe_timeout interaction

2021-04-05T07:17:56Z

deferred_probe_timeout kernel commandline parameter allows probing of consumer devices if the supplier devices don't have any drivers. fw_devlink=on will indefintely block probe() calls on a device if all its suppliers haven't probed successfully. This completely skips calls to driver_deferred_probe_check_state() since that's only called when a .probe() function calls framework APIs. So fw_devlink=on breaks deferred_probe_timeout. deferred_probe_timeout in its current state also ignores a lot of information that's now available to the kernel. It assumes all suppliers that haven't probed when the timer expires (or when initcalls are done on a static kernel) will never probe and fails any calls to acquire resources from these unprobed suppliers. However, this assumption by deferred_probe_timeout isn't true under many conditions. For example: - If the consumer happens to be before the supplier in the deferred probe list. - If the supplier itself is waiting on its supplier to probe. This patch fixes both these issues by relaxing device links between devices only if the supplier doesn't have any driver that could match with (NOT bound to) the supplier device. This way, we only fail attempts to acquire resources from suppliers that truly don't have any driver vs suppliers that just happen to not have probed yet. Signed-off-by: Saravana Kannan Link: https://lore.kernel.org/r/20210402040342.2944858-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman

driver core: Update device link status properly for device_bind_driver()

2021-03-23T13:58:11Z

Device link status was not getting updated correctly when device_bind_driver() is called on a device. This causes a warning[1]. Fix this by updating device links that can be updated and dropping device links that can't be updated to a sensible state. [1] - https://lore.kernel.org/lkml/56f7d032-ba5a-a8c7-23de-2969d98c527e@nvidia.com/ Tested-by: Jon Hunter Signed-off-by: Saravana Kannan Link: https://lore.kernel.org/r/20210302211133.2244281-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman

driver core: auxiliary bus: Fix calling stage for auxiliary bus init

2021-02-11T07:43:03Z

When the auxiliary device code is built into the kernel, it can be executed before the auxiliary bus is registered. This causes bus->p to be not allocated and triggers a NULL pointer dereference when the auxiliary bus device gets added with bus_add_device(). Call the auxiliary_bus_init() under driver_init() so the bus is initialized before devices. Below is the kernel splat for the bug: [ 1.948215] BUG: kernel NULL pointer dereference, address: 0000000000000060 [ 1.950670] #PF: supervisor read access in kernel mode [ 1.950670] #PF: error_code(0x0000) - not-present page [ 1.950670] PGD 0 [ 1.950670] Oops: 0000 1 SMP NOPTI [ 1.950670] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.0-intel-nextsvmtest+ #2205 [ 1.950670] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 1.950670] RIP: 0010:bus_add_device+0x64/0x140 [ 1.950670] Code: 00 49 8b 75 20 48 89 df e8 59 a1 ff ff 41 89 c4 85 c0 75 7b 48 8b 53 50 48 85 d2 75 03 48 8b 13 49 8b 85 a0 00 00 00 48 89 de <48> 8 78 60 48 83 c7 18 e8 ef d9 a9 ff 41 89 c4 85 c0 75 45 48 8b [ 1.950670] RSP: 0000:ff46032ac001baf8 EFLAGS: 00010246 [ 1.950670] RAX: 0000000000000000 RBX: ff4597f7414aa680 RCX: 0000000000000000 [ 1.950670] RDX: ff4597f74142bbc0 RSI: ff4597f7414aa680 RDI: ff4597f7414aa680 [ 1.950670] RBP: ff46032ac001bb10 R08: 0000000000000044 R09: 0000000000000228 [ 1.950670] R10: ff4597f741141b30 R11: ff4597f740182a90 R12: 0000000000000000 [ 1.950670] R13: ffffffffa5e936c0 R14: 0000000000000000 R15: 0000000000000000 [ 1.950670] FS: 0000000000000000(0000) GS:ff4597f7bba00000(0000) knlGS:0000000000000000 [ 1.950670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.950670] CR2: 0000000000000060 CR3: 000000002140c001 CR4: 0000000000f71ef0 [ 1.950670] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1.950670] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1.950670] PKRU: 55555554 [ 1.950670] Call Trace: [ 1.950670] device_add+0x3ee/0x850 [ 1.950670] __auxiliary_device_add+0x47/0x60 [ 1.950670] idxd_pci_probe+0xf77/0x1180 [ 1.950670] local_pci_probe+0x4a/0x90 [ 1.950670] pci_device_probe+0xff/0x1b0 [ 1.950670] really_probe+0x1cf/0x440 [ 1.950670] ? rdinit_setup+0x31/0x31 [ 1.950670] driver_probe_device+0xe8/0x150 [ 1.950670] device_driver_attach+0x58/0x60 [ 1.950670] __driver_attach+0x8f/0x150 [ 1.950670] ? device_driver_attach+0x60/0x60 [ 1.950670] ? device_driver_attach+0x60/0x60 [ 1.950670] bus_for_each_dev+0x79/0xc0 [ 1.950670] ? kmem_cache_alloc_trace+0x323/0x430 [ 1.950670] driver_attach+0x1e/0x20 [ 1.950670] bus_add_driver+0x154/0x1f0 [ 1.950670] driver_register+0x70/0xc0 [ 1.950670] __pci_register_driver+0x54/0x60 [ 1.950670] idxd_init_module+0xe2/0xfc [ 1.950670] ? idma64_platform_driver_init+0x19/0x19 [ 1.950670] do_one_initcall+0x4a/0x1e0 [ 1.950670] kernel_init_freeable+0x1fc/0x25c [ 1.950670] ? rest_init+0xba/0xba [ 1.950670] kernel_init+0xe/0x116 [ 1.950670] ret_from_fork+0x1f/0x30 [ 1.950670] Modules linked in: [ 1.950670] CR2: 0000000000000060 [ 1.950670] --[ end trace cd7d1b226d3ca901 ]-- Fixes: 7de3697e9cbd ("Add auxiliary bus support") Reported-by: Jacob Pan Reviewed-by: Dan Williams Acked-by: Dave Ertman Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/20210210201611.1611074-1-dave.jiang@intel.com Cc: stable Signed-off-by: Greg Kroah-Hartman

driver core: make driver_probe_device() static

2020-12-09T18:30:44Z

It's only used inside drivers/base/dd.c Signed-off-by: Julian Wiedmann Link: https://lore.kernel.org/r/20201123111938.18968-1-jwi@linux.ibm.com Signed-off-by: Greg Kroah-Hartman

Revert "driver core: fw_devlink: Add support for batching fwnode parsing"

2020-12-09T18:10:20Z

This reverts commit 716a7a25969003d82ab738179c3f1068a120ed11. The fw_devlink_pause/resume() APIs added by the commit being reverted were a first cut attempt at optimizing boot time. But these APIs don't fully solve the problem and are very fragile (can only be used for the top level devices being added). This series replaces them with a much better optimization that works for all device additions and also has the benefit of reducing the complexity of the firmware (DT, EFI) specific code and abstracting out common code to driver core. Signed-off-by: Saravana Kannan Link: https://lore.kernel.org/r/20201121020232.908850-7-saravanak@google.com Signed-off-by: Greg Kroah-Hartman

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

2020-12-09T18:10:20Z

This reverts commit cec72f3efc6272420c2c2c699607f03d09b93e41. Commit cec72f3efc62 ("driver core: Don't do deferred probe in parallel with kernel_init thread") was fixing a commit 716a7a259690 ("driver core: fw_devlink: Add support for batching fwnode parsing"). Since the commit being fixed itself is going to be reverted, the fix can also be reverted. Signed-off-by: Saravana Kannan Link: https://lore.kernel.org/r/20201121020232.908850-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman

driver core: add deferring probe reason to devices_deferred property

2020-07-30T07:03:43Z

/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:38Z

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:52Z

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