Messages in this thread | | | Date | Tue, 21 Nov 2023 09:37:21 +0100 | Subject | Re: [PATCH v2] docs: dt-bindings: add DTS Coding Style document | From | Krzysztof Kozlowski <> |
| |
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
| |