Hi Tomasz, On Mon, Sep 28, 2020 at 06:49:22PM +0200, Tomasz Figa wrote: > On Mon, Sep 28, 2020 at 4:18 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > > > On Sun, Sep 27, 2020 at 9:44 PM Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote: > > > > > > On Sun, Sep 27, 2020 at 9:39 PM Wolfram Sang <wsa@xxxxxxxxxxxxx> wrote: > > > > > > > > > > > > > I think we might be overly complicating things. IMHO the series as is > > > > > with the "i2c_" prefix removed from the flags introduced would be > > > > > reusable as is for any other subsystem that needs it. Of course, for > > > > > now, the handling of the flag would remain implemented only in the I2C > > > > > subsystem. > > > > > > > > Just to be clear: you are suggesting to remove "i2c" from the DSD > > > > binding "i2c-allow-low-power-probe". And you are not talking about > > > > moving I2C_DRV_FL_ALLOW_LOW_POWER_PROBE to struct device_driver? I > > > > recall the latter has been NACKed by gkh so far. > > > > > > > > > > I'd also drop "I2C_" from "I2C_DRV_FL_ALLOW_LOW_POWER_PROBE", but all > > > the implementation would remain where it is in the code. IOW, I'm just > > > suggesting a naming change to avoid proliferating duplicate flags of > > > the same meaning across subsystems. > > > > But that would indicate that the property was recognized by other > > subsystems which wouldn't be the case, so it would be confusing. > > > > That's why it cannot be documented as a general property ATM too. > > I guess that's true. Well, this is kAPI in the end, so if we have more > subsystems, it could be always renamed. So feel free to ignore my > previous comment. I wouldn't expect this flag to be needed outside I²C since the other potential use case (I3C) appears to be entirely free of power management, so it's up to the drivers on ACPI, too. The property itself, though, might be. -- Regards, Sakari Ailus
