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@xxxxxx> > >>>> > >>>> $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
