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
