linux/drivers/base/dd.c, branch v4.19

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

drivers: base: initcall_debug logs for driver probe times

2018-07-06T14:53:17Z

Add initcall_debug logs for each driver device probe call, for example: probe of a3800000.ramoops returned 1 after 3007 usecs This replaces the previous code added to report times for deferred probes. It also reports OF platform bus device creates that were formerly lumped together in a single entry for function of_platform_default_populate_init, as well as helping to annotate other initcalls that involve device probing. Remove restriction on printing probe times only during initcalls, since initcall_debug now continues to show driver timing info past the boot phase. Signed-off-by: Todd Poynor Reviewed-by: Rob Herring Signed-off-by: Greg Kroah-Hartman

Merge tag 'pm-4.18-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

2018-06-13T14:24:18Z

Pull more power management updates from Rafael Wysocki: "These revert a recent PM core change that introduced a regression, fix the build when the recently added Kryo cpufreq driver is selected, add support for devices attached to multiple power domains to the generic power domains (genpd) framework, add support for iowait boosting on systens with hardware-managed P-states (HWP) enabled to the intel_pstate driver, modify the behavior of the wakeup_count device attribute in sysfs, fix a few issues and clean up some ugliness, mostly in cpufreq (core and drivers) and in the cpupower utility. Specifics: - Revert a recent PM core change that attempted to fix an issue related to device links, but introduced a regression (Rafael Wysocki) - Fix build when the recently added cpufreq driver for Kryo processors is selected by making it possible to build that driver as a module (Arnd Bergmann) - Fix the long idle detection mechanism in the out-of-band (ondemand and conservative) cpufreq governors (Chen Yu) - Add support for devices in multiple power domains to the generic power domains (genpd) framework (Ulf Hansson) - Add support for iowait boosting on systems with hardware-managed P-states (HWP) enabled to the intel_pstate driver and make it use that feature on systems with Skylake Xeon processors as it is reported to improve performance significantly on those systems (Srinivas Pandruvada) - Fix and update the acpi_cpufreq, ti-cpufreq and imx6q cpufreq drivers (Colin Ian King, Suman Anna, Sébastien Szymanski) - Change the behavior of the wakeup_count device attribute in sysfs to expose the number of events when the device might have aborted system suspend in progress (Ravi Chandra Sadineni) - Fix two minor issues in the cpupower utility (Abhishek Goel, Colin Ian King)" * tag 'pm-4.18-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Revert "PM / runtime: Fixup reference counting of device link suppliers at probe" cpufreq: imx6q: check speed grades for i.MX6ULL cpufreq: governors: Fix long idle detection logic in load calculation cpufreq: intel_pstate: enable boost for Skylake Xeon PM / wakeup: Export wakeup_count instead of event_count via sysfs PM / Domains: Add dev_pm_domain_attach_by_id() to manage multi PM domains PM / Domains: Add support for multi PM domains per device to genpd PM / Domains: Split genpd_dev_pm_attach() PM / Domains: Don't attach devices in genpd with multi PM domains PM / Domains: dt: Allow power-domain property to be a list of specifiers cpufreq: intel_pstate: New sysfs entry to control HWP boost cpufreq: intel_pstate: HWP boost performance on IO wakeup cpufreq: intel_pstate: Add HWP boost utility and sched util hooks cpufreq: ti-cpufreq: Use devres managed API in probe() cpufreq: ti-cpufreq: Fix an incorrect error return value cpufreq: ACPI: make function acpi_cpufreq_fast_switch() static cpufreq: kryo: allow building as a loadable module cpupower : Fix header name to read idle state name cpupower: fix spelling mistake: "logilename" -> "logfilename"

Revert "PM / runtime: Fixup reference counting of device link suppliers at probe"

2018-06-12T08:24:13Z

Revert commit 1e8378619841 (PM / runtime: Fixup reference counting of device link suppliers at probe), as it has introduced a regression and the condition it was designed to address should be covered by the existing code. Reported-by: Marek Szyprowski Signed-off-by: Rafael J. Wysocki

Merge tag 'driver-core-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2018-06-05T23:29:19Z

Pull driver core updates from Greg KH: "Here is the driver core patchset for 4.18-rc1. The large chunk of these are firmware core documentation and api updates. Nothing major there, just better descriptions for others to be able to understand the firmware code better. There's also a user for a new firmware api call. Other than that, there are some minor updates for debugfs, kernfs, and the driver core itself. All of these have been in linux-next for a while with no reported issues" * tag 'driver-core-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (23 commits) driver core: hold dev's parent lock when needed driver-core: return EINVAL error instead of BUG_ON() driver core: add __printf verification to device_create_groups_vargs mm: memory_hotplug: use put_device() if device_register fail base: core: fix typo 'can by' to 'can be' debugfs: inode: debugfs_create_dir uses mode permission from parent debugfs: Re-use kstrtobool_from_user() Documentation: clarify firmware_class provenance and why we can't rename the module Documentation: remove stale firmware API reference Documentation: fix few typos and clarifications for the firmware loader ath10k: re-enable the firmware fallback mechanism for testmode ath10k: use firmware_request_nowarn() to load firmware firmware: add firmware_request_nowarn() - load firmware without warnings firmware_loader: make firmware_fallback_sysfs() print more useful firmware_loader: move kconfig FW_LOADER entries to its own file firmware_loader: replace ---help--- with help firmware_loader: enhance Kconfig documentation over FW_LOADER firmware_loader: document firmware_sysfs_fallback() firmware: rename fw_sysfs_fallback to firmware_fallback_sysfs() firmware: use () to terminate kernel-doc function names ...

driver core: hold dev's parent lock when needed

2018-05-31T08:12:07Z

SoC have internal I/O buses that can't be proved for devices. The devices on the buses can be accessed directly without additinal configuration required. This type of bus is represented as "simple-bus". In some platforms, we name "soc" with "simple-bus" attribute and many devices are hooked under it described in DT (device tree). In commit bf74ad5bc417 ("Hold the device's parent's lock during probe and remove") to solve USB subsystem lock sequence since USB device's characteristic. Thus "soc" needs to be locked whenever a device and driver's probing happen under "soc" bus. During this period, an async driver tries to probe a device which is under the "soc" bus would be blocked until previous driver finish the probing and release "soc" lock. And the next probing under the "soc" bus need to wait for async finish. Because of that, driver's async probe for init time improvement will be shadowed. Since many devices don't have USB devices' characteristic, they actually don't need parent's lock. Thus, we introduce a lock flag in bus_type struct and driver core would lock the parent lock base on the flag. For USB, we set this flag in usb_bus_type to keep original lock behavior in driver core. Async probe could have more benefit after this patch. Signed-off-by: Martin Liu Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

PM / runtime: Fixup reference counting of device link suppliers at probe

2018-05-27T10:10:32Z

In the driver core, before it invokes really_probe() it runtime resumes the suppliers for the device via calling pm_runtime_get_suppliers(), which also increases the runtime PM usage count for each of the available supplier. This makes sense, as to be able to allow the consumer device to be probed by its driver. However, if the driver decides to add a new supplier link during ->probe(), hence updating the list of suppliers, the following call to pm_runtime_put_suppliers(), invoked after really_probe() in the driver core, we get into trouble. More precisely, pm_runtime_put() gets called also for the new supplier(s), which is wrong as the driver core, didn't trigger pm_runtime_get_sync() to be called for it in the first place. In other words, the new supplier may be runtime suspended even in cases when it shouldn't. Fix this behaviour, by runtime resume suppliers according to the same conditions as managed by the runtime PM core, when runtime resume callbacks are being invoked. Additionally, don't try to runtime suspend any of the suppliers after really_probe(), but instead rely on that to happen via the consumer device, when it becomes runtime suspended. Fixes: 21d5c57b3726 (PM / runtime: Use device links) Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki