Message-ID: <20240520124034.mo5rhbgjsuakxoo7@severity>
Date: Mon, 20 May 2024 07:40:34 -0500
From: Nishanth Menon <nm@...com>
To: Krzysztof Kozlowski <krzk@...nel.org>
CC: Francesco Dolcini <francesco@...cini.it>,
        Parth Pancholi
	<parth105105@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob
 Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor
 Dooley <conor+dt@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Parth
 Pancholi <parth.pancholi@...adex.com>,
        <linux-usb@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <vigneshr@...com>
Subject: Re: [PATCH] dt-bindings: usb: gpio-sbu-mux: Add an entry for
 TMUXHS4212

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

Powered by blists - more mailing lists