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: <20251021132529.GA4133357-robh@kernel.org>
Date: Tue, 21 Oct 2025 08:25:29 -0500
From: Rob Herring <robh@...nel.org>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>
Cc: Svyatoslav Ryhel <clamor95@...il.com>,
	Andi Shyti <andi.shyti@...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

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

Agreed.

What really slows things down is when there is only 1 user of a new 
binding. Too many times have I accepted one only for the 2nd user to 
show up right after accepting it and wanting something different. So 
now I just require more than 1 user and it is on the submitter(s) to do 
that. After all, it is their itch, not mine.

Rob