Hi Wolfram,
Thank you for the review.
On Fri, Aug 28, 2020 at 10:38:32AM +0200, Wolfram Sang wrote:
> Hi Sakari,
>
> On Wed, Aug 26, 2020 at 02:54:27PM +0300, Sakari Ailus wrote:
> > Enable drivers to tell ACPI that there's no need to power on a device for
> > probe. Drivers should still perform this by themselves if there's a need
> > to. In some cases powering on the device during probe is undesirable, and
> > this change enables a driver to choose what fits best for it.
> >
> > Add a field called "flags" into struct i2c_driver for driver flags, and a
> > flag I2C_DRV_FL_ALLOW_LOW_POWER_PROBE to tell a driver supports probe in
> > low power state.
> >
> > Signed-off-by: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx>
> > ---
> > drivers/i2c/i2c-core-base.c | 18 +++++++++++++++---
> > include/linux/i2c.h | 14 ++++++++++++++
> > 2 files changed, 29 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> > index 34a9609f256da..f2683790eb0d2 100644
> > --- a/drivers/i2c/i2c-core-base.c
> > +++ b/drivers/i2c/i2c-core-base.c
> > @@ -436,6 +436,15 @@ static int i2c_smbus_host_notify_to_irq(const struct i2c_client *client)
> > return irq > 0 ? irq : -ENXIO;
> > }
> >
> > +static bool allow_low_power_probe(struct device *dev)
> > +{
> > + struct i2c_driver *driver = to_i2c_driver(dev->driver);
> > +
> > + return driver->flags & I2C_DRV_FL_ALLOW_LOW_POWER_PROBE &&
> > + is_acpi_node(dev_fwnode(dev)) &&
> > + device_property_present(dev, "allow-low-power-probe");
>
> So, I wondered about potential DT usage and I read the discussion about
> that in v5 which concluded that for the DT case, the drivers can make
> use of the binding individually. I can agree to that, but then the name
> of the binding is probably problematic. 'allow-*' sounds like
> configuration but DT is for describing HW. So, I think something in the
> range of 'keep-low-power' or so might be better suited. Grepping shows
> there already is a generic binding "low-power-enable". Not sure, if it
> really fits, because here it is more about 'keeping' rather than
> enabling. Or?
The low-power-enable appears to be telling pinctrl drivers the pin can
be configured for low power operation.
This patchset is really about changing the default of ACPI powering up I²C
devices. On OF the drivers are indeed responsible for that.
Another approach in naming the property could related to the consequence
that device accesses must be omitted during driver probe time, but the
first device access takes place when the user actually needs it, e.g.
"skip-device-probe". Due to that the device does not need to be powered on
for probe, so powering it on can be omitted. I'd still keep the naming in
the kernel as-is in that case.
>
> > +/**
> > + * enum i2c_driver_flags - Flags for an I2C device driver
> > + *
> > + * @I2C_DRV_FL_ALLOW_LOW_POWER_PROBE: Let the ACPI driver manage the device's
> > + * power state during probe and remove
> > + */
> > +enum i2c_driver_flags {
> > + I2C_DRV_FL_ALLOW_LOW_POWER_PROBE = BIT(0),
> > +};
> > +
> > /**
> > * struct i2c_driver - represent an I2C device driver
> > * @class: What kind of i2c device we instantiate (for detect)
> > @@ -231,6 +242,7 @@ enum i2c_alert_protocol {
> > * @detect: Callback for device detection
> > * @address_list: The I2C addresses to probe (for detect)
> > * @clients: List of detected clients we created (for i2c-core use only)
> > + * @flags: A bitmask of flags defined in &enum i2c_driver_flags
> > *
> > * The driver.owner field should be set to the module owner of this driver.
> > * The driver.name field should be set to the name of this driver.
> > @@ -289,6 +301,8 @@ struct i2c_driver {
> > int (*detect)(struct i2c_client *client, struct i2c_board_info *info);
> > const unsigned short *address_list;
> > struct list_head clients;
> > +
> > + unsigned int flags;
>
> Here I wonder if all this is really I2C specific? I could imagine this
> being useful for other busses as well, so maybe 'struct device_driver'
> is a better place?
The default power state appears to depend on the bus type on ACPI. I'd
think it's unlikely this feature would be needed elsewhere, with the
possible exception of I3C, if hardware design does not improve from the
current I²C connected cameras.
My original series had a field in struct device_driver for this purpose but
Greg K-H suggested moving it to I²C instead:
<URL:https://lore.kernel.org/linux-acpi/20190826084343.GA1095@xxxxxxxxx/>
--
Kind regards,
Sakari Ailus
