On Mon, Aug 31, 2020 at 11:31:09AM +0200, Wolfram Sang wrote: > > > This patchset is really about changing the default of ACPI powering up I²C > > devices. On OF the drivers are indeed responsible for that. > > So, maybe it makes sense then to move from 'device_property_present()' > to 'acpi_dev_get_property()' or something alike? To clearly tell this
I'll do that for v7 soon. > binding is expected to be used with ACPI only. Then, we can skip this > discussion now and postpone it to when someone wants to use it with DT. > Which is hopefully never. Or does this approach have drawbacks? The same issue in principle could be there on DT, too, as the cameras are the same. There are a few sensor drivers supporting DT that currently don't access the device in probe to avoid having to power it on. For cameras I suppose that's just fine but I'd be hesitant changing the behaviour of e.g. the at24 driver to support that use case without making it somehow configurable. > > > 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/[email protected]/> > > Ok, we can still factor it out in the unlikely case it needs to be done > again. > > I still have the question via which tree this should go upstream? > It is probably more I2C than ACPI? I think so. Rafael, would you be fine with this set being merged through the I²C tree? There's a single patch adding an ACPI function there. -- Sakari Ailus
