On Wed, Aug 1, 2018 at 9:56 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > Hi, > > On 31-07-18 21:30, Wolfram Sang wrote: >> >> >>> As mentioned in an earlier reply in this thread, the only alternative >>> to this patch-set which I see would be to duplicate the list of >>> ACPI HIDs found in the new drivers/i2c/i2c-multi-instantiate.c >>> inside code under drivers/acpi and make the acpi code not >>> skip enumerating devices with these HIDs as platform drivers. >>> >>> Then the i2c-multi-instantiate.c driver could become a >>> platform driver (*) and the I2C_CLIENT_IGNORE_BUSY >>> flag / hack can go away (at the price of duplicating >>> the HIDs in 2 places). >> >> >> What is the downside of duplicating the HID? > > > The downside is that as new HIDs show up they need to be added in > 2 places. The drivers/hid code has something similar where devices > needing custom drivers needed to have their VID:PID added to a > blacklist for the generic driver and in my experience I always > forget about this and the first time I test a new custom hid > driver it fails because of this. > > IOW its not ideal but it is not really a problem either. > >> My gut feeling is that it can't be worse than having two devices mapped >> to the same I2C address and work around that by I2C_CLIENT_IGNORE_BUSY. >> But I may be biased :) >> >> I mean this is broken firmware, and having that fixed in ACPI and >> platform/x86 code instead of I2C core sounds way more proper to me. > > > Andy, Heikki, what is your take on this approach: > > 1) Have a list of ACPI IDs for which to not set the > acpi_device_enumeration_by_parent flag in drivers/acpi/scan.c > so that they get enumerated as a platform device. > > 2) Turn the i2c-multi-instantiate.c driver from the second patch > of this series into a platform driver which will then > instantiate *all* the i2c-clients for the ACPI fwnode as > before. What would that bind to? Anyway, this sounds like a reasonable approach to me, FWIW.
