From: Krzysztof Kozlowski <krzk@kernel.org>
To: Ryder Lee <Ryder.Lee@mediatek.com>
Cc: "robh@kernel.org" <robh@kernel.org>,
"nbd@nbd.name" <nbd@nbd.name>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"Allen Ye (葉芷勳)" <Allen.Ye@mediatek.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH v5 2/2] dt-bindings: net: wireless: mt76: clarify backoff limit usage
Date: Sun, 15 Feb 2026 09:55:35 +0100 [thread overview]
Message-ID: <a80eada0-c30b-4e4c-a47d-5e03f5331ff6@kernel.org> (raw)
In-Reply-To: <d7e22b328fda50ebbf96f334fc15d63da9e7c19b.camel@mediatek.com>
On 12/02/2026 18:31, Ryder Lee wrote:
>>>
>>> reg:
>>> minItems: 1
>>> @@ -252,6 +257,14 @@ 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 mt7981/mt7986/mt7915/mt7916
>>> + - Beamforming entries for BW20~BW160 and
>>> OFDM do not
>>> + include 1T1ss.
>>> + - When 1T1ss is not used, it should be
>>> filled with 0.
>>
>> Shouldn't be skipped in such case? Why filling with 0 matters?
>>
> This logic was already present in driver. The driver determines whether
> to skip 1T1ss based on its value (0), so my update is focused on
> improving the documentation to guide users on the correct DTS format.
>
> For example, in the paths-ru-bf entries:
> <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>;
> (The order of all fields is required by the firmware.)
>
> The value for 1T1ss is set to 0 when it is not used, and the driver
> will skip it during parsing. So, users should always fill the DTS with
> all 10 values, using 0 for unused entries.
>
> This ensures that the parsing logic remains simple and uniform,
> avoiding potential errors or misalignment.
>
OK
Best regards,
Krzysztof
prev parent reply other threads:[~2026-02-15 8:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-12 0:36 [PATCH v5 1/2] wifi: mt76: fix backoff fields and max_power calculation Ryder Lee
2026-02-12 0:36 ` [PATCH v5 2/2] dt-bindings: net: wireless: mt76: clarify backoff limit usage Ryder Lee
2026-02-12 7:50 ` Krzysztof Kozlowski
2026-02-12 17:31 ` Ryder Lee
2026-02-15 8:55 ` Krzysztof Kozlowski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a80eada0-c30b-4e4c-a47d-5e03f5331ff6@kernel.org \
--to=krzk@kernel.org \
--cc=Allen.Ye@mediatek.com \
--cc=Ryder.Lee@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=nbd@nbd.name \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox