Hi Rafael, On Mon, Nov 20, 2023 at 09:22:53PM +0100, Rafael J. Wysocki wrote: > 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). There are probably some exceptions but they should be quite rare. If the boot loader already powered on the device, then it'd be no use avoiding accessing it. That doesn't mean the rest of the device shouldn't be accessed though. > > 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. The DT case may need a different API for that: telling whether the device should be powered on for probe (by the driver) rather what acpi_dev_state_d0() does. And on ACPI we've only needed this for I²C but likely I3C will follow. It appears to be lacking ACPI support at the moment. -- Regards, Sakari Ailus
