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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Laurent,

On Wed, May 31, 2023 at 3:37 PM Laurent Pinchart
<laurent.pinchart@xxxxxxxxxxxxxxxx> wrote:
> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
> > >
> > > 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 :-)

That was v2... (do I need to repeat I don't like mfds? ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux