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

[Laurent Pinchart]

Hi Geert,

On Wed, May 31, 2023 at 02:51:48PM +0200, Geert Uytterhoeven wrote:
> On Wed, May 31, 2023 at 10:59 AM Laurent Pinchart wrote:
> > On Mon, May 29, 2023 at 09:00:43AM +0000, Biju Das wrote:
> > > > Subject: Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
> > > > And why do you need this ?
> > >
> > > As per Krzysztof [2],
> > >
> > > The DT schema allows multiple addresses for children. But we lack
> > > implementation of parent child relationship, As parent owns the resources.
> > > Child device needs to parse parent node to get some resource
> > > like clocks.
> > >
> > > [2] https://lore.kernel.org/linux-renesas-soc/TYCPR01MB5933BFFD4EB556F5FB4EA82186729@TYCPR01MB5933.jpnprd01.prod.outlook.com/
> >
> > The I2C ancillary clients are not meant to be handled by separate
> > drivers. You're supposed to have one device node in DT, which causes the
> > I2C core to instantiate a main i2c_client, and bind it to one driver.
> > That driver then uses i2c_new_ancillary_device() to create other
> > i2c_client instances for the secondary I2C addresses. Those i2c_client
> > instances are not bound to a separate driver, so there should be no code
> > that needs to look at the parent for resources.
> 
> 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
> is that the second instance is a derivative of an existing i2c device
> with an existing Linux driver.  Hence the desire to make the existing
> driver match against the second instance, which requires these changes
> to i2c_new_ancillary_device().
> 
> 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?

MFD ? Otherwise, I'll delegate that to Wolfram, I've spent enough time
on this patch series I'm afraid :-)

> Wolfram: time to chime in ;-)

-- 
Regards,

Laurent Pinchart