[PATCH v2] wifi: mt76: fix backoff fields and max_power calculation

[Ryder Lee]

On Mon, 2026-02-09 at 10:17 +0100, Sven Eckelmann wrote:
> On Monday, 9 February 2026 08:48:50 CET Ryder Lee wrote:
> > - In connac2, beamforming entries for BW20~BW160 and OFDM do not
> > include 1T1ss.
> > - In connac3, beamforming entries for BW20~BW160 and RU include
> > 1T1ss,
> > but OFDM beamforming does not include 1T1ss.
> 
> This doesn't seem to match the documentation [1]:
> 
>                   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-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
> 
> Regards,
> 	Sven
> 	
> [1]
> https://www.kernel.org/doc/Documentation/devicetree/bindings/net/wireless/mediatek%2Cmt76.yaml

Hmm...If we really want to dig it out, this document is indeed not
precise enough.

This is for the 7915 when filling in the Bw20/40/80/160 power values.

In mt7915_mcu_set_txpower_sku()
....
        for (i = 0; i < 8; i++) {
                bool bf = i % 2;
                u8 idx = (i + 6) / 2;
                s8 *buf = bf ? la.path.ru_bf[idx] : la.path.ru[idx];
                /* The non-bf fields of RU26 to RU106 are special cases
*/
                if (bf)
                        skb_put_data(skb, buf + 1, 9);
                else
                        skb_put_data(skb, buf, 10);
        }

The skb order is filled according to the firmware requirements.

Each field corresponds to: 1T1ss, 2T1ss, 3T1ss, 4T1ss, 2T2ss, 3T2ss,
4T2ss, 3T3ss, 4T3ss, and 4T4ss, for a total of 10 values.

For beamform case, mt76 does not need to fill in the value for 1T1ss,
so the length is 9.

For non-beamform case, mt76 needs to fill in the value for 1T1ss, so
the length is 10.

The DTS still needs to provide 1 + 10 because mt76 does not
specifically check for this when parsing DTS.

So a connac2 DTS would be filled like this:

paths-ru-bf =
<1 20 22 38 36 24 30 23 21 28 29>,
<1 20 39 31 25 26 25 28 30 39 39>,
<1 37 34 26 26 25 21 34 23 34 24>,
<1 0 20 23 31 23 30 39 28 29 36>,
<1 0 27 34 33 34 29 38 33 33 22>,
<1 0 30 23 39 28 21 25 29 28 21>,
<1 0 34 20 38 32 35 33 37 26 36>;

When 1T1ss is not used, it should be filled with 0. For connac3, since
1T1ss is taken into account, we don’t need to fill it with 0.

The unused 1T1ss still needs to be written in the DTS. This is to make
parsing easier.

So the number indicated in the current document is correct; it’s just
that the description isn’t precise enough.

Of course, I can revise the description for connac3. I just wanted to
say that there’s no need to change the min and max values, which should
make things much simpler.


Ryder