[PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API

[Wolfram Sang]

Hi all,

sorry for not being able to chime in earlier.

> In Biju's particular use case, the i2c device responds to two addresses,
> which is the standard i2c ancillary use case.  However, what's special

Not quite. ancillary is used when a *driver* needs to take care of two
addresses. We already have devices bundling two features into the same
chip. I recall at least RTC + EEPROM somewhere. And so far, we have been
handling this by creating two nodes in DT and have proper binding docs.
I think this is cleaner. First, you can see in DT already what the
compound device really consists of. In this case, which RTC and RTC
driver is exactly needed. Second, the code added here adds complexity to
the I2C core with another layer of inderection for dummy devices.

> As some resources are shared (knowledge about the clocks), splitting
> this in two distinct devices in DT (which is what Biju's initial patch
> series did) would need phandles to link both nodes together.
> 
> Do you have a better idea how to represent this?

Not sure if I understood this chip correctly, but maybe: The PMIC driver
exposes a clock gate which can be consumed by the RTC driver?

Happy hacking,

   Wolfram

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20230607/56757da6/attachment.sig>