On 10/01/2023 23:18, Florian Fainelli wrote: > On 1/10/23 00:40, Krzysztof Kozlowski wrote: >>>> No, it is discouraged in such forms. Family or IP block compatibles >>>> should be prepended with a specific compatible. There were many issues >>>> when people insisted on generic or family compatibles... >>>> >>>>> Otherwise we will have to have a compatible string with chip model for >>>>> each SoC even they share the same IP. We already have more than ten of >>>>> SoCs and the list will increase. I don't see this is a good solution too. >>>> >>>> You will have to do it anyway even with generic fallback, so I don't get >>>> what is here to gain... I also don't get why Broadcom should be here >>>> special, different than others. Why it is not a good solution for >>>> Broadcom SoCs but it is for others? >>>> >>> I saw a few other vendors like these qcom ones: >>> qcom,spi-qup.yaml >>> - qcom,spi-qup-v1.1.1 # for 8660, 8960 and 8064 >>> - qcom,spi-qup-v2.1.1 # for 8974 and later >>> - qcom,spi-qup-v2.2.1 # for 8974 v2 and later >>> qcom,spi-qup.yaml >>> const: qcom,geni-spi >> >> IP block version numbers are allowed when there is clear mapping between >> version and SoCs using it. This is the case for Qualcomm because there >> is such clear mapping documented and available for Qualcomm engineers >> and also some of us (although not public). >> >>> I guess when individual who only has one particular board/chip and is >>> not aware of the IP family, it is understandable to use the chip >>> specific compatible string. >> >> Family of devices is not a versioned IP block. > > Would it be acceptable to define for instance: > > - compatible = "brcm,bcm6868-hsspi", "brcm,bcmbca-hsspi"; Yes, this is perfectly valid. Although it does not solve William concerns because it requires defining specific compatibles for all of the SoCs. Best regards, Krzysztof
