linux/drivers/base/dd.c, branch v5.0

driver core: Add missing dev->bus->need_parent_lock checks

2018-12-19T09:08:34Z

__device_release_driver() has to check dev->bus->need_parent_lock before dropping the parent lock and acquiring it again as it may attempt to drop a lock that hasn't been acquired or lock a device that shouldn't be locked and create a lock imbalance. Fixes: 8c97a46af04b (driver core: hold dev's parent lock when needed) Signed-off-by: Rafael J. Wysocki Cc: stable Reviewed-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

driver core: Move async_synchronize_full call

2018-12-06T15:00:43Z

Move the async_synchronize_full call out of __device_release_driver and into driver_detach. The idea behind this is that the async_synchronize_full call will only guarantee that any existing async operations are flushed. This doesn't do anything to guarantee that a hotplug event that may occur while we are doing the release of the driver will not be asynchronously scheduled. By moving this into the driver_detach path we can avoid potential deadlocks as we aren't holding the device lock at this point and we should not have the driver we want to flush loaded so the flush will take care of any asynchronous events the driver we are detaching might have scheduled. Fixes: 765230b5f084 ("driver-core: add asynchronous probing support for drivers") Reviewed-by: Bart Van Assche Reviewed-by: Dan Williams Signed-off-by: Alexander Duyck Reviewed-by: Luis Chamberlain Signed-off-by: Greg Kroah-Hartman

driver core: fix comments for device_block_probing()

2018-11-11T17:54:42Z

Correct function name and spelling/typo for device_block_probing() in drivers/base/dd.c. Signed-off-by: Randy Dunlap Reviewed-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

driver core: Replace simple_strtol by kstrtoint

2018-11-11T17:54:42Z

The simple_strtol() function is deprecated, use kstrtoint() instead. Signed-off-by: Muchun Song Signed-off-by: Greg Kroah-Hartman

dma-mapping: remove dma_deconfigure

2018-09-08T09:19:28Z

This goes through a lot of hooks just to call arch_teardown_dma_ops. Replace it with a direct call instead. Signed-off-by: Christoph Hellwig Reviewed-by: Robin Murphy

dma-mapping: remove dma_configure

2018-09-08T09:19:20Z

There is no good reason for this indirection given that the method always exists. Signed-off-by: Christoph Hellwig Reviewed-by: Robin Murphy

Merge 4.18-rc7 into driver-core-next

2018-07-30T08:08:09Z

We need the driver core changes in here as well for testing. Signed-off-by: Greg Kroah-Hartman

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

2018-07-10T15:47:43Z

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: allow stopping deferred probe after init

2018-07-10T15:22:35Z

Deferred probe will currently wait forever on dependent devices to probe, but sometimes a driver will never exist. It's also not always critical for a driver to exist. Platforms can rely on default configuration from the bootloader or reset defaults for things such as pinctrl and power domains. This is often the case with initial platform support until various drivers get enabled. There's at least 2 scenarios where deferred probe can render a platform broken. Both involve using a DT which has more devices and dependencies than the kernel supports. The 1st case is a driver may be disabled in the kernel config. The 2nd case is the kernel version may simply not have the dependent driver. This can happen if using a newer DT (provided by firmware perhaps) with a stable kernel version. Deferred probe issues can be difficult to debug especially if the console has dependencies or userspace fails to boot to a shell. There are also cases like IOMMUs where only built-in drivers are supported, so deferring probe after initcalls is not needed. The IOMMU subsystem implemented its own mechanism to handle this using OF_DECLARE linker sections. This commit adds makes ending deferred probe conditional on initcalls being completed or a debug timeout. Subsystems or drivers may opt-in by calling driver_deferred_probe_check_init_done() instead of unconditionally returning -EPROBE_DEFER. They may use additional information from DT or kernel's config to decide whether to continue to defer probe or not. The timeout mechanism is intended for debug purposes and WARNs loudly. The remaining deferred probe pending list will also be dumped after the timeout. Not that this timeout won't work for the console which needs to be enabled before userspace starts. However, if the console's dependencies are resolved, then the kernel log will be printed (as opposed to no output). Cc: Alexander Graf Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman

driver core: add a debugfs entry to show deferred devices

2018-07-08T13:55:03Z

With Device Trees (DT), the dependencies of the devices are defined in the DT, then the drivers parse that information to lookup the needed resources that have as dependencies. Since drivers and devices are registered in a non-deterministic way, it is possible that a device that is a dependency has not been registered yet by the time that is looked up. In this case the driver that requires this dependency cannot probe and has to defer it. So the driver core adds it to a list of deferred devices that is iterated again every time that a new driver is probed successfully. For debugging purposes it may be useful to know what are the devices whose probe function was deferred. Add a debugfs entry showing that information. $ cat /sys/kernel/debug/devices_deferred 48070000.i2c:twl@48:bci musb-hdrc.0.auto omapdrm.0 This information could be obtained partially by enabling debugging, but it means that the kernel log has to be parsed and the probe deferral balanced with the successes. This can be error probe and has to be done in a ad-hoc manner by everyone who needs to debug these kind of issues. Since the information is already known by the kernel, just show it to make it easier to debug. Signed-off-by: Javier Martinez Canillas Reviewed-by: Andy Shevchenko Reviewed-by: Mark Brown Signed-off-by: Greg Kroah-Hartman