[PATCH v3 1/2] wifi: mt76: fix backoff fields and max_power calculation

[PATCH v3 1/2] wifi: mt76: fix backoff fields and max_power calculation

[Ryder Lee]

From: Allen Ye <allen.ye@mediatek.com>

The maximum power value may exist in either the data or backoff field.
Previously, backoff power limits were not considered in txpower reporting.
This patch ensures mt76 also considers backoff values in the SKU table.

Also, each RU entry (RU26, RU52, RU106, BW20, ...) in the DTS corresponds
to 10 stream combinations (1T1ss, 2T1ss, 3T1ss, 4T1ss, 2T2ss, 3T2ss,
4T2ss, 3T3ss, 4T3ss, 4T4ss).

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.

Fixes: b05ab4be9fd7 ("wifi: mt76: mt7915: add bf backoff limit table support")
Signed-off-by: Allen Ye <allen.ye@mediatek.com>
Co-developed-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
v1:
- Add "wifi:" prefix to the subject.

v2:
- Fix checkpatch errors.
- Remove unnecessary style changes.
- Add explanation for connac2 index adjustment.

v3:
- Fix "case"s for MT76_SKU_BACKOFF_BF_OFFSET and MT76_SKU_BACKOFF.
- add more explanation for connac2/connac3 tables.
---
 drivers/net/wireless/mediatek/mt76/eeprom.c | 154 ++++++++++++++------
 drivers/net/wireless/mediatek/mt76/mt76.h   |   1 -
 2 files changed, 109 insertions(+), 46 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/eeprom.c b/drivers/net/wireless/mediatek/mt76/eeprom.c
index 573400d57..afdb73661 100644
--- a/drivers/net/wireless/mediatek/mt76/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
@@ -9,6 +9,13 @@
 #include <linux/nvmem-consumer.h>
 #include <linux/etherdevice.h>
 #include "mt76.h"
+#include "mt76_connac.h"
+
+enum mt76_sku_type {
+	MT76_SKU_RATE,
+	MT76_SKU_BACKOFF,
+	MT76_SKU_BACKOFF_BF_OFFSET,
+};
 
 static int mt76_get_of_eeprom_data(struct mt76_dev *dev, void *eep, int len)
 {
@@ -292,7 +299,6 @@ mt76_find_channel_node(struct device_node *np, struct ieee80211_channel *chan)
 }
 EXPORT_SYMBOL_GPL(mt76_find_channel_node);
 
-
 static s8
 mt76_get_txs_delta(struct device_node *np, u8 nss)
 {
@@ -306,9 +312,24 @@ mt76_get_txs_delta(struct device_node *np, u8 nss)
 	return be32_to_cpu(val[nss - 1]);
 }
 
+static inline u8 mt76_backoff_n_chains(struct mt76_dev *dev, u8 idx)
+{
+	/* 0:1T1ss, 1:2T1ss, ..., 14:5T5ss */
+	static const u8 connac3_table[] = {
+		1, 2, 3, 4, 5, 2, 3, 4, 5, 3, 4, 5, 4, 5, 5};
+	static const u8 connac2_table[] = {
+		1, 2, 3, 4, 2, 3, 4, 3, 4, 4, 0, 0, 0, 0, 0};
+
+	if (idx >= ARRAY_SIZE(connac3_table))
+		return 0;
+
+	return is_mt799x(dev) ? connac3_table[idx] : connac2_table[idx];
+}
+
 static void
-mt76_apply_array_limit(s8 *pwr, size_t pwr_len, const s8 *data,
-		       s8 target_power, s8 nss_delta, s8 *max_power)
+mt76_apply_array_limit(struct mt76_dev *dev, s8 *pwr, size_t pwr_len,
+		       const s8 *data, s8 target_power, s8 nss_delta,
+		       s8 *max_power, int n_chains, enum mt76_sku_type type)
 {
 	int i;
 
@@ -316,18 +337,51 @@ mt76_apply_array_limit(s8 *pwr, size_t pwr_len, const s8 *data,
 		return;
 
 	for (i = 0; i < pwr_len; i++) {
-		pwr[i] = min_t(s8, target_power, data[i] + nss_delta);
+		u8 backoff_chain_idx = i;
+		int backoff_n_chains;
+		s8 backoff_delta;
+		s8 delta;
+
+		switch (type) {
+		case MT76_SKU_RATE:
+			delta = 0;
+			backoff_delta = 0;
+			backoff_n_chains = 0;
+			break;
+		case MT76_SKU_BACKOFF_BF_OFFSET:
+			backoff_chain_idx += 1;
+			fallthrough;
+		case MT76_SKU_BACKOFF:
+			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:
+			return;
+		}
+
+		pwr[i] = min_t(s8, target_power + delta - backoff_delta, data[i] + nss_delta);
+
+		/* used for padding, doesn't need to be considered */
+		if (data[i] >= S8_MAX - 1)
+			continue;
+
+		/* only consider backoff value for the configured chain number */
+		if (type != MT76_SKU_RATE && n_chains != backoff_n_chains)
+			continue;
+
 		*max_power = max(*max_power, pwr[i]);
 	}
 }
 
 static void
-mt76_apply_multi_array_limit(s8 *pwr, size_t pwr_len, s8 pwr_num,
-			     const s8 *data, size_t len, s8 target_power,
-			     s8 nss_delta)
+mt76_apply_multi_array_limit(struct mt76_dev *dev, s8 *pwr, size_t pwr_len,
+			     s8 pwr_num, const s8 *data, size_t len,
+			     s8 target_power, s8 nss_delta, s8 *max_power,
+			     int n_chains, enum mt76_sku_type type)
 {
+	static const int connac2_backoff_ru_idx = 2;
 	int i, cur;
-	s8 max_power = -128;
 
 	if (!data)
 		return;
@@ -337,8 +391,26 @@ mt76_apply_multi_array_limit(s8 *pwr, size_t pwr_len, s8 pwr_num,
 		if (len < pwr_len + 1)
 			break;
 
-		mt76_apply_array_limit(pwr + pwr_len * i, pwr_len, data + 1,
-				       target_power, nss_delta, &max_power);
+		/* Each RU entry (RU26, RU52, RU106, BW20, ...) in the DTS
+		 * corresponds to 10 stream combinations (1T1ss, 2T1ss, 3T1ss,
+		 * 4T1ss, 2T2ss, 3T2ss, 4T2ss, 3T3ss, 4T3ss, 4T4ss).
+		 *
+		 * 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.
+		 */
+		if (!is_mt799x(dev) && type == MT76_SKU_BACKOFF &&
+		    i > connac2_backoff_ru_idx)
+			type = MT76_SKU_BACKOFF_BF_OFFSET;
+
+		mt76_apply_array_limit(dev, pwr + pwr_len * i, pwr_len, data + 1,
+				       target_power, nss_delta, max_power,
+				       n_chains, type);
 		if (--cur > 0)
 			continue;
 
@@ -360,18 +432,11 @@ s8 mt76_get_rate_power_limits(struct mt76_phy *phy,
 	struct device_node *np;
 	const s8 *val;
 	char name[16];
-	u32 mcs_rates = dev->drv->mcs_rates;
-	u32 ru_rates = ARRAY_SIZE(dest->ru[0]);
 	char band;
 	size_t len;
-	s8 max_power = 0;
-	s8 max_power_backoff = -127;
+	s8 max_power = -127;
 	s8 txs_delta;
 	int n_chains = hweight16(phy->chainmask);
-	s8 target_power_combine = target_power + mt76_tx_power_path_delta(n_chains);
-
-	if (!mcs_rates)
-		mcs_rates = 10;
 
 	memset(dest, target_power, sizeof(*dest) - sizeof(dest->path));
 	memset(&dest->path, 0, sizeof(dest->path));
@@ -409,46 +474,45 @@ s8 mt76_get_rate_power_limits(struct mt76_phy *phy,
 	txs_delta = mt76_get_txs_delta(np, hweight16(phy->chainmask));
 
 	val = mt76_get_of_array_s8(np, "rates-cck", &len, ARRAY_SIZE(dest->cck));
-	mt76_apply_array_limit(dest->cck, ARRAY_SIZE(dest->cck), val,
-			       target_power, txs_delta, &max_power);
+	mt76_apply_array_limit(dev, dest->cck, ARRAY_SIZE(dest->cck), val,
+			       target_power, txs_delta, &max_power, n_chains, MT76_SKU_RATE);
 
-	val = mt76_get_of_array_s8(np, "rates-ofdm",
-				   &len, ARRAY_SIZE(dest->ofdm));
-	mt76_apply_array_limit(dest->ofdm, ARRAY_SIZE(dest->ofdm), val,
-			       target_power, txs_delta, &max_power);
+	val = mt76_get_of_array_s8(np, "rates-ofdm", &len, ARRAY_SIZE(dest->ofdm));
+	mt76_apply_array_limit(dev, dest->ofdm, ARRAY_SIZE(dest->ofdm), val,
+			       target_power, txs_delta, &max_power, n_chains, MT76_SKU_RATE);
 
-	val = mt76_get_of_array_s8(np, "rates-mcs", &len, mcs_rates + 1);
-	mt76_apply_multi_array_limit(dest->mcs[0], ARRAY_SIZE(dest->mcs[0]),
-				     ARRAY_SIZE(dest->mcs), val, len,
-				     target_power, txs_delta);
+	val = mt76_get_of_array_s8(np, "rates-mcs", &len, ARRAY_SIZE(dest->mcs[0]) + 1);
+	mt76_apply_multi_array_limit(dev, dest->mcs[0], ARRAY_SIZE(dest->mcs[0]),
+				     ARRAY_SIZE(dest->mcs), val, len, target_power,
+				     txs_delta, &max_power, n_chains, MT76_SKU_RATE);
 
-	val = mt76_get_of_array_s8(np, "rates-ru", &len, ru_rates + 1);
-	mt76_apply_multi_array_limit(dest->ru[0], ARRAY_SIZE(dest->ru[0]),
-				     ARRAY_SIZE(dest->ru), val, len,
-				     target_power, txs_delta);
+	val = mt76_get_of_array_s8(np, "rates-ru", &len, ARRAY_SIZE(dest->ru[0]) + 1);
+	mt76_apply_multi_array_limit(dev, dest->ru[0], ARRAY_SIZE(dest->ru[0]),
+				     ARRAY_SIZE(dest->ru), val, len, target_power,
+				     txs_delta, &max_power, n_chains, MT76_SKU_RATE);
 
-	max_power_backoff = max_power;
 	val = mt76_get_of_array_s8(np, "paths-cck", &len, ARRAY_SIZE(dest->path.cck));
-	mt76_apply_array_limit(dest->path.cck, ARRAY_SIZE(dest->path.cck), val,
-			       target_power_combine, txs_delta, &max_power_backoff);
+	mt76_apply_array_limit(dev, dest->path.cck, ARRAY_SIZE(dest->path.cck), val,
+			       target_power, txs_delta, &max_power, n_chains, MT76_SKU_BACKOFF);
 
 	val = mt76_get_of_array_s8(np, "paths-ofdm", &len, ARRAY_SIZE(dest->path.ofdm));
-	mt76_apply_array_limit(dest->path.ofdm, ARRAY_SIZE(dest->path.ofdm), val,
-			       target_power_combine, txs_delta, &max_power_backoff);
+	mt76_apply_array_limit(dev, dest->path.ofdm, ARRAY_SIZE(dest->path.ofdm), val,
+			       target_power, txs_delta, &max_power, n_chains, MT76_SKU_BACKOFF);
 
 	val = mt76_get_of_array_s8(np, "paths-ofdm-bf", &len, ARRAY_SIZE(dest->path.ofdm_bf));
-	mt76_apply_array_limit(dest->path.ofdm_bf, ARRAY_SIZE(dest->path.ofdm_bf), val,
-			       target_power_combine, txs_delta, &max_power_backoff);
+	mt76_apply_array_limit(dev, dest->path.ofdm_bf, ARRAY_SIZE(dest->path.ofdm_bf), val,
+			       target_power, txs_delta, &max_power, n_chains,
+			       MT76_SKU_BACKOFF_BF_OFFSET);
 
 	val = mt76_get_of_array_s8(np, "paths-ru", &len, ARRAY_SIZE(dest->path.ru[0]) + 1);
-	mt76_apply_multi_array_limit(dest->path.ru[0], ARRAY_SIZE(dest->path.ru[0]),
-				     ARRAY_SIZE(dest->path.ru), val, len,
-				     target_power_combine, txs_delta);
+	mt76_apply_multi_array_limit(dev, dest->path.ru[0], ARRAY_SIZE(dest->path.ru[0]),
+				     ARRAY_SIZE(dest->path.ru), val, len, target_power,
+				     txs_delta, &max_power, n_chains, MT76_SKU_BACKOFF);
 
 	val = mt76_get_of_array_s8(np, "paths-ru-bf", &len, ARRAY_SIZE(dest->path.ru_bf[0]) + 1);
-	mt76_apply_multi_array_limit(dest->path.ru_bf[0], ARRAY_SIZE(dest->path.ru_bf[0]),
-				     ARRAY_SIZE(dest->path.ru_bf), val, len,
-				     target_power_combine, txs_delta);
+	mt76_apply_multi_array_limit(dev, dest->path.ru_bf[0], ARRAY_SIZE(dest->path.ru_bf[0]),
+				     ARRAY_SIZE(dest->path.ru_bf), val, len, target_power,
+				     txs_delta, &max_power, n_chains, MT76_SKU_BACKOFF);
 
 	return max_power;
 }
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index d05e83ea1..32876eab2 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -540,7 +540,6 @@ struct mt76_driver_ops {
 	u32 survey_flags;
 	u16 txwi_size;
 	u16 token_size;
-	u8 mcs_rates;
 
 	unsigned int link_data_size;
 
-- 
2.45.2

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

[Ryder Lee]

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.

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>
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
+                        - 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.
                     minItems: 1
                     maxItems: 7
                     items:
@@ -270,6 +280,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
+                        - 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.
                     minItems: 1
                     maxItems: 7
                     items:
-- 
2.45.2

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

[Ryder Lee]

On Tue, 2026-02-10 at 10:08 -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.
> 
> 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>
> 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
> +                        - 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.
>                      minItems: 1
>                      maxItems: 7
>                      items:
> @@ -270,6 +280,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
> +                        - 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.
>                      minItems: 1
>                      maxItems: 7
>                      items:

Oops. Please ignore this patch, I mistakenly added the wrong entries.

Ryder

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

[Ryder Lee]

On Tue, 2026-02-10 at 18:12 +0000, Ryder Lee wrote:
> On Tue, 2026-02-10 at 10:08 -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.
> > 
> > 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>
> > 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
> > +                        - 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.
> >                      minItems: 1
> >                      maxItems: 7
> >                      items:
> > @@ -270,6 +280,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
> > +                        - 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.
> >                      minItems: 1
> >                      maxItems: 7
> >                      items:
> 
> Oops. Please ignore this patch, I mistakenly added the wrong entries.
> 
> Ryder

Oh, never mind. This is actually correct. I must have been a bit dizzy.

Ryder

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

[Krzysztof Kozlowski]

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.

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

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

> +                        - 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?

Best regards,
Krzysztof

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

[Ryder Lee]

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.

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.

You can also look at the v2 discussion.
[v2] wifi: mt76: fix backoff fields and max_power calculation
https://patchwork.kernel.org/project/linux-mediatek/patch/54627282cfb8e5a89fe753da66552c0a084f6387.1769557863.git.ryder.lee@mediatek.com/

> 
> > +                        - 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
explanation of the differences in handling between different
devices/generations.

But actually, the differences between these generations can be fully
handled in the driver (that's exactly what my [1/2] is doing), so
whether to update the documentation is really just a matter of personal
preference.

I'm also not sure how to describe a Connac3 PCIe device (non-SoC type)
that isn't mentioned in the documentation.

If we need to drop the DTS change, I’m okay with that and will leave it
up to the reviewers. Or, we can just apply [1/2] on its own, which
won’t affect the documentation’s description or usage.

Ryder

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

[Krzysztof Kozlowski]

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://patchwork.kernel.org/project/linux-mediatek/patch/54627282cfb8e5a89fe753da66552c0a084f6387.1769557863.git.ryder.lee@mediatek.com/

That's driver code.

> 
>>
>>> +                        - 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?

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


Best regards,
Krzysztof

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

[Ryder Lee]

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

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

[Krzysztof Kozlowski]

On 11/02/2026 09:33, Ryder Lee wrote:
>>>> 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.

Where exactly it is already a schema? Please point me line encoding this.

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



Best regards,
Krzysztof

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

[Ryder Lee]

On Wed, 2026-02-11 at 09:41 +0100, Krzysztof Kozlowski wrote:
> On 11/02/2026 09:33, Ryder Lee wrote:
> > > > > 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.
> 
> Where exactly it is already a schema? Please point me line encoding
> this.
> 
> 
line 243 paths-ru
line 261 paths-ru-bf

1T1ss refers to the second row in the example below

Previously, we were mainly discussing how the driver should handle
parsing 0 versus non-zero cases, but this can be fully managed by the
driver itself. My [1/2] patch already explains this clearly.

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

Whether the DTS needs to interpret it is really up to personal
preference. Personally, I don’t think it’s needed but I respect
everyone's opinion.

Our newer IC generations are only going to get more complex. If we
hardcode too many definitions now, you’ll end up having to change them
repeatedly. It’s better to let the driver handle this logic.

Ryder

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

[Krzysztof Kozlowski]

On 11/02/2026 09:59, Ryder Lee wrote:
> On Wed, 2026-02-11 at 09:41 +0100, Krzysztof Kozlowski wrote:
>> On 11/02/2026 09:33, Ryder Lee wrote:
>>>>>> 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.
>>
>> Where exactly it is already a schema? Please point me line encoding
>> this.
>>
>>
> line 243 paths-ru
> line 261 paths-ru-bf

I do not see there anything like you wrote here. You just list all of
them, no device constraints.

Best regards,
Krzysztof

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

[Ryder Lee]

On Wed, 2026-02-11 at 10:08 +0100, Krzysztof Kozlowski wrote:
> On 11/02/2026 09:59, Ryder Lee wrote:
> > On Wed, 2026-02-11 at 09:41 +0100, Krzysztof Kozlowski wrote:
> > > On 11/02/2026 09:33, Ryder Lee wrote:
> > > > > > > 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.
> > > 
> > > Where exactly it is already a schema? Please point me line
> > > encoding
> > > this.
> > > 
> > > 
> > line 243 paths-ru
> > line 261 paths-ru-bf
> 
> I do not see there anything like you wrote here. You just list all of
> them, no device constraints.
> 
> Best regards,
> Krzysztof
> 

The original schema is a broad description. Now a reviewer want me to
describe the differences for various connected devices, but I don’t
know how to add a compatible string for PCIe, USB, or even SDIO devices
for their constraints. So I used the driver’s generation name... can I
just write “mt7996”? Or do I need a complete and meaningful compatible
string?

Or maybe there’s no need to change the documentation at all and just
let the driver handle it, so we don’t have to discuss these details.

Ryder

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

[Ryder Lee]

On Wed, 2026-02-11 at 09:19 +0000, Ryder Lee wrote:
> On Wed, 2026-02-11 at 10:08 +0100, Krzysztof Kozlowski wrote:
> > On 11/02/2026 09:59, Ryder Lee wrote:
> > > On Wed, 2026-02-11 at 09:41 +0100, Krzysztof Kozlowski wrote:
> > > > On 11/02/2026 09:33, Ryder Lee wrote:
> > > > > > > > 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.
> > > > 
> > > > Where exactly it is already a schema? Please point me line
> > > > encoding
> > > > this.
> > > > 
> > > > 
> > > line 243 paths-ru
> > > line 261 paths-ru-bf
> > 
> > I do not see there anything like you wrote here. You just list all
> > of
> > them, no device constraints.
> > 
> > Best regards,
> > Krzysztof
> > 
> 
> The original schema is a broad description. Now a reviewer want me to
> describe the differences for various connected devices, but I don’t
> know how to add a compatible string for PCIe, USB, or even SDIO
> devices
> for their constraints. So I used the driver’s generation name... can
> I
> just write “mt7996”? Or do I need a complete and meaningful
> compatible
> string?
> 
> Or maybe there’s no need to change the documentation at all and just
> let the driver handle it, so we don’t have to discuss these details.
> 
> Ryder

I think we should just drop this DTS change for now. I’ll focus on the
[1/2] driver change. Right now, we’re just moving what the driver
already does into the documentation, which feels a bit excessive to me.

This makes things simpler.

Ryder

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

[Chen-Yu Tsai]

On Wed, Feb 11, 2026 at 5:19 PM Ryder Lee <Ryder.Lee@mediatek.com> wrote:
>
> On Wed, 2026-02-11 at 10:08 +0100, Krzysztof Kozlowski wrote:
> > On 11/02/2026 09:59, Ryder Lee wrote:
> > > On Wed, 2026-02-11 at 09:41 +0100, Krzysztof Kozlowski wrote:
> > > > On 11/02/2026 09:33, Ryder Lee wrote:
> > > > > > > > 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.
> > > >
> > > > Where exactly it is already a schema? Please point me line
> > > > encoding
> > > > this.
> > > >
> > > >
> > > line 243 paths-ru
> > > line 261 paths-ru-bf
> >
> > I do not see there anything like you wrote here. You just list all of
> > them, no device constraints.
> >
> > Best regards,
> > Krzysztof
> >
>
> The original schema is a broad description. Now a reviewer want me to
> describe the differences for various connected devices, but I don’t
> know how to add a compatible string for PCIe, USB, or even SDIO devices
> for their constraints. So I used the driver’s generation name... can I
> just write “mt7996”? Or do I need a complete and meaningful compatible
> string?

You can fill in the PCI or USB IDs as the compatible string.

See for example
- Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
- Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
- Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml

There's no equivalent for SDIO, so they just have separate compatibles.
The bcm4329-fmac binding also has examples of these.

If the hardware has something like a chip ID register, then you can
have a common fallback string. At the extreme end of this is the ARM
Mali bindings, which just have one compatible string for the core GPU
as the fallback, and per platform/SoC compatibles to cover the glue
layer:

- Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml


ChenYu

> Or maybe there’s no need to change the documentation at all and just
> let the driver handle it, so we don’t have to discuss these details.
>
> Ryder

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

[Ryder Lee]

On Wed, 2026-02-11 at 17:52 +0800, Chen-Yu Tsai wrote:
> On Wed, Feb 11, 2026 at 5:19 PM Ryder Lee <Ryder.Lee@mediatek.com>
> wrote:
> > 
> > On Wed, 2026-02-11 at 10:08 +0100, Krzysztof Kozlowski wrote:
> > > On 11/02/2026 09:59, Ryder Lee wrote:
> > > > On Wed, 2026-02-11 at 09:41 +0100, Krzysztof Kozlowski wrote:
> > > > > On 11/02/2026 09:33, Ryder Lee wrote:
> > > > > > > > > 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.
> > > > > 
> > > > > Where exactly it is already a schema? Please point me line
> > > > > encoding
> > > > > this.
> > > > > 
> > > > > 
> > > > line 243 paths-ru
> > > > line 261 paths-ru-bf
> > > 
> > > I do not see there anything like you wrote here. You just list
> > > all of
> > > them, no device constraints.
> > > 
> > > Best regards,
> > > Krzysztof
> > > 
> > 
> > The original schema is a broad description. Now a reviewer want me
> > to
> > describe the differences for various connected devices, but I don’t
> > know how to add a compatible string for PCIe, USB, or even SDIO
> > devices
> > for their constraints. So I used the driver’s generation name...
> > can I
> > just write “mt7996”? Or do I need a complete and meaningful
> > compatible
> > string?
> 
> You can fill in the PCI or USB IDs as the compatible string.
> 
> See for example
> - Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-
> fmac.yaml
> - Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-
> fmac.yaml
> - Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml

Oh, I see. These examples are really helpful. I’ll add the PCI IDs and
replace the original connac2/3 patch with these PCI IDs.

> 
> There's no equivalent for SDIO, so they just have separate
> compatibles.
> The bcm4329-fmac binding also has examples of these.
> 
> If the hardware has something like a chip ID register, then you can
> have a common fallback string. At the extreme end of this is the ARM
> Mali bindings, which just have one compatible string for the core GPU
> as the fallback, and per platform/SoC compatibles to cover the glue
> layer:
> 
> - Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> 
> 
> ChenYu
> 

Ryder

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

[Chen-Yu Tsai]

On Wed, Feb 11, 2026 at 4:41 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 11/02/2026 09:33, Ryder Lee wrote:
> >>>> 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.
>
> Where exactly it is already a schema? Please point me line encoding this.

I think what Krzysztof is asking is why can't you have different compatible
strings for each generation (connac, connac2, connac3), and then have
conditionals in this document to describe in proper DT schema, not text,
the length requirements of each property for each generation.


ChenYu

> >
> >> 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.
>
>
>
> Best regards,
> Krzysztof
>

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

[Ryder Lee]

On Wed, 2026-02-11 at 17:01 +0800, Chen-Yu Tsai wrote:
> On Wed, Feb 11, 2026 at 4:41 PM Krzysztof Kozlowski <krzk@kernel.org>
> wrote:
> > 
> > On 11/02/2026 09:33, Ryder Lee wrote:
> > > > > > 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.
> > 
> > Where exactly it is already a schema? Please point me line encoding
> > this.
> 
> I think what Krzysztof is asking is why can't you have different
> compatible
> strings for each generation (connac, connac2, connac3), and then have
> conditionals in this document to describe in proper DT schema, not
> text,
> the length requirements of each property for each generation.
> 
> 
> ChenYu
> 

Oh, so this is exactly my original question: how do I describe a PCIe
device in the platform binding when there is no compatible string for
it (a NIC card)?

Ryder