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!