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] [day] [month] [year] [list]

Message-ID: <aK2-we94b-x2fgW_@shikoro>
Date: Tue, 26 Aug 2025 16:03:45 +0200
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: Rob Herring <robh@...nel.org>
Cc: Luca Ceresoli <luca.ceresoli@...tlin.com>,
	Herve Codina <herve.codina@...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,

> > 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.

See you soon, may the A/V-setup be with us,

   Wolfram


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)