linux-kernel - Re: [PATCH v3 1/1] schemas: i2c: Introduce I2C bus extensions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250829125238.4117947f@bootlin.com>
Date: Fri, 29 Aug 2025 12:52:38 +0200
From: Herve Codina <herve.codina@...tlin.com>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>
Cc: Rob Herring <robh@...nel.org>, Luca Ceresoli
 <luca.ceresoli@...tlin.com>, Ayush Singh <ayush@...gleboard.org>, Andi
 Shyti <andi.shyti@...nel.org>, Krzysztof Kozlowski <krzk@...nel.org>, Conor
 Dooley <conor+dt@...nel.org>, linux-i2c@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 devicetree-spec@...r.kernel.org, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v3 1/1] schemas: i2c: Introduce I2C bus extensions

Hi Wolfram,

On Tue, 26 Aug 2025 16:03:45 +0200
Wolfram Sang <wsa+renesas@...g-engineering.com> wrote:

> Hi,
> 
> > > A different option is to only have the "i2c-parent" phandle in the
> > > extension node and nothing else in DT (no bidirectional link, no
> > > compatible string), without any full-tree searches.
> > >
> > > On the implementation side, the connector driver when probing would
> > > register the extension nodes at the I2C core, which would maintain a
> > > list of extension nodes. This is important when the connector probes
> > > first. Then when any adapter probes the core would iterate over the
> > > list to check whether the newly-probed adapter is pointed to by one of
> > > the registered bus extensions, and then start populating the devices on
> > > the matching bus extension(s).
> > >
> > > A lot of care would have to be put in the disconnection path and while
> > > removing any bus extension from the global list, which could race with
> > > the I2C core using the list itself. The drive core wouldn't do it for
> > > us for free.  
> > 
> > I'll defer to Wolfram on I2C core implementation...  
> 
> One input already before we dive into the unconference. I don't want to
> maintain the above solution, i.e. handling lists with sublte race issues
> which could be (and should be IMO) handled by the driver core anyhow.

Wolfram, could it be ok if this list is not global but related to the
adapter the extension belongs to?

If the list is really a nogo, registering extensions cannot be done and
so with:
 1) "i2c-parent" phandle and the compatible string "i2c-bus-extension" in
    the extension node.
 2) No registering extensions capabilities available

the only solution I see is to parse the full DT in order to find extension
nodes when we need to register adapter children (adapter probe() step).

A matching extension node will be a node where:
 1) compatible = "i2c-bus-extension"
 2) "i2c-parent" phandle points to the expected adapter.

Wolfram, is it a solution you can accept?

Best regards,
Hervé