On Wed, Aug 01, 2018 at 09:56:53AM +0200, Hans de Goede 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. > > This will get rid of the ugly duplicate i2c_client for the first > listed i2c-resouce in the ACPI fwnode and instantiating a > platform device for ACPI fwnode-s is normal, so I think that this > is the cleaner way. > > If you agree then I will rework the patch-set to do this when > I've some time for this. Looks reasonable to me. Thanks, -- heikki
