Hi,
On 01-08-18 10:27, Rafael J. Wysocki wrote:
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?
To the platform device which will be instantiated for the
ACPI fwnode because of us not setting the acpi_device_enumeration_by_parent
flag (*) for fwnode's with a HID for which we know we need the
i2c-multi-instantiate.c driver, which is why we will then have
a list of the HIDs in 2 places.
Anyway, this sounds like a reasonable approach to me, FWIW.
That is good to hear.
Regards,
Hans
*) As mentioned as 1. above
