On 28/01/2023 22:43, Luca Weiss wrote: > On Montag, 23. Jänner 2023 19:08:03 CET Krzysztof Kozlowski wrote: >> On 23/01/2023 18:41, Stefan Hansson wrote: >>>>> 2. You base on other SoC but you do not include its compatibles. Why? Is >>>>> it intended? None of the properties applicable to other SoC will match >>>>> here, thus I actually wonder if you run dtbs_check... >>> >>> Sorry, I forgot about running dtbs_check. However, I'm not sure I >>> understand the question. What do you mean by that I don't include its >>> compatibles? >> >> I understood you include the msm8226.dtsi which is a different SoC. If >> you include it, you get all of its content. We do it only for compatible >> devices, but your device does not indicate compatibility with msm8226. > > Hi Krzysztof, > > the way the earlier Qualcomm SoCs work, especially regarding naming scheme is > the following. > > There's for example the msm8x74 family which includes msm8974, msm8674, > msm8274, and the a bit differently named apq8074 where the significant > different are the RF capabilities, I think with those only 8974 had LTE, 8674 > and 8274 only 3G but different band support, and the apq8074 has no mobile > radio. > > The same exists for sure also for 8x16 and 8x26, probably a bunch of other > SoCs as well. > > So from software side (apart from modem firmware of course) it can be treated > in practise as the same SoC so that's why we included the dtsi in this case in > msm8226 but also msm8926 and apq8026. First, there is distinction between SoC having and not having modem. I guess small enough that we just include the DTSI. Second, there is distinction between different families, even if they share a lot. All of the SoCs here share something, because Qualcomm has versionable IP blocks which they re-use. > > But the compatible on board-level is in practise (to my knowledge) not really > used for anything important other than having a nice string in the dts file. I > know some software uses compatible from user space but there for > differentiating between different devices and ignoring the SoC compatibles. It's not only about board, but about all devices in the SoC. > > But while they are software-compatible for the most part, they *are* distinct > SoCs with different capabilities and I just don't see the point in trying to > establish some kinds of relationships between different SoCs that are somewhat > or very similar (msm8226 and msm8974 also share many components but are > obviously different SoCs). You don't have to create such relationships. You don't have to include other DTSI, either. What yo have to is - quoting Linux docs: "DO make 'compatible' properties specific. DON'T use wildcards in compatible strings. DO use fallback compatibles when devices are the same as or a subset of prior implementations. DO add new compatibles in case there are new features or bugs." > > And also e.g. (nearly) all apq* dts files we already have in mainline only > have apq compatible and not the corresponding msm* compatible. And I think > that's totally legitimate. We do not talk here about apq, actually, at all. We talk about one msm8xxx including other msm8xxx... Best regards, Krzysztof
