Re: [PATCH v2] docs: dt-bindings: add DTS Coding Style document

[Dragan Simic]

On 2023-11-22 09:01, Krzysztof Kozlowski wrote:
> On 21/11/2023 17:04, Geert Uytterhoeven wrote:
> > Hi Krzysztof,
> >
> > On Tue, Nov 21, 2023 at 1:36 PM Krzysztof Kozlowski
> > <krzysztof.kozlowski@xxxxxxxxxx> wrote:
> > > On 21/11/2023 12:55, Michal Simek wrote:
> > > > > > device-tree specification v0.4. Chapter 2.2.1/Table 2.1 is 
> > > > > > describing much more
> > > > > > valid characters for node names.
> > > > > > It means above description is not accurate or DT spec should be 
> > > > > > updated.
> > > > >
> > > > > Spec allows way to much. dtc doesn't.
> > > > > One thing is the spec, second
> > > > > thing is coding style.
> > > >
> > > >  From my point of view spec is primary source of truth. If spec is 
> > > > saying name
> > > > can use upper case then I can use it. If upper case is not
> > > > recommended/deprecated because of whatever reason spec should be 
> > > > updated to
> > > > reflect it.
> > > > I know that DTC is reporting other issues but isn't it the right way 
> > > > to reflect
> > > > it back to the spec?
> > >
> > > Then why aren't you putting Linux Coding Style into C spec? I do not 
> > > see
> > > any relation between specification of the language and the coding 
> > > style
> > > chosen for given project.
> > >
> > > Zephyr can go with upper-case. Why it should be disallowed by the 
> > > spec?
> >
> > I thought there was only One DT to bind them all?
> > IMHO it would be better to align DT usage of Zephyr and Linux (and
> > anything else).
>
> I actually don't know what Zephyr decides, but used it as example that
> it might want different coding style. Just like C standard allows to
> have all variables (including local ones) upper-case, we do not have
> such coding style. And no one proposes to update C spec to match Linux
> coding style. :)

I also agree about the need to differentiate the coding styles from the 
underlying specifications.  Also, as we know, the C language is the 
unifying factor between various projects, but with wildly differing 
coding styles.  Expecting all those projects to have their C coding 
styles aligned wouldn't be reasonable, if you agree.

BTW, having this document as part of the kernel documentation will be 
great, and it's in fact quite overdue, if you agree.  Huge thanks to 
everyone working on it!