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

From: Raj Kumar Bhagat
Date: Tue Feb 04 2025 - 00:58:02 EST


On 2/3/2025 3:39 PM, Krzysztof Kozlowski wrote:
> 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.
>

I meant that, 'qcom,ath10k.yaml' has qcom,ath10k-calibration-variant and
'qcom,ath11k.yaml' has qcom,ath11k-calibration-variant. The same name pattern
has been inherited.

> 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?
>

Yes, the WiFi component of the same SoC package can have different FEMs.

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

The calibration board data for different variant are packed into firmware binary 'board-2.bin'.
Thus, board-2.bin can contain multiple board data for various variants. Ath12k driver selects
the correct board data based on the variant. The "qcom,ath12k-calibration-variant" is used
as one of the parameter to select the correct board data from board-2.bin.

> 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?
>

The SoC in the following statement 'you have one board, but might have different SoCs inside'
, I am assuming SoC to be WiFi controller/component.

Consider, if we have two WiFi (qcom,ipq5332-wifi) controller with different FEM in IPQ5332 board.
Then in the DTS we have two wifi node. Each wifi node in DTS will have different value for
'qcom,ath12k-calibration-variant'. With the help of this property driver will be able to
download the correct calibration board data from board-2.bin.