Re: [PATCH v5 01/13] dt-bindings: net: wireless: describe the ath12k AHB module

[Krzysztof Kozlowski]

On 03/02/2025 10:05, Raj Kumar Bhagat wrote:
> 
>>> +    items:
>>> +      - const: q6-region
>>> +      - const: m3-dump
>>> +      - const: q6-caldb
>>> +      - const: mlo-global-mem
>>> +
>>> +  qcom,ath12k-calibration-variant:
>>> +    $ref: /schemas/types.yaml#/definitions/string
>> Why this is named after ath12k? Why this is just not
>> "qcom,calibration-variant"? None of the other properties have ath12k in
>> their names, so why this one in the WSI schema was named like that?
>>
> 
> This property is added after the below comment.
> https://lore.kernel.org/all/qzjgpwemwaknwbs3dwils6kaa5c3inabfvkaryvc32kblzfhy3@6yduooj4dk63/
> 
> This `ath12k` in the name of this property is inherited from the 'qcom,ath10k.yaml' and
> 'qcom,ath11k.yaml'. Same was followed for WSI schema as well.

They do not have ath12k prefix in the name, so I don't understand.

People, start re-using properties, not creating one per each binding.

> 
>>> +    description:
>>> +      String to uniquely identify variant of the calibration data for designs
>>> +      with colliding bus and device ids
>> I don't think this property is here possible. How could you have on the
>> same SoC different devices?
> 
> The WiFi controller in the SoC includes an internal or external Front-End Module (FEM).
> These FEMs can vary and require different calibration data. This property uniquely

1. So exactly the same SoC package has different FEMs?

2. How does it exactly work? Different bins? Different revisions?

3. How is it supposed to work in practice - you have one board, but
might have different SoCs inside? Which calibration data would you use
in such case?

> identify the variant of calibration data required by a FEM.
> 


Best regards,
Krzysztof