On Mon, Nov 9, 2020 at 1:33 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > On 11/5/20 11:38 AM, Andy Shevchenko wrote: > > On Thu, Nov 5, 2020 at 10:00 AM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: ... > >> But before coming to the conclusion that i2c-multi-instantiate > >> would not work I had already written this series. Since this might > >> be useful for some other case in the future I'm sending this out > >> as a RFC now, mostly so that it gets added to the archives. > > > > I think they are in pretty good shape (only the 4th required a bit of > > attention). > > FWIW I agree with the changes which you suggest for the 4th patch. > > > Please, send as non-RFC and also Cc Heikki (just in case if he has > > comments wrt INT3515). > > But do we really want to land these changes, while ATM we do not > really have any need for them ? Esp. the > > "platform/x86: i2c-multi-instantiate: Pass ACPI fwnode to instantiated I2C-clients" > > Change is not without a chance of regressions. The acpi_device_is_first_physical_node() > behavior surprised me a bit while working on the BOSC0200 changes. So I'm not > 100% sure I have managed to see / think of all implications of this change. I think in general the direction to switch to fwnode is a good one. I was thinking about moving i2c core to use swnodes in which case they will utilize fwnode pointer. But it might have complications, you are right. > Heikki do you now (or in the near future) need access to the fwnode for > the TypeC controllers handled by the i2c-multi-instantiate code ? > > Note that if we do decide to move forward with this set, it should probably > be merged in its entirety by Wolfram as it also makes i2c-core changes > (or Wolfram could just merge the i2c-core change and provide an immutable > branch for me to merge into pdx86/for-next. > > And then your (Andy's) cleanup series can be applied on top of this once merged. Fine to me. -- With Best Regards, Andy Shevchenko
