From: Rob Herring <robh@kernel.org>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: "Svyatoslav Ryhel" <clamor95@gmail.com>,
"Andi Shyti" <andi.shyti@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Peter Rosin" <peda@axentia.se>,
"Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
"Jonas Schwöbel" <jonasschwoebel@yahoo.de>,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Luca Ceresoli" <luca@lucaceresoli.net>,
"Herve Codina" <herve.codina@bootlin.com>
Subject: Re: [PATCH v1 0/2 RESEND] i2c: muxes: Add GPIO-detected hotplug I2C
Date: Tue, 21 Oct 2025 08:25:29 -0500 [thread overview]
Message-ID: <20251021132529.GA4133357-robh@kernel.org> (raw)
In-Reply-To: <aPCfiJxyKOXsgNJe@shikoro>
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
next prev parent reply other threads:[~2025-10-21 13:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-13 6:00 [PATCH v1 0/2 RESEND] i2c: muxes: Add GPIO-detected hotplug I2C Svyatoslav Ryhel
2025-10-13 6:00 ` [PATCH v1 1/2 RESEND] dt-bindings: i2c: Document GPIO detected hot-plugged I2C bus Svyatoslav Ryhel
2025-10-13 6:00 ` [PATCH v1 2/2 RESEND] i2c: muxes: Add GPIO-detected hotplug I2C Svyatoslav Ryhel
2025-10-15 22:50 ` [PATCH v1 0/2 " Andi Shyti
2025-10-16 7:00 ` Svyatoslav Ryhel
2025-10-16 7:32 ` Wolfram Sang
2025-10-17 10:29 ` Andi Shyti
2025-10-21 13:25 ` Rob Herring [this message]
2025-10-16 7:11 ` Herve Codina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251021132529.GA4133357-robh@kernel.org \
--to=robh@kernel.org \
--cc=andi.shyti@kernel.org \
--cc=clamor95@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=herve.codina@bootlin.com \
--cc=jonasschwoebel@yahoo.de \
--cc=krzk+dt@kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luca@lucaceresoli.net \
--cc=mirq-linux@rere.qmqm.pl \
--cc=peda@axentia.se \
--cc=wsa+renesas@sang-engineering.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).