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

ARM: 8524/1: driver cohandle -EPROBE_DEFER from bus_type.match()

2016-02-16T16:28:51Z

Allow implementations of the match() callback in struct bus_type to return errors and if it's -EPROBE_DEFER then queue the device for deferred probing. This is useful to buses such as AMBA in which devices are registered before their matching information can be retrieved from the HW (typically because a clock driver hasn't probed yet). [changed if-else code structure, adjusted documentation to match the code, extended comments] Signed-off-by: Tomeu Vizoso Signed-off-by: Marek Szyprowski Reviewed-by: Ulf Hansson Acked-by: Greg Kroah-Hartman Signed-off-by: Russell King

driver core: Avoid NULL pointer dereferences in device_is_bound()

2016-01-12T00:51:44Z

If device_is_bound() is called on a device that's not been registered yet, it will attepmt to dereference dev->p which is NULL, so avoid that by checking dev->p in there against NULL. Fixes: 6b9cb42752da "device core: add device_is_bound()" Reported-and-tested-by: Guenter Roeck Tested-by: Tony Lindgren Signed-off-by: Rafael J. Wysocki

PM / sleep: Go direct_complete if driver has no callbacks

2016-01-08T00:12:06Z

If a suitable prepare callback cannot be found for a given device and its driver has no PM callbacks at all, assume that it can go direct to complete when the system goes to sleep. The reason for this is that there's lots of devices in a system that do no PM at all and there's no reason for them to prevent their ancestors to do direct_complete if they can support it. Signed-off-by: Tomeu Vizoso Reviewed-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

device core: add device_is_bound()

2016-01-08T00:12:06Z

Adds a function that tells whether a device is already bound to a driver. This is needed to warn when there is an attempt to change the PM domain of a device that has finished probing already. The reason why we want to enforce that is because in the general case that can cause problems and also that we can simplify code quite a bit if we can always assume that. Signed-off-by: Tomeu Vizoso Reviewed-by: Ulf Hansson Acked-by: Greg Kroah-Hartman Signed-off-by: Rafael J. Wysocki

Merge branch 'acpi-soc' into pm-core

2016-01-08T00:11:49Z

device core: add BUS_NOTIFY_DRIVER_NOT_BOUND notification

2015-12-09T00:25:01Z

The users of BUS_NOTIFY_BIND_DRIVER have no chance to do any cleanup in case of a probe failure. In the result there might be problems, such as some resources that had been allocated will continue to be allocated and therefore lead to a resource leak. Introduce a new notification to inform the subscriber that ->probe() failed. Do the same in case of failed device_bind_driver() call. Signed-off-by: Andy Shevchenko Acked-by: Greg Kroah-Hartman Signed-off-by: Rafael J. Wysocki

Merge branches 'pm-sleep' and 'pm-runtime' into pm-core

2015-12-07T01:17:17Z

PM / runtime: Re-init runtime PM states at probe error and driver unbind

2015-11-30T13:50:05Z

There are two common expectations among several subsystems/drivers that deploys runtime PM support, but which isn't met by the driver core. Expectation 1) At ->probe() the subsystem/driver expects the runtime PM status of the device to be RPM_SUSPENDED, which is the initial status being assigned at device registration. This expectation is especially common among some of those subsystems/ drivers that manages devices with an attached PM domain, as those requires the ->runtime_resume() callback at the PM domain level to be invoked during ->probe(). Moreover these subsystems/drivers entirely relies on runtime PM resources being managed at the PM domain level, thus don't implement their own set of runtime PM callbacks. These are two scenarios that suffers from this unmet expectation. i) A failed ->probe() sequence requests probe deferral: ->probe() ... pm_runtime_enable() pm_runtime_get_sync() ... err: pm_runtime_put() pm_runtime_disable() ... As there are no guarantees that such sequence turns the runtime PM status of the device into RPM_SUSPENDED, the re-trying ->probe() may start with the status in RPM_ACTIVE. In such case the runtime PM core won't invoke the ->runtime_resume() callback because of a pm_runtime_get_sync(), as it considers the device to be already runtime resumed. ii) A driver re-bind sequence: At driver unbind, the subsystem/driver's >remove() callback invokes a sequence of runtime PM APIs, to undo actions during ->probe() and to put the device into low power state. ->remove() ... pm_runtime_put() pm_runtime_disable() ... Similar as in the failing ->probe() case, this sequence don't guarantee the runtime PM status of the device to turn into RPM_SUSPENDED. Trying to re-bind the driver thus causes the same issue as when re-trying ->probe(), in the probe deferral scenario. Expectation 2) Drivers that invokes the pm_runtime_irq_safe() API during ->probe(), triggers the runtime PM core to increase the usage count for the device's parent and permanently make it runtime resumed. The usage count is only dropped at device removal, which also allows it to be runtime suspended again. A re-trying ->probe() repeats the call to pm_runtime_irq_safe() and thus once more triggers the usage count of the device's parent to be increased. This leads to not only an imbalance issue of the usage count of the device's parent, but also to keep it runtime resumed permanently even if ->probe() fails. To address these issues, let's change the policy of the driver core to meet these expectations. More precisely, at ->probe() failures and driver unbind, restore the initial states of runtime PM. Although to still allow subsystem's to control PM for devices that doesn't ->probe() successfully, don't restore the initial states unless runtime PM is disabled. Signed-off-by: Ulf Hansson Reviewed-by: Kevin Hilman Signed-off-by: Rafael J. Wysocki

PM / sleep: prohibit devices probing during suspend/hibernation

2015-11-30T13:47:22Z

It is unsafe [1] if probing of devices will happen during suspend or hibernation and system behavior will be unpredictable in this case. So, let's prohibit device's probing in dpm_prepare() and defer their probing instead. The normal behavior will be restored in dpm_complete(). This patch introduces new DD core APIs: device_block_probing() It will disable probing of devices and defer their probes instead. device_unblock_probing() It will restore normal behavior and trigger re-probing of deferred devices. [1] https://lkml.org/lkml/2015/9/11/554 Signed-off-by: Grygorii Strashko Acked-by: Pavel Machek Signed-off-by: Rafael J. Wysocki

drivers/pinctrl: Add the concept of an "init" state

2015-10-27T10:24:23Z

For pinctrl the "default" state is applied to pins before the driver's probe function is called. This is normally a sensible thing to do, but in some cases can cause problems. That's because the pins will change state before the driver is given a chance to program how those pins should behave. As an example you might have a regulator that is controlled by a PWM (output high = high voltage, output low = low voltage). The firmware might leave this pin as driven high. If we allow the driver core to reconfigure this pin as a PWM pin before the PWM's probe function runs then you might end up running at too low of a voltage while we probe. Let's introudce a new "init" state. If this is defined we'll set pinctrl to this state before probe and then "default" after probe (unless the driver explicitly changed states already). An alternative idea that was thought of was to use the pre-existing "sleep" or "idle" states and add a boolean property that we should start in that mode. This was not done because the "init" state is needed for correctness and those other states are only present (and only transitioned in to and out of) when (optional) power management is enabled. Changes in v3: - Moved declarations to pinctrl/devinfo.h - Fixed author/SoB Changes in v2: - Added comment to pinctrl_init_done() as per Linus W. Signed-off-by: Douglas Anderson Acked-by: Greg Kroah-Hartman Tested-by: Caesar Wang Signed-off-by: Linus Walleij