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.
