Hi,
On 02-07-18 15:25, Andy Shevchenko wrote:
On Sun, 2018-07-01 at 14:23 +0200, Hans de Goede wrote:
On systems with ACPI instantiated i2c-clients, normally there is 1
fw_node
per i2c-device and that fw-node contains 1 I2cSerialBus resource for
that 1
i2c-device.
But in some rare cases the manufacturer has decided to describe
multiple
i2c-devices in a single ACPI fwnode with multiple I2cSerialBus
resources.
An earlier attempt to fix this in the i2c-core resulted in a lot of
extra
code to support this corner-case.
This commitintroduces a new i2c-multi-instantiate driver which fixes
this
in a different way. This new driver can be built as a module which
will
only loaded on affected systems.
This driver will instantiate a new i2c-client per I2cSerialBus
resource,
using the driver_data from the acpi_device_id it is binding to to tell
it
which chip-type (and optional irq-resource) to use when instantiating.
Note this means that we will be instantiating 2 i2c_client-s for the
first
I2cSerialBus resource, this is not pretty, but since the multi-
instantiate
driver does exactly 0 i2c-transfers this is not a problem.
Hmm... I was thinking about somelike MFD for I2C devices where we have a
real tree, thus, we instantiate parent device (that has nothing to do
with I2C per se) and per each I2cSerialBus resource we would instantiate
its children.
I think it would be slightly cleaner approach (no need to care about
parent device being I2C client).
I dunno if it's possible to implement in a tiny way, though.
Not really, one thing which comes to mind is to modify the ACPI
code to enumerate the ACPI fwnode into a platform device as it
normally does. But this means duplicating the list of ACPI HIDs
which is now in the pseudo driver inside the ACPI core and
add special treatment for them there, which I think is not a good
idea.
This would allow us to get rid of the I2C_CLIENT_IGNORE_BUSY,
note that the instantiated i2c devices will still have their
i2c bus controller as parent, not the new ACPI instantiated
platform device, as that is just how the i2c subsys works.
So the only thing this would fix from a user looking into
sysfs to see how devices are connected pov is that we no
longer have the original (pseudo) i2c client instantiated
by the ACPI core to which the "multi-instantiate pseudo driver"
binds.
So all in all I'm afraid that this patch-set is the least
ugly solution I can come up with.
Regards,
Hans
