linux/drivers/base/dd.c, branch v3.12.10

PM / runtime: Use pm_runtime_put_sync() in __device_release_driver()

2013-12-04T19:05:37Z

commit baab52ded242c35a2290e1fa82e0cc147d0d8c1a upstream. Commit fa180eb448fa (PM / Runtime: Idle devices asynchronously after probe|release) modified __device_release_driver() to call pm_runtime_put(dev) instead of pm_runtime_put_sync(dev) before detaching the driver from the device. However, that was a mistake, because pm_runtime_put(dev) causes rpm_idle() to be queued up and the driver may be gone already when that function is executed. That breaks the assumptions the drivers have the right to make about the core's behavior on the basis of the existing documentation and actually causes problems to happen, so revert that part of commit fa180eb448fa and restore the previous behavior of __device_release_driver(). Reported-by: Tomi Valkeinen Fixes: fa180eb448fa (PM / Runtime: Idle devices asynchronously after probe|release) Signed-off-by: Rafael J. Wysocki Acked-by: Kevin Hilman Acked-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

PM / Runtime: Idle devices asynchronously after probe|release

2013-04-11T19:42:52Z

Putting devices into idle|suspend in a synchronous manner means we are waiting for each device to become idle|suspended before the probe|release is fully done. This patch switch to use the asynchronous runtime PM API:s instead and thus improves the parallelism since we can move on and handle the next device in queue in an earlier phase. Signed-off-by: Ulf Hansson Acked-by: Kevin Hilman Acked-by: Rafael J. Wysocki Cc: Alan Stern Acked-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

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

2013-02-21T20:05:51Z

Pull driver core patches from Greg Kroah-Hartman: "Here is the big driver core merge for 3.9-rc1 There are two major series here, both of which touch lots of drivers all over the kernel, and will cause you some merge conflicts: - add a new function called devm_ioremap_resource() to properly be able to check return values. - remove CONFIG_EXPERIMENTAL Other than those patches, there's not much here, some minor fixes and updates" Fix up trivial conflicts * tag 'driver-core-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (221 commits) base: memory: fix soft/hard_offline_page permissions drivercore: Fix ordering between deferred_probe and exiting initcalls backlight: fix class_find_device() arguments TTY: mark tty_get_device call with the proper const values driver-core: constify data for class_find_device() firmware: Ignore abort check when no user-helper is used firmware: Reduce ifdef CONFIG_FW_LOADER_USER_HELPER firmware: Make user-mode helper optional firmware: Refactoring for splitting user-mode helper code Driver core: treat unregistered bus_types as having no devices watchdog: Convert to devm_ioremap_resource() thermal: Convert to devm_ioremap_resource() spi: Convert to devm_ioremap_resource() power: Convert to devm_ioremap_resource() mtd: Convert to devm_ioremap_resource() mmc: Convert to devm_ioremap_resource() mfd: Convert to devm_ioremap_resource() media: Convert to devm_ioremap_resource() iommu: Convert to devm_ioremap_resource() drm: Convert to devm_ioremap_resource() ...

drivercore: Fix ordering between deferred_probe and exiting initcalls

2013-02-15T18:50:33Z

One of the side effects of deferred probe is that some drivers which used to be probed before initcalls completed are now happening slightly later. This causes two problems. - If a console driver gets deferred, then it may not be ready when userspace starts. For example, if a uart depends on pinctrl, then the uart will get deferred and /dev/console will not be available - __init sections will be discarded before built-in drivers are probed. Strictly speaking, __init functions should not be called in a drivers __probe path, but there are a lot of drivers (console stuff again) that do anyway. In the past it was perfectly safe to do so because all built-in drivers got probed before the end of initcalls. This patch fixes the problem by forcing the first pass of the deferred list to complete at late_initcall time. This is late enough to catch the drivers that are known to have the above issues. Signed-off-by: Grant Likely Tested-by: Haojian Zhuang Cc: Arnd Bergmann Cc: Russell King Cc: Linus Torvalds Cc: stable # 3.4+ Signed-off-by: Greg Kroah-Hartman

drivers/pinctrl: grab default handles from device core

2013-01-23T15:39:51Z

This makes the device core auto-grab the pinctrl handle and set the "default" (PINCTRL_STATE_DEFAULT) state for every device that is present in the device model right before probe. This will account for the lion's share of embedded silicon devcies. A modification of the semantics for pinctrl_get() is also done: previously if the pinctrl handle for a certain device was already taken, the pinctrl core would return an error. Now, since the core may have already default-grabbed the handle and set its state to "default", if the handle was already taken, this will be disregarded and the located, previously instanitated handle will be returned to the caller. This way all code in drivers explicitly requesting their pinctrl handlers will still be functional, and drivers that want to explicitly retrieve and switch their handles can still do that. But if the desired functionality is just boilerplate of this type in the probe() function: struct pinctrl *p; p = devm_pinctrl_get_select_default(&dev); if (IS_ERR(p)) { if (PTR_ERR(p) == -EPROBE_DEFER) return -EPROBE_DEFER; dev_warn(&dev, "no pinctrl handle\n"); } The discussion began with the addition of such boilerplate to the omap4 keypad driver: http://marc.info/?l=linux-input&m=135091157719300&w=2 A previous approach using notifiers was discussed: http://marc.info/?l=linux-kernel&m=135263661110528&w=2 This failed because it could not handle deferred probes. This patch alone does not solve the entire dilemma faced: whether code should be distributed into the drivers or if it should be centralized to e.g. a PM domain. But it solves the immediate issue of the addition of boilerplate to a lot of drivers that just want to grab the default state. As mentioned, they can later explicitly retrieve the handle and set different states, and this could as well be done by e.g. PM domains as it is only related to a certain struct device * pointer. ChangeLog v4->v5 (Stephen): - Simplified the devicecore grab code. - Deleted a piece of documentation recommending that pins be mapped to a device rather than hogged. ChangeLog v3->v4 (Linus): - Drop overzealous NULL checks. - Move kref initialization to pinctrl_create(). - Seeking Tested-by from Stephen Warren so we do not disturb the Tegra platform. - Seeking ACK on this from Greg (and others who like it) so I can merge it through the pinctrl subsystem. ChangeLog v2->v3 (Linus): - Abstain from using IS_ERR_OR_NULL() in the driver core, Russell recently sent a patch to remove it. Handle the NULL case explicitly even though it's a bogus case. - Make sure we handle probe deferral correctly in the device core file. devm_kfree() the container on error so we don't waste memory for devices without pinctrl handles. - Introduce reference counting into the pinctrl core using so that we don't release pinctrl handles that have been obtained for two or more places. ChangeLog v1->v2 (Linus): - Only store a pointer in the device struct, and only allocate this if it's really used by the device. Cc: Felipe Balbi Cc: Benoit Cousson Cc: Dmitry Torokhov Cc: Thomas Petazzoni Cc: Mitch Bradley Cc: Ulf Hansson Cc: Rafael J. Wysocki Cc: Jean-Christophe PLAGNIOL-VILLARD Cc: Rickard Andersson Cc: Russell King Reviewed-by: Mark Brown Acked-by: Greg Kroah-Hartman Signed-off-by: Linus Walleij [swarren: fixed and simplified error-handling in pinctrl_bind_pins(), to correctly handle deferred probe. Removed admonition from docs not to use pinctrl hogs for devices] Signed-off-by: Stephen Warren Signed-off-by: Linus Walleij

PM / Runtime: Do not increment device usage counts before probing

2012-07-17T02:25:49Z

The pm_runtime_get_noresume() calls before really_probe() and before executing __device_attach() for each driver on the device's bus cause problems to happen if probing fails and if the driver has enabled runtime PM for the device in its .probe() callback. Namely, in that case, if the device has been resumed by the driver after enabling its runtime PM and if it turns out that .probe() should return an error, the driver is supposed to suspend the device and disable its runtime PM before exiting .probe(). However, because the device's runtime PM usage counter was incremented by the core before calling .probe(), the driver's attempt to suspend the device will not succeed and the device will remain in the full-power state after the failing .probe() has returned. To fix this issue, remove the pm_runtime_get_noresume() calls from driver_probe_device() and from device_attach() and replace the corresponding pm_runtime_put_sync() calls with pm_runtime_idle() to preserve the existing behavior (which is to check if the device is idle and to suspend it eventually in that case after probing). Reported-and-tested-by: Kevin Hilman Reviewed-by: Kevin Hilman Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

driver core: Move deferred devices to the end of dpm_list before probing

2012-07-17T01:05:45Z

When deferred probe was originally added the idea was that devices which defer their probes would move themselves to the end of dpm_list in order to try to keep the assumptions that we're making about the list being in roughly the order things should be suspended correct. However this hasn't been what's been happening and doing it requires a lot of duplicated code to do the moves. Instead take a simple, brute force solution and have the deferred probe code push devices to the end of dpm_list before it retries the probe. This does mean we lock the dpm_list a bit more often but it's very simple and the code shouldn't be a fast path. We do the move with the deferred mutex dropped since doing things with fewer locks held simultaneously seems like a good idea. This approach was most recently suggested by Grant Likely. Signed-off-by: Mark Brown Acked-by: Rafael J. Wysocki Cc: Grant Likely , Signed-off-by: Greg Kroah-Hartman

Merge v3.5-rc5 into driver-core-next

2012-07-05T15:25:34Z

This picks up the big printk fixes, and resolves a merge issue with: drivers/extcon/extcon_gpio.c Signed-off-by: Greg Kroah-Hartman

device-core: Ensure drvdata = NULL when no driver is bound

2012-06-13T23:40:41Z

1) drvdata is for a driver to store a pointer to driver specific data 2) If no driver is bound, there is no driver specific data associated with the device 3) Thus logically drvdata should be NULL if no driver is bound. But many drivers don't clear drvdata on device_release, or set drvdata early on in probe and leave it set on probe error. Both of which results in a dangling pointer in drvdata. This patch enforce for drvdata to be NULL after device_release or on probe failure. Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman

driver core: fixup reversed deferred probe order

2012-06-13T20:42:39Z

If driver requests probe deferral, it will be added to deferred_probe_pending_list by driver_deferred_probe_add(), but, it used list_add(). Because of that, deferred probe will be run as reversed order. This patch uses list_add_tail(), and solved this issue. Signed-off-by: Kuninori Morimoto Signed-off-by: Greg Kroah-Hartman