From: Nishanth Menon <nm@ti.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Francesco Dolcini <francesco@dolcini.it>,
Parth Pancholi <parth105105@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Parth Pancholi <parth.pancholi@toradex.com>,
<linux-usb@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <vigneshr@ti.com>
Subject: Re: [PATCH] dt-bindings: usb: gpio-sbu-mux: Add an entry for TMUXHS4212
Date: Mon, 20 May 2024 07:40:34 -0500 [thread overview]
Message-ID: <20240520124034.mo5rhbgjsuakxoo7@severity> (raw)
In-Reply-To: <20240520121441.svp6oabjyev4vmih@magazine>
On 07:14-20240520, Nishanth Menon wrote:
> On 08:53-20240520, Krzysztof Kozlowski wrote:
> > On 19/05/2024 22:27, Francesco Dolcini wrote:
>
> [...]
> > > If it's not the case we'll send the patch later on, however some
> > > DT files maintainers (e.g. arch/arm64/boot/dts/ti/) have a policy to
> > > just accept DT file in which the binding changes are already merged
> > > therefore I was trying to be a little bit proactive here.
> >
> > TI? Never heard something like this from them... Such requirement would
> > seriously slow down any work, so it's not really reasonable. Expectation
> > is to post both binding change and an user, so DTS, in case of USB in
> > separate patchsets.
>
> There is a reason we have set that "soft rule":
> - Driver subsystem merges have known to be broken from time to time and
> the dt maintainer is left holding compatibles that have not made to
> master.
> - ARM subsystem merges prefers not to see checkpatch warnings -
> typically, this happens with new compatibles in the driver subsystem.
> - Off chance that driver subsystem maintainer picks up the dt changes as
> well (should not happen, but has happened)
>
> We have however flexed the rule when:
> a) driver maintainer is willing to provide us an immutable tag that we
> can merge in and base the dts on top.
> b) We felt that the chances of the driver not making it is very very low
> (typically after 1+ month in next) and the dts change is in the wider
> interest of the community. In such case, we have to explicitly take
> the action of letting the patch submitter, driver subsystem to let us
> know if something bad happens to the PR, also in our PR to SoC
> maintainers, we have to call it out along with rationale why this is
> OK. This is a bunch of work from a lot of folks, so prefer only to
> trigger this path in case of exceptional cases - there have been a
> few far in between.
>
> Again, the default rule (driver in one window, binding in next) has
That went out wrong :( - correction:
s/driver in one window, binding in next/driver and binding in one
window, dts in the next window/
Apologies on the confusion.
> kept us out of trouble for a few years now at the detriment of pace
> of merges, but that took care of a lot of conflicts that we had seen
> during initial days of k3 - there are few chains in the lakml list
> where this was the direction we ended up in after discussion.
>
> But, yes - as you mentioned, send the patches of the "user" of the dt
> binding and driver gives the subsystem and dt maintainers a chance to
> review in the context of usage prior to the driver and binding merge.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
next prev parent reply other threads:[~2024-05-20 12:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-17 11:11 [PATCH] dt-bindings: usb: gpio-sbu-mux: Add an entry for TMUXHS4212 Parth Pancholi
2024-05-19 17:38 ` Krzysztof Kozlowski
2024-05-19 20:27 ` Francesco Dolcini
2024-05-20 6:53 ` Krzysztof Kozlowski
2024-05-20 12:14 ` Nishanth Menon
2024-05-20 12:40 ` Nishanth Menon [this message]
2024-05-21 7:43 ` Krzysztof Kozlowski
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=20240520124034.mo5rhbgjsuakxoo7@severity \
--to=nm@ti.com \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=francesco@dolcini.it \
--cc=gregkh@linuxfoundation.org \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=parth.pancholi@toradex.com \
--cc=parth105105@gmail.com \
--cc=robh@kernel.org \
--cc=vigneshr@ti.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 read-only IMAP folder(s) and NNTP newsgroup(s).