| Message ID | 20200109154529.19484-3-sakari.ailus@linux.intel.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Support running driver's probe for a device powered off | expand |
On Thu, Jan 9, 2020 at 4:44 PM Sakari Ailus <sakari.ailus@linux.intel.com> wrote: > > Add a convenience function to tell whether a device is suspended for probe > or remove, for busses where the custom is that drivers don't need to > resume devices in probe, or suspend them in their remove handlers. > > Returns false on non-ACPI systems. > > Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > --- > drivers/acpi/device_pm.c | 35 +++++++++++++++++++++++++++++++++++ > include/linux/acpi.h | 5 +++++ > 2 files changed, 40 insertions(+) > > diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c > index 5e4a8860a9c0c..87393020276d8 100644 > --- a/drivers/acpi/device_pm.c > +++ b/drivers/acpi/device_pm.c > @@ -1348,4 +1348,39 @@ int acpi_dev_pm_attach(struct device *dev, bool power_on) > return 1; > } > EXPORT_SYMBOL_GPL(acpi_dev_pm_attach); > + > +/** > + * acpi_dev_low_power_state_probe - Tell if a device is in a low power state "Check the current ACPI power state of a device." > + * during probe Why is this limited to probe? The function actually checks whether or not the ACPI power state of the device is low-power at the call time (except that it is a bit racy with respect to _set_power(), so it may not work as expected if called in parallel with that one). Maybe drop the "probe" part of the name (actually, I would call this function acpi_dev_state_low_power()) and add a paragraph about the potential race with _set_power() to the description? > + * @dev: The device "Physical device the ACPI power state of which to check". > + * > + * Tell whether a given device is in a low power state during the driver's probe > + * or remove operation. > + * > + * Drivers of devices on certain busses such as I²C can generally assume (on > + * ACPI based systems) that the devices they control are powered on without > + * driver having to do anything about it. Using struct > + * device_driver.probe_low_power and "probe-low-power" property, this can be > + * negated and the driver has full control of the device power management. The above information belongs somewhere else in my view. > + * Always returns false on non-ACPI based systems. True is returned on ACPI "On a system without ACPI, return false. On a system with ACPI, return true if the current ACPI power state of the device is not D0, or false otherwise. Note that the power state of a device is not well-defined after it has been passed to acpi_device_set_power() and before that function returns, so it is not valid to ask for the ACPI power state of the device in that time frame." > + * based systems iff the device is in a low power state during probe or remove. > + */ > +bool acpi_dev_low_power_state_probe(struct device *dev) > +{ > + int power_state; > + int ret; > + > + if (!is_acpi_device_node(dev_fwnode(dev))) > + return false; This is (at least) inefficient, because the same check is repeated by ACPI_COMPANION(). If you really want to print the message, it is better to do something like struct acpi_device *adev = ACPI_COMPANION(dev); if (!adev) return false; ret = acpi_device_get_power(adev, &power_state); > + > + ret = acpi_device_get_power(ACPI_COMPANION(dev), &power_state); > + if (ret) { > + dev_warn(dev, "Cannot obtain power state (%d)\n", ret); And the log level of this message is way too high IMO. This means a firmware bug AFAICS and so after seeing it once on a given system it becomes noise. I'd use pr_debug() to print it. > + return false; > + } > + > + return power_state != ACPI_STATE_D0; > +} > +EXPORT_SYMBOL_GPL(acpi_dev_low_power_state_probe); > + > #endif /* CONFIG_PM */
Hi Rafael, Thank you for the review. On Mon, Jan 13, 2020 at 11:41:12AM +0100, Rafael J. Wysocki wrote: > On Thu, Jan 9, 2020 at 4:44 PM Sakari Ailus > <sakari.ailus@linux.intel.com> wrote: > > > > Add a convenience function to tell whether a device is suspended for probe > > or remove, for busses where the custom is that drivers don't need to > > resume devices in probe, or suspend them in their remove handlers. > > > > Returns false on non-ACPI systems. > > > > Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > > --- > > drivers/acpi/device_pm.c | 35 +++++++++++++++++++++++++++++++++++ > > include/linux/acpi.h | 5 +++++ > > 2 files changed, 40 insertions(+) > > > > diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c > > index 5e4a8860a9c0c..87393020276d8 100644 > > --- a/drivers/acpi/device_pm.c > > +++ b/drivers/acpi/device_pm.c > > @@ -1348,4 +1348,39 @@ int acpi_dev_pm_attach(struct device *dev, bool power_on) > > return 1; > > } > > EXPORT_SYMBOL_GPL(acpi_dev_pm_attach); > > + > > +/** > > + * acpi_dev_low_power_state_probe - Tell if a device is in a low power state > > "Check the current ACPI power state of a device." Sounds good. > > > + * during probe > > Why is this limited to probe? Well.. that was the purpose. It could be used at other times, too, I guess, but most of the time runtime PM is the right interface for doing that. > > The function actually checks whether or not the ACPI power state of > the device is low-power at the call time (except that it is a bit racy > with respect to _set_power(), so it may not work as expected if called > in parallel with that one). > > Maybe drop the "probe" part of the name (actually, I would call this > function acpi_dev_state_low_power()) and add a paragraph about the > potential race with _set_power() to the description? Agreed, I'll use the text you provided below. > > > + * @dev: The device > > "Physical device the ACPI power state of which to check". Ok. > > > + * > > + * Tell whether a given device is in a low power state during the driver's probe > > + * or remove operation. > > + * > > + * Drivers of devices on certain busses such as I²C can generally assume (on > > + * ACPI based systems) that the devices they control are powered on without > > + * driver having to do anything about it. Using struct > > + * device_driver.probe_low_power and "probe-low-power" property, this can be > > + * negated and the driver has full control of the device power management. > > The above information belongs somewhere else in my view. How about putting it to the DSD ReST property documentation, perhaps with a little bit more context? I can add another patch for that. > > > + * Always returns false on non-ACPI based systems. True is returned on ACPI > > "On a system without ACPI, return false. On a system with ACPI, > return true if the current ACPI power state of the device is not D0, > or false otherwise. > > Note that the power state of a device is not well-defined after it has > been passed to acpi_device_set_power() and before that function > returns, so it is not valid to ask for the ACPI power state of the > device in that time frame." Works for me. > > > + * based systems iff the device is in a low power state during probe or remove. > > + */ > > +bool acpi_dev_low_power_state_probe(struct device *dev) > > +{ > > + int power_state; > > + int ret; > > + > > + if (!is_acpi_device_node(dev_fwnode(dev))) > > + return false; > > This is (at least) inefficient, because the same check is repeated by > ACPI_COMPANION(). > > If you really want to print the message, it is better to do something like > > struct acpi_device *adev = ACPI_COMPANION(dev); > > if (!adev) > return false; > > ret = acpi_device_get_power(adev, &power_state); Yes, makes sense. > > > + > > + ret = acpi_device_get_power(ACPI_COMPANION(dev), &power_state); > > + if (ret) { > > + dev_warn(dev, "Cannot obtain power state (%d)\n", ret); > > And the log level of this message is way too high IMO. > > This means a firmware bug AFAICS and so after seeing it once on a > given system it becomes noise. I'd use pr_debug() to print it. I'll switch to dev_dbg() then --- as we have the device. > > > + return false; > > + } > > + > > + return power_state != ACPI_STATE_D0; > > +} > > +EXPORT_SYMBOL_GPL(acpi_dev_low_power_state_probe); > > + > > #endif /* CONFIG_PM */
On Tue, Jan 21, 2020 at 10:09 AM Sakari Ailus <sakari.ailus@linux.intel.com> wrote: > > Hi Rafael, > > Thank you for the review. > > On Mon, Jan 13, 2020 at 11:41:12AM +0100, Rafael J. Wysocki wrote: > > On Thu, Jan 9, 2020 at 4:44 PM Sakari Ailus > > <sakari.ailus@linux.intel.com> wrote: > > > > > > Add a convenience function to tell whether a device is suspended for probe > > > or remove, for busses where the custom is that drivers don't need to > > > resume devices in probe, or suspend them in their remove handlers. > > > > > > Returns false on non-ACPI systems. > > > > > > Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> > > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > > > --- > > > drivers/acpi/device_pm.c | 35 +++++++++++++++++++++++++++++++++++ > > > include/linux/acpi.h | 5 +++++ > > > 2 files changed, 40 insertions(+) > > > > > > diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c > > > index 5e4a8860a9c0c..87393020276d8 100644 > > > --- a/drivers/acpi/device_pm.c > > > +++ b/drivers/acpi/device_pm.c > > > @@ -1348,4 +1348,39 @@ int acpi_dev_pm_attach(struct device *dev, bool power_on) > > > return 1; > > > } > > > EXPORT_SYMBOL_GPL(acpi_dev_pm_attach); > > > + > > > +/** > > > + * acpi_dev_low_power_state_probe - Tell if a device is in a low power state > > > > "Check the current ACPI power state of a device." > > Sounds good. > > > > > > + * during probe > > > > Why is this limited to probe? > > Well.. that was the purpose. It could be used at other times, too, I guess, > but most of the time runtime PM is the right interface for doing that. PM-runtime is a layer above this one. It is mostly about the coordination between devices, reference counting etc which this is about device power states. > > > > The function actually checks whether or not the ACPI power state of > > the device is low-power at the call time (except that it is a bit racy > > with respect to _set_power(), so it may not work as expected if called > > in parallel with that one). > > > > Maybe drop the "probe" part of the name (actually, I would call this > > function acpi_dev_state_low_power()) and add a paragraph about the > > potential race with _set_power() to the description? > > Agreed, I'll use the text you provided below. > > > > > > + * @dev: The device > > > > "Physical device the ACPI power state of which to check". > > Ok. > > > > > > + * > > > + * Tell whether a given device is in a low power state during the driver's probe > > > + * or remove operation. > > > + * > > > + * Drivers of devices on certain busses such as I涎 can generally assume (on > > > + * ACPI based systems) that the devices they control are powered on without > > > + * driver having to do anything about it. Using struct > > > + * device_driver.probe_low_power and "probe-low-power" property, this can be > > > + * negated and the driver has full control of the device power management. > > > > The above information belongs somewhere else in my view. > > How about putting it to the DSD ReST property documentation, perhaps with a > little bit more context? I can add another patch for that. Yes, something like that.
diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c index 5e4a8860a9c0c..87393020276d8 100644 --- a/drivers/acpi/device_pm.c +++ b/drivers/acpi/device_pm.c @@ -1348,4 +1348,39 @@ int acpi_dev_pm_attach(struct device *dev, bool power_on) return 1; } EXPORT_SYMBOL_GPL(acpi_dev_pm_attach); + +/** + * acpi_dev_low_power_state_probe - Tell if a device is in a low power state + * during probe + * @dev: The device + * + * Tell whether a given device is in a low power state during the driver's probe + * or remove operation. + * + * Drivers of devices on certain busses such as I²C can generally assume (on + * ACPI based systems) that the devices they control are powered on without + * driver having to do anything about it. Using struct + * device_driver.probe_low_power and "probe-low-power" property, this can be + * negated and the driver has full control of the device power management. + * Always returns false on non-ACPI based systems. True is returned on ACPI + * based systems iff the device is in a low power state during probe or remove. + */ +bool acpi_dev_low_power_state_probe(struct device *dev) +{ + int power_state; + int ret; + + if (!is_acpi_device_node(dev_fwnode(dev))) + return false; + + ret = acpi_device_get_power(ACPI_COMPANION(dev), &power_state); + if (ret) { + dev_warn(dev, "Cannot obtain power state (%d)\n", ret); + return false; + } + + return power_state != ACPI_STATE_D0; +} +EXPORT_SYMBOL_GPL(acpi_dev_low_power_state_probe); + #endif /* CONFIG_PM */ diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 0f37a7d5fa774..fd00853074e1a 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -926,6 +926,7 @@ int acpi_dev_resume(struct device *dev); int acpi_subsys_runtime_suspend(struct device *dev); int acpi_subsys_runtime_resume(struct device *dev); int acpi_dev_pm_attach(struct device *dev, bool power_on); +bool acpi_dev_low_power_state_probe(struct device *dev); #else static inline int acpi_dev_runtime_suspend(struct device *dev) { return 0; } static inline int acpi_dev_runtime_resume(struct device *dev) { return 0; } @@ -935,6 +936,10 @@ static inline int acpi_dev_pm_attach(struct device *dev, bool power_on) { return 0; } +static inline bool acpi_dev_low_power_state_probe(struct device *dev) +{ + return false; +} #endif #if defined(CONFIG_ACPI) && defined(CONFIG_PM_SLEEP)
Add a convenience function to tell whether a device is suspended for probe or remove, for busses where the custom is that drivers don't need to resume devices in probe, or suspend them in their remove handlers. Returns false on non-ACPI systems. Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> --- drivers/acpi/device_pm.c | 35 +++++++++++++++++++++++++++++++++++ include/linux/acpi.h | 5 +++++ 2 files changed, 40 insertions(+)