* [PATCH rtw-next 08/13] wifi: rtw89: chan: recalc MLO DBCC mode based on current entity mode
From: Ping-Ke Shih @ 2026-03-10 8:01 UTC (permalink / raw)
To: linux-wireless; +Cc: timlee, phhuang, kevin_yang
In-Reply-To: <20260310080146.31113-1-pkshih@realtek.com>
From: Zong-Zhe Yang <kevin_yang@realtek.com>
Since MLD vif can do MLSR switch, it may not always run on HW band 0.
But when preparing MCC for MLD + P2P, P2P vif needs to use HW band 0
to handle connection, i.e. uses of HW bands may be different by vif.
The current major role/vif can be indicated through entity mode. So,
based on it, recalculate MLO DBCC mode to change use of HW band.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/chan.c | 61 +++++++++++++++--------
1 file changed, 41 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw89/chan.c b/drivers/net/wireless/realtek/rtw89/chan.c
index def9e4f3af59..ceb399fc2b94 100644
--- a/drivers/net/wireless/realtek/rtw89/chan.c
+++ b/drivers/net/wireless/realtek/rtw89/chan.c
@@ -381,6 +381,23 @@ static void rtw89_normalize_link_chanctx(struct rtw89_dev *rtwdev,
rtw89_swap_chanctx(rtwdev, rtwvif_link->chanctx_idx, cur->chanctx_idx);
}
+static u8 rtw89_entity_role_get_index(struct rtw89_dev *rtwdev)
+{
+ enum rtw89_entity_mode mode;
+
+ mode = rtw89_get_entity_mode(rtwdev);
+ switch (mode) {
+ default:
+ WARN(1, "Invalid ent mode: %d\n", mode);
+ fallthrough;
+ case RTW89_ENTITY_MODE_SCC_OR_SMLD:
+ case RTW89_ENTITY_MODE_MCC:
+ return 0;
+ case RTW89_ENTITY_MODE_MCC_PREPARE:
+ return 1;
+ }
+}
+
const struct rtw89_chan *__rtw89_mgnt_chan_get(struct rtw89_dev *rtwdev,
const char *caller_message,
u8 link_index, bool nullchk)
@@ -388,7 +405,6 @@ const struct rtw89_chan *__rtw89_mgnt_chan_get(struct rtw89_dev *rtwdev,
struct rtw89_hal *hal = &rtwdev->hal;
struct rtw89_entity_mgnt *mgnt = &hal->entity_mgnt;
enum rtw89_chanctx_idx chanctx_idx;
- enum rtw89_entity_mode mode;
u8 role_index;
lockdep_assert_wiphy(rtwdev->hw->wiphy);
@@ -399,19 +415,7 @@ const struct rtw89_chan *__rtw89_mgnt_chan_get(struct rtw89_dev *rtwdev,
goto dflt;
}
- mode = rtw89_get_entity_mode(rtwdev);
- switch (mode) {
- case RTW89_ENTITY_MODE_SCC_OR_SMLD:
- case RTW89_ENTITY_MODE_MCC:
- role_index = 0;
- break;
- case RTW89_ENTITY_MODE_MCC_PREPARE:
- role_index = 1;
- break;
- default:
- WARN(1, "Invalid ent mode: %d\n", mode);
- goto dflt;
- }
+ role_index = rtw89_entity_role_get_index(rtwdev);
chanctx_idx = mgnt->chanctx_tbl[role_index][link_index];
if (chanctx_idx == RTW89_CHANCTX_IDLE)
@@ -479,10 +483,28 @@ rtw89_entity_sel_mlo_dbcc_mode(struct rtw89_dev *rtwdev, u8 active_hws)
}
}
-static
-void rtw89_entity_recalc_mlo_dbcc_mode(struct rtw89_dev *rtwdev, u8 active_hws)
+static void rtw89_entity_recalc_mlo_dbcc_mode(struct rtw89_dev *rtwdev)
{
+ struct rtw89_entity_mgnt *mgnt = &rtwdev->hal.entity_mgnt;
enum rtw89_mlo_dbcc_mode mode;
+ struct rtw89_vif *role;
+ u8 active_hws = 0;
+ u8 ridx;
+
+ ridx = rtw89_entity_role_get_index(rtwdev);
+ role = mgnt->active_roles[ridx];
+ if (role) {
+ struct rtw89_vif_link *link;
+ int i;
+
+ for (i = 0; i < role->links_inst_valid_num; i++) {
+ link = rtw89_vif_get_link_inst(role, i);
+ if (!link || !link->chanctx_assigned)
+ continue;
+
+ active_hws |= BIT(i);
+ }
+ }
mode = rtw89_entity_sel_mlo_dbcc_mode(rtwdev, active_hws);
rtwdev->mlo_dbcc_mode = mode;
@@ -496,7 +518,6 @@ static void rtw89_entity_recalc_mgnt_roles(struct rtw89_dev *rtwdev)
struct rtw89_entity_mgnt *mgnt = &hal->entity_mgnt;
struct rtw89_vif_link *link;
struct rtw89_vif *role;
- u8 active_hws = 0;
u8 pos = 0;
int i, j;
@@ -545,13 +566,10 @@ static void rtw89_entity_recalc_mgnt_roles(struct rtw89_dev *rtwdev)
continue;
mgnt->chanctx_tbl[pos][i] = link->chanctx_idx;
- active_hws |= BIT(i);
}
mgnt->active_roles[pos++] = role;
}
-
- rtw89_entity_recalc_mlo_dbcc_mode(rtwdev, active_hws);
}
enum rtw89_entity_mode rtw89_entity_recalc(struct rtw89_dev *rtwdev)
@@ -621,6 +639,9 @@ enum rtw89_entity_mode rtw89_entity_recalc(struct rtw89_dev *rtwdev)
return rtw89_get_entity_mode(rtwdev);
rtw89_set_entity_mode(rtwdev, mode);
+
+ rtw89_entity_recalc_mlo_dbcc_mode(rtwdev);
+
return mode;
}
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 07/13] wifi: rtw89: chan: simplify link handling related to ROC
From: Ping-Ke Shih @ 2026-03-10 8:01 UTC (permalink / raw)
To: linux-wireless; +Cc: timlee, phhuang, kevin_yang
In-Reply-To: <20260310080146.31113-1-pkshih@realtek.com>
From: Zong-Zhe Yang <kevin_yang@realtek.com>
The original channel is swapped out for the target channel during ROC.
And, all vifs/links accessing the original channel will be marked with
off-channel. So, it doesn't seem necessary for chan.c to determine which
link instance it is.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/chan.c | 11 -----------
drivers/net/wireless/realtek/rtw89/core.h | 1 -
2 files changed, 12 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw89/chan.c b/drivers/net/wireless/realtek/rtw89/chan.c
index 9b2f6f0a00fd..def9e4f3af59 100644
--- a/drivers/net/wireless/realtek/rtw89/chan.c
+++ b/drivers/net/wireless/realtek/rtw89/chan.c
@@ -276,7 +276,6 @@ void rtw89_config_roc_chandef(struct rtw89_dev *rtwdev,
}
hal->roc_chandef = *chandef;
- hal->roc_link_index = rtw89_vif_link_inst_get_index(rtwvif_link);
} else {
cur = atomic_cmpxchg(&hal->roc_chanctx_idx, idx,
RTW89_CHANCTX_IDLE);
@@ -389,7 +388,6 @@ const struct rtw89_chan *__rtw89_mgnt_chan_get(struct rtw89_dev *rtwdev,
struct rtw89_hal *hal = &rtwdev->hal;
struct rtw89_entity_mgnt *mgnt = &hal->entity_mgnt;
enum rtw89_chanctx_idx chanctx_idx;
- enum rtw89_chanctx_idx roc_idx;
enum rtw89_entity_mode mode;
u8 role_index;
@@ -419,15 +417,6 @@ const struct rtw89_chan *__rtw89_mgnt_chan_get(struct rtw89_dev *rtwdev,
if (chanctx_idx == RTW89_CHANCTX_IDLE)
goto dflt;
- roc_idx = atomic_read(&hal->roc_chanctx_idx);
- if (roc_idx != RTW89_CHANCTX_IDLE) {
- /* ROC is ongoing (given ROC runs on @hal->roc_link_index).
- * If @link_index is the same, get the ongoing ROC chanctx.
- */
- if (link_index == hal->roc_link_index)
- chanctx_idx = roc_idx;
- }
-
return rtw89_chan_get(rtwdev, chanctx_idx);
dflt:
diff --git a/drivers/net/wireless/realtek/rtw89/core.h b/drivers/net/wireless/realtek/rtw89/core.h
index 05f8ad6d3034..01573150ab3c 100644
--- a/drivers/net/wireless/realtek/rtw89/core.h
+++ b/drivers/net/wireless/realtek/rtw89/core.h
@@ -5170,7 +5170,6 @@ struct rtw89_hal {
bool no_eht;
atomic_t roc_chanctx_idx;
- u8 roc_link_index;
DECLARE_BITMAP(changes, NUM_OF_RTW89_CHANCTX_CHANGES);
DECLARE_BITMAP(entity_map, NUM_OF_RTW89_CHANCTX);
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 06/13] wifi: rtw89: tweak settings of TX power and channel for Wi-Fi 7
From: Ping-Ke Shih @ 2026-03-10 8:01 UTC (permalink / raw)
To: linux-wireless; +Cc: timlee, phhuang, kevin_yang
In-Reply-To: <20260310080146.31113-1-pkshih@realtek.com>
From: Zong-Zhe Yang <kevin_yang@realtek.com>
The support_mlo flag depends on FW features, so it's determined at runtime.
Since Wi-Fi 7 chip now needs to initialize second HW band, if support_mlo
is not allowed, second HW band might act without settings of TX power and
channel. So, set that for Wi-Fi 7 chip.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw89/core.c b/drivers/net/wireless/realtek/rtw89/core.c
index 81004ef18168..6ab99a3577f3 100644
--- a/drivers/net/wireless/realtek/rtw89/core.c
+++ b/drivers/net/wireless/realtek/rtw89/core.c
@@ -463,7 +463,7 @@ void rtw89_core_set_chip_txpwr(struct rtw89_dev *rtwdev)
chan = rtw89_mgnt_chan_get(rtwdev, 0);
__rtw89_core_set_chip_txpwr(rtwdev, chan, RTW89_PHY_0);
- if (!rtwdev->support_mlo)
+ if (rtwdev->chip->chip_gen == RTW89_CHIP_AX)
return;
chan = rtw89_mgnt_chan_get(rtwdev, 1);
@@ -558,7 +558,7 @@ int rtw89_set_channel(struct rtw89_dev *rtwdev)
chan = rtw89_mgnt_chan_get(rtwdev, 0);
__rtw89_set_channel(rtwdev, chan, RTW89_MAC_0, RTW89_PHY_0);
- if (!rtwdev->support_mlo)
+ if (rtwdev->chip->chip_gen == RTW89_CHIP_AX)
return 0;
chan = rtw89_mgnt_chan_get(rtwdev, 1);
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 05/13] wifi: rtw89: move disabling dynamic mechanism functions to core
From: Ping-Ke Shih @ 2026-03-10 8:01 UTC (permalink / raw)
To: linux-wireless; +Cc: timlee, phhuang, kevin_yang
In-Reply-To: <20260310080146.31113-1-pkshih@realtek.com>
From: Zong-Zhe Yang <kevin_yang@realtek.com>
Some dynamic mechanism (DM) may need to be disabled during some normal
processes rather than debugging. For example, should not do MLSR switch
during SCAN/ROC or even MCC. So, move the disabling DM functions to core
for impending uses.
No logic changes.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/core.c | 29 ++++++++++++++++++
drivers/net/wireless/realtek/rtw89/core.h | 3 ++
drivers/net/wireless/realtek/rtw89/debug.c | 35 ++--------------------
3 files changed, 35 insertions(+), 32 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw89/core.c b/drivers/net/wireless/realtek/rtw89/core.c
index 9d9b91570989..81004ef18168 100644
--- a/drivers/net/wireless/realtek/rtw89/core.c
+++ b/drivers/net/wireless/realtek/rtw89/core.c
@@ -4713,6 +4713,35 @@ static void rtw89_track_work(struct wiphy *wiphy, struct wiphy_work *work)
rtw89_enter_lps_track(rtwdev);
}
+void rtw89_core_dm_disable_cfg(struct rtw89_dev *rtwdev, u32 new)
+{
+ struct rtw89_hal *hal = &rtwdev->hal;
+ u32 old = hal->disabled_dm_bitmap;
+
+ if (new == old)
+ return;
+
+ hal->disabled_dm_bitmap = new;
+
+ rtw89_debug(rtwdev, RTW89_DBG_STATE, "Disable DM: 0x%x -> 0x%x\n", old, new);
+}
+
+void rtw89_core_dm_disable_set(struct rtw89_dev *rtwdev, enum rtw89_dm_type type)
+{
+ struct rtw89_hal *hal = &rtwdev->hal;
+ u32 cur = hal->disabled_dm_bitmap;
+
+ rtw89_core_dm_disable_cfg(rtwdev, cur | BIT(type));
+}
+
+void rtw89_core_dm_disable_clr(struct rtw89_dev *rtwdev, enum rtw89_dm_type type)
+{
+ struct rtw89_hal *hal = &rtwdev->hal;
+ u32 cur = hal->disabled_dm_bitmap;
+
+ rtw89_core_dm_disable_cfg(rtwdev, cur & ~BIT(type));
+}
+
u8 rtw89_core_acquire_bit_map(unsigned long *addr, unsigned long size)
{
unsigned long bit;
diff --git a/drivers/net/wireless/realtek/rtw89/core.h b/drivers/net/wireless/realtek/rtw89/core.h
index cf0cc718f41c..05f8ad6d3034 100644
--- a/drivers/net/wireless/realtek/rtw89/core.h
+++ b/drivers/net/wireless/realtek/rtw89/core.h
@@ -7862,5 +7862,8 @@ void rtw89_core_update_p2p_ps(struct rtw89_dev *rtwdev,
void rtw89_core_ntfy_btc_event(struct rtw89_dev *rtwdev, enum rtw89_btc_hmsg event);
int rtw89_core_mlsr_switch(struct rtw89_dev *rtwdev, struct rtw89_vif *rtwvif,
unsigned int link_id);
+void rtw89_core_dm_disable_cfg(struct rtw89_dev *rtwdev, u32 new);
+void rtw89_core_dm_disable_set(struct rtw89_dev *rtwdev, enum rtw89_dm_type type);
+void rtw89_core_dm_disable_clr(struct rtw89_dev *rtwdev, enum rtw89_dm_type type);
#endif
diff --git a/drivers/net/wireless/realtek/rtw89/debug.c b/drivers/net/wireless/realtek/rtw89/debug.c
index 3e16ed2c4570..aee0f25e036a 100644
--- a/drivers/net/wireless/realtek/rtw89/debug.c
+++ b/drivers/net/wireless/realtek/rtw89/debug.c
@@ -4333,35 +4333,6 @@ static ssize_t rtw89_debug_priv_stations_get(struct rtw89_dev *rtwdev,
return p - buf;
}
-static void rtw89_debug_disable_dm_cfg_bmap(struct rtw89_dev *rtwdev, u32 new)
-{
- struct rtw89_hal *hal = &rtwdev->hal;
- u32 old = hal->disabled_dm_bitmap;
-
- if (new == old)
- return;
-
- hal->disabled_dm_bitmap = new;
-
- rtw89_debug(rtwdev, RTW89_DBG_STATE, "Disable DM: 0x%x -> 0x%x\n", old, new);
-}
-
-static void rtw89_debug_disable_dm_set_flag(struct rtw89_dev *rtwdev, u8 flag)
-{
- struct rtw89_hal *hal = &rtwdev->hal;
- u32 cur = hal->disabled_dm_bitmap;
-
- rtw89_debug_disable_dm_cfg_bmap(rtwdev, cur | BIT(flag));
-}
-
-static void rtw89_debug_disable_dm_clr_flag(struct rtw89_dev *rtwdev, u8 flag)
-{
- struct rtw89_hal *hal = &rtwdev->hal;
- u32 cur = hal->disabled_dm_bitmap;
-
- rtw89_debug_disable_dm_cfg_bmap(rtwdev, cur & ~BIT(flag));
-}
-
#define DM_INFO(type) {RTW89_DM_ ## type, #type}
static const struct rtw89_disabled_dm_info {
@@ -4412,7 +4383,7 @@ rtw89_debug_priv_disable_dm_set(struct rtw89_dev *rtwdev,
if (ret)
return -EINVAL;
- rtw89_debug_disable_dm_cfg_bmap(rtwdev, conf);
+ rtw89_core_dm_disable_cfg(rtwdev, conf);
return count;
}
@@ -4475,7 +4446,7 @@ rtw89_debug_priv_mlo_mode_set(struct rtw89_dev *rtwdev,
if (num != 2)
return -EINVAL;
- rtw89_debug_disable_dm_set_flag(rtwdev, RTW89_DM_MLO);
+ rtw89_core_dm_disable_set(rtwdev, RTW89_DM_MLO);
rtw89_debug(rtwdev, RTW89_DBG_STATE, "Set MLO mode to %x\n", mlo_mode);
@@ -4485,7 +4456,7 @@ rtw89_debug_priv_mlo_mode_set(struct rtw89_dev *rtwdev,
break;
default:
rtw89_debug(rtwdev, RTW89_DBG_STATE, "Unsupported MLO mode\n");
- rtw89_debug_disable_dm_clr_flag(rtwdev, RTW89_DM_MLO);
+ rtw89_core_dm_disable_clr(rtwdev, RTW89_DM_MLO);
return -EOPNOTSUPP;
}
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 04/13] wifi: rtw89: phy: limit AMPDU number for RA try rate
From: Ping-Ke Shih @ 2026-03-10 8:01 UTC (permalink / raw)
To: linux-wireless; +Cc: timlee, phhuang, kevin_yang
In-Reply-To: <20260310080146.31113-1-pkshih@realtek.com>
When RA (Rate Adaptive) does try higher rate, a TRY bit is flagged, and
hardware will reference registers configured by this patch as maximum
number of AMPDU. To prevent aggregate too many MPDU over peer's capability
causing loss in peer side, set the minimum values across all stations and
TID since there is single one register per hardware band. Consider MLD
case, a BA session can run across two hardware bands, so set the same
value as well.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/mac.c | 2 ++
drivers/net/wireless/realtek/rtw89/mac.h | 1 +
drivers/net/wireless/realtek/rtw89/mac80211.c | 3 +++
drivers/net/wireless/realtek/rtw89/mac_be.c | 2 ++
drivers/net/wireless/realtek/rtw89/phy.c | 27 +++++++++++++++++++
drivers/net/wireless/realtek/rtw89/phy.h | 1 +
6 files changed, 36 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw89/mac.c b/drivers/net/wireless/realtek/rtw89/mac.c
index 234928613ef4..a292a14394b2 100644
--- a/drivers/net/wireless/realtek/rtw89/mac.c
+++ b/drivers/net/wireless/realtek/rtw89/mac.c
@@ -7319,6 +7319,8 @@ const struct rtw89_mac_gen_def rtw89_mac_gen_ax = {
},
.wow_ctrl = {.addr = R_AX_WOW_CTRL, .mask = B_AX_WOW_WOWEN,},
.agg_limit = {.addr = R_AX_AMPDU_AGG_LIMIT, .mask = B_AX_AMPDU_MAX_TIME_MASK,},
+ .ra_agg_limit = {.addr = R_AX_AMPDU_AGG_LIMIT,
+ .mask = B_AX_RA_TRY_RATE_AGG_LMT_MASK,},
.txcnt_limit = {.addr = R_AX_TXCNT, .mask = B_AX_L_TXCNT_LMT_MASK,},
.check_mac_en = rtw89_mac_check_mac_en_ax,
diff --git a/drivers/net/wireless/realtek/rtw89/mac.h b/drivers/net/wireless/realtek/rtw89/mac.h
index e6b715b95409..9c77bfaa34ee 100644
--- a/drivers/net/wireless/realtek/rtw89/mac.h
+++ b/drivers/net/wireless/realtek/rtw89/mac.h
@@ -1037,6 +1037,7 @@ struct rtw89_mac_gen_def {
struct rtw89_reg_def narrow_bw_ru_dis;
struct rtw89_reg_def wow_ctrl;
struct rtw89_reg_def agg_limit;
+ struct rtw89_reg_def ra_agg_limit;
struct rtw89_reg_def txcnt_limit;
int (*check_mac_en)(struct rtw89_dev *rtwdev, u8 band,
diff --git a/drivers/net/wireless/realtek/rtw89/mac80211.c b/drivers/net/wireless/realtek/rtw89/mac80211.c
index 1ef73bfc40d1..cd8e2c8de888 100644
--- a/drivers/net/wireless/realtek/rtw89/mac80211.c
+++ b/drivers/net/wireless/realtek/rtw89/mac80211.c
@@ -1005,6 +1005,8 @@ static int rtw89_ops_ampdu_action(struct ieee80211_hw *hw,
clear_bit(tid, rtwsta->ampdu_map);
rtw89_chip_h2c_ampdu_cmac_tbl(rtwdev, rtwvif, rtwsta);
ieee80211_stop_tx_ba_cb_irqsafe(vif, sta->addr, tid);
+ rtw89_leave_ps_mode(rtwdev);
+ rtw89_phy_ra_recalc_agg_limit(rtwdev);
break;
case IEEE80211_AMPDU_TX_OPERATIONAL:
set_bit(RTW89_TXQ_F_AMPDU, &rtwtxq->flags);
@@ -1013,6 +1015,7 @@ static int rtw89_ops_ampdu_action(struct ieee80211_hw *hw,
set_bit(tid, rtwsta->ampdu_map);
rtw89_leave_ps_mode(rtwdev);
rtw89_chip_h2c_ampdu_cmac_tbl(rtwdev, rtwvif, rtwsta);
+ rtw89_phy_ra_recalc_agg_limit(rtwdev);
break;
case IEEE80211_AMPDU_RX_START:
rtw89_chip_h2c_ba_cam(rtwdev, rtwsta, true, params);
diff --git a/drivers/net/wireless/realtek/rtw89/mac_be.c b/drivers/net/wireless/realtek/rtw89/mac_be.c
index ed1ea13bb98d..b9e8f4fa366b 100644
--- a/drivers/net/wireless/realtek/rtw89/mac_be.c
+++ b/drivers/net/wireless/realtek/rtw89/mac_be.c
@@ -3196,6 +3196,8 @@ const struct rtw89_mac_gen_def rtw89_mac_gen_be = {
},
.wow_ctrl = {.addr = R_BE_WOW_CTRL, .mask = B_BE_WOW_WOWEN,},
.agg_limit = {.addr = R_BE_AMPDU_AGG_LIMIT, .mask = B_BE_AMPDU_MAX_TIME_MASK,},
+ .ra_agg_limit = {.addr = R_BE_AMPDU_AGG_LIMIT,
+ .mask = B_BE_RA_TRY_RATE_AGG_LMT_MASK,},
.txcnt_limit = {.addr = R_BE_TXCNT, .mask = B_BE_L_TXCNT_LMT_MASK,},
.check_mac_en = rtw89_mac_check_mac_en_be,
diff --git a/drivers/net/wireless/realtek/rtw89/phy.c b/drivers/net/wireless/realtek/rtw89/phy.c
index 74f5d5562848..0fa4d8d791f1 100644
--- a/drivers/net/wireless/realtek/rtw89/phy.c
+++ b/drivers/net/wireless/realtek/rtw89/phy.c
@@ -775,6 +775,33 @@ void rtw89_phy_ra_assoc(struct rtw89_dev *rtwdev, struct rtw89_sta_link *rtwsta_
rtw89_fw_h2c_ra(rtwdev, ra, csi);
}
+void rtw89_phy_ra_recalc_agg_limit(struct rtw89_dev *rtwdev)
+{
+ const struct rtw89_mac_gen_def *mac = rtwdev->chip->mac_def;
+ const struct rtw89_reg_def *ra_limit = &mac->ra_agg_limit;
+ struct ieee80211_sta *sta;
+ struct rtw89_sta *rtwsta;
+ u16 agg_num = U16_MAX;
+ u8 tid;
+
+ for_each_station(sta, rtwdev->hw) {
+ rtwsta = sta_to_rtwsta(sta);
+
+ for_each_set_bit(tid, rtwsta->ampdu_map, IEEE80211_NUM_TIDS)
+ agg_num = min(agg_num, rtwsta->ampdu_params[tid].agg_num);
+ }
+
+ if (agg_num == U16_MAX)
+ agg_num = 0x3F;
+ else
+ agg_num = clamp(agg_num, 1, 256) - 1;
+
+ rtw89_write32_idx(rtwdev, ra_limit->addr, ra_limit->mask, agg_num, RTW89_MAC_0);
+ if (!rtwdev->dbcc_en)
+ return;
+ rtw89_write32_idx(rtwdev, ra_limit->addr, ra_limit->mask, agg_num, RTW89_MAC_1);
+}
+
u8 rtw89_phy_get_txsc(struct rtw89_dev *rtwdev,
const struct rtw89_chan *chan,
enum rtw89_bandwidth dbw)
diff --git a/drivers/net/wireless/realtek/rtw89/phy.h b/drivers/net/wireless/realtek/rtw89/phy.h
index 094c7e45f254..bde419edf744 100644
--- a/drivers/net/wireless/realtek/rtw89/phy.h
+++ b/drivers/net/wireless/realtek/rtw89/phy.h
@@ -1006,6 +1006,7 @@ void rtw89_phy_ra_update_sta(struct rtw89_dev *rtwdev, struct ieee80211_sta *sta
void rtw89_phy_ra_update_sta_link(struct rtw89_dev *rtwdev,
struct rtw89_sta_link *rtwsta_link,
u32 changed);
+void rtw89_phy_ra_recalc_agg_limit(struct rtw89_dev *rtwdev);
void rtw89_phy_rate_pattern_vif(struct rtw89_dev *rtwdev,
struct ieee80211_vif *vif,
const struct cfg80211_bitrate_mask *mask);
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 03/13] wifi: rtw89: mac: remove A-die off setting for RTL8852C and RTL8922A
From: Ping-Ke Shih @ 2026-03-10 8:01 UTC (permalink / raw)
To: linux-wireless; +Cc: timlee, phhuang, kevin_yang
In-Reply-To: <20260310080146.31113-1-pkshih@realtek.com>
Fix timing issue of A-die off followed by XTAL off. Otherwise, device might
get lost potentially.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/rtw8852c.c | 2 +-
drivers/net/wireless/realtek/rtw89/rtw8922a.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw89/rtw8852c.c b/drivers/net/wireless/realtek/rtw89/rtw8852c.c
index e62a7288c8aa..7ea0a8905282 100644
--- a/drivers/net/wireless/realtek/rtw89/rtw8852c.c
+++ b/drivers/net/wireless/realtek/rtw89/rtw8852c.c
@@ -463,7 +463,7 @@ static int rtw8852c_pwr_off_func(struct rtw89_dev *rtwdev)
else if (rtwdev->hci.type == RTW89_HCI_TYPE_USB)
rtw89_write32_clr(rtwdev, R_AX_SYS_PW_CTRL, B_AX_SOP_EDSWR);
- rtw89_write32_set(rtwdev, R_AX_SYS_PW_CTRL, B_AX_XTAL_OFF_A_DIE);
+ rtw89_write32_clr(rtwdev, R_AX_SYS_PW_CTRL, B_AX_XTAL_OFF_A_DIE);
rtw89_write32_set(rtwdev, R_AX_SYS_SWR_CTRL1, B_AX_SYM_CTRL_SPS_PWMFREQ);
rtw89_write32_mask(rtwdev, R_AX_SPS_DIG_ON_CTRL0,
B_AX_REG_ZCDC_H_MASK, 0x3);
diff --git a/drivers/net/wireless/realtek/rtw89/rtw8922a.c b/drivers/net/wireless/realtek/rtw89/rtw8922a.c
index 36ef36110602..a489aaf90f23 100644
--- a/drivers/net/wireless/realtek/rtw89/rtw8922a.c
+++ b/drivers/net/wireless/realtek/rtw89/rtw8922a.c
@@ -492,7 +492,7 @@ static int rtw8922a_pwr_off_func(struct rtw89_dev *rtwdev)
return ret;
rtw89_write32(rtwdev, R_BE_WLLPS_CTRL, 0x0000A1B2);
- rtw89_write32_set(rtwdev, R_BE_SYS_PW_CTRL, B_BE_XTAL_OFF_A_DIE);
+ rtw89_write32_clr(rtwdev, R_BE_SYS_PW_CTRL, B_BE_XTAL_OFF_A_DIE);
rtw89_write32_set(rtwdev, R_BE_SYS_PW_CTRL, B_BE_APFM_SWLPS);
rtw89_write32(rtwdev, R_BE_UDM1, 0);
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 02/13] wifi: rtw89: pci: update SER parameters for suspend/resume
From: Ping-Ke Shih @ 2026-03-10 8:01 UTC (permalink / raw)
To: linux-wireless; +Cc: timlee, phhuang, kevin_yang
In-Reply-To: <20260310080146.31113-1-pkshih@realtek.com>
In suspend mode, SER timer unit is different from normal mode. Set proper
value to prevent expected SER happened during suspend.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/pci.h | 1 +
drivers/net/wireless/realtek/rtw89/pci_be.c | 52 +++++++++++++++++++--
2 files changed, 50 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw89/pci.h b/drivers/net/wireless/realtek/rtw89/pci.h
index ccfa6d33623a..dc488d9a8884 100644
--- a/drivers/net/wireless/realtek/rtw89/pci.h
+++ b/drivers/net/wireless/realtek/rtw89/pci.h
@@ -1016,6 +1016,7 @@
#define B_BE_PL1_IGNORE_HOT_RST BIT(30)
#define B_BE_PL1_TIMER_UNIT_MASK GENMASK(19, 17)
#define PCIE_SER_TIMER_UNIT 0x2
+#define PCIE_SER_WOW_TIMER_UNIT 0x4
#define B_BE_PL1_TIMER_CLEAR BIT(0)
#define R_BE_REG_PL1_MASK 0x34B0
diff --git a/drivers/net/wireless/realtek/rtw89/pci_be.c b/drivers/net/wireless/realtek/rtw89/pci_be.c
index 114f40c6c31b..dea01d9e57fd 100644
--- a/drivers/net/wireless/realtek/rtw89/pci_be.c
+++ b/drivers/net/wireless/realtek/rtw89/pci_be.c
@@ -721,12 +721,24 @@ static int __maybe_unused rtw89_pci_suspend_be(struct device *dev)
{
struct ieee80211_hw *hw = dev_get_drvdata(dev);
struct rtw89_dev *rtwdev = hw->priv;
+ u32 val32;
rtw89_write32_set(rtwdev, R_BE_RSV_CTRL, B_BE_WLOCK_1C_BIT6);
rtw89_write32_set(rtwdev, R_BE_RSV_CTRL, B_BE_R_DIS_PRST);
rtw89_write32_clr(rtwdev, R_BE_RSV_CTRL, B_BE_WLOCK_1C_BIT6);
rtw89_write32_set(rtwdev, R_BE_PCIE_FRZ_CLK, B_BE_PCIE_FRZ_REG_RST);
- rtw89_write32_clr(rtwdev, R_BE_REG_PL1_MASK, B_BE_SER_PM_MASTER_IMR);
+
+ val32 = rtw89_read32(rtwdev, R_BE_SER_PL1_CTRL);
+ if (val32 & B_BE_PL1_SER_PL1_EN) {
+ val32 = u32_replace_bits(val32, PCIE_SER_WOW_TIMER_UNIT,
+ B_BE_PL1_TIMER_UNIT_MASK);
+ rtw89_write32(rtwdev, R_BE_SER_PL1_CTRL, val32);
+
+ if (rtwdev->chip->chip_id == RTL8922A)
+ rtw89_write32_clr(rtwdev, R_BE_REG_PL1_MASK,
+ B_BE_SER_PM_MASTER_IMR);
+ }
+
return 0;
}
@@ -735,12 +747,19 @@ static int __maybe_unused rtw89_pci_resume_be(struct device *dev)
struct ieee80211_hw *hw = dev_get_drvdata(dev);
struct rtw89_dev *rtwdev = hw->priv;
u32 polling;
+ u32 val32;
+ u16 val16;
int ret;
rtw89_write32_set(rtwdev, R_BE_RSV_CTRL, B_BE_WLOCK_1C_BIT6);
rtw89_write32_clr(rtwdev, R_BE_RSV_CTRL, B_BE_R_DIS_PRST);
rtw89_write32_clr(rtwdev, R_BE_RSV_CTRL, B_BE_WLOCK_1C_BIT6);
rtw89_write32_clr(rtwdev, R_BE_PCIE_FRZ_CLK, B_BE_PCIE_FRZ_REG_RST);
+
+ val32 = rtw89_read32(rtwdev, R_BE_SER_PL1_CTRL);
+ if (!(val32 & B_BE_PL1_SER_PL1_EN))
+ goto clear_phy_isr;
+
rtw89_write32_clr(rtwdev, R_BE_SER_PL1_CTRL, B_BE_PL1_SER_PL1_EN);
ret = read_poll_timeout_atomic(rtw89_read32, polling, !polling, 1, 1000,
@@ -748,8 +767,35 @@ static int __maybe_unused rtw89_pci_resume_be(struct device *dev)
if (ret)
rtw89_warn(rtwdev, "[ERR] PCIE SER clear polling fail\n");
- rtw89_write32_set(rtwdev, R_BE_SER_PL1_CTRL, B_BE_PL1_SER_PL1_EN);
- rtw89_write32_set(rtwdev, R_BE_REG_PL1_MASK, B_BE_SER_PM_MASTER_IMR);
+ if (rtwdev->chip->chip_id == RTL8922A)
+ rtw89_write32_set(rtwdev, R_BE_REG_PL1_MASK,
+ B_BE_SER_PM_MASTER_IMR | B_BE_SER_PCLKREQ_ACK_MASK);
+
+ val32 = rtw89_read32(rtwdev, R_BE_SER_PL1_CTRL);
+ val32 = u32_replace_bits(val32, PCIE_SER_TIMER_UNIT, B_BE_PL1_TIMER_UNIT_MASK);
+ val32 |= B_BE_PL1_SER_PL1_EN;
+ rtw89_write32(rtwdev, R_BE_SER_PL1_CTRL, val32);
+
+clear_phy_isr:
+ if (rtwdev->chip->chip_id == RTL8922D) {
+ val16 = rtw89_read16(rtwdev, RAC_DIRECT_OFFESET_L0_G2 +
+ RAC_ANA41 * RAC_MULT);
+ if (val16 & PHY_ERR_FLAG_EN) {
+ rtw89_write16_clr(rtwdev, RAC_DIRECT_OFFESET_L0_G2 +
+ RAC_ANA41 * RAC_MULT, PHY_ERR_FLAG_EN);
+ rtw89_write16_set(rtwdev, RAC_DIRECT_OFFESET_L0_G2 +
+ RAC_ANA41 * RAC_MULT, PHY_ERR_FLAG_EN);
+ }
+
+ val16 = rtw89_read16(rtwdev, RAC_DIRECT_OFFESET_L0_G1 +
+ RAC_ANA41 * RAC_MULT);
+ if (val16 & PHY_ERR_FLAG_EN) {
+ rtw89_write16_clr(rtwdev, RAC_DIRECT_OFFESET_L0_G1 +
+ RAC_ANA41 * RAC_MULT, PHY_ERR_FLAG_EN);
+ rtw89_write16_set(rtwdev, RAC_DIRECT_OFFESET_L0_G1 +
+ RAC_ANA41 * RAC_MULT, PHY_ERR_FLAG_EN);
+ }
+ }
rtw89_pci_basic_cfg(rtwdev, true);
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 01/13] wifi: rtw89: mac: finish active TX immediately without waiting for DMAC
From: Ping-Ke Shih @ 2026-03-10 8:01 UTC (permalink / raw)
To: linux-wireless; +Cc: timlee, phhuang, kevin_yang
In-Reply-To: <20260310080146.31113-1-pkshih@realtek.com>
Currently active TX only finishes after ensuring PCIE and DMAC become idle.
However, the waiting time might be long. Since the packet is already
transmitted over the air, update the registers to finish active TX
immediately, regardless of the PCIE/DMAC status.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/mac_be.c | 3 +++
drivers/net/wireless/realtek/rtw89/reg.h | 28 +++++++++++++++++++++
2 files changed, 31 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw89/mac_be.c b/drivers/net/wireless/realtek/rtw89/mac_be.c
index dc66b1ee851a..ed1ea13bb98d 100644
--- a/drivers/net/wireless/realtek/rtw89/mac_be.c
+++ b/drivers/net/wireless/realtek/rtw89/mac_be.c
@@ -1173,6 +1173,9 @@ static int scheduler_init_be(struct rtw89_dev *rtwdev, u8 mac_idx)
if (ret)
return ret;
+ reg = rtw89_mac_reg_by_idx(rtwdev, R_BE_MISC_1, mac_idx);
+ rtw89_write32_set(rtwdev, reg, B_BE_EN_TX_FINISH_PRD_RESP);
+
if (chip->chip_id == RTL8922D) {
reg = rtw89_mac_reg_by_idx(rtwdev, R_BE_SCH_EXT_CTRL, mac_idx);
rtw89_write32_set(rtwdev, reg, B_BE_CWCNT_PLUS_MODE);
diff --git a/drivers/net/wireless/realtek/rtw89/reg.h b/drivers/net/wireless/realtek/rtw89/reg.h
index 9b605617c3f0..66ed847c9009 100644
--- a/drivers/net/wireless/realtek/rtw89/reg.h
+++ b/drivers/net/wireless/realtek/rtw89/reg.h
@@ -6745,6 +6745,34 @@
#define B_BE_MUEDCA_EN_MASK GENMASK(1, 0)
#define B_BE_MUEDCA_EN_0 BIT(0)
+#define R_BE_MISC_1 0x1037C
+#define R_BE_MISC_1_C1 0x1437C
+#define B_BE_PPS_REMAIN_TIME_MODE BIT(31)
+#define B_BE_PPS_IDLE_SORT_EN BIT(30)
+#define B_BE_SR_TXOP_USE_SR_PERIOD_EN BIT(29)
+#define B_BE_SCH_CCA_PIFS_CLK_GATING_DIS BIT(28)
+#define B_BE_SR_TXOP_EN BIT(27)
+#define B_BE_SCH_ABORT_CNT_SIFS_EN BIT(26)
+#define B_BE_SCH_ABORT_CNT_TB_EN BIT(25)
+#define B_BE_SCH_ABORT_CNT_CTN_EN BIT(24)
+#define B_BE_SR_CCA_PER20_BITMAP_EN BIT(23)
+#define B_BE_SR_CCA_S80_EN BIT(22)
+#define B_BE_SR_CCA_S40_EN BIT(21)
+#define B_BE_SR_CCA_S20_EN BIT(20)
+#define B_BE_EN_TX_FINISH_PRD_RESP BIT(18)
+#define B_BE_RESP_TX_ABORT_NON_IDLE BIT(17)
+#define B_BE_RESP_TX_ABORT_QUICK_EN BIT(16)
+#define B_BE_PREBKF_CHK_LINK_BUSY BIT(15)
+#define B_BE_SCH_MSD_PRD_RST_EDCA_EN BIT(14)
+#define B_BE_LINK_BUSY_RST_EDCA_EN_MASK GENMASK(13, 12)
+#define B_BE_RX_TSFT_SYNC_BYPASS_FCS BIT(11)
+#define B_BE_RX_TSFT_DIFF_THD_MASK GENMASK(10, 8)
+#define B_BE_CAL_TBTT_OV_EN BIT(5)
+#define B_BE_SUBBCN_MS_CNT_MODE BIT(3)
+#define B_BE_CAL_ALWAYS_EN BIT(2)
+#define B_BE_SIFS_TIMER_AUTO_RST_EN BIT(1)
+#define B_BE_CHK_HAS_SIFS_TX_ABORT BIT(0)
+
#define R_BE_CTN_DRV_TXEN 0x10398
#define R_BE_CTN_DRV_TXEN_C1 0x14398
#define B_BE_CTN_TXEN_TWT_3 BIT(17)
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 00/13] wifi: rtw89: update hardware settings and tweak for MLO
From: Ping-Ke Shih @ 2026-03-10 8:01 UTC (permalink / raw)
To: linux-wireless; +Cc: timlee, phhuang, kevin_yang
Mainly, this patchset is to add hardware settings, and tweak code related
to hardware MLO mode value. Others are almost random fixes.
The first four patches are to configure hardware settings, which are
written according to internal patches.
Patches 5-8 are to refine hardware MLO mode.
Patch 9 is WoWLAN related, which is to add retry times to let WoWLAN
being reliable.
Patch 10 is to remove mutex lock from driver. Since driver has used
wiphy_lock, it should be not necessary.
Patch 11 is a workaround to deal with AP interoperability problem.
Patch 12 is to recalculate AMSDU length to improve performance.
The last patch is for firmware crash simulation.
Chin-Yen Lee (1):
wifi: rtw89: wow: add retry for ensuring packet are processed
Ping-Ke Shih (4):
wifi: rtw89: mac: finish active TX immediately without waiting for
DMAC
wifi: rtw89: pci: update SER parameters for suspend/resume
wifi: rtw89: mac: remove A-die off setting for RTL8852C and RTL8922A
wifi: rtw89: phy: limit AMPDU number for RA try rate
Po-Hao Huang (2):
wifi: rtw89: Drop malformed AMPDU frames with abnormal PN
wifi: rtw89: Recalculate station aggregates when AMSDU length changes
for MLO links
Zong-Zhe Yang (6):
wifi: rtw89: move disabling dynamic mechanism functions to core
wifi: rtw89: tweak settings of TX power and channel for Wi-Fi 7
wifi: rtw89: chan: simplify link handling related to ROC
wifi: rtw89: chan: recalc MLO DBCC mode based on current entity mode
wifi: rtw89: replace RF mutex with wiphy lock assertion
wifi: rtw89: debug: simulate Wi-Fi 7 SER L0/L1 without PS mode
drivers/net/wireless/realtek/rtw89/chan.c | 72 +++++----
drivers/net/wireless/realtek/rtw89/core.c | 150 +++++++++++++++++-
drivers/net/wireless/realtek/rtw89/core.h | 29 ++--
drivers/net/wireless/realtek/rtw89/debug.c | 45 ++----
drivers/net/wireless/realtek/rtw89/mac.c | 17 +-
drivers/net/wireless/realtek/rtw89/mac.h | 2 +
drivers/net/wireless/realtek/rtw89/mac80211.c | 6 +
drivers/net/wireless/realtek/rtw89/mac_be.c | 5 +
drivers/net/wireless/realtek/rtw89/pci.h | 1 +
drivers/net/wireless/realtek/rtw89/pci_be.c | 52 +++++-
drivers/net/wireless/realtek/rtw89/phy.c | 46 +++++-
drivers/net/wireless/realtek/rtw89/phy.h | 1 +
drivers/net/wireless/realtek/rtw89/reg.h | 28 ++++
drivers/net/wireless/realtek/rtw89/rtw8852c.c | 2 +-
drivers/net/wireless/realtek/rtw89/rtw8922a.c | 2 +-
drivers/net/wireless/realtek/rtw89/util.h | 17 ++
drivers/net/wireless/realtek/rtw89/wow.c | 2 +
drivers/net/wireless/realtek/rtw89/wow.h | 7 -
18 files changed, 386 insertions(+), 98 deletions(-)
base-commit: 039cd522dc70151da13329a5e3ae19b1736f468a
--
2.25.1
^ permalink raw reply
* Re: [PATCH 02/14] firmware: qcom: Add a generic PAS service
From: Trilok Soni @ 2026-03-10 7:33 UTC (permalink / raw)
To: Sumit Garg, Jeff Johnson
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, andersson,
konradybcio, robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo,
lumag, abhinav.kumar, jesszhan0024, marijn.suijten, airlied,
simona, vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, mukesh.ojha, pavan.kondeti, jorge.ramirez, tonyh,
vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, Sumit Garg
In-Reply-To: <aa5qdscMRq7abfwT@sumit-xelite>
On 3/8/2026 11:36 PM, Sumit Garg wrote:
> On Fri, Mar 06, 2026 at 02:00:48PM -0800, Jeff Johnson wrote:
>> On 3/6/2026 11:47 AM, Trilok Soni wrote:
>>> On 3/6/2026 2:50 AM, Sumit Garg wrote:
>>>> +MODULE_LICENSE("GPL");
>>>> +MODULE_AUTHOR("Sumit Garg <sumit.garg@oss.qualcomm.com>");
>>>
>>> What is the convention for Qualcomm authored drivers? In some drivers
>>> I find that Qualcomm doesn't add MODULE_AUTHOR. Can Qualcomm community
>>> clarify it here. I prefer consistency here for the Qualcomm submissions.
>>
>> WLAN team was told to not have MODULE_AUTHOR(), so ath10k was the last WLAN
>> driver that had a MODULE_AUTHOR() -- ath11k and ath12k do not have one.
>
> As I said in my other reply, it is quite subsystem specific.
>
>>
>> And in reality it is very rare for a given module, over time, to only have a
>> single author. The git history contains the real authorship. So just for that
>> reason I'd drop it.
>
> Sure, but you would like the driver author to be involved in future
> maintenence of the driver. In my experience that's how usually the kernel
> development process works. If a separate maintainer's entry is fine then I
> can switch to that instead.
I would prefer the maintainers entry than MODULE_AUTHOR.
---Trilok Soni
^ permalink raw reply
* Re: [PATCH 11/14] media: qcom: Switch to generic PAS TZ APIs
From: Sumit Garg @ 2026-03-10 5:04 UTC (permalink / raw)
To: Jorge Ramirez
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, andersson,
konradybcio, robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo,
lumag, abhinav.kumar, jesszhan0024, marijn.suijten, airlied,
simona, vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, mukesh.ojha, pavan.kondeti,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, Sumit Garg
In-Reply-To: <aa6O5tir4kVIe0eZ@trex>
On Mon, Mar 09, 2026 at 10:12:06AM +0100, Jorge Ramirez wrote:
> On 06/03/26 16:20:24, Sumit Garg wrote:
> > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >
> > Switch qcom media client drivers over to generic PAS TZ APIs. Generic PAS
> > TZ service allows to support multiple TZ implementation backends like QTEE
> > based SCM PAS service, OP-TEE based PAS service and any further future TZ
> > backend service.
> >
> > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > ---
> > drivers/media/platform/qcom/iris/iris_firmware.c | 9 +++++----
> > drivers/media/platform/qcom/venus/firmware.c | 11 ++++++-----
> > 2 files changed, 11 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/media/platform/qcom/iris/iris_firmware.c b/drivers/media/platform/qcom/iris/iris_firmware.c
> > index 5f408024e967..b3c5281aea91 100644
> > --- a/drivers/media/platform/qcom/iris/iris_firmware.c
> > +++ b/drivers/media/platform/qcom/iris/iris_firmware.c
> > @@ -4,6 +4,7 @@
> > */
> >
> > #include <linux/firmware.h>
> > +#include <linux/firmware/qcom/qcom_pas.h>
> > #include <linux/firmware/qcom/qcom_scm.h>
> > #include <linux/of_address.h>
> > #include <linux/of_reserved_mem.h>
> > @@ -79,7 +80,7 @@ int iris_fw_load(struct iris_core *core)
> > return -ENOMEM;
> > }
> >
> > - ret = qcom_scm_pas_auth_and_reset(core->iris_platform_data->pas_id);
> > + ret = qcom_pas_auth_and_reset(core->iris_platform_data->pas_id);
> > if (ret) {
> > dev_err(core->dev, "auth and reset failed: %d\n", ret);
> > return ret;
> > @@ -93,7 +94,7 @@ int iris_fw_load(struct iris_core *core)
> > cp_config->cp_nonpixel_size);
> > if (ret) {
> > dev_err(core->dev, "qcom_scm_mem_protect_video_var failed: %d\n", ret);
> > - qcom_scm_pas_shutdown(core->iris_platform_data->pas_id);
> > + qcom_pas_shutdown(core->iris_platform_data->pas_id);
> > return ret;
> > }
> > }
> > @@ -103,10 +104,10 @@ int iris_fw_load(struct iris_core *core)
> >
> > int iris_fw_unload(struct iris_core *core)
> > {
> > - return qcom_scm_pas_shutdown(core->iris_platform_data->pas_id);
> > + return qcom_pas_shutdown(core->iris_platform_data->pas_id);
> > }
> >
>
> are the calls to set_remote_state required?
> 0 is not the IRIS/VENUS remote processor.
>
> If it is legacy, maybe they can be phased out?
Vikash, Dikshita,
Do you know the background of this set_remote_state calls?
BTW, the scope of this patch-set is to not change existing subsystem
drivers behaviour but just to enable the generic PAS interface. So
any driver changes can be taken as a follow up work.
-Sumit
>
>
> > int iris_set_hw_state(struct iris_core *core, bool resume)
> > {
> > - return qcom_scm_set_remote_state(resume, 0);
> > + return qcom_pas_set_remote_state(resume, 0);
> > }
> > diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c
> > index 1de7436713ed..3a38ff985822 100644
> > --- a/drivers/media/platform/qcom/venus/firmware.c
> > +++ b/drivers/media/platform/qcom/venus/firmware.c
> > @@ -12,6 +12,7 @@
> > #include <linux/of_reserved_mem.h>
> > #include <linux/platform_device.h>
> > #include <linux/of_device.h>
> > +#include <linux/firmware/qcom/qcom_pas.h>
> > #include <linux/firmware/qcom/qcom_scm.h>
> > #include <linux/sizes.h>
> > #include <linux/soc/qcom/mdt_loader.h>
> > @@ -58,7 +59,7 @@ int venus_set_hw_state(struct venus_core *core, bool resume)
> > int ret;
> >
> > if (core->use_tz) {
> > - ret = qcom_scm_set_remote_state(resume, 0);
> > + ret = qcom_pas_set_remote_state(resume, 0);
> > if (resume && ret == -EINVAL)
> > ret = 0;
> > return ret;
>
^ permalink raw reply
* Re: [PATCH 02/14] firmware: qcom: Add a generic PAS service
From: Sumit Garg @ 2026-03-10 4:58 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, andersson,
konradybcio, robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo,
lumag, abhinav.kumar, jesszhan0024, marijn.suijten, airlied,
simona, vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, mukesh.ojha, pavan.kondeti,
jorge.ramirez, tonyh, vignesh.viswanathan, srinivas.kandagatla,
amirreza.zarrabi, jens.wiklander, op-tee, apurupa, skare,
Sumit Garg
In-Reply-To: <aa5z23EtUF9k1MTy@sumit-xelite>
On Mon, Mar 09, 2026 at 12:46:43PM +0530, Sumit Garg wrote:
> On Mon, Mar 09, 2026 at 08:10:02AM +0100, Krzysztof Kozlowski wrote:
> > On 09/03/2026 05:55, Sumit Garg wrote:
> > > On Fri, Mar 06, 2026 at 12:15:01PM +0100, Krzysztof Kozlowski wrote:
> > >> On 06/03/2026 11:50, Sumit Garg wrote:
> > >>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > >>>
> > >>> Qcom platforms has the legacy of using non-standard SCM calls
> > >>> splintered over the various kernel drivers. These SCM calls aren't
> > >>> compliant with the standard SMC calling conventions which is a
> > >>> prerequisite to enable migration to the FF-A specifications from
> > >>> Arm.
> > >>>
> > >>> OP-TEE as an alternative trusted OS to QTEE can't support these non-
> > >>> standard SCM calls. And even for newer architectures QTEE won't be able
> > >>> to support SCM calls either with FF-A requirements coming in. And with
> > >>> both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it
> > >>> makes further sense to reuse the TEE bus client drivers infrastructure.
> > >>>
> > >>> The added benefit of TEE bus infrastructure is that there is support
> > >>> for discoverable/enumerable services. With that client drivers don't
> > >>> have to manually invoke a special SCM call to know the service status.
> > >>>
> > >>> So enable the generic Peripheral Authentication Service (PAS) provided
> > >>> by the firmware. It acts as the common layer with different TZ
> > >>> backends plugged in whether it's an SCM implementation or a proper
> > >>> TEE bus based PAS service implementation.
> > >>>
> > >>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > >>> ---
> > >>> drivers/firmware/qcom/Kconfig | 8 +
> > >>> drivers/firmware/qcom/Makefile | 1 +
> > >>> drivers/firmware/qcom/qcom_pas.c | 295 +++++++++++++++++++++++++
> > >>> drivers/firmware/qcom/qcom_pas.h | 53 +++++
> > >>> include/linux/firmware/qcom/qcom_pas.h | 41 ++++
> > >>> 5 files changed, 398 insertions(+)
> > >>> create mode 100644 drivers/firmware/qcom/qcom_pas.c
> > >>> create mode 100644 drivers/firmware/qcom/qcom_pas.h
> > >>> create mode 100644 include/linux/firmware/qcom/qcom_pas.h
> > >>>
> > >>> diff --git a/drivers/firmware/qcom/Kconfig b/drivers/firmware/qcom/Kconfig
> > >>> index b477d54b495a..8653639d06db 100644
> > >>> --- a/drivers/firmware/qcom/Kconfig
> > >>> +++ b/drivers/firmware/qcom/Kconfig
> > >>> @@ -6,6 +6,14 @@
> > >>>
> > >>> menu "Qualcomm firmware drivers"
> > >>>
> > >>> +config QCOM_PAS
> > >>> + tristate
> > >>> + help
> > >>> + Enable the generic Peripheral Authentication Service (PAS) provided
> > >>> + by the firmware. It acts as the common layer with different TZ
> > >>> + backends plugged in whether it's an SCM implementation or a proper
> > >>> + TEE bus based PAS service implementation.
> > >>> +
> > >>> config QCOM_SCM
> > >>> select QCOM_TZMEM
> > >>> tristate
> > >>> diff --git a/drivers/firmware/qcom/Makefile b/drivers/firmware/qcom/Makefile
> > >>> index 0be40a1abc13..dc5ab45f906a 100644
> > >>> --- a/drivers/firmware/qcom/Makefile
> > >>> +++ b/drivers/firmware/qcom/Makefile
> > >>> @@ -8,3 +8,4 @@ qcom-scm-objs += qcom_scm.o qcom_scm-smc.o qcom_scm-legacy.o
> > >>> obj-$(CONFIG_QCOM_TZMEM) += qcom_tzmem.o
> > >>> obj-$(CONFIG_QCOM_QSEECOM) += qcom_qseecom.o
> > >>> obj-$(CONFIG_QCOM_QSEECOM_UEFISECAPP) += qcom_qseecom_uefisecapp.o
> > >>> +obj-$(CONFIG_QCOM_PAS) += qcom_pas.o
> > >>> diff --git a/drivers/firmware/qcom/qcom_pas.c b/drivers/firmware/qcom/qcom_pas.c
> > >>> new file mode 100644
> > >>> index 000000000000..dc04ff1b6be0
> > >>> --- /dev/null
> > >>> +++ b/drivers/firmware/qcom/qcom_pas.c
> > >>> @@ -0,0 +1,295 @@
> > >>> +// SPDX-License-Identifier: GPL-2.0
> > >>> +/*
> > >>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> > >>> + */
> > >>> +
> > >>> +#include <linux/delay.h>
> > >>> +#include <linux/device/devres.h>
> > >>> +#include <linux/firmware/qcom/qcom_pas.h>
> > >>> +#include <linux/of.h>
> > >>> +#include <linux/kernel.h>
> > >>> +#include <linux/module.h>
> > >>> +#include <linux/slab.h>
> > >>> +
> > >>> +#include "qcom_pas.h"
> > >>> +#include "qcom_scm.h"
> > >>> +
> > >>> +static struct qcom_pas_ops *ops_ptr;
> > >>
> > >> I really dislike this singleton design. And it is not even needed! If
> > >> you were storing here some allocated instance of SCM/PAS I could
> > >> understand, but singleton for only ops? Just implement one driver (so
> > >> SCM + whatever you have here) which will decide which ops to use,
> > >> through the probe. Really, this is neither needed nor beneficial.
> > >
> > > The motivation here is rather quite opposite to the single monolithic
> > > SCM driver design. The TZ services like PAS, ICE and so on are going to
> > > be implemented as independent discoverable devices on TEE bus which
> > > rather needs independent kernel client drivers.
> >
> > You still have singleton here. So if you think you do opposite to
> > singleton, then drop this static.
>
> Sure.
>
> >
> > >
> > > Also, the single driver probe can't work here since the SCM driver is
> > > bound to the platform bus whereas the TEE PAS driver is bound to the TEE
> > > bus. So there is a reason for the current design.
> > >
> > >>
> > >> It actually leads to more problems with this barrier handling, see
> > >> further comments.
> > >
> > > The barrier handling is something that I carried over from existing
> > > implmentation but I can't see a reason why it can't be replaced with a
> > > simple mutex. See diff below for mutex.
> > >
> > >> ...
> > >>
> > >>> +
> > >>> +/**
> > >>> + * qcom_pas_shutdown() - Shut down the remote processor
> > >>> + * @pas_id: peripheral authentication service id
> > >>> + *
> > >>> + * Returns 0 on success.
> > >>> + */
> > >>> +int qcom_pas_shutdown(u32 pas_id)
> > >>> +{
> > >>> + if (ops_ptr)
> > >>> + return ops_ptr->shutdown(ops_ptr->dev, pas_id);
> > >>> +
> > >>> + return -ENODEV;
> > >>> +}
> > >>> +EXPORT_SYMBOL_GPL(qcom_pas_shutdown);
> > >>> +
> > >>> +/**
> > >>> + * qcom_pas_supported() - Check if the peripheral authentication service is
> > >>> + * available for the given peripheral
> > >>> + * @pas_id: peripheral authentication service id
> > >>> + *
> > >>> + * Returns true if PAS is supported for this peripheral, otherwise false.
> > >>> + */
> > >>> +bool qcom_pas_supported(u32 pas_id)
> > >>> +{
> > >>> + if (ops_ptr)
> > >>
> > >> Lack of barriers here is not looking right. Existing/old code is not a
> > >> good example, I fixed only the obvious issue, but new code should be
> > >> correct from the beginning.
> > >>
> > >> Barriers should normally be always paired, unless you have some clear
> > >> path no concurrent execution can happen here, but such explanation is
> > >> missing, look:
> > >
> > > Actually concurrent execution is rather required here since TZ can
> > > support parallel bring-up of co-processors. The synchonization is only
> > > needed when PAS client drivers are performing a deferred probe waiting
> > > for the service to be available. However, you are right explanation is
> > > missing here which I will add in the next version.
> >
> > Hm? Existing comments are completely useless. Your comment said just
> > "barrier" basically... That's nothing useful.
>
> Agree, following is something I plan for v2 (using mutex instead of a
> barrier):
>
> /*
> * The ops mutex here is only intended to synchronize when client drivers
> * are in parallel checking for PAS service availability. However, once the
> * PAS backend becomes available, it is allowed for multiple threads to enter
> * TZ for parallel bringup of co-processors during boot.
> */
> static DEFINE_MUTEX(ops_mutex);
After more testing, it came out that there are corner cases where the
registered ops structure writes aren't visible to other cores. So indeed
a data barrier is needed instead of mutex. I will add relevant code
comments.
-Sumit
^ permalink raw reply
* [PATCH] wifi: ath12k: fix use-after-free of arvif in assign_vif_chanctx()
From: James Kim @ 2026-03-10 2:43 UTC (permalink / raw)
To: jjohnson
Cc: quic_srirrama, quic_ramess, kvalo, stable, linux-wireless, ath12k,
linux-kernel, James Kim
In ath12k_mac_op_assign_vif_chanctx(), arvif is obtained from
ath12k_mac_assign_link_vif() and then passed to
ath12k_mac_assign_vif_to_vdev(). Inside that function, when the
target radio (ar) differs from arvif->ar (multi-radio configuration),
the old arvif is freed via ath12k_mac_unassign_link_vif() -> kfree()
and a new one is allocated internally. However, only the ar pointer
is returned to the caller — the caller's arvif still points to the
freed memory.
The caller then continues to dereference this stale arvif pointer
at multiple locations (arvif->vdev_id, arvif->punct_bitmap,
arvif->is_started, etc.), resulting in a use-after-free.
Fix this by re-fetching arvif from ahvif->link[link_id] after
ath12k_mac_assign_vif_to_vdev() returns, since the link pointer
is always updated when a new arvif is assigned.
Fixes: 477cabfdb776 ("wifi: ath12k: modify link arvif creation and removal for MLO")
Cc: stable@vger.kernel.org
Signed-off-by: James Kim <james010kim@gmail.com>
---
drivers/net/wireless/ath/ath12k/mac.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index b253d1e3f405..ee44a8b59e9b 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -12069,6 +12069,17 @@ ath12k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
return -EINVAL;
}
+ /* ath12k_mac_assign_vif_to_vdev() may free and reassign arvif
+ * internally when switching radios (ar != arvif->ar). Refresh
+ * arvif from ahvif->link[].
+ */
+ arvif = wiphy_dereference(hw->wiphy, ahvif->link[link_id]);
+ if (!arvif) {
+ ath12k_hw_warn(ah, "failed to get arvif for link %u after vdev assignment",
+ link_id);
+ return -ENOENT;
+ }
+
ab = ar->ab;
ath12k_dbg(ab, ATH12K_DBG_MAC,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH ath-next] wifi: ath12k: avoid dynamic alloc when parsing wmi tb
From: Baochen Qiang @ 2026-03-10 2:05 UTC (permalink / raw)
To: Nicolas Escande, ath12k; +Cc: linux-wireless
In-Reply-To: <20260309152050.191820-1-nico.escande@gmail.com>
On 3/9/2026 11:20 PM, Nicolas Escande wrote:
> On each WMI message received from the hardware, we alloc a temporary array
> of WMI_TAG_MAX entries of type void *. This array is then populated with
> pointers of parsed structs depending on the WMI type, and then freed. This
> alloc can fail when memory pressure in the system is high enough.
>
> Given the fact that it is scheduled in softirq with the system_bh_wq, we
> should not be able to parse more than one WMI message per CPU at any time
>
> So instead lets move to a per cpu allocated array, stored in the struct
> ath12k_base, that is reused accros calls. The ath12k_wmi_tlv_parse_alloc()
> is also renamed into / merged with ath12k_wmi_tlv_parse() as it no longer
> allocs memory but returns the existing per-cpu one.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00218-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
> ---
> changes from RFC:
> - rebased on ath-next 8e0ab5b9adb7
> - converted missing call sites ath12k_wmi_obss_color_collision_event()
> & ath12k_wmi_pdev_temperature_event()
> - changed alloc order & cleanup path in ath12k_core_alloc() as it seems
> it confused people
> - used sizeof(*tb) in ath12k_wmi_tlv_parse()
>
> Note I did try to move to a DEFINE_PER_CPU() allocated array but the module
> loader complained about the array size. So I stuck to the per ab alloc.
> ---
> drivers/net/wireless/ath/ath12k/core.c | 7 +
> drivers/net/wireless/ath/ath12k/core.h | 2 +
> drivers/net/wireless/ath/ath12k/wmi.c | 178 ++++++-------------------
> 3 files changed, 51 insertions(+), 136 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
> index c31c47fb5a73..c1de70b24828 100644
> --- a/drivers/net/wireless/ath/ath12k/core.c
> +++ b/drivers/net/wireless/ath/ath12k/core.c
> @@ -2258,6 +2258,7 @@ void ath12k_core_free(struct ath12k_base *ab)
> timer_delete_sync(&ab->rx_replenish_retry);
> destroy_workqueue(ab->workqueue_aux);
> destroy_workqueue(ab->workqueue);
> + free_percpu(ab->wmi_tb);
> kfree(ab);
> }
>
> @@ -2270,6 +2271,11 @@ struct ath12k_base *ath12k_core_alloc(struct device *dev, size_t priv_size,
> if (!ab)
> return NULL;
>
> + ab->wmi_tb = __alloc_percpu(WMI_TAG_MAX * sizeof(void *),
> + __alignof__(void *));
> + if (!ab->wmi_tb)
> + goto err_sc_free;
> +
> init_completion(&ab->driver_recovery);
>
> ab->workqueue = create_singlethread_workqueue("ath12k_wq");
> @@ -2317,6 +2323,7 @@ struct ath12k_base *ath12k_core_alloc(struct device *dev, size_t priv_size,
> err_free_wq:
> destroy_workqueue(ab->workqueue);
> err_sc_free:
> + free_percpu(ab->wmi_tb);
> kfree(ab);
> return NULL;
> }
> diff --git a/drivers/net/wireless/ath/ath12k/core.h b/drivers/net/wireless/ath/ath12k/core.h
> index 59c193b24764..ebe7b94fd712 100644
> --- a/drivers/net/wireless/ath/ath12k/core.h
> +++ b/drivers/net/wireless/ath/ath12k/core.h
> @@ -19,6 +19,7 @@
> #include <linux/average.h>
> #include <linux/of.h>
> #include <linux/rhashtable.h>
> +#include <linux/percpu.h>
> #include "qmi.h"
> #include "htc.h"
> #include "wmi.h"
> @@ -937,6 +938,7 @@ struct ath12k_base {
> struct device *dev;
> struct ath12k_qmi qmi;
> struct ath12k_wmi_base wmi_ab;
> + void __percpu *wmi_tb;
any reason why my v1 suggestion is not considered?
instead of allocating it per device, how about making it global and define/allocate once
when loading driver. This way we may save some memory in case where more than one devices
get probed?
^ permalink raw reply
* RE: [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict)
From: Ping-Ke Shih @ 2026-03-10 2:02 UTC (permalink / raw)
To: LB F; +Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CALdGYqSQ1Ko2TTBhUizMu_FvLMUAuQfFrVwS10n_C-LSQJQQkQ@mail.gmail.com>
LB F <goainwo@gmail.com> wrote:
> Hi Ping-Ke,
>
> I am writing to formally report a critical bug that causes a hard
> system freeze on laptops equipped with the RTL8821CE WiFi module, and
> to propose solutions.
>
> Description:
> On an HP laptop equipped with a Realtek RTL8821CE 802.11ac PCIe
> adapter (PCI ID: 10ec:c821), the system experiences a hard lockup
> (complete freeze of the UI and kernel, sysrq doesn't work, requires
> holding the power button) when the WiFi adapter enters the power
> saving state.
>
> This issue occurs consistently across multiple Linux distributions and
> kernel versions (reproduced on upstream kernel 6.13 and 6.19-rc).
>
> Steps to Reproduce:
> 1. Use a system with RTL8821CE (pci:10ec:c821).
> 2. Ensure NetworkManager is configured with wifi.powersave = 3 (or
> power saving is enabled via TLP/iw).
> 3. Connect to a WiFi network and let the system idle.
> 4. The system will eventually freeze completely.
Can you dig kernel log (by netconsole or ramoops) if something useful?
I'd like to know this is hardware level freeze or kernel can capture
something wrong.
>
> Workarounds that successfully prevent the freeze:
> * Passing disable_lps_deep=y to rtw88_core.
> * Passing disable_aspm=y to rtw88_pci (or pcie_aspm=off).
> * Disabling WiFi power save via NetworkManager.
Are these totally needed to workaround the problem? Or disable_aspm is
enough?
I'd list them in order of power consumption impact: (the topmost is lower impact)
1. disable_aspm=y
2. disable_lps_deep=y
3. disable WiFi power save
If you can do experiments on your platform, we can be easier to decide
which workarounds are adopted.
>
> Technical Analysis:
> The root cause appears to be an unhandled race condition or hardware
> bug between the adapter's Low Power State (LPS) Deep mode
> (LPS_DEEP_MODE_LCLK) and the PCIe Active State Power Management (ASPM
> L1) mechanism.
>
> When the firmware drops into LPS_DEEP_MODE_LCLK concurrently with the
> PCIe bus entering ASPM L1, the chip fails to handle PCIe Wake
> signaling correctly. While there is an existing workaround in
> rtw_pci_napi_poll (pci.c:1806) that sets `rtwpci->rx_no_aspm = true`
> during NAPI poll for 8821CE, this polling wrapper is insufficient. The
> deadlock often occurs during idle states when polling isn't actively
> disabling ASPM, but the system suddenly needs to wake the radio.
`rtwpci->rx_no_aspm = true` was another workaround years ago on certain
platform. I'd say ASPM has many interoperability problems, even years ago.
But what does 'deadlock' mean? As I know NAPI poll is scheduled by ISR,
and going to receive packets. The rx_no_aspm workaround is to forcely turn
off ASPM during this period.
>
> Proposed Solutions:
> Given that LPS_DEEP_MODE_LCLK seems fundamentally unreliable on 8821ce
> PCIe variants when paired with standard Windows-era ASPM
> implementations on laptops (HP, Lenovo, ASUS are all affected), the
> most robust solution is to strip the unsupported deep sleep flag from
> the hardware spec.
>
> ```diff
> --- a/drivers/net/wireless/realtek/rtw88/rtw8821c.c
> +++ b/drivers/net/wireless/realtek/rtw88/rtw8821c.c
> @@ -1999,7 +1999,7 @@ struct rtw_chip_info rtw8821c_hw_spec = {
> .bt_supported = true,
> .fbtc_has_ext_ctrl = true,
> .coex_info_hw_supported = true,
> - .lps_deep_mode_supported = BIT(LPS_DEEP_MODE_LCLK),
> + .lps_deep_mode_supported = 0, /* Disabled due to ASPM L1 hard locks */
> .dpk_supported = true,
> .pstdma_type = COEX_PSTDMA_FORCE_LPSOFF,
> .bfee_support = false,
> ```
>
> Alternatively, a PCI Subsystem-based quirk should be introduced in
> rtw_pci_aspm_set() to refuse ASPM BIT_L1_SW_EN transitions for
> affected hardware IDs, similar to how CLKREQ issues are handled for
> 8822C via efuse->rfe_option.
I'd add a quirk to your platforms, so other platforms can still have
better power consumption.
>
> Cross-Reference Analysis of other RTL8821CE Bugs:
> After aggregating recent open bug reports for the 8821ce chip on
> Bugzilla (https://bugzilla.kernel.org), it is apparent that almost all
> of them are victims of the exact same underlying race condition.
> 1. Bug 215131: System freeze preceded by 'pci bus timeout, check dma
> status'. Workaround used: disable_aspm=1.
> 2. Bug 219830: Log shows 'firmware failed to leave lps state' and
> 'failed to send h2c command'. A direct smoking gun for LPS Deep mode
> freezing.
> 3. Bug 218697 & Bug 217491: Endless 'timed out to flush queue' floods.
> 4. Bug 217781 & Bug 216685: Random dropouts and low wireless speed.
>
> Given the volume and age of these unresolved reports, disabling
> .lps_deep_mode_supported (or restricting ASPM L1) specifically for
> 10ec:c821 is desperately needed.
>
> System Information:
> - Hardware: HP Notebook (SKU: P3S95EA#ACB, Family: 103C_5335KV)
> - CPU: Intel Core i3-5005U
> - WiFi PCI ID: 10ec:c821, Subsystem: 103c:831a
> - Kernel: 6.13 / 6.19
> - Driver module: rtw88_8821ce
>
> I am happy to test any patches provided or formally submit the patch
> above if maintainers agree it is the right approach. Thank you!
We have not modified RTL8821CE for a long time, so I'd add workaround
to specific platform as mentioned above.
Ping-Ke
^ permalink raw reply
* Re: [PATCHv2 wireless-next] wifi: brcmsmac: use FAM for debug code
From: Rosen Penev @ 2026-03-10 1:47 UTC (permalink / raw)
To: Julian Calaby
Cc: Arend van Spriel, linux-wireless,
open list:BROADCOM BRCM80211 IEEE802.11 WIRELESS DRIVERS,
open list:BROADCOM BRCM80211 IEEE802.11 WIRELESS DRIVERS,
open list
In-Reply-To: <CAGRGNgUsVxecZobcXvVwmaHD+QHmzp4qTPGSLOpJb6Uinrpa+w@mail.gmail.com>
On Mon, Mar 9, 2026 at 6:11 PM Julian Calaby <julian.calaby@gmail.com> wrote:
>
> Hi Arend,
>
> On Tue, Mar 10, 2026 at 8:59 AM Rosen Penev <rosenp@gmail.com> wrote:
> >
> > Debug code requires a separate allocation to duplicate a string. A FAM
> > allows properly sized allocation with a single kfree.
>
> Sorry Rosen for hijacking your patch here.
>
> With these changes, does allocating and copying the string really need
> to be behind a DEBUG ifdef?
I don't know. I didn't write this code.
>
> The allocation, copying and freeing of the memory isn't in a hot path,
> so allocating/freeing a couple more bytes shouldn't matter that much,
> which only leaves the memory footprint, which appears to be less than
> 10 bytes.
>
> Thanks,
>
> --
> Julian Calaby
>
> Email: julian.calaby@gmail.com
> Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCHv2 wireless-next] wifi: brcmsmac: use FAM for debug code
From: Julian Calaby @ 2026-03-10 1:11 UTC (permalink / raw)
To: Arend van Spriel
Cc: linux-wireless, Rosen Penev,
open list:BROADCOM BRCM80211 IEEE802.11 WIRELESS DRIVERS,
open list:BROADCOM BRCM80211 IEEE802.11 WIRELESS DRIVERS,
open list
In-Reply-To: <20260309215907.5789-1-rosenp@gmail.com>
Hi Arend,
On Tue, Mar 10, 2026 at 8:59 AM Rosen Penev <rosenp@gmail.com> wrote:
>
> Debug code requires a separate allocation to duplicate a string. A FAM
> allows properly sized allocation with a single kfree.
Sorry Rosen for hijacking your patch here.
With these changes, does allocating and copying the string really need
to be behind a DEBUG ifdef?
The allocation, copying and freeing of the memory isn't in a hot path,
so allocating/freeing a couple more bytes shouldn't matter that much,
which only leaves the memory footprint, which appears to be less than
10 bytes.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [BUG] wifi: mt76: mt7925u: probe with driver mt7925u failed with error -110
From: Nick @ 2026-03-10 0:30 UTC (permalink / raw)
To: Sean Wang
Cc: linux-wireless, Felix Fietkau, Lorenzo Bianconi, Ryder Lee,
Shayne Chen, Sean Wang, Deren Wu, Leon Yen
In-Reply-To: <CAGp9Lzp2s675kmTJG+iYgLXS=fjiD-JC6GYjom7i-bcWFDxWoQ@mail.gmail.com>
On Fri, Mar 6, 2026 at 6:46 PM Sean Wang <sean.wang@kernel.org> wrote:
>
> Hi Nick,
>
> Thanks for the detailed report this is very helpful. I don't have an
> MT7925 USB device to detail look into the issue, but based on the
> trace I wrote a small change to try a different MT7925 reset sequence.
> please help test.
>
> --- a/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
> @@ -234,6 +234,36 @@ int mt792xu_dma_init(struct mt792x_dev *dev, bool resume)
> }
> EXPORT_SYMBOL_GPL(mt792xu_dma_init);
>
> +static int mt7925u_wfsys_reset(struct mt792x_dev *dev)
> +{
> + u32 val;
> + int i;
> +
> +#define MT7925_CBTOP_RGU_WF_SUBSYS_RST 0x70028600
> +#define MT7925_WFSYS_SW_INIT_DONE_ADDR 0x184c1604
> +#define MT7925_WFSYS_SW_INIT_DONE 0x00001d1e
> +
> + val = mt792xu_uhw_rr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST);
> + val |= MT_CBTOP_RGU_WF_SUBSYS_RST_WF_WHOLE_PATH;
> + mt792xu_uhw_wr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST, val);
> +
> + msleep(20);
> +
> + val = mt792xu_uhw_rr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST);
> + val &= ~MT_CBTOP_RGU_WF_SUBSYS_RST_WF_WHOLE_PATH;
> + mt792xu_uhw_wr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST, val);
> +
> + for (i = 0; i < MT792x_WFSYS_INIT_RETRY_COUNT; i++) {
> + val = mt792xu_uhw_rr(&dev->mt76, MT7925_WFSYS_SW_INIT_DONE_ADDR);
> + if (val == MT7925_WFSYS_SW_INIT_DONE)
> + return 0;
> +
> + msleep(100);
> + }
> +
> + return -ETIMEDOUT;
> +}
> +
> int mt792xu_wfsys_reset(struct mt792x_dev *dev)
> {
> u32 val;
> @@ -241,6 +271,9 @@ int mt792xu_wfsys_reset(struct mt792x_dev *dev)
>
> mt792xu_epctl_rst_opt(dev, false);
>
> + if (is_mt7925(&dev->mt76))
> + return mt7925u_wfsys_reset(dev);
> +
> val = mt792xu_uhw_rr(&dev->mt76, MT_CBTOP_RGU_WF_SUBSYS_RST);
>
>
Sean,
Testing complete. Results are good. You can show the following:
Tested-by: Nick Morrow <morrownr@gmail.com>
Tested-by: Satadru Pramanik <satadru@gmail.com>
Thank you for working on this issue. If it is possible for your patch to go
directly in to be in one of the next rc's, that would be great and setting
it to backport would also be much appreciated.
Nick Morrow
> On Fri, Mar 6, 2026 at 1:24 PM Nick <morrownr@gmail.com> wrote:
> >
> > > > Reference: https://github.com/morrownr/USB-WiFi/issues/688#issuecomment-3999038526
> > > >
> > > > The above thread is rather lengthy as we have been working on this
> > > > issue since Dec. 25.
> > > >
> > > > Testing with a Netgear A9000 USB WiFi adapter (mt7925u driver). Kernel
> > > > 7.0 rc2 and a x86_64 system. Additional testing with older kernels was
> > > > also performed with the same results.
> > > >
> > > > Problem description:
> > > >
> > > > Cold boot shows the adapter coming up and operating normally.
> > > >
> > > > Removing the adapter from the USB port and replacing it shows the
> > > > adapter coming up and operating normally.
> > > >
> > > > A warm reboot does not provide a WiFi interface and shows the
> > > > following in the system log:
> > > >
> > > > mt7925u 2-3.2:1.0: probe with driver mt7925u failed with error -110
> > > >
> > > > Using the commands rmmod and modeprobe do not provide a WiFi interface.
> > > >
> > > > Thoughts: The problem likely is not the module teardown. The problem
> > > > seems to be that the firmware (or the mt7925u driver) leaves the
> > > > adapter in a strange state such that a power cycle of the adapter
> > > > hardware is needed before the mt7925u driver can properly initialize
> > > > it a second time.
> > > >
> > >
> > > Hi Nick,
> > >
> > > Could you enable debug logs and check whether the driver can still
> > > read the correct chip ID after a warm reboot, and at which step the
> > > initialization fails before the -110 error? Thanks for continuing to
> > > test and gather this useful information.
> > >
> > > Sean
> >
> > Hi Sean,
> >
> > Github user @exct has performed the testing requested and provides the
> > following report:
> >
> > mt7925u Probe Failure Debug Report
> > Adapter: Netgear A9000 (USB ID 0846:9072, MediaTek MT7925)
> > Kernel: 6.19.6-2-cachyos
> >
> > Summary
> > The driver can read the correct chip ID after a warm reload. The
> > failure occurs before firmware is loaded, inside
> > mt792xu_wfsys_reset(), which times out waiting for the WiFi subsystem
> > to reinitialize. -ETIMEDOUT (-110) is returned and the probe aborts.
> >
> > Findings
> >
> > Question: Chip ID readable after warm reload?
> > Answer: Yes — MT_HW_CHIPID = 0x7925, MT_HW_REV = 0x8a00
> >
> > Question: Which step fails?
> > Answer: mt792xu_wfsys_reset() — WFSYS_INIT_DONE never asserted
> >
> > Question: Does it reach mt792xu_mcu_power_on()?
> > Answer: No
> >
> > Question: Does it reach mt7925_run_firmware()?
> > Answer: No
> >
> > Probe Sequence Trace
> >
> > mt7925u_probe()
> > ├─ mt76_alloc_device() OK
> > ├─ __mt76u_init() OK
> > ├─ read MT_HW_CHIPID (0x70010200) → 0x00007925 ✓
> > ├─ read MT_HW_REV (0x70010204) → 0x00008a00 ✓
> > ├─ read MT_CONN_ON_MISC (0x7c0600f0) → 0x00000003 ← FW_N9_RDY is SET
> > ├─ enters mt792xu_wfsys_reset() ← triggered because FW_N9_RDY = 1
> > │ ├─ write MT_CBTOP_RGU_WF_SUBSYS_RST (assert reset)
> > │ ├─ write MT_CBTOP_RGU_WF_SUBSYS_RST (deassert reset)
> > │ ├─ poll MT_UDMA_CONN_INFRA_STATUS (0x74000a20) → 0x00000000
> > │ ├─ poll MT_UDMA_CONN_INFRA_STATUS (0x74000a20) → 0x00000000
> > │ └─ ... timeout after ~212 ms → return -ETIMEDOUT
> > └─ goto error: (mt76u_queues_deinit + mt76_free_device)
> >
> > Root Cause
> >
> > After rmmod, the firmware leaves FW_N9_RDY asserted in
> > MT_CONN_ON_MISC. On re-probe, the driver correctly detects this and
> > calls mt792xu_wfsys_reset() to recover. However, the WiFi subsystem
> > never signals completion — WFSYS_INIT_DONE in
> > MT_UDMA_CONN_INFRA_STATUS (reg 0x74000a20) stays 0x00000000 throughout
> > the retry loop. The subsystem is stuck in a state that the software
> > reset path cannot recover from. Only a full USB power cycle clears it.
> >
> > Hope this helps,
> >
> > Nick
^ permalink raw reply
* Re: [PATCH v1 0/8] Group QMI service IDs into the QMI header
From: Dmitry Baryshkov @ 2026-03-10 0:11 UTC (permalink / raw)
To: Daniel Lezcano
Cc: konradybcio, andersson, linux-kernel, Alex Elder, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jeff Johnson, Mathieu Poirier, Srinivas Kandagatla,
Jaroslav Kysela, Takashi Iwai, Kees Cook, Greg Kroah-Hartman,
Arnd Bergmann, Mark Brown, Wesley Cheng, netdev, linux-wireless,
ath10k, ath11k, ath12k, linux-arm-msm, linux-remoteproc,
linux-sound
In-Reply-To: <20260309230346.3584252-1-daniel.lezcano@oss.qualcomm.com>
On Tue, Mar 10, 2026 at 12:03:29AM +0100, Daniel Lezcano wrote:
> The different subsystems implementing the QMI service protocol are
> using their own definition of the service id. It is not a problem but
> it results on having those duplicated with different names but the
> same value and without consistency in their name.
>
> It makes more sense to unify their names and move the definitions in
> the QMI header file providing a consistent way to represent the
> supported protocols. Consequently the different drivers will use them
> instead of their own definition of the service id.
Also this looks like a first step towards providing qrtr service debugfs
in the kernel.
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v1 0/8] Group QMI service IDs into the QMI header
From: Daniel Lezcano @ 2026-03-10 0:09 UTC (permalink / raw)
To: Jeff Johnson, konradybcio, andersson
Cc: linux-kernel, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Jeff Johnson,
Mathieu Poirier, Srinivas Kandagatla, Jaroslav Kysela,
Takashi Iwai, Kees Cook, Greg Kroah-Hartman, Arnd Bergmann,
Mark Brown, Wesley Cheng, netdev, linux-wireless, ath10k, ath11k,
ath12k, linux-arm-msm, linux-remoteproc, linux-sound
In-Reply-To: <9cc7638f-1232-4cb7-b4d7-cdac66a2f4ba@oss.qualcomm.com>
On 3/10/26 00:50, Jeff Johnson wrote:
> On 3/9/2026 4:03 PM, Daniel Lezcano wrote:
>> The different subsystems implementing the QMI service protocol are
>> using their own definition of the service id. It is not a problem but
>> it results on having those duplicated with different names but the
>> same value and without consistency in their name.
>>
>> It makes more sense to unify their names and move the definitions in
[ ... ]
> prefix for wireless drivers is simply wifi: <driver>:
> so s/net: drivers: wireless:/wifi:/
Noted, thanks
>> remoteproc: qcom: Use the unified QMI service ID instead of defining
>> it locally
>> slimbus: qcom-ngd-ctrl: Use the unified QMI service ID instead of
>> defining it locally
>> soc: qcom: pdr: Use the unified QMI service ID instead of defining it
>> locally
>> ALSA: usb-audio: qcom: Use the unified QMI service ID instead of
>> defining it locally
>> samples: qmi: Use the unified QMI service ID instead of defining it
>> locally
>>
>> drivers/net/ipa/ipa_qmi.c | 6 ++----
>> drivers/net/wireless/ath/ath10k/qmi.c | 2 +-
>> drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h | 1 -
>> drivers/net/wireless/ath/ath11k/qmi.c | 2 +-
>> drivers/net/wireless/ath/ath11k/qmi.h | 1 -
>> drivers/net/wireless/ath/ath12k/qmi.c | 2 +-
>> drivers/net/wireless/ath/ath12k/qmi.h | 1 -
>> drivers/remoteproc/qcom_sysmon.c | 2 +-
>> drivers/slimbus/qcom-ngd-ctrl.c | 5 ++---
>> drivers/soc/qcom/pdr_interface.c | 4 ++--
>> drivers/soc/qcom/pdr_internal.h | 3 ---
>> drivers/soc/qcom/qcom_pd_mapper.c | 2 +-
>> include/linux/soc/qcom/qmi.h | 12 ++++++++++++
>> samples/qmi/qmi_sample_client.c | 2 +-
>> sound/usb/qcom/qc_audio_offload.c | 2 +-
>> sound/usb/qcom/usb_audio_qmi_v01.h | 1 -
>
> You are touching a lot of subsystems with a single series.
> How do you plan on having these land?
> Do you have a maintainer who will take all of these through their tree?
Yes I thought Bjorn or Konrad would take them with the acked-by from the
different subsystems
^ permalink raw reply
* Re: [PATCH v1 8/8] samples: qmi: Use the unified QMI service ID instead of defining it locally
From: Dmitry Baryshkov @ 2026-03-10 0:07 UTC (permalink / raw)
To: Daniel Lezcano
Cc: konradybcio, andersson, linux-kernel, Alex Elder, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jeff Johnson, Mathieu Poirier, Srinivas Kandagatla,
Jaroslav Kysela, Takashi Iwai, Kees Cook, Greg Kroah-Hartman,
Arnd Bergmann, Mark Brown, Wesley Cheng, netdev, linux-wireless,
ath10k, ath11k, ath12k, linux-arm-msm, linux-remoteproc,
linux-sound
In-Reply-To: <20260309230346.3584252-9-daniel.lezcano@oss.qualcomm.com>
On Tue, Mar 10, 2026 at 12:03:37AM +0100, Daniel Lezcano wrote:
> Instead of defining a local macro with a custom name for the QMI
> service identifier, use the one provided in qmi.h and remove the
> locally defined macro.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
> ---
> samples/qmi/qmi_sample_client.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v1 7/8] ALSA: usb-audio: qcom: Use the unified QMI service ID instead of defining it locally
From: Dmitry Baryshkov @ 2026-03-10 0:07 UTC (permalink / raw)
To: Daniel Lezcano
Cc: konradybcio, andersson, linux-kernel, Alex Elder, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jeff Johnson, Mathieu Poirier, Srinivas Kandagatla,
Jaroslav Kysela, Takashi Iwai, Kees Cook, Greg Kroah-Hartman,
Arnd Bergmann, Mark Brown, Wesley Cheng, netdev, linux-wireless,
ath10k, ath11k, ath12k, linux-arm-msm, linux-remoteproc,
linux-sound, Erick Karanja
In-Reply-To: <20260309230346.3584252-8-daniel.lezcano@oss.qualcomm.com>
On Tue, Mar 10, 2026 at 12:03:36AM +0100, Daniel Lezcano wrote:
> Instead of defining a local macro with a custom name for the QMI
> service identifier, use the one provided in qmi.h and remove the
> locally defined macro.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
> ---
> sound/usb/qcom/qc_audio_offload.c | 2 +-
> sound/usb/qcom/usb_audio_qmi_v01.h | 1 -
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v1 6/8] soc: qcom: pdr: Use the unified QMI service ID instead of defining it locally
From: Dmitry Baryshkov @ 2026-03-10 0:06 UTC (permalink / raw)
To: Daniel Lezcano
Cc: konradybcio, andersson, linux-kernel, Alex Elder, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jeff Johnson, Mathieu Poirier, Srinivas Kandagatla,
Jaroslav Kysela, Takashi Iwai, Kees Cook, Greg Kroah-Hartman,
Arnd Bergmann, Mark Brown, Wesley Cheng, netdev, linux-wireless,
ath10k, ath11k, ath12k, linux-arm-msm, linux-remoteproc,
linux-sound
In-Reply-To: <20260309230346.3584252-7-daniel.lezcano@oss.qualcomm.com>
On Tue, Mar 10, 2026 at 12:03:35AM +0100, Daniel Lezcano wrote:
> Instead of defining a local macro with a custom name for the QMI
> service identifier, use the one provided in qmi.h and remove the
> locally defined macro.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
> ---
> drivers/soc/qcom/pdr_interface.c | 4 ++--
> drivers/soc/qcom/pdr_internal.h | 3 ---
> drivers/soc/qcom/qcom_pd_mapper.c | 2 +-
> 3 files changed, 3 insertions(+), 6 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v1 5/8] slimbus: qcom-ngd-ctrl: Use the unified QMI service ID instead of defining it locally
From: Dmitry Baryshkov @ 2026-03-10 0:06 UTC (permalink / raw)
To: Daniel Lezcano
Cc: konradybcio, andersson, linux-kernel, Alex Elder, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jeff Johnson, Mathieu Poirier, Srinivas Kandagatla,
Jaroslav Kysela, Takashi Iwai, Kees Cook, Greg Kroah-Hartman,
Arnd Bergmann, Mark Brown, Wesley Cheng, netdev, linux-wireless,
ath10k, ath11k, ath12k, linux-arm-msm, linux-remoteproc,
linux-sound
In-Reply-To: <20260309230346.3584252-6-daniel.lezcano@oss.qualcomm.com>
On Tue, Mar 10, 2026 at 12:03:34AM +0100, Daniel Lezcano wrote:
> Instead of defining a local macro with a custom name for the QMI
> service identifier, use the one provided in qmi.h and remove the
> locally defined macro.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
> ---
> drivers/slimbus/qcom-ngd-ctrl.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v1 4/8] remoteproc: qcom: Use the unified QMI service ID instead of defining it locally
From: Dmitry Baryshkov @ 2026-03-10 0:05 UTC (permalink / raw)
To: Daniel Lezcano
Cc: konradybcio, andersson, linux-kernel, Alex Elder, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jeff Johnson, Mathieu Poirier, Srinivas Kandagatla,
Jaroslav Kysela, Takashi Iwai, Kees Cook, Greg Kroah-Hartman,
Arnd Bergmann, Mark Brown, Wesley Cheng, netdev, linux-wireless,
ath10k, ath11k, ath12k, linux-arm-msm, linux-remoteproc,
linux-sound
In-Reply-To: <20260309230346.3584252-5-daniel.lezcano@oss.qualcomm.com>
On Tue, Mar 10, 2026 at 12:03:33AM +0100, Daniel Lezcano wrote:
> Instead of defining a local macro with a custom name for the QMI
> service identifier, use the one provided in qmi.h and remove the
> locally defined macro.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
> ---
> drivers/remoteproc/qcom_sysmon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox