linux-kernel - Re: [PATCH v1 0/2 RESEND] i2c: muxes: Add GPIO-detected hotplug I2C

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: <aPCfiJxyKOXsgNJe@shikoro>
Date: Thu, 16 Oct 2025 09:32:24 +0200
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: Svyatoslav Ryhel <clamor95@...il.com>
Cc: Andi Shyti <andi.shyti@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Peter Rosin <peda@...ntia.se>,
	Michał Mirosław <mirq-linux@...e.qmqm.pl>,
	Jonas Schwöbel <jonasschwoebel@...oo.de>,
	linux-i2c@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, Luca Ceresoli <luca@...aceresoli.net>,
	Herve Codina <herve.codina@...tlin.com>
Subject: Re: [PATCH v1 0/2 RESEND] i2c: muxes: Add GPIO-detected hotplug I2C

Hi Svyatoslav,

> Herve and Luca did not come up with anything meaningful, they provided
> just a few rough ideas. It will take an inconsiderate amount of time

Well, IIRC they said that your use case can be mapped onto their
approach. Which is meaningful in my book.

> before there will be any consensus between them and schema
> maintainers, and even more time would be requited to settle this into
> schemas and implement into drivers. Why should I suffer from this? Why
> should changes I need be halted due to some incomplete 'ideas'? This
> driver uses existing i2c mux framework and fits into it just fine.

I am sorry to bring you bad news, but you need to suffer because this is
how development goes. If I get presented a generic solution (see Herve's
mail) and a specific solution (your driver), for this case I as a
maintainer will prefer the generic solution. Generic solutions need more
time because there are more things to handle, of course. This is typical
for development, I would say, it is not Linux or Free Software specific.

I appreciate that you tackled your issue and were open to share it with
the community. I see the work being done there. However, there are so
many things going on independently that I can't really prevent double
development from happening despite it having a high priority for me. As
soon as I get aware of people working on similar issues, I connect them.
That's what I did here as well.

So, if you want upstream supported I2C hot-plugging, you need to wait
for Luca's and Herve's work being accepted. Or provide a superior
solution. Or, if you want, join the ride. You already have experience in
this field (and hardware plus use case), you would be a very welcome
contributor, I would say.

All the best,

   Wolfram

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