linux-kernel - Re: [RFC PATCH 0/3] 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: <Z9wO8SIy1CcfO0bZ@shikoro>
Date: Thu, 20 Mar 2025 13:49:53 +0100
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: Herve Codina <herve.codina@...tlin.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, linux-i2c@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	Luca Ceresoli <luca.ceresoli@...tlin.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [RFC PATCH 0/3] i2c: Introduce i2c bus extensions

Hi Herve,

> The related big picture has been already presented in
>   - the 'Add support for GE SUNH hot-pluggable connector' series [0]
>   - the 'Runtime hotplug on non-discoverable busses with device tree
>     overlays' talk at Linux Plumbers Conference 2024 [1].

Any outcome of the Plumbers meetup? Was this "double-link" solution
agreed on or so? I mean the code is the easy part here, but I would like
to have an agreed approach for handling all kinds of non-probable
busses. I really don't want an island solution for I2C. So, the key
question here is what do DT maintainers think?

You sent code without bindings, but I'd think the other way around would
be better for the discussion.

Makes sense?

Happy hacking,

   Wolfram

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