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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.