Re: [PATCH v3 2/2] dt-bindings: net: wireless: mt76: clarify backoff limit format

[Ryder Lee <Ryder.Lee@mediatek.com>]

On Wed, 2026-02-11 at 09:16 +0100, Krzysztof Kozlowski wrote:
> On 11/02/2026 09:13, Ryder Lee wrote:
> > On Wed, 2026-02-11 at 07:31 +0100, Krzysztof Kozlowski wrote:
> > > On Tue, Feb 10, 2026 at 10:08:56AM -0800, Ryder Lee wrote:
> > > > Clarify the format of path backoff limit properties in mt76
> > > > binding.
> > > > Add explicit documentation for connac2 (mt7915, mt7981, mt7986)
> > > > and
> > > > connac3 (mt7990, mt7992, mt7996...) devices, including the
> > > > difference
> > > > in beamforming and non-beamforming entries.
> > > 
> > > I do not see any reformatting happening.
> > > 
> > Maybe I should use "rephrase" here.
> > 
> > > > 
> > > > Also reformat the description to make is more precise.
> > > > 
> > > > Signed-off-by: Allen Ye <allen.ye@mediatek.com>
> > > > Co-developed-by: Allen Ye <allen.ye@mediatek.com>
> > > 
> > > Incorrect SoB chain. Read submitting patches.
> > > 
> > 
> > Will fix.
> > 
> > > > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> > > > ---
> > > >  .../bindings/net/wireless/mediatek,mt76.yaml  | 20
> > > > +++++++++++++++++++
> > > >  1 file changed, 20 insertions(+)
> > > > 
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.
> > > > yaml
> > > > b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.
> > > > yaml
> > > > index ae6b97cdc..4156e1c97 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.
> > > > yaml
> > > > +++
> > > > b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.
> > > > yaml
> > > > @@ -252,6 +252,16 @@ properties:
> > > >                        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.
> > > > +                      - For connac2
> > > 
> > > There is no such term as connac2 in this binding at all.
> > > 
> > > What is the point of adding new terms?
> > 
> > I didn’t think it was needed at first, but other reviewers
> > suggested
> > adding it.
> 
> 
> Adding secret terms in the binding is not helping.
> 
> > 
> > The commit message talks about mt7915, mt7990, mt7992, and mt7996,
> > which are all PCIe WiFi devices, so their names aren’t included in
> > the
> > platform binding. Only WiFi integrated SoCs like mt7981 and mt7986
> > are
> > listed.
> > 
> > These descriptions are meant to explain how a platform configures
> > TX
> > power for the connected WiFi devices, whether it’s a PCIe NIC (like
> > Connac3 devices I listed) or an integrated SoC itself (like
> > mt7981/mt7986).
> > 
> > What do you suggest? I’m actually okay with keeping everything as
> > is.
> 
> I have no clue what you want to achieve.
> > 
> > You can also look at the v2 discussion.
> > [v2] wifi: mt76: fix backoff fields and max_power calculation
> > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/54627282cfb8e5a89fe753da66552c0a084f6387.1769557863.git.ryder.lee@mediatek.com/__;!!CTRNKA9wMg0ARbw!kDXm7YfZY9fDiYPEWx7FWevmY3AqYGd2m9MlwoMZLHZuq8JBgfm2n02oFJ0ag692SgETTmtSSW1F-Q$
> >  
> 
> That's driver code.
> 

The driver code used to parse the DTS. You can look at the final
discussion—that’s why we need to change this DTS (if you’re
interested). This whole section is a discussion about the differences
in how the driver parses the DTS. But this part is already getting into
WiFi-specific details

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

> > 
> > > 
> > > > +                        - Beamforming entries for BW20~BW160
> > > > and
> > > > OFDM do not
> > > > +                          include 1T1ss.
> > > > +                        - When 1T1ss is not used, it should be
> > > > filled with 0.
> > > > +                      - For connac3
> > > > +                        - Beamforming entries for BW20~BW160
> > > > and
> > > > RU include
> > > > +                          1T1ss, but OFDM does not include
> > > > 1T1ss.
> > > > +                        - 1T1ss is taken into account, so no
> > > > need
> > > > to fill with 0.
> > > > +                      Non-beamforming and RU entries for both
> > > > connac2 and
> > > > +                      connac3 include 1T1ss.
> > > 
> > > Why this cannot be a schema?
> > > 
> > > 
> > Well, actually, it's already a schema. This is just an expanded
> 
> Where exactly?
> 

How 1T1ss is used across different generations is what my example above
was talking about.

> But if it is, then this patch is redundant. Don't repeat constraints
> in
> free form text.
> 

Alright then, let’s drop this change. Felix, please ignore this one.

Ryder