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.
Regards,
Hans
