Hi Sakari, On Mon, Nov 20, 2023 at 9:03 PM Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> wrote: > > Hi Rafael, > > On Mon, Nov 20, 2023 at 01:52:39PM +0100, Rafael J. Wysocki wrote: > > On Mon, Nov 20, 2023 at 10:31 AM Sakari Ailus > > <sakari.ailus@xxxxxxxxxxxxxxx> wrote: > > > > > > Hi Laurent, > > > > > > On Sat, Nov 18, 2023 at 08:50:49PM +0200, Laurent Pinchart wrote: > > > > Hi Sakari, > > > > > > > > Thank you for the patch. > > > > > > > > On Fri, Nov 17, 2023 at 01:14:29PM +0200, Sakari Ailus wrote: > > > > > Document that acpi_dev_state_d0() can be used to tell if the device was > > > > > powered on for probe. > > > > > > > > > > Signed-off-by: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> > > > > > --- > > > > > Documentation/firmware-guide/acpi/non-d0-probe.rst | 8 ++++++++ > > > > > 1 file changed, 8 insertions(+) > > > > > > > > > > diff --git a/Documentation/firmware-guide/acpi/non-d0-probe.rst b/Documentation/firmware-guide/acpi/non-d0-probe.rst > > > > > index 7afd16701a02..815bcc8db69f 100644 > > > > > --- a/Documentation/firmware-guide/acpi/non-d0-probe.rst > > > > > +++ b/Documentation/firmware-guide/acpi/non-d0-probe.rst > > > > > @@ -24,6 +24,14 @@ there's a problem with the device, the driver likely probes just fine but the > > > > > first user will find out the device doesn't work, instead of a failure at probe > > > > > time. This feature should thus be used sparingly. > > > > > > > > > > +ACPI framework > > > > > +-------------- > > > > > + > > > > > +Use the Linux ACPI framework function :c:func:`acpi_dev_state_d0()` to tell > > > > > +whether the device was powered on for probe. :c:func:`acpi_dev_state_d0()` > > > > > +returns true if the device is powered on, false otherwise. For non-ACPI backed > > > > > +devices it returns true always. > > > > > + > > > > > > > > While this is true, I don't want to see drivers having to call > > > > ACPI-specific functions, the same way you dislike OF-specific functions > > > > in drivers. Please find a better way to handle this. > > > > > > The functionality is only available on ACPI and the function does the right > > > thing on non-ACPI platforms. I don't see an issue here. > > > > The issue would be calling an ACPI-specific function from code that's > > otherwise firmware-agnostic, AFAICS. > > > > It would be good to have a more generic way of checking whether or not > > a device is operational. > > In DT case it's up to the driver to do that, so the device is powered off. Unless the boot loader (or whatever happens to run before the kernel) turns it on for some reason (whatever that may be). I guess the original point has been that in the ACPI case the generic enumeration code may power up the device if not instructed otherwise by the platform firmware, whereas in the DT case this is entirely up to the driver, but I'm not sure if this really matters. I would suggest adding a generic wrapper around acpi_dev_state_d0() that will just always return true in the DT case, something like device_is_accessible() or device_is_operational(), that can be invoked from generic code without any visible ACPI connotations.
