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: <mgrmrpvqoj5ucknfbtyuu3n54r2cnrqpcvnobzj37c6tfm3qze@m7e5elocpfvu>
Date: Fri, 17 Oct 2025 12:29:18 +0200
From: Andi Shyti <andi.shyti@...nel.org>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>
Cc: Svyatoslav Ryhel <clamor95@...il.com>, 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,

On Thu, Oct 16, 2025 at 09:32:24AM +0200, Wolfram Sang wrote:
> > 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.

I agree with all what is said above. I just want to add that
Herve has provided links to all his work and what I would do is
to rebase all my work on top of theirs; make sure their work
together with yours work in your system and, perhaps, merge the
series.

Please, let me know if this works.

Andi