[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240615144304.ty7cpigqddpux55w@bryanbrattlof.com>
Date: Sat, 15 Jun 2024 09:43:04 -0500
From: Bryan Brattlof <bb@...com>
To: Krzysztof Kozlowski <krzk@...nel.org>
CC: Conor Dooley <conor.dooley@...rochip.com>, Lee Jones <lee@...nel.org>,
Conor Dooley <conor@...nel.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Viresh Kumar <viresh.kumar@...aro.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Nishanth Menon <nm@...com>,
Vignesh Raghavendra <vigneshr@...com>,
Tero
Kristo <kristo@...nel.org>, Vibhore Vardhan <vibhore@...com>,
<linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<devicetree@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 3/5] DONOTMERGE: dt-bindings: mfd: syscon: add TI's opp
table compatible
On June 13, 2024 thus sayeth Krzysztof Kozlowski:
> On 13/06/2024 14:20, Conor Dooley wrote:
> > On Thu, Jun 13, 2024 at 01:09:23PM +0100, Lee Jones wrote:
> >> On Wed, 12 Jun 2024, Bryan Brattlof wrote:
> >>
> >>> On June 12, 2024 thus sayeth Conor Dooley:
> >>>> On Wed, Jun 12, 2024 at 11:41:52AM -0500, Bryan Brattlof wrote:
> >>>>> The JTAG_USER_ID_USERCODE efuse address, which is located inside the
> >>>>> WKUP_CTRL_MMR0 range holds information to identify the speed grades of
> >>>>> various components on TI's K3 SoCs. Add a compatible to allow the
> >>>>> cpufreq driver to obtain the data to limit the maximum frequency for the
> >>>>> CPUs under Linux control.
> >>>>>
> >>>>> Signed-off-by: Bryan Brattlof <bb@...com>
> >>>>
> >>>> $subject: DONOTMERGE: dt-bindings: mfd: syscon: add TI's opp table compatible
> >>>>
> >>>> Okay, if this isn't for merging then I won't Ack it.
> >>>
> >>> Ha! Nice. If I don't hear anything from anyone else I'll send a v2 in a
> >>> few hours.
> >>
> >> What's the point of all the DONOTMERGE nonsense?
> >
> > AFAICT, TI live in fear of subsystem maintainers merging the dts patches,
> > so they do this.
>
> And want some strict timeframe of merging bindings (via subsystem) and
> DTS (via SoC tree), which causes all weird submissions like this above
> or sending bindings without users.
>
> So far I can live with it but if more such peculiarities come up, then
> sorry, fix your process/tools instead of putting burden on maintainers
> and community.
>
Yeah my worry was all the DTB additions filter in would require a lot of
coordination between the maintainers of all the different trees.
Having a few DONOTMERGE patches gave the driver maintainer a full look
at the outcome of the series without having to worry about DTB conflicts
when another tree picked something up, however I guess if everyone
participates in -next it shouldn't be that big of a problem.
~Bryan
Powered by blists - more mailing lists