Re: [PATCH 02/16] dt-bindings: spi: Add bcmbca-hsspi controller support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux