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

[Sven Eckelmann]

On Wednesday, 28 January 2026 00:55:57 CET Ryder Lee wrote:
> +               case MT76_SKU_BACKOFF:
> +                       backoff_chain_idx += 1;
> +                       fallthrough;
> +               case MT76_SKU_BACKOFF_BF_OFFSET:
> +                       delta = mt76_tx_power_path_delta(n_chains);
> +                       backoff_n_chains = mt76_backoff_n_chains(dev, backoff_chain_idx);
> +                       backoff_delta = mt76_tx_power_path_delta(backoff_n_chains);
> +                       break;
> +               default:

Please double check whether the "case"s for MT76_SKU_BACKOFF_BF_OFFSET and 
MT76_SKU_BACKOFF should actually be swapped. I think I've originally 
introduced this mistake when trying to demonstrate different ways to write the
switch block.


> +               /* For connac2 devices,
> +                * - paths-ru = RU26, RU52, RU106, BW20, BW40, BW80, BW160
> +                * - paths-ru-bf = RU26, RU52, RU106, BW20, BW40, BW80, BW160
> +                * Only the first three entries use 1T1ss and do not need index
> +                * adjustment; the remaining four require index offset.
> +                */


Hm, I doubt that anyone can understand this (same for the commit message).
You basically just showed a list of two equal "array"s.

Actually important here is that, RU26, RU52, RU106, ... stand here for 10
different values:

1T1ss, 2T1ss, 3T1ss, 4T1ss, 2T2ss, 3T2ss, 4T2ss, 3T3ss, 4T3ss, 4T4ss

For paths-ru-bf, also 10 values are stored in the DT for each of these
(RU26, ..., BW160) - but only the non-1T1ss are relevant for this
calculation for BW20, ..., BW160.

These 1T1ss beamforming values for BW20, ..., BW160 were (if I understand it 
correctly) removed for connac3. 

If you introduce some change in the DT interpretation, then you must also 
inform the DT maintainers (Rob Herring <robh at kernel.org>, 
Saravana Kannan <saravanak at kernel.org>, devicetree at vger.kernel.org) while 
updatingDocumentation/devicetree/bindings/net/wireless/mediatek%2Cmt76.yaml. 
The latter is currently still expecting 1 ("rates multiplier") + 10 values
(limits). And DTs with only 1 + 9 values per rate would therefore fail to be
validated.

At the moment, your connac3 code is basically conflicting with the devicetree
documentation. I will leave it to the experts to figure out if the devicetree
should have two different interpretations for the same property or whether
the property should be the same and the code must handle the differences
before sending these values to the HW.

Regards,
	Sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-mediatek/attachments/20260202/16f7dc4c/attachment-0001.sig>