On devicetree platforms, ath{10k/11k} drivers rely on the presence of the
'qcom,calibration-variant' property to select the correct calibration data
for device variants with colliding IDs.
But this property based selection has its own downside that it needs to be
added to the devicetree node of the WLAN device, especially for PCI based
devices. Currently, the users/vendors are forced to hardcode this property
in the PCI device node. If a different device need to be attached to the
slot, then the devicetree node also has to be changed. This approach is not
scalable and creates a bad user experience.
So deprecate this property from WLAN devicetree nodes and let the drivers
do the devicetree model based calibration variant lookup using a static
table.
This also warrants removing the property from examples in the binding.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml | 1 +
Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml | 3 +--
Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml | 1 +
Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml | 6 +-----
.../devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml | 2 +-
5 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
index f2440d39b7ebcda77db592de85573bec902fb334..efe11bdec30dcdb6d48185b68093ea8c247b8c3d 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
@@ -107,6 +107,7 @@ properties:
qcom,calibration-variant:
$ref: /schemas/types.yaml#/definitions/string
+ deprecated: true
description:
Unique variant identifier of the calibration data in board-2.bin
for designs with colliding bus and device specific ids
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml
index e34d42a30192b80311a4c6bb41bd3c8ffc66375f..df7d7aae3343168ffa92bcce16a0b429a6d7bfef 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml
@@ -24,6 +24,7 @@ properties:
qcom,calibration-variant:
$ref: /schemas/types.yaml#/definitions/string
+ deprecated: true
description: |
string to uniquely identify variant of the calibration data for designs
with colliding bus and device ids
@@ -139,8 +140,6 @@ examples:
vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
vddrfa1p8-supply = <&vreg_pmu_rfa_1p7>;
-
- qcom,calibration-variant = "LE_X13S";
};
};
};
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
index c089677702cf17f3016b054d21494d2a7706ce5d..45ae5d3ca73b75b0755466f4dd92df1625dcb4c1 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
@@ -43,6 +43,7 @@ properties:
qcom,calibration-variant:
$ref: /schemas/types.yaml#/definitions/string
+ deprecated: true
description:
string to uniquely identify variant of the calibration data in the
board-2.bin for designs with colliding bus and device specific ids
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml
index 589960144fe1d56eb6f15f63a2d594210e045d27..cd6604eab5f3608811805d204a4c59ce1dcc060a 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml
@@ -54,6 +54,7 @@ properties:
qcom,calibration-variant:
$ref: /schemas/types.yaml#/definitions/string
+ deprecated: true
description:
String to uniquely identify variant of the calibration data for designs
with colliding bus and device ids
@@ -110,8 +111,6 @@ examples:
compatible = "pci17cb,1109";
reg = <0x0 0x0 0x0 0x0 0x0>;
- qcom,calibration-variant = "RDP433_1";
-
ports {
#address-cells = <1>;
#size-cells = <0>;
@@ -146,7 +145,6 @@ examples:
compatible = "pci17cb,1109";
reg = <0x0 0x0 0x0 0x0 0x0>;
- qcom,calibration-variant = "RDP433_2";
qcom,wsi-controller;
ports {
@@ -183,8 +181,6 @@ examples:
compatible = "pci17cb,1109";
reg = <0x0 0x0 0x0 0x0 0x0>;
- qcom,calibration-variant = "RDP433_3";
-
ports {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml
index 363a0ecb6ad97c3dce72881ff552d238d08a2c12..1e6ff8e7a6c20cbe4abe31cacd8b25a78af05f4c 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml
@@ -151,6 +151,7 @@ properties:
qcom,calibration-variant:
$ref: /schemas/types.yaml#/definitions/string
+ deprecated: true
description:
String to uniquely identify variant of the calibration data for designs
with colliding bus and device ids
@@ -304,7 +305,6 @@ examples:
memory-region = <&q6_region>, <&m3_dump>, <&q6_caldb>, <&mlo_mem>;
memory-region-names = "q6-region", "m3-dump", "q6-caldb", "mlo-global-mem";
- qcom,calibration-variant = "RDP441_1";
qcom,rproc = <&q6v5_wcss>;
qcom,smem-states = <&wcss_smp2p_out 8>,
<&wcss_smp2p_out 9>,
--
2.48.1On 14/11/2025 11:22, Manivannan Sadhasivam wrote:
> On devicetree platforms, ath{10k/11k} drivers rely on the presence of the
> 'qcom,calibration-variant' property to select the correct calibration data
> for device variants with colliding IDs.
>
> But this property based selection has its own downside that it needs to be
> added to the devicetree node of the WLAN device, especially for PCI based
> devices. Currently, the users/vendors are forced to hardcode this property
> in the PCI device node. If a different device need to be attached to the
> slot, then the devicetree node also has to be changed. This approach is not
> scalable and creates a bad user experience.
>
> So deprecate this property from WLAN devicetree nodes and let the drivers
> do the devicetree model based calibration variant lookup using a static
> table.
>
> This also warrants removing the property from examples in the binding.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
The problem - visible in one of the examples here - is that one board
has multiple WiFi chips and they use different calibration-variant
properties. How do you find the right calibration variant for such case
based on board machine match?
Best regards,
Krzysztof
On Fri, Nov 14, 2025 at 11:47:25AM +0100, Krzysztof Kozlowski wrote:
> On 14/11/2025 11:22, Manivannan Sadhasivam wrote:
> > On devicetree platforms, ath{10k/11k} drivers rely on the presence of the
> > 'qcom,calibration-variant' property to select the correct calibration data
> > for device variants with colliding IDs.
> >
> > But this property based selection has its own downside that it needs to be
> > added to the devicetree node of the WLAN device, especially for PCI based
> > devices. Currently, the users/vendors are forced to hardcode this property
> > in the PCI device node. If a different device need to be attached to the
> > slot, then the devicetree node also has to be changed. This approach is not
> > scalable and creates a bad user experience.
> >
> > So deprecate this property from WLAN devicetree nodes and let the drivers
> > do the devicetree model based calibration variant lookup using a static
> > table.
> >
> > This also warrants removing the property from examples in the binding.
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
>
> The problem - visible in one of the examples here - is that one board
> has multiple WiFi chips and they use different calibration-variant
> properties. How do you find the right calibration variant for such case
> based on board machine match?
>
I suspect the legitimacy of the example here. I don't understand how a single
machine can have same devices with 3 different calibration data.
AFAIU, calibration data is specific to the platform design. And I don't see any
upstream supported devicetree having similar properties.
- Mani
--
மணிவண்ணன் சதாசிவம்
On 14/11/2025 12:02, Manivannan Sadhasivam wrote:
> On Fri, Nov 14, 2025 at 11:47:25AM +0100, Krzysztof Kozlowski wrote:
>> On 14/11/2025 11:22, Manivannan Sadhasivam wrote:
>>> On devicetree platforms, ath{10k/11k} drivers rely on the presence of the
>>> 'qcom,calibration-variant' property to select the correct calibration data
>>> for device variants with colliding IDs.
>>>
>>> But this property based selection has its own downside that it needs to be
>>> added to the devicetree node of the WLAN device, especially for PCI based
>>> devices. Currently, the users/vendors are forced to hardcode this property
>>> in the PCI device node. If a different device need to be attached to the
>>> slot, then the devicetree node also has to be changed. This approach is not
>>> scalable and creates a bad user experience.
>>>
>>> So deprecate this property from WLAN devicetree nodes and let the drivers
>>> do the devicetree model based calibration variant lookup using a static
>>> table.
>>>
>>> This also warrants removing the property from examples in the binding.
>>>
>>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>>> ---
>>
>> The problem - visible in one of the examples here - is that one board
>> has multiple WiFi chips and they use different calibration-variant
>> properties. How do you find the right calibration variant for such case
>> based on board machine match?
>>
>
> I suspect the legitimacy of the example here. I don't understand how a single
> machine can have same devices with 3 different calibration data.
Me neither but I am not the domain expert here.
>
> AFAIU, calibration data is specific to the platform design. And I don't see any
> upstream supported devicetree having similar properties.
Deprecating these is fine with me, but I would prefer if we get here
some clear answers that mentioned case cannot happen. If you are sure of
that, please mention it in commit msg.
Best regards,
Krzysztof
On Fri, Nov 14, 2025 at 12:04:55PM +0100, Krzysztof Kozlowski wrote:
> On 14/11/2025 12:02, Manivannan Sadhasivam wrote:
> > On Fri, Nov 14, 2025 at 11:47:25AM +0100, Krzysztof Kozlowski wrote:
> >> On 14/11/2025 11:22, Manivannan Sadhasivam wrote:
> >>> On devicetree platforms, ath{10k/11k} drivers rely on the presence of the
> >>> 'qcom,calibration-variant' property to select the correct calibration data
> >>> for device variants with colliding IDs.
> >>>
> >>> But this property based selection has its own downside that it needs to be
> >>> added to the devicetree node of the WLAN device, especially for PCI based
> >>> devices. Currently, the users/vendors are forced to hardcode this property
> >>> in the PCI device node. If a different device need to be attached to the
> >>> slot, then the devicetree node also has to be changed. This approach is not
> >>> scalable and creates a bad user experience.
> >>>
> >>> So deprecate this property from WLAN devicetree nodes and let the drivers
> >>> do the devicetree model based calibration variant lookup using a static
> >>> table.
> >>>
> >>> This also warrants removing the property from examples in the binding.
> >>>
> >>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> >>> ---
> >>
> >> The problem - visible in one of the examples here - is that one board
> >> has multiple WiFi chips and they use different calibration-variant
> >> properties. How do you find the right calibration variant for such case
> >> based on board machine match?
> >>
> >
> > I suspect the legitimacy of the example here. I don't understand how a single
> > machine can have same devices with 3 different calibration data.
>
> Me neither but I am not the domain expert here.
>
> >
> > AFAIU, calibration data is specific to the platform design. And I don't see any
> > upstream supported devicetree having similar properties.
> Deprecating these is fine with me, but I would prefer if we get here
> some clear answers that mentioned case cannot happen. If you are sure of
> that, please mention it in commit msg.
>
I'm pretty sure that this example is wrong. But I will wait for Jeff or other
ath developers to confirm.
- Mani
--
மணிவண்ணன் சதாசிவம்
On 11/14/2025 3:18 AM, Manivannan Sadhasivam wrote:
> On Fri, Nov 14, 2025 at 12:04:55PM +0100, Krzysztof Kozlowski wrote:
>> On 14/11/2025 12:02, Manivannan Sadhasivam wrote:
>>> On Fri, Nov 14, 2025 at 11:47:25AM +0100, Krzysztof Kozlowski wrote:
>>>> On 14/11/2025 11:22, Manivannan Sadhasivam wrote:
>>>>> On devicetree platforms, ath{10k/11k} drivers rely on the presence of the
>>>>> 'qcom,calibration-variant' property to select the correct calibration data
>>>>> for device variants with colliding IDs.
>>>>>
>>>>> But this property based selection has its own downside that it needs to be
>>>>> added to the devicetree node of the WLAN device, especially for PCI based
>>>>> devices. Currently, the users/vendors are forced to hardcode this property
>>>>> in the PCI device node. If a different device need to be attached to the
>>>>> slot, then the devicetree node also has to be changed. This approach is not
>>>>> scalable and creates a bad user experience.
>>>>>
>>>>> So deprecate this property from WLAN devicetree nodes and let the drivers
>>>>> do the devicetree model based calibration variant lookup using a static
>>>>> table.
>>>>>
>>>>> This also warrants removing the property from examples in the binding.
>>>>>
>>>>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>>>>> ---
>>>>
>>>> The problem - visible in one of the examples here - is that one board
>>>> has multiple WiFi chips and they use different calibration-variant
>>>> properties. How do you find the right calibration variant for such case
>>>> based on board machine match?
>>>>
>>>
>>> I suspect the legitimacy of the example here. I don't understand how a single
>>> machine can have same devices with 3 different calibration data.
>>
>> Me neither but I am not the domain expert here.
>>
>>>
>>> AFAIU, calibration data is specific to the platform design. And I don't see any
>>> upstream supported devicetree having similar properties.
>> Deprecating these is fine with me, but I would prefer if we get here
>> some clear answers that mentioned case cannot happen. If you are sure of
>> that, please mention it in commit msg.
>>
>
> I'm pretty sure that this example is wrong. But I will wait for Jeff or other
> ath developers to confirm.
As discussed privately this is a valid example. This is a single-band chip. So
a tri-band router platform will have 3 boards, one that is supporting 2 GHz,
one supporting 5 GHz, and one supporting 6 GHz, and each frequency range will
have different calibration data.
So we still need to support slot-specific configuration in cases where the
slot to board mapping really is fixed in the platform.
/jeff
On Fri, Nov 14, 2025 at 09:29:46AM -0800, Jeff Johnson wrote:
> On 11/14/2025 3:18 AM, Manivannan Sadhasivam wrote:
> > On Fri, Nov 14, 2025 at 12:04:55PM +0100, Krzysztof Kozlowski wrote:
> >> On 14/11/2025 12:02, Manivannan Sadhasivam wrote:
> >>> On Fri, Nov 14, 2025 at 11:47:25AM +0100, Krzysztof Kozlowski wrote:
> >>>> On 14/11/2025 11:22, Manivannan Sadhasivam wrote:
> >>>>> On devicetree platforms, ath{10k/11k} drivers rely on the presence of the
> >>>>> 'qcom,calibration-variant' property to select the correct calibration data
> >>>>> for device variants with colliding IDs.
> >>>>>
> >>>>> But this property based selection has its own downside that it needs to be
> >>>>> added to the devicetree node of the WLAN device, especially for PCI based
> >>>>> devices. Currently, the users/vendors are forced to hardcode this property
> >>>>> in the PCI device node. If a different device need to be attached to the
> >>>>> slot, then the devicetree node also has to be changed. This approach is not
> >>>>> scalable and creates a bad user experience.
> >>>>>
> >>>>> So deprecate this property from WLAN devicetree nodes and let the drivers
> >>>>> do the devicetree model based calibration variant lookup using a static
> >>>>> table.
> >>>>>
> >>>>> This also warrants removing the property from examples in the binding.
> >>>>>
> >>>>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> >>>>> ---
> >>>>
> >>>> The problem - visible in one of the examples here - is that one board
> >>>> has multiple WiFi chips and they use different calibration-variant
> >>>> properties. How do you find the right calibration variant for such case
> >>>> based on board machine match?
> >>>>
> >>>
> >>> I suspect the legitimacy of the example here. I don't understand how a single
> >>> machine can have same devices with 3 different calibration data.
> >>
> >> Me neither but I am not the domain expert here.
> >>
> >>>
> >>> AFAIU, calibration data is specific to the platform design. And I don't see any
> >>> upstream supported devicetree having similar properties.
> >> Deprecating these is fine with me, but I would prefer if we get here
> >> some clear answers that mentioned case cannot happen. If you are sure of
> >> that, please mention it in commit msg.
> >>
> >
> > I'm pretty sure that this example is wrong. But I will wait for Jeff or other
> > ath developers to confirm.
>
> As discussed privately this is a valid example. This is a single-band chip. So
> a tri-band router platform will have 3 boards, one that is supporting 2 GHz,
> one supporting 5 GHz, and one supporting 6 GHz, and each frequency range will
> have different calibration data.
>
> So we still need to support slot-specific configuration in cases where the
> slot to board mapping really is fixed in the platform.
>
Thanks for letting me know of the multi-band usecase, which I was not aware of.
Yes, this property has to be used for those special usecases, so we cannot
deprecate it. But going forward, for the single calibration data usecase (like
almost all upstream DTS), this static table should be used.
- Mani
--
மணிவண்ணன் சதாசிவம்
© 2016 - 2026 Red Hat, Inc.