[PATCH v2] docs: dt-bindings: add DTS Coding Style document
Krzysztof Kozlowski
krzysztof.kozlowski at linaro.org
Tue Nov 21 00:37:21 PST 2023
On 21/11/2023 09:08, Geert Uytterhoeven wrote:
>>>>> I guess there are (many) other examples...
>>>>
>>>> OK, I never had such in my hands. Anyway, the SoM which can run
>>>> standalone has a meaning of a board, so how exactly you want to
>>>> rephrase the paragraph?
>>>
>>> What about?
>>>
>>> 2. If applicable: DTSI with common or re-usable parts of the hardware (e.g.
>>> entire System-on-Module). DTS if runs standalone.
>>
>> OK, but then it's duplicating the option 3. It also suggests that SoM
>> should be a DTS, which is not what we want for such case. Such SoMs must
>> have DTSI+DTS.
>
> So you want us to have a one-line <SoM>.dts, which just includes <SoM>.dtsi?
> IMHO that adds more files for no much gain.
Yes, if this is a real SoM, then yes. There is much gain - it clearly
represents the hardware like we in general expect. It allows re-usage by
in- and out-tree users, while documenting this possibility.
We structure DTS according to main components of the hardware, which
serves as self-documenting, re-usable and easy to grasp solution.
> Users of a SoM can easily include <SoM>.dts.
Which is confusing during review and not a welcomed pattern.
> 'git grep "#include .*dts\>"' tells you we have plenty of users of that scheme.
Yeah, you can put C functions inside header (included only once). You
can include C file in other C file. But just because you can do it, it
does not mean you should do it. It's not the way we want to make code
organized.
Best regards,
Krzysztof
More information about the linux-amlogic
mailing list