On Tue, Aug 30, 2022 at 2:22 PM Andrew Lunn <andrew@xxxxxxx> wrote: > > On Tue, Aug 30, 2022 at 01:43:34PM -0500, Rob Herring wrote: > > On Thu, Aug 25, 2022 at 03:32:46AM +0200, Andrew Lunn wrote: > > > This is the first batch of patches converting the Marvell MVEBU driver > > > bindings from .txt to .yaml. So far, kirkwood has been used for > > > testing, but these drivers apply to a range of Marvell SoCs. > > > > > > In order to reduce the number of warnings from the DT schema checking > > > tools, a few minor changes have been made to a few DT files. No actual > > > errors have been found, the changes just make the checker quiet. > > > > > > I propose these patches are merged via mvebu to arm-soc. No conflicts > > > are expected with these patches. > > > > Why? I strongly prefer the bindings go via subsystem trees. That is the > > documented way. > > I have 50 patches to convert kirkwood from .txt to .yaml. probably > around 30 subsystems. > > 1) Complete nightmare to keep track of so many different patchsets > going in 30 different directions. That's what everyone else does. Send them out and let the maintainers pick them up. Anything left can go via the DT tree or arm-soc. That is going to happen anyways once you Cc the correct maintainers unless you state in each patch not to apply. > 2) None of these patches change any driver code. This is pure > 'Documentation'. The subsystem probably reviewed the .txt file 10 > years ago when I and other mvebu maintainers submitted > them. Nothing is changing in the kernel code base, except now we > gain some degree of validation for this 'Documentation'. > > 3) Pretty much all of these were merged via arm-soc 10 years ago. Why > do it different now? What is gained by not going via arm-soc? 10 years ago it was hit or miss whether bindings even got reviewed. Shall we go back to that? Probably my biggest complaint is when anything breaks in next, fixes going into arm-soc are slow because there are 2 levels of maintainers. Rob
