Introduce path backoff limit properties in mt76 binding in order to specify
beamforming and non-beamforming backoff limits for 802.11n/ac/ax.
Signed-off-by: Sven Eckelmann (Plasma Cloud) <se@simonwunderlich.de>
---
.../bindings/net/wireless/mediatek,mt76.yaml | 60 ++++++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
index f8f72f3f1b1dd185b4797be38b87c621ef3eac08..0b06455ce955c38b324efebf8c7762bee33b57f6 100644
--- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
@@ -215,6 +215,66 @@ properties:
minItems: 13
maxItems: 13
+ paths-cck:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ minItems: 4
+ maxItems: 4
+ description:
+ 4 half-dBm backoff values (1 - 4 antennas, single spacial
+ stream)
+
+ paths-ofdm:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ minItems: 4
+ maxItems: 4
+ description:
+ 4 half-dBm backoff values (1 - 4 antennas, single spacial
+ stream)
+
+ paths-ofdm-bf:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ minItems: 4
+ maxItems: 4
+ description:
+ 4 half-dBm backoff values for beamforming
+ (1 - 4 antennas, single spacial stream)
+
+ paths-ru:
+ $ref: /schemas/types.yaml#/definitions/uint8-matrix
+ description:
+ Sets of half-dBm backoff values for 802.11ax rates for
+ 1T1ss (aka 1 transmitting antenna with 1 spacial stream),
+ 2T1ss, 3T1ss, 4T1ss, 2T2ss, 3T2ss, 4T2ss, 3T3ss, 4T3ss
+ and 4T4ss.
+ Each set starts with the number of channel bandwidth or
+ resource unit settings for which the rate set applies,
+ followed by 10 power limit values. The order of the
+ channel resource unit settings is RU26, RU52, RU106,
+ RU242/SU20, RU484/SU40, RU996/SU80 and RU2x996/SU160.
+ minItems: 1
+ maxItems: 7
+ items:
+ minItems: 11
+ maxItems: 11
+
+ paths-ru-bf:
+ $ref: /schemas/types.yaml#/definitions/uint8-matrix
+ description:
+ Sets of half-dBm backoff (beamforming) values for 802.11ax
+ rates for 1T1ss (aka 1 transmitting antenna with 1 spacial
+ stream), 2T1ss, 3T1ss, 4T1ss, 2T2ss, 3T2ss, 4T2ss, 3T3ss,
+ 4T3ss and 4T4ss.
+ Each set starts with the number of channel bandwidth or
+ resource unit settings for which the rate set applies,
+ followed by 10 power limit values. The order of the
+ channel resource unit settings is RU26, RU52, RU106,
+ RU242/SU20, RU484/SU40, RU996/SU80 and RU2x996/SU160.
+ minItems: 1
+ maxItems: 7
+ items:
+ minItems: 11
+ maxItems: 11
+
txs-delta:
$ref: /schemas/types.yaml#/definitions/uint32-array
description:
--
2.47.3
On Fri, 26 Sep 2025 12:04:53 +0200, Sven Eckelmann (Plasma Cloud) wrote: > Introduce path backoff limit properties in mt76 binding in order to specify > beamforming and non-beamforming backoff limits for 802.11n/ac/ax. > > Signed-off-by: Sven Eckelmann (Plasma Cloud) <se@simonwunderlich.de> > --- > .../bindings/net/wireless/mediatek,mt76.yaml | 60 ++++++++++++++++++++++ > 1 file changed, 60 insertions(+) > Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Though I know nothing about this. Is there any reason why this is all specific to mt76 rather than being common? Perhaps these settings are all just part of the opaque "calibration data" in the QCom case? Rob
On Monday, 6 October 2025 22:53:36 CEST Rob Herring (Arm) wrote: > > On Fri, 26 Sep 2025 12:04:53 +0200, Sven Eckelmann (Plasma Cloud) wrote: > > Introduce path backoff limit properties in mt76 binding in order to specify > > beamforming and non-beamforming backoff limits for 802.11n/ac/ax. > > > > Signed-off-by: Sven Eckelmann (Plasma Cloud) <se@simonwunderlich.de> > > --- > > .../bindings/net/wireless/mediatek,mt76.yaml | 60 ++++++++++++++++++++++ > > 1 file changed, 60 insertions(+) > > > > Reviewed-by: Rob Herring (Arm) <robh@kernel.org> > > Though I know nothing about this. Is there any reason why this is > all specific to mt76 rather than being common? Perhaps these settings > are all just part of the opaque "calibration data" in the QCom case? Yes, everyone handles it differently and has different requirement for the actual provided data. Qcom has the calibration data, pre-calibration data, calibration files and pre-calibration files (which also needs variants for different devices or regions). But the actual interpretation of this "opaque" blob is secret and handled directly by their firmware. Don't let me get started with the (sometimes) embedded regdb in their calibration data. Regards, Sven
© 2016 - 2026 Red Hat, Inc.