On 01/11/2023 01:02 AM, Krzysztof Kozlowski wrote:
As I mentioned in another email, I would be okay to use these compatibles to differentiate by ip rev and to conforms to brcm convention: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-spiIP 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
"brcm,bcmXYZ-hsspi", "brcm,bcmbca-hsspi-v1.0", "brcm,bcmbca-hsspi"; "brcm,bcmXYZ-hsspi", "brcm,bcmbca-hsspi-v1.1", "brcm,bcmbca-hsspi";In the two drivers I included in this series, it will be bound to brcm,bcmbca-hsspi-v1.0 (in additional to brcm,bcm6328-hsspi) and brcm,bcmbca-hsspi-v1.1 respectively. This way we don't need to update the driver with a new soc specific compatible whenever a new chips comes out.
Does this sound good to you?
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature