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

[Ryder Lee]

On Mon, 2026-02-02 at 09:14 +0100, Sven Eckelmann wrote:
> 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%2Cmt7
> 6.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
> 
I think the DTS format for connac3 is also 1 multiplier plus 10 values,
not 1+9. The key should be:

For beamforming tables:

- 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.

Non-beamforming and RU entries for both connac2 and connac3 include
1T1ss.

I will add this explanation to patch v3, and I have already fixed the
copy-paste error above.

Ryder