Hi Rob, On Fri, Jun 8, 2018 at 10:41 PM Rob Herring <robh+dt@xxxxxxxxxx> wrote: > On Fri, Jun 8, 2018 at 2:47 AM, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > On Fri, Jun 8, 2018 at 8:50 AM, Michel Pollet > > <michel.pollet@xxxxxxxxxxxxxx> wrote: > >>> > + I add this to the cpu.txt, as a separate patch: > >>> > # On other systems, the property can be either > >>> > 32 bits or 64 bits, it is the driver's responsibility > >>> > to deal with either sizes. > >>> > >>> That is definitely not what we want to say. Use of 32-bit should be > >>> considered out of spec. Yes, we have a few platforms in that category, but > >>> they already handle that themselves. Would be nice to fix them, but at least > >>> the STi platforms don't seem too active. > >>> > >>> IMO, we should delete whatever text we can here and at most just refer to > >>> the spec. > >> > >> So actually I didn't use 32 bits by plain chance, I read the cpu.txt file which says > >> that 64 bits systems use 64 bits property, concluded that in my case I ought to > >> use 32 bits, then grepped around and found other systems using 32 bits, therefore > >> I went forward and used it.. > >> > >> Nothing said here that it should be 64 bits everywhere -- So the documentation > >> needs fixing somehow. Right now it certainly led me wrong. > > > > Perhaps we should add to Documentation/devicetree/bindings/ the standard > > bindings from ePAPR and successors, too? > > I hope you mean *reference* here, not duplicate the bindings here. We > want to move in the other direction and move the common bindings out > of the kernel and into the spec. I did mean copy... I usually grep in Documentation/devicetree/bindings/, and fall back to the spec only rarely, mostly because the spec usually doesn't cover what I need. I am aware of the ongoing work on updating the spec. I guess it's a chicken-and-egg problem... A list of standardized properties under Documentation/devicetree/bindings/, referring to the spec may be a good interim solution. So at least it would show it with git grep. > The real solution here is validation which I'm working on. I had > already converted cpus.txt. Here's an example of the results of the > validation: > > arch/arm/boot/dts/stih410-b2120.dt.yaml:1962:7: cpu@0: 'enable-method' > is a dependency of 'cpu-release-addr' > arch/arm/boot/dts/stih410-b2120.dt.yaml:1965:26: > cpu@0:cpu-release-addr: [155254948] is too short Thanks, nice! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds