Messages in this thread | | | Subject | Re: [PATCH 02/16] dt-bindings: spi: Add bcmbca-hsspi controller support | From | William Zhang <> | Date | Tue, 10 Jan 2023 17:08:47 -0800 |
| |
On 01/10/2023 02:18 PM, 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"; > > in which case, having a fallback compatible on the SoC family that sees > this IP being deployed is very useful for client programs of the DT > (u-boot or kernel). As long as the fallback works, we use it, the day it > stops and a quirk needs to be applied because SoC XYZ has a bug, match > the SoC XYZ compatible string. > > FWIW, and feel free to rant at me, we have adopted this convention a > while ago for STB chips whereby we want bindings to be defined with: > > <chip specific compatible>, <version of the IP>, <fallback> > > and the fallback may, or may not be matched, but defining in does not > hurt at all, in fact it dramatically helps with the boot loader looking > for specific nodes because it can search for the fallback. > > If the version specific compatible is not available, it does not get used.
Thanks Florian for jumping in! I was thinking to propose something with version info: brcm,bcmbca-hsspi-v1.0 brcm,bcmbca-hsspi-v1.1
To meet STB chip convention, then it would be: compatible = "brcm,bcm63138-hsspi", "brcm,bcmbca-hsspi-v1.0", "brcm,bcmbca-hsspi"; compatible = "brcm,bcm6756-hsspi", "brcm,bcmbca-hsspi-v1.1", "brcm,bcmbca-hsspi";
Although I am not a fan of having a chip specific compatible while we already have IP version, I am okay to have it to be consistent with Broadcom convention. We will need to remember to update this yaml file whenever we have a new chip. [unhandled content-type:application/pkcs7-signature]
| |