On 11.12.2018 13:36, Andrew Lunn wrote: >>> Hi Rob, gentle ping on this. >>> >>> I would like to be sure how to proceed with this. Do you really want me >>> to move *all* nodes that are disabled in this common dtsi into the per >>> board dts? >>> >>> All the boards use identical PCB. Anything that is disabled here is not >>> present on at least one of the boards. It means it is routed on the >>> board and the SoC has the capability but the parts are not populated. >>> >>> So it is not only about the LED controller. What about the LCD, OLED, >>> backlight, USB..? >> >> Can anybody advice how to split these dts/dtsi files, please? >> I am not sure what should reside in the common dtsi and what should >> be moved into the per board dts in case my current solution is not >> appropriate. > > The kirkwood-synology.dtsi might be of interest? There are a lot of > Synology NAS boxes which share a lot in common. So all the common > parts are in that .dtsi. The .dbs file for each individual model then > enables the parts its needs. That is a great example Andrew, thank you! That is exactly what I am doing. Everything that is supported by the PCB/platform is specified in the common file. Only parts that are populated on all products are enabled there, the other stuff is disabled. The .dts files then enable additional stuff they need. To me it seems reasonable to do it that way and maybe I only misunderstood what Rob actually meant by his comment? I still do not have his reply to that though. > Although you have one PCB, or the different population options > considered different products, each with there own name? Yes, each of the three population options can be considered a different product with different name. That is still the same as the Synology NAS boxes, right? Michal
