[PATCH 3/5] DONOTMERGE: dt-bindings: mfd: syscon: add TI's opp table compatible

[Bryan Brattlof]

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 at ti.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