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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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!




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux