* [PATCH iwlwifi 3/3] wifi: cfg80211: ignore link disabled flag from userspace
From: Miri Korenblit @ 2026-01-18 7:51 UTC (permalink / raw)
To: linux-wireless; +Cc: Benjamin Berg, Johannes Berg, Ilan Peer
In-Reply-To: <20260118075115.808517-1-miriam.rachel.korenblit@intel.com>
From: Benjamin Berg <benjamin.berg@intel.com>
When the AP has an advertised TID to Link Mapping (TTLM) it shall
include the element in the association response. As such, when this
element is present it needs to be used for the currently dormant links.
See Draft P802.11REVmf_D1.0 section 35.3.7.2.3 ("Negotiation of TTLM")
for the details. The flag is also not usable in case userspace wants to
specify a negotiated TTLM during association.
Note that for the link reconfiguration case, mac80211 did not use the
information. Draft P802.11REVmf_D1.0 states in section 35.3.6.4 ("Link
reconfiguration to the setup links) that we "shall operate with all the
TIDs mapped to the newly added links ..."
All this means that the flag is not needed. The implementation should
parse the information from the association response.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
include/net/cfg80211.h | 3 ---
include/uapi/linux/nl80211.h | 5 +++--
net/wireless/nl80211.c | 10 ----------
3 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 899f267b7cf9..2900202588a5 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3221,8 +3221,6 @@ struct cfg80211_auth_request {
* if this is %NULL for a link, that link is not requested
* @elems: extra elements for the per-STA profile for this link
* @elems_len: length of the elements
- * @disabled: If set this link should be included during association etc. but it
- * should not be used until enabled by the AP MLD.
* @error: per-link error code, must be <= 0. If there is an error, then the
* operation as a whole must fail.
*/
@@ -3230,7 +3228,6 @@ struct cfg80211_assoc_link {
struct cfg80211_bss *bss;
const u8 *elems;
size_t elems_len;
- bool disabled;
int error;
};
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 8134f10e4e6c..8433bac48112 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2880,8 +2880,9 @@ enum nl80211_commands {
* index. If the userspace includes more RNR elements than number of
* MBSSID elements then these will be added in every EMA beacon.
*
- * @NL80211_ATTR_MLO_LINK_DISABLED: Flag attribute indicating that the link is
- * disabled.
+ * @NL80211_ATTR_MLO_LINK_DISABLED: Unused. It was used to indicate that a link
+ * is disabled during association. However, the AP will send the
+ * information by including a TTLM in the association response.
*
* @NL80211_ATTR_BSS_DUMP_INCLUDE_USE_DATA: Include BSS usage data, i.e.
* include BSSes that can only be used in restricted scenarios and/or
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index c961cd42a832..03efd45c007f 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -12241,9 +12241,6 @@ static int nl80211_process_links(struct cfg80211_registered_device *rdev,
return -EINVAL;
}
}
-
- links[link_id].disabled =
- nla_get_flag(attrs[NL80211_ATTR_MLO_LINK_DISABLED]);
}
return 0;
@@ -12423,13 +12420,6 @@ static int nl80211_associate(struct sk_buff *skb, struct genl_info *info)
goto free;
}
- if (req.links[req.link_id].disabled) {
- GENL_SET_ERR_MSG(info,
- "cannot have assoc link disabled");
- err = -EINVAL;
- goto free;
- }
-
if (info->attrs[NL80211_ATTR_ASSOC_MLD_EXT_CAPA_OPS])
req.ext_mld_capa_ops =
nla_get_u16(info->attrs[NL80211_ATTR_ASSOC_MLD_EXT_CAPA_OPS]);
--
2.34.1
^ permalink raw reply related
* [PATCH iwlwifi 2/3] wifi: mac80211: apply advertised TTLM from association response
From: Miri Korenblit @ 2026-01-18 7:51 UTC (permalink / raw)
To: linux-wireless; +Cc: Benjamin Berg
In-Reply-To: <20260118075115.808517-1-miriam.rachel.korenblit@intel.com>
From: Benjamin Berg <benjamin.berg@intel.com>
When the AP has a disabled link that the station can include in the
association, the fact that the link is dormant needs to be advertised
in the TID to Link Mapping (TTLM). Section 35.3.7.2.3 ("Negotiation of
TTLM") of Draft P802.11REVmf_D1.0 also states that the mapping needs to
be included in the association response frame.
As such, we can simply rely on the TTLM from the association response.
Before this change mac80211 would not properly track that an advertised
TTLM was effectively active, resulting in it not enabling the link once
it became available again.
For the link reconfiguration case, the data was not used at all. This
behaviour is actually correct because Draft P802.11REVmf_D1.0 states in
section 35.3.6.4 that we "shall operate with all the TIDs mapped to the
newly added links ..."
Fixes: 6d543b34dbcf ("wifi: mac80211: Support disabled links during association")
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
net/mac80211/ieee80211_i.h | 2 -
net/mac80211/mlme.c | 216 ++++++++++++++++++++-----------------
2 files changed, 119 insertions(+), 99 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 9d9313eee59f..bd573f8e61fb 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -451,8 +451,6 @@ struct ieee80211_mgd_assoc_data {
struct ieee80211_conn_settings conn;
u16 status;
-
- bool disabled;
} link[IEEE80211_MLD_MAX_NUM_LINKS];
u8 ap_addr[ETH_ALEN] __aligned(2);
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 3f6bbe4e0175..b72345c779c0 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -6161,6 +6161,98 @@ static bool ieee80211_get_dtim(const struct cfg80211_bss_ies *ies,
return true;
}
+static u16 ieee80211_get_ttlm(u8 bm_size, u8 *data)
+{
+ if (bm_size == 1)
+ return *data;
+
+ return get_unaligned_le16(data);
+}
+
+static int
+ieee80211_parse_adv_t2l(struct ieee80211_sub_if_data *sdata,
+ const struct ieee80211_ttlm_elem *ttlm,
+ struct ieee80211_adv_ttlm_info *ttlm_info)
+{
+ /* The element size was already validated in
+ * ieee80211_tid_to_link_map_size_ok()
+ */
+ u8 control, link_map_presence, map_size, tid;
+ u8 *pos;
+
+ memset(ttlm_info, 0, sizeof(*ttlm_info));
+ pos = (void *)ttlm->optional;
+ control = ttlm->control;
+
+ if ((control & IEEE80211_TTLM_CONTROL_DIRECTION) !=
+ IEEE80211_TTLM_DIRECTION_BOTH) {
+ sdata_info(sdata, "Invalid advertised T2L map direction\n");
+ return -EINVAL;
+ }
+
+ link_map_presence = *pos;
+ pos++;
+
+ if (control & IEEE80211_TTLM_CONTROL_SWITCH_TIME_PRESENT) {
+ ttlm_info->switch_time = get_unaligned_le16(pos);
+
+ /* Since ttlm_info->switch_time == 0 means no switch time, bump
+ * it by 1.
+ */
+ if (!ttlm_info->switch_time)
+ ttlm_info->switch_time = 1;
+
+ pos += 2;
+ }
+
+ if (control & IEEE80211_TTLM_CONTROL_EXPECTED_DUR_PRESENT) {
+ ttlm_info->duration = pos[0] | pos[1] << 8 | pos[2] << 16;
+ pos += 3;
+ }
+
+ if (control & IEEE80211_TTLM_CONTROL_DEF_LINK_MAP) {
+ ttlm_info->map = 0xffff;
+ return 0;
+ }
+
+ if (control & IEEE80211_TTLM_CONTROL_LINK_MAP_SIZE)
+ map_size = 1;
+ else
+ map_size = 2;
+
+ /* According to Draft P802.11be_D3.0 clause 35.3.7.1.7, an AP MLD shall
+ * not advertise a TID-to-link mapping that does not map all TIDs to the
+ * same link set, reject frame if not all links have mapping
+ */
+ if (link_map_presence != 0xff) {
+ sdata_info(sdata,
+ "Invalid advertised T2L mapping presence indicator\n");
+ return -EINVAL;
+ }
+
+ ttlm_info->map = ieee80211_get_ttlm(map_size, pos);
+ if (!ttlm_info->map) {
+ sdata_info(sdata,
+ "Invalid advertised T2L map for TID 0\n");
+ return -EINVAL;
+ }
+
+ pos += map_size;
+
+ for (tid = 1; tid < 8; tid++) {
+ u16 map = ieee80211_get_ttlm(map_size, pos);
+
+ if (map != ttlm_info->map) {
+ sdata_info(sdata, "Invalid advertised T2L map for tid %d\n",
+ tid);
+ return -EINVAL;
+ }
+
+ pos += map_size;
+ }
+ return 0;
+}
+
static bool ieee80211_assoc_success(struct ieee80211_sub_if_data *sdata,
struct ieee80211_mgmt *mgmt,
struct ieee802_11_elems *elems,
@@ -6192,8 +6284,6 @@ static bool ieee80211_assoc_success(struct ieee80211_sub_if_data *sdata,
continue;
valid_links |= BIT(link_id);
- if (assoc_data->link[link_id].disabled)
- dormant_links |= BIT(link_id);
if (link_id != assoc_data->assoc_link_id) {
err = ieee80211_sta_allocate_link(sta, link_id);
@@ -6202,6 +6292,33 @@ static bool ieee80211_assoc_success(struct ieee80211_sub_if_data *sdata,
}
}
+ /*
+ * We do not support setting a negotiated TTLM during
+ * association. As such, we can assume that if there is a TTLM,
+ * then it is the currently active advertised TTLM.
+ * In that case, there must be exactly one TTLM that does not
+ * have a switch time set. This mapping should also leave us
+ * with at least one usable link.
+ */
+ if (elems->ttlm_num > 1) {
+ sdata_info(sdata,
+ "More than one advertised TTLM in association response\n");
+ goto out_err;
+ } else if (elems->ttlm_num == 1) {
+ if (ieee80211_parse_adv_t2l(sdata, elems->ttlm[0],
+ &sdata->u.mgd.ttlm_info) ||
+ sdata->u.mgd.ttlm_info.switch_time != 0 ||
+ !(valid_links & sdata->u.mgd.ttlm_info.map)) {
+ sdata_info(sdata,
+ "Invalid advertised TTLM in association response\n");
+ goto out_err;
+ }
+
+ sdata->u.mgd.ttlm_info.active = true;
+ dormant_links =
+ valid_links & ~sdata->u.mgd.ttlm_info.map;
+ }
+
ieee80211_vif_set_links(sdata, valid_links, dormant_links);
}
@@ -6992,98 +7109,6 @@ static void ieee80211_tid_to_link_map_work(struct wiphy *wiphy,
sdata->u.mgd.ttlm_info.switch_time = 0;
}
-static u16 ieee80211_get_ttlm(u8 bm_size, u8 *data)
-{
- if (bm_size == 1)
- return *data;
- else
- return get_unaligned_le16(data);
-}
-
-static int
-ieee80211_parse_adv_t2l(struct ieee80211_sub_if_data *sdata,
- const struct ieee80211_ttlm_elem *ttlm,
- struct ieee80211_adv_ttlm_info *ttlm_info)
-{
- /* The element size was already validated in
- * ieee80211_tid_to_link_map_size_ok()
- */
- u8 control, link_map_presence, map_size, tid;
- u8 *pos;
-
- memset(ttlm_info, 0, sizeof(*ttlm_info));
- pos = (void *)ttlm->optional;
- control = ttlm->control;
-
- if ((control & IEEE80211_TTLM_CONTROL_DIRECTION) !=
- IEEE80211_TTLM_DIRECTION_BOTH) {
- sdata_info(sdata, "Invalid advertised T2L map direction\n");
- return -EINVAL;
- }
-
- link_map_presence = *pos;
- pos++;
-
- if (control & IEEE80211_TTLM_CONTROL_SWITCH_TIME_PRESENT) {
- ttlm_info->switch_time = get_unaligned_le16(pos);
-
- /* Since ttlm_info->switch_time == 0 means no switch time, bump
- * it by 1.
- */
- if (!ttlm_info->switch_time)
- ttlm_info->switch_time = 1;
-
- pos += 2;
- }
-
- if (control & IEEE80211_TTLM_CONTROL_EXPECTED_DUR_PRESENT) {
- ttlm_info->duration = pos[0] | pos[1] << 8 | pos[2] << 16;
- pos += 3;
- }
-
- if (control & IEEE80211_TTLM_CONTROL_DEF_LINK_MAP) {
- ttlm_info->map = 0xffff;
- return 0;
- }
-
- if (control & IEEE80211_TTLM_CONTROL_LINK_MAP_SIZE)
- map_size = 1;
- else
- map_size = 2;
-
- /* According to Draft P802.11be_D3.0 clause 35.3.7.1.7, an AP MLD shall
- * not advertise a TID-to-link mapping that does not map all TIDs to the
- * same link set, reject frame if not all links have mapping
- */
- if (link_map_presence != 0xff) {
- sdata_info(sdata,
- "Invalid advertised T2L mapping presence indicator\n");
- return -EINVAL;
- }
-
- ttlm_info->map = ieee80211_get_ttlm(map_size, pos);
- if (!ttlm_info->map) {
- sdata_info(sdata,
- "Invalid advertised T2L map for TID 0\n");
- return -EINVAL;
- }
-
- pos += map_size;
-
- for (tid = 1; tid < 8; tid++) {
- u16 map = ieee80211_get_ttlm(map_size, pos);
-
- if (map != ttlm_info->map) {
- sdata_info(sdata, "Invalid advertised T2L map for tid %d\n",
- tid);
- return -EINVAL;
- }
-
- pos += map_size;
- }
- return 0;
-}
-
static void ieee80211_process_adv_ttlm(struct ieee80211_sub_if_data *sdata,
struct ieee802_11_elems *elems,
u64 beacon_ts)
@@ -9740,7 +9765,6 @@ int ieee80211_mgd_assoc(struct ieee80211_sub_if_data *sdata,
req, true, i,
&assoc_data->link[i].conn);
assoc_data->link[i].bss = link_cbss;
- assoc_data->link[i].disabled = req->links[i].disabled;
if (!bss->uapsd_supported)
uapsd_supported = false;
@@ -10722,8 +10746,6 @@ int ieee80211_mgd_assoc_ml_reconf(struct ieee80211_sub_if_data *sdata,
&data->link[link_id].conn);
data->link[link_id].bss = link_cbss;
- data->link[link_id].disabled =
- req->add_links[link_id].disabled;
data->link[link_id].elems =
(u8 *)req->add_links[link_id].elems;
data->link[link_id].elems_len =
--
2.34.1
^ permalink raw reply related
* [PATCH iwlwifi 1/3] wifi: mac80211: parse all TTLM entries
From: Miri Korenblit @ 2026-01-18 7:51 UTC (permalink / raw)
To: linux-wireless; +Cc: Benjamin Berg, Johannes Berg, Ilan Peer
In-Reply-To: <20260118075115.808517-1-miriam.rachel.korenblit@intel.com>
From: Benjamin Berg <benjamin.berg@intel.com>
For the follow up patch, we need to properly parse TTLM entries that do
not have a switch time. Change the logic so that ieee80211_parse_adv_t2l
returns usable values in all non-error cases. Before the values filled
in were technically incorrect but enough for ieee80211_process_adv_ttlm.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
net/mac80211/mlme.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index ad53dedd929c..3f6bbe4e0175 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -7015,10 +7015,6 @@ ieee80211_parse_adv_t2l(struct ieee80211_sub_if_data *sdata,
pos = (void *)ttlm->optional;
control = ttlm->control;
- if ((control & IEEE80211_TTLM_CONTROL_DEF_LINK_MAP) ||
- !(control & IEEE80211_TTLM_CONTROL_SWITCH_TIME_PRESENT))
- return 0;
-
if ((control & IEEE80211_TTLM_CONTROL_DIRECTION) !=
IEEE80211_TTLM_DIRECTION_BOTH) {
sdata_info(sdata, "Invalid advertised T2L map direction\n");
@@ -7028,21 +7024,28 @@ ieee80211_parse_adv_t2l(struct ieee80211_sub_if_data *sdata,
link_map_presence = *pos;
pos++;
- ttlm_info->switch_time = get_unaligned_le16(pos);
+ if (control & IEEE80211_TTLM_CONTROL_SWITCH_TIME_PRESENT) {
+ ttlm_info->switch_time = get_unaligned_le16(pos);
- /* Since ttlm_info->switch_time == 0 means no switch time, bump it
- * by 1.
- */
- if (!ttlm_info->switch_time)
- ttlm_info->switch_time = 1;
+ /* Since ttlm_info->switch_time == 0 means no switch time, bump
+ * it by 1.
+ */
+ if (!ttlm_info->switch_time)
+ ttlm_info->switch_time = 1;
- pos += 2;
+ pos += 2;
+ }
if (control & IEEE80211_TTLM_CONTROL_EXPECTED_DUR_PRESENT) {
ttlm_info->duration = pos[0] | pos[1] << 8 | pos[2] << 16;
pos += 3;
}
+ if (control & IEEE80211_TTLM_CONTROL_DEF_LINK_MAP) {
+ ttlm_info->map = 0xffff;
+ return 0;
+ }
+
if (control & IEEE80211_TTLM_CONTROL_LINK_MAP_SIZE)
map_size = 1;
else
--
2.34.1
^ permalink raw reply related
* [PATCH iwlwifi 0/3] wifi: cfg80211/mac80211: apply advertised TTLM from association response
From: Miri Korenblit @ 2026-01-18 7:51 UTC (permalink / raw)
To: linux-wireless
This series implements applying advertized TTLM from the association
response. This required a preparation patch to parse a TTLM entry
without a switch time,
and is followed by a cleanup patch that removes the no longer needed link
disabled flag.
Benjamin Berg (3):
wifi: mac80211: parse all TTLM entries
wifi: mac80211: apply advertised TTLM from association response
wifi: cfg80211: ignore link disabled flag from userspace
include/net/cfg80211.h | 3 -
include/uapi/linux/nl80211.h | 5 +-
net/mac80211/ieee80211_i.h | 2 -
net/mac80211/mlme.c | 213 +++++++++++++++++++----------------
net/wireless/nl80211.c | 10 --
5 files changed, 122 insertions(+), 111 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH iwlwifi] wifi: mac80211: don't increment crypto_tx_tailroom_needed_cnt twice
From: Miri Korenblit @ 2026-01-18 7:28 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In reconfig, in case the driver asks to disconnect during the reconfig,
all the keys of the interface are marked as tainted.
Then ieee80211_reenable_keys will loop over all the interface keys, and
for each one it will
a) increment crypto_tx_tailroom_needed_cnt
b) call ieee80211_key_enable_hw_accel, which in turn will detect that
this key is tainted, so it will mark it as "not in hardware", which is
paired with crypto_tx_tailroom_needed_cnt incrementation, so we get two
incrementations for each tainted key.
Then we get a warning in ieee80211_free_keys.
To fix it, don't increment the count in ieee80211_reenable_keys for
tainted keys
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
net/mac80211/key.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index d5da7ccea66e..04c8809173d7 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -987,7 +987,8 @@ void ieee80211_reenable_keys(struct ieee80211_sub_if_data *sdata)
if (ieee80211_sdata_running(sdata)) {
list_for_each_entry(key, &sdata->key_list, list) {
- increment_tailroom_need_count(sdata);
+ if (!(key->flags & KEY_FLAG_TAINTED))
+ increment_tailroom_need_count(sdata);
ieee80211_key_enable_hw_accel(key);
}
}
--
2.34.1
^ permalink raw reply related
* [BUG] mt7921e driver loads abnormal firmware "____010000" on ThinkPad T14 Gen 2a, causing Wi-Fi stalls
From: yizhe @ 2026-01-18 4:03 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1.1: Type: text/plain, Size: 2425 bytes --]
Hello mt76 maintainers and linux-wireless community,
I am reporting a bug where the `mt7921e` driver consistently loads an abnormal firmware version on my MediaTek MT7921 Wi-Fi adapter, leading to frequent upload/download speed drops to zero.
### 1. Problem Description
- **Hardware**: ThinkPad T14 Gen 2a with MediaTek MT7921 (PCI ID: 14c3:7961).
- **Software**: Arch Linux with kernel `6.12.65-1-lts` (also reproducible on `linux-zen`).
- **Symptom**: Wi-Fi connects but frequently stalls (speed drops to 0 B/s). The driver logs show it is using firmware version `____010000` with a future build time `20250625153703`. Normal external firmware files are ignored.
### 2. Diagnostic Evidence
- The abnormal firmware version appears in dmesg immediately after driver load.
- `modinfo mt7921e` shows the driver is configured for MT7922/MT7961 firmware only, with no entry for MT7921.
- We have confirmed that the correct MT7961 firmware files exist in `/lib/firmware/mediatek/` and are properly compressed.
- Attempts to specify firmware via module parameters (`fw_name`, `wmfw_name`) failed because these parameters are not supported by the current driver.
- **Crucially, a full-system search confirms that the string `____010000` does NOT exist in any kernel module file**, ruling out simple built-in firmware. This suggests a driver logic bug in version reporting or fallback.
### 3. Steps to Reproduce
1. Boot Arch Linux on a ThinkPad T14 Gen 2a with MT7921.
2. Check `sudo dmesg | grep -i "WM Firmware Version"`.
3. Observe the abnormal version `____010000`.
### 4. What has been tried (and failed)
- Placing various MT7961 firmware files with different names and creating symlinks.
- Adding `disable_aspm=1` and attempting firmware path parameters via `modprobe.d`.
- Switching between `linux-zen`, `linux`, and `linux-lts` kernels.
- Completely reinstalling `linux-firmware` and `linux-firmware-mediatek` packages.
### 5. Request
Could you please investigate:
1. Why does the driver report and possibly use this abnormal firmware version?
2. Is the driver's firmware configuration for PCI ID 14c3:7961 incomplete or incorrect?
3. What is the correct way to make the driver load the proper firmware for this device?
The full diagnostic logs are attached below for your reference.
Thank you for your time and work on the mt76 driver.
Full unprocessed dmesg logs are attached as a text file.
Best regards,
[yizhe]
[-- Attachment #1.2: Type: text/html, Size: 2701 bytes --]
[-- Attachment #2: mt7921_full_dmesg.log --]
[-- Type: text/plain, Size: 1377 bytes --]
[ 0.126644] Spectre V2 : Enabling Restricted Speculation for firmware calls
[ 1.161159] xhci-pci-renesas 0000:06:00.0: failed to load firmware renesas_usb_fw.mem, fallback to ROM
[ 3.410422] [drm] Loading DMUB firmware via PSP: version=0x0101002B
[ 3.410952] [drm] Found VCN firmware Version ENC: 1.24 DEC: 8 VEP: 0 Revision: 9
[ 5.522859] systemd[1]: Clear Stale Hibernate Storage Info was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/efivars/HibernateLocation-8cf2644b-4b0b-428f-9387-6d876050dc67).
[ 6.083414] Using s2idle quirk to avoid T14 Gen2 AMD platform firmware bug
[ 6.204406] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 6.461984] mt7921e: unknown parameter 'fw_name' ignored
[ 6.461988] mt7921e: unknown parameter 'wmfw_name' ignored
[ 6.462075] mt7921e 0000:03:00.0: enabling device (0000 -> 0002)
[ 6.463812] mt7921e 0000:03:00.0: disabling ASPM L1
[ 6.470444] mt7921e 0000:03:00.0: ASIC revision: 79610010
[ 6.550653] mt7921e 0000:03:00.0: HW/SW Version: 0x8a108a10, Build Time: 20250625153620a
[ 6.562272] mt7921e 0000:03:00.0: WM Firmware Version: ____010000, Build Time: 20250625153703
[ 7.399150] mt7921e 0000:03:00.0 wlp3s0: renamed from wlan0
[ 7.776550] psmouse serio2: trackpoint: Elan TrackPoint firmware: 0x12, buttons: 3/3
^ permalink raw reply
* [PATCH rtw-next 9/9] wifi: rtw89: 8922a: add digital compensation for 2GHz
From: Ping-Ke Shih @ 2026-01-17 4:41 UTC (permalink / raw)
To: linux-wireless; +Cc: echuang, phhuang, kevin_yang
In-Reply-To: <20260117044157.2392958-1-pkshih@realtek.com>
From: Po-Hao Huang <phhuang@realtek.com>
This fixes transmit power too low under 2GHz connection. Previously
we missed the settings of 2GHz, add the according calibrated tables.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/rtw8922a.c | 57 +++++++++++++++----
1 file changed, 47 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw89/rtw8922a.c b/drivers/net/wireless/realtek/rtw89/rtw8922a.c
index 0a3c2207dd4b..f41b66b362c4 100644
--- a/drivers/net/wireless/realtek/rtw89/rtw8922a.c
+++ b/drivers/net/wireless/realtek/rtw89/rtw8922a.c
@@ -1768,6 +1768,32 @@ static int rtw8922a_ctrl_rx_path_tmac(struct rtw89_dev *rtwdev,
}
#define DIGITAL_PWR_COMP_REG_NUM 22
+static const u32 rtw8922a_digital_pwr_comp_2g_s0_val[][DIGITAL_PWR_COMP_REG_NUM] = {
+ {0x012C0064, 0x04B00258, 0x00432710, 0x019000A7, 0x06400320,
+ 0x0D05091D, 0x14D50FA0, 0x00000000, 0x01010000, 0x00000101,
+ 0x01010101, 0x02020201, 0x02010000, 0x03030202, 0x00000303,
+ 0x03020101, 0x06060504, 0x01010000, 0x06050403, 0x01000606,
+ 0x05040202, 0x07070706},
+ {0x012C0064, 0x04B00258, 0x00432710, 0x019000A7, 0x06400320,
+ 0x0D05091D, 0x14D50FA0, 0x00000000, 0x01010100, 0x00000101,
+ 0x01000000, 0x01010101, 0x01010000, 0x02020202, 0x00000404,
+ 0x03020101, 0x04040303, 0x02010000, 0x03030303, 0x00000505,
+ 0x03030201, 0x05050303},
+};
+
+static const u32 rtw8922a_digital_pwr_comp_2g_s1_val[][DIGITAL_PWR_COMP_REG_NUM] = {
+ {0x012C0064, 0x04B00258, 0x00432710, 0x019000A7, 0x06400320,
+ 0x0D05091D, 0x14D50FA0, 0x01010000, 0x01010101, 0x00000101,
+ 0x01010100, 0x01010101, 0x01010000, 0x02020202, 0x01000202,
+ 0x02020101, 0x03030202, 0x02010000, 0x05040403, 0x01000606,
+ 0x05040302, 0x07070605},
+ {0x012C0064, 0x04B00258, 0x00432710, 0x019000A7, 0x06400320,
+ 0x0D05091D, 0x14D50FA0, 0x00000000, 0x01010100, 0x00000101,
+ 0x01010000, 0x02020201, 0x02010100, 0x03030202, 0x01000404,
+ 0x04030201, 0x05050404, 0x01010100, 0x04030303, 0x01000505,
+ 0x03030101, 0x05050404},
+};
+
static const u32 rtw8922a_digital_pwr_comp_val[][DIGITAL_PWR_COMP_REG_NUM] = {
{0x012C0096, 0x044C02BC, 0x00322710, 0x015E0096, 0x03C8028A,
0x0BB80708, 0x17701194, 0x02020100, 0x03030303, 0x01000303,
@@ -1782,7 +1808,7 @@ static const u32 rtw8922a_digital_pwr_comp_val[][DIGITAL_PWR_COMP_REG_NUM] = {
};
static void rtw8922a_set_digital_pwr_comp(struct rtw89_dev *rtwdev,
- bool enable, u8 nss,
+ u8 band, u8 nss,
enum rtw89_rf_path path)
{
static const u32 ltpc_t0[2] = {R_BE_LTPC_T0_PATH0, R_BE_LTPC_T0_PATH1};
@@ -1790,14 +1816,25 @@ static void rtw8922a_set_digital_pwr_comp(struct rtw89_dev *rtwdev,
u32 addr, val;
u32 i;
- if (nss == 1)
- digital_pwr_comp = rtw8922a_digital_pwr_comp_val[0];
- else
- digital_pwr_comp = rtw8922a_digital_pwr_comp_val[1];
+ if (nss == 1) {
+ if (band == RTW89_BAND_2G)
+ digital_pwr_comp = path == RF_PATH_A ?
+ rtw8922a_digital_pwr_comp_2g_s0_val[0] :
+ rtw8922a_digital_pwr_comp_2g_s1_val[0];
+ else
+ digital_pwr_comp = rtw8922a_digital_pwr_comp_val[0];
+ } else {
+ if (band == RTW89_BAND_2G)
+ digital_pwr_comp = path == RF_PATH_A ?
+ rtw8922a_digital_pwr_comp_2g_s0_val[1] :
+ rtw8922a_digital_pwr_comp_2g_s1_val[1];
+ else
+ digital_pwr_comp = rtw8922a_digital_pwr_comp_val[1];
+ }
addr = ltpc_t0[path];
for (i = 0; i < DIGITAL_PWR_COMP_REG_NUM; i++, addr += 4) {
- val = enable ? digital_pwr_comp[i] : 0;
+ val = digital_pwr_comp[i];
rtw89_phy_write32(rtwdev, addr, val);
}
}
@@ -1806,7 +1843,7 @@ static void rtw8922a_digital_pwr_comp(struct rtw89_dev *rtwdev,
enum rtw89_phy_idx phy_idx)
{
const struct rtw89_chan *chan = rtw89_chan_get(rtwdev, RTW89_CHANCTX_0);
- bool enable = chan->band_type != RTW89_BAND_2G;
+ u8 band = chan->band_type;
u8 path;
if (rtwdev->mlo_dbcc_mode == MLO_1_PLUS_1_1RF) {
@@ -1814,10 +1851,10 @@ static void rtw8922a_digital_pwr_comp(struct rtw89_dev *rtwdev,
path = RF_PATH_A;
else
path = RF_PATH_B;
- rtw8922a_set_digital_pwr_comp(rtwdev, enable, 1, path);
+ rtw8922a_set_digital_pwr_comp(rtwdev, band, 1, path);
} else {
- rtw8922a_set_digital_pwr_comp(rtwdev, enable, 2, RF_PATH_A);
- rtw8922a_set_digital_pwr_comp(rtwdev, enable, 2, RF_PATH_B);
+ rtw8922a_set_digital_pwr_comp(rtwdev, band, 2, RF_PATH_A);
+ rtw8922a_set_digital_pwr_comp(rtwdev, band, 2, RF_PATH_B);
}
}
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 8/9] wifi: rtw89: mac: set force MBA duration to 0
From: Ping-Ke Shih @ 2026-01-17 4:41 UTC (permalink / raw)
To: linux-wireless; +Cc: echuang, phhuang, kevin_yang
In-Reply-To: <20260117044157.2392958-1-pkshih@realtek.com>
Enable force MBA (Multi-user Block Ack) field to ensure trasnmiting
packet of duration field of MBA in multi-user block ack request is 0
as expected.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/mac_be.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw89/mac_be.c b/drivers/net/wireless/realtek/rtw89/mac_be.c
index e552711ffce4..1281f68aad4a 100644
--- a/drivers/net/wireless/realtek/rtw89/mac_be.c
+++ b/drivers/net/wireless/realtek/rtw89/mac_be.c
@@ -1328,6 +1328,9 @@ static int nav_ctrl_init_be(struct rtw89_dev *rtwdev, u8 mac_idx)
reg = rtw89_mac_reg_by_idx(rtwdev, R_BE_SPECIAL_TX_SETTING, mac_idx);
rtw89_write32_clr(rtwdev, reg, B_BE_BMC_NAV_PROTECT);
+ reg = rtw89_mac_reg_by_idx(rtwdev, R_BE_TRXPTCL_RESP_0, mac_idx);
+ rtw89_write32_set(rtwdev, reg, B_BE_WMAC_MBA_DUR_FORCE);
+
return 0;
}
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 7/9] wifi: rtw89: mac: clear DTOP disable excluding CID7090 variant for RTL8922D
From: Ping-Ke Shih @ 2026-01-17 4:41 UTC (permalink / raw)
To: linux-wireless; +Cc: echuang, phhuang, kevin_yang
In-Reply-To: <20260117044157.2392958-1-pkshih@realtek.com>
The data TX FIFO operation (DTOP) is a hardware component in TMAC circuit
to control TX flow, since CID7090 variant can clear DTOP by default, no
need it by driver.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/mac_be.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtw89/mac_be.c b/drivers/net/wireless/realtek/rtw89/mac_be.c
index 142e892f85c4..e552711ffce4 100644
--- a/drivers/net/wireless/realtek/rtw89/mac_be.c
+++ b/drivers/net/wireless/realtek/rtw89/mac_be.c
@@ -1352,6 +1352,7 @@ static int spatial_reuse_init_be(struct rtw89_dev *rtwdev, u8 mac_idx)
static int tmac_init_be(struct rtw89_dev *rtwdev, u8 mac_idx)
{
const struct rtw89_chip_info *chip = rtwdev->chip;
+ struct rtw89_hal *hal = &rtwdev->hal;
u32 reg;
reg = rtw89_mac_reg_by_idx(rtwdev, R_BE_TB_PPDU_CTRL, mac_idx);
@@ -1363,7 +1364,7 @@ static int tmac_init_be(struct rtw89_dev *rtwdev, u8 mac_idx)
rtw89_write32_mask(rtwdev, reg, B_BE_EHT_HE_PPDU_2XLTF_ZLD_USTIMER_MASK, 0xe);
}
- if (chip->chip_id == RTL8922D) {
+ if (chip->chip_id == RTL8922D && hal->cid != RTL8922D_CID7090) {
reg = rtw89_mac_reg_by_idx(rtwdev, R_BE_COMMON_PHYINTF_CTRL_0, mac_idx);
rtw89_write32_clr(rtwdev, reg, CLEAR_DTOP_DIS);
}
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 6/9] wifi: rtw89: phy: update TSSI flow for RTL8922D
From: Ping-Ke Shih @ 2026-01-17 4:41 UTC (permalink / raw)
To: linux-wireless; +Cc: echuang, phhuang, kevin_yang
In-Reply-To: <20260117044157.2392958-1-pkshih@realtek.com>
From: Zong-Zhe Yang <kevin_yang@realtek.com>
TSSI is to do TX compensation caused by temperature. The RTL8922D defines
different H2C command format. Update it accordingly.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/fw.c | 7 +++-
drivers/net/wireless/realtek/rtw89/phy.c | 46 +++++++++++++++++-------
2 files changed, 40 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw89/fw.c b/drivers/net/wireless/realtek/rtw89/fw.c
index 46161e06a1d9..a0de6a17166c 100644
--- a/drivers/net/wireless/realtek/rtw89/fw.c
+++ b/drivers/net/wireless/realtek/rtw89/fw.c
@@ -7291,6 +7291,7 @@ int rtw89_fw_h2c_rf_pre_ntfy_mcc(struct rtw89_dev *rtwdev, enum rtw89_phy_idx ph
int rtw89_fw_h2c_rf_tssi(struct rtw89_dev *rtwdev, enum rtw89_phy_idx phy_idx,
const struct rtw89_chan *chan, enum rtw89_tssi_mode tssi_mode)
{
+ const struct rtw89_chip_info *chip = rtwdev->chip;
struct rtw89_efuse *efuse = &rtwdev->efuse;
struct rtw89_hal *hal = &rtwdev->hal;
struct rtw89_h2c_rf_tssi *h2c;
@@ -7311,11 +7312,15 @@ int rtw89_fw_h2c_rf_tssi(struct rtw89_dev *rtwdev, enum rtw89_phy_idx phy_idx,
h2c->ch = chan->channel;
h2c->bw = chan->band_width;
h2c->band = chan->band_type;
- h2c->hwtx_en = true;
h2c->cv = hal->cv;
h2c->tssi_mode = tssi_mode;
h2c->rfe_type = efuse->rfe_type;
+ if (chip->chip_id == RTL8922A)
+ h2c->hwtx_en = true;
+ else
+ h2c->hwtx_en = false;
+
rtw89_phy_rfk_tssi_fill_fwcmd_efuse_to_de(rtwdev, phy_idx, chan, h2c);
rtw89_phy_rfk_tssi_fill_fwcmd_tmeter_tbl(rtwdev, phy_idx, chan, h2c);
diff --git a/drivers/net/wireless/realtek/rtw89/phy.c b/drivers/net/wireless/realtek/rtw89/phy.c
index 5c7c76a53d60..cf7484e4cec4 100644
--- a/drivers/net/wireless/realtek/rtw89/phy.c
+++ b/drivers/net/wireless/realtek/rtw89/phy.c
@@ -4444,6 +4444,7 @@ void rtw89_phy_rfk_tssi_fill_fwcmd_efuse_to_de(struct rtw89_dev *rtwdev,
const struct rtw89_chan *chan,
struct rtw89_h2c_rf_tssi *h2c)
{
+ const struct rtw89_chip_info *chip = rtwdev->chip;
struct rtw89_tssi_info *tssi_info = &rtwdev->tssi;
u8 ch = chan->channel;
s8 trim_de;
@@ -4467,9 +4468,14 @@ void rtw89_phy_rfk_tssi_fill_fwcmd_efuse_to_de(struct rtw89_dev *rtwdev,
cck_de = tssi_info->tssi_cck[i][gidx];
val = u32_get_bits(cck_de + trim_de, 0xff);
- h2c->curr_tssi_cck_de[i] = 0x0;
- h2c->curr_tssi_cck_de_20m[i] = val;
- h2c->curr_tssi_cck_de_40m[i] = val;
+ if (chip->chip_id == RTL8922A) {
+ h2c->curr_tssi_cck_de[i] = 0x0;
+ h2c->curr_tssi_cck_de_20m[i] = val;
+ h2c->curr_tssi_cck_de_40m[i] = val;
+ } else {
+ h2c->curr_tssi_cck_de[i] = val;
+ }
+
h2c->curr_tssi_efuse_cck_de[i] = cck_de;
rtw89_debug(rtwdev, RTW89_DBG_TSSI,
@@ -4478,12 +4484,17 @@ void rtw89_phy_rfk_tssi_fill_fwcmd_efuse_to_de(struct rtw89_dev *rtwdev,
ofdm_de = phy_tssi_get_ofdm_de(rtwdev, phy, chan, i);
val = u32_get_bits(ofdm_de + trim_de, 0xff);
- h2c->curr_tssi_ofdm_de[i] = 0x0;
- h2c->curr_tssi_ofdm_de_20m[i] = val;
- h2c->curr_tssi_ofdm_de_40m[i] = val;
- h2c->curr_tssi_ofdm_de_80m[i] = val;
- h2c->curr_tssi_ofdm_de_160m[i] = val;
- h2c->curr_tssi_ofdm_de_320m[i] = val;
+ if (chip->chip_id == RTL8922A) {
+ h2c->curr_tssi_ofdm_de[i] = 0x0;
+ h2c->curr_tssi_ofdm_de_20m[i] = val;
+ h2c->curr_tssi_ofdm_de_40m[i] = val;
+ h2c->curr_tssi_ofdm_de_80m[i] = val;
+ h2c->curr_tssi_ofdm_de_160m[i] = val;
+ h2c->curr_tssi_ofdm_de_320m[i] = val;
+ } else {
+ h2c->curr_tssi_ofdm_de[i] = val;
+ }
+
h2c->curr_tssi_efuse_ofdm_de[i] = ofdm_de;
rtw89_debug(rtwdev, RTW89_DBG_TSSI,
@@ -4498,10 +4509,12 @@ void rtw89_phy_rfk_tssi_fill_fwcmd_tmeter_tbl(struct rtw89_dev *rtwdev,
{
struct rtw89_fw_txpwr_track_cfg *trk = rtwdev->fw.elm_info.txpwr_trk;
struct rtw89_tssi_info *tssi_info = &rtwdev->tssi;
+ const struct rtw89_chip_info *chip = rtwdev->chip;
const s8 *thm_up[RF_PATH_B + 1] = {};
const s8 *thm_down[RF_PATH_B + 1] = {};
u8 subband = chan->subband_type;
- s8 thm_ofst[128] = {0};
+ s8 thm_ofst[128] = {};
+ int multiplier;
u8 thermal;
u8 path;
u8 i, j;
@@ -4565,6 +4578,11 @@ void rtw89_phy_rfk_tssi_fill_fwcmd_tmeter_tbl(struct rtw89_dev *rtwdev,
rtw89_debug(rtwdev, RTW89_DBG_TSSI,
"[TSSI] tmeter tbl on subband: %u\n", subband);
+ if (chip->chip_id == RTL8922A)
+ multiplier = 1;
+ else
+ multiplier = -1;
+
for (path = RF_PATH_A; path <= RF_PATH_B; path++) {
thermal = tssi_info->thermal[path];
rtw89_debug(rtwdev, RTW89_DBG_TSSI,
@@ -4579,16 +4597,20 @@ void rtw89_phy_rfk_tssi_fill_fwcmd_tmeter_tbl(struct rtw89_dev *rtwdev,
h2c->pg_thermal[path] = thermal;
i = 0;
- for (j = 0; j < 64; j++)
+ for (j = 0; j < 64; j++) {
thm_ofst[j] = i < DELTA_SWINGIDX_SIZE ?
thm_up[path][i++] :
thm_up[path][DELTA_SWINGIDX_SIZE - 1];
+ thm_ofst[j] *= multiplier;
+ }
i = 1;
- for (j = 127; j >= 64; j--)
+ for (j = 127; j >= 64; j--) {
thm_ofst[j] = i < DELTA_SWINGIDX_SIZE ?
-thm_down[path][i++] :
-thm_down[path][DELTA_SWINGIDX_SIZE - 1];
+ thm_ofst[j] *= multiplier;
+ }
for (i = 0; i < 128; i += 4) {
h2c->ftable[path][i + 0] = thm_ofst[i + 3];
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 5/9] wifi: rtw89: phy: add firmware element of digital TX power compensation
From: Ping-Ke Shih @ 2026-01-17 4:41 UTC (permalink / raw)
To: linux-wireless; +Cc: echuang, phhuang, kevin_yang
In-Reply-To: <20260117044157.2392958-1-pkshih@realtek.com>
Define and set compensation value to corresponding frequency bands.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/chan.c | 23 +++++++++++++++++++++++
drivers/net/wireless/realtek/rtw89/core.h | 12 ++++++++++++
drivers/net/wireless/realtek/rtw89/fw.c | 23 +++++++++++++++++++++++
drivers/net/wireless/realtek/rtw89/fw.h | 1 +
4 files changed, 59 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw89/chan.c b/drivers/net/wireless/realtek/rtw89/chan.c
index 0b5509468582..c0af61992226 100644
--- a/drivers/net/wireless/realtek/rtw89/chan.c
+++ b/drivers/net/wireless/realtek/rtw89/chan.c
@@ -60,6 +60,28 @@ static enum rtw89_subband rtw89_get_subband_type(enum rtw89_band band,
}
}
+static enum rtw89_tx_comp_band rtw89_get_tx_comp_band(enum rtw89_band band,
+ u8 center_chan)
+{
+ switch (band) {
+ default:
+ case RTW89_BAND_2G:
+ return RTW89_TX_COMP_BAND_2GHZ;
+ case RTW89_BAND_5G:
+ if (center_chan < 149)
+ return RTW89_TX_COMP_BAND_5GHZ_L;
+ else
+ return RTW89_TX_COMP_BAND_5GHZ_H;
+ case RTW89_BAND_6G:
+ if (center_chan < 65)
+ return RTW89_TX_COMP_BAND_5GHZ_H;
+ else if (center_chan < 193)
+ return RTW89_TX_COMP_BAND_6GHZ_M;
+ else
+ return RTW89_TX_COMP_BAND_6GHZ_UH;
+ }
+}
+
static enum rtw89_sc_offset rtw89_get_primary_chan_idx(enum rtw89_bandwidth bw,
u32 center_freq,
u32 primary_freq)
@@ -123,6 +145,7 @@ void rtw89_chan_create(struct rtw89_chan *chan, u8 center_chan, u8 primary_chan,
chan->freq = center_freq;
chan->subband_type = rtw89_get_subband_type(band, center_chan);
+ chan->tx_comp_band = rtw89_get_tx_comp_band(band, center_chan);
chan->pri_ch_idx = rtw89_get_primary_chan_idx(bandwidth, center_freq,
primary_freq);
chan->pri_sb_idx = rtw89_get_primary_sb_idx(center_chan, primary_chan,
diff --git a/drivers/net/wireless/realtek/rtw89/core.h b/drivers/net/wireless/realtek/rtw89/core.h
index 509357a1c072..c39ce15d30c8 100644
--- a/drivers/net/wireless/realtek/rtw89/core.h
+++ b/drivers/net/wireless/realtek/rtw89/core.h
@@ -115,6 +115,16 @@ enum rtw89_subband {
RTW89_SUBBAND_2GHZ_5GHZ_NR = RTW89_CH_5G_BAND_4 + 1,
};
+enum rtw89_tx_comp_band {
+ RTW89_TX_COMP_BAND_2GHZ,
+ RTW89_TX_COMP_BAND_5GHZ_L,
+ RTW89_TX_COMP_BAND_5GHZ_H,
+ RTW89_TX_COMP_BAND_6GHZ_M,
+ RTW89_TX_COMP_BAND_6GHZ_UH,
+
+ RTW89_TX_COMP_BAND_NR,
+};
+
enum rtw89_gain_offset {
RTW89_GAIN_OFFSET_2G_CCK,
RTW89_GAIN_OFFSET_2G_OFDM,
@@ -991,6 +1001,7 @@ struct rtw89_chan {
*/
u32 freq;
enum rtw89_subband subband_type;
+ enum rtw89_tx_comp_band tx_comp_band;
enum rtw89_sc_offset pri_ch_idx;
u8 pri_sb_idx;
};
@@ -4831,6 +4842,7 @@ struct rtw89_fw_elm_info {
const struct rtw89_regd_data *regd;
const struct rtw89_fw_element_hdr *afe;
const struct rtw89_fw_element_hdr *diag_mac;
+ const struct rtw89_fw_element_hdr *tx_comp;
};
enum rtw89_fw_mss_dev_type {
diff --git a/drivers/net/wireless/realtek/rtw89/fw.c b/drivers/net/wireless/realtek/rtw89/fw.c
index 329606a5bc20..46161e06a1d9 100644
--- a/drivers/net/wireless/realtek/rtw89/fw.c
+++ b/drivers/net/wireless/realtek/rtw89/fw.c
@@ -1382,6 +1382,26 @@ int rtw89_recognize_diag_mac_from_elm(struct rtw89_dev *rtwdev,
return 0;
}
+static
+int rtw89_build_tx_comp_from_elm(struct rtw89_dev *rtwdev,
+ const struct rtw89_fw_element_hdr *elm,
+ const union rtw89_fw_element_arg arg)
+{
+ struct rtw89_fw_elm_info *elm_info = &rtwdev->fw.elm_info;
+ struct rtw89_hal *hal = &rtwdev->hal;
+ u16 aid;
+
+ aid = le16_to_cpu(elm->aid);
+ if (aid && aid != hal->aid)
+ return 1; /* ignore if aid not matched */
+ else if (elm_info->tx_comp)
+ return 1; /* ignore if an element is existing */
+
+ elm_info->tx_comp = elm;
+
+ return 0;
+}
+
static const struct rtw89_fw_element_handler __fw_element_handlers[] = {
[RTW89_FW_ELEMENT_ID_BBMCU0] = {__rtw89_fw_recognize_from_elm,
{ .fw_type = RTW89_FW_BBMCU0 }, NULL},
@@ -1473,6 +1493,9 @@ static const struct rtw89_fw_element_handler __fw_element_handlers[] = {
[RTW89_FW_ELEMENT_ID_DIAG_MAC] = {
rtw89_recognize_diag_mac_from_elm, {}, NULL,
},
+ [RTW89_FW_ELEMENT_ID_TX_COMP] = {
+ rtw89_build_tx_comp_from_elm, {}, NULL,
+ },
};
int rtw89_fw_recognize_elements(struct rtw89_dev *rtwdev)
diff --git a/drivers/net/wireless/realtek/rtw89/fw.h b/drivers/net/wireless/realtek/rtw89/fw.h
index 146403d285b4..521702f97d50 100644
--- a/drivers/net/wireless/realtek/rtw89/fw.h
+++ b/drivers/net/wireless/realtek/rtw89/fw.h
@@ -4262,6 +4262,7 @@ enum rtw89_fw_element_id {
RTW89_FW_ELEMENT_ID_TXPWR_DA_LMT_RU_6GHZ = 26,
RTW89_FW_ELEMENT_ID_AFE_PWR_SEQ = 27,
RTW89_FW_ELEMENT_ID_DIAG_MAC = 28,
+ RTW89_FW_ELEMENT_ID_TX_COMP = 29,
RTW89_FW_ELEMENT_ID_NUM,
};
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 4/9] wifi: rtw89: phy: update edcca log parsing for RTL8922D
From: Ping-Ke Shih @ 2026-01-17 4:41 UTC (permalink / raw)
To: linux-wireless; +Cc: echuang, phhuang, kevin_yang
In-Reply-To: <20260117044157.2392958-1-pkshih@realtek.com>
From: Eric Huang <echuang@realtek.com>
Before this change the rtw89_phy_edcca_log routine didn't handled
RTL8922D. This update expands the logic to recognize RTL8922D EDCCA
reports.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/phy.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw89/phy.c b/drivers/net/wireless/realtek/rtw89/phy.c
index 6059f40f34b3..5c7c76a53d60 100644
--- a/drivers/net/wireless/realtek/rtw89/phy.c
+++ b/drivers/net/wireless/realtek/rtw89/phy.c
@@ -7838,6 +7838,7 @@ static void rtw89_phy_edcca_log(struct rtw89_dev *rtwdev, struct rtw89_bb_ctx *b
bool flag_fb, flag_p20, flag_s20, flag_s40, flag_s80;
s8 pwdb_fb, pwdb_p20, pwdb_s20, pwdb_s40, pwdb_s80;
u8 path, per20_bitmap = 0;
+ u8 pwdb_sel = 5;
u8 pwdb[8];
u32 tmp;
@@ -7849,12 +7850,14 @@ static void rtw89_phy_edcca_log(struct rtw89_dev *rtwdev, struct rtw89_bb_ctx *b
else
edcca_p_regs = &edcca_regs->p[RTW89_PHY_0];
- if (rtwdev->chip->chip_id == RTL8922A)
- rtw89_phy_write32_mask(rtwdev, edcca_regs->rpt_sel_be,
- edcca_regs->rpt_sel_be_mask, 0);
-
rtw89_phy_write32_mask(rtwdev, edcca_p_regs->rpt_sel,
edcca_p_regs->rpt_sel_mask, 0);
+ if (rtwdev->chip->chip_id == RTL8922A || rtwdev->chip->chip_id == RTL8922D) {
+ rtw89_phy_write32_mask(rtwdev, edcca_regs->rpt_sel_be,
+ edcca_regs->rpt_sel_be_mask, 0);
+ per20_bitmap = rtw89_phy_read32_mask(rtwdev, edcca_p_regs->rpt_a,
+ MASKBYTE0);
+ }
tmp = rtw89_phy_read32(rtwdev, edcca_p_regs->rpt_b);
path = u32_get_bits(tmp, B_EDCCA_RPT_B_PATH_MASK);
flag_s80 = u32_get_bits(tmp, B_EDCCA_RPT_B_S80);
@@ -7866,13 +7869,16 @@ static void rtw89_phy_edcca_log(struct rtw89_dev *rtwdev, struct rtw89_bb_ctx *b
pwdb_p20 = u32_get_bits(tmp, MASKBYTE2);
pwdb_fb = u32_get_bits(tmp, MASKBYTE3);
+ if (rtwdev->chip->chip_id == RTL8922D)
+ pwdb_sel = 2;
+
rtw89_phy_write32_mask(rtwdev, edcca_p_regs->rpt_sel,
- edcca_p_regs->rpt_sel_mask, 5);
+ edcca_p_regs->rpt_sel_mask, pwdb_sel);
tmp = rtw89_phy_read32(rtwdev, edcca_p_regs->rpt_b);
pwdb_s80 = u32_get_bits(tmp, MASKBYTE1);
pwdb_s40 = u32_get_bits(tmp, MASKBYTE2);
- if (rtwdev->chip->chip_id == RTL8922A) {
+ if (rtwdev->chip->chip_id == RTL8922A || rtwdev->chip->chip_id == RTL8922D) {
rtw89_phy_write32_mask(rtwdev, edcca_regs->rpt_sel_be,
edcca_regs->rpt_sel_be_mask, 4);
tmp = rtw89_phy_read32(rtwdev, edcca_p_regs->rpt_b);
@@ -7880,8 +7886,6 @@ static void rtw89_phy_edcca_log(struct rtw89_dev *rtwdev, struct rtw89_bb_ctx *b
pwdb[1] = u32_get_bits(tmp, MASKBYTE2);
pwdb[2] = u32_get_bits(tmp, MASKBYTE1);
pwdb[3] = u32_get_bits(tmp, MASKBYTE0);
- per20_bitmap = rtw89_phy_read32_mask(rtwdev, edcca_p_regs->rpt_a,
- MASKBYTE0);
rtw89_phy_write32_mask(rtwdev, edcca_regs->rpt_sel_be,
edcca_regs->rpt_sel_be_mask, 5);
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 3/9] wifi: rtw89: phy: add H2C command to send detail RX gain and link parameters for PS mode
From: Ping-Ke Shih @ 2026-01-17 4:41 UTC (permalink / raw)
To: linux-wireless; +Cc: echuang, phhuang, kevin_yang
In-Reply-To: <20260117044157.2392958-1-pkshih@realtek.com>
From: Eric Huang <echuang@realtek.com>
Introduce support for a new PS multi-link common info version (v1)
for RTL8922D, enabling the driver to send detailed RX gain and link
parameters to firmware via a new H2C command.
A dedicated 20 MHz beacon channel (chan_bcn) that replicates the primary
channel and band type of the original channel but forces a 20 MHz width.
This ensures that beacon mode always reference the 20 MHz gain table,
fixing the mis-assignment that could degrade signal strength or cause
incorrect RSSI calibration.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/core.h | 1 +
drivers/net/wireless/realtek/rtw89/fw.c | 155 ++++++++++++++++++++++
drivers/net/wireless/realtek/rtw89/fw.h | 65 +++++++++
drivers/net/wireless/realtek/rtw89/ps.c | 2 +
drivers/net/wireless/realtek/rtw89/reg.h | 1 +
5 files changed, 224 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw89/core.h b/drivers/net/wireless/realtek/rtw89/core.h
index 5c3684064d38..509357a1c072 100644
--- a/drivers/net/wireless/realtek/rtw89/core.h
+++ b/drivers/net/wireless/realtek/rtw89/core.h
@@ -4767,6 +4767,7 @@ enum rtw89_fw_feature {
RTW89_FW_FEATURE_ADDR_CAM_V0,
RTW89_FW_FEATURE_SER_L1_BY_EVENT,
RTW89_FW_FEATURE_SIM_SER_L0L1_BY_HALT_H2C,
+ RTW89_FW_FEATURE_LPS_ML_INFO_V1,
NUM_OF_RTW89_FW_FEATURES,
};
diff --git a/drivers/net/wireless/realtek/rtw89/fw.c b/drivers/net/wireless/realtek/rtw89/fw.c
index f09387e089a2..329606a5bc20 100644
--- a/drivers/net/wireless/realtek/rtw89/fw.c
+++ b/drivers/net/wireless/realtek/rtw89/fw.c
@@ -3264,6 +3264,161 @@ int rtw89_fw_h2c_lps_ml_cmn_info(struct rtw89_dev *rtwdev,
return ret;
}
+void rtw89_bb_lps_cmn_info_rx_gain_fill(struct rtw89_dev *rtwdev,
+ struct rtw89_bb_link_info_rx_gain *h2c_gain,
+ const struct rtw89_chan *chan, u8 phy_idx)
+{
+ const struct rtw89_phy_bb_gain_info_be *gain = &rtwdev->bb_gain.be;
+ enum rtw89_bb_link_rx_gain_table_type tab_idx;
+ struct rtw89_chan chan_bcn;
+ u8 bw = chan->band_width;
+ u8 gain_band;
+ u8 bw_idx;
+ u8 path;
+ int i;
+
+ rtw89_chan_create(&chan_bcn, chan->primary_channel, chan->primary_channel,
+ chan->band_type, RTW89_CHANNEL_WIDTH_20);
+
+ for (tab_idx = RTW89_BB_PS_LINK_RX_GAIN_TAB_BCN_PATH_A;
+ tab_idx < RTW89_BB_PS_LINK_RX_GAIN_TAB_MAX; tab_idx++) {
+ struct rtw89_phy_calc_efuse_gain calc = {};
+
+ path = (tab_idx & BIT(0)) ? (RF_PATH_B) : (RF_PATH_A);
+ if (tab_idx & BIT(1)) {
+ rtw89_chip_calc_rx_gain_normal(rtwdev, chan, path, phy_idx,
+ &calc);
+ gain_band = rtw89_subband_to_gain_band_be(chan->subband_type);
+ if (bw > RTW89_CHANNEL_WIDTH_40)
+ bw_idx = RTW89_BB_BW_80_160_320;
+ else
+ bw_idx = RTW89_BB_BW_20_40;
+ } else {
+ rtw89_chip_calc_rx_gain_normal(rtwdev, &chan_bcn, path, phy_idx,
+ &calc);
+ gain_band = rtw89_subband_to_gain_band_be(chan_bcn.subband_type);
+ bw_idx = RTW89_BB_BW_20_40;
+ }
+
+ /* efuse ofst and comp */
+ h2c_gain->gain_ofst[tab_idx] = calc.rssi_ofst;
+ h2c_gain->cck_gain_ofst[tab_idx] = calc.cck_rpl_ofst;
+ h2c_gain->cck_rpl_bias_comp[tab_idx][0] = calc.cck_mean_gain_bias;
+ h2c_gain->cck_rpl_bias_comp[tab_idx][1] = calc.cck_mean_gain_bias;
+
+ for (i = 0; i < TIA_GAIN_NUM; i++) {
+ h2c_gain->gain_err_tia[tab_idx][i] =
+ cpu_to_le16(gain->tia_gain[gain_band][bw_idx][path][i]);
+ }
+ memcpy(h2c_gain->gain_err_lna[tab_idx],
+ gain->lna_gain[gain_band][bw_idx][path],
+ LNA_GAIN_NUM);
+ memcpy(h2c_gain->op1db_lna[tab_idx],
+ gain->lna_op1db[gain_band][bw_idx][path],
+ LNA_GAIN_NUM);
+ memcpy(h2c_gain->op1db_tia[tab_idx],
+ gain->tia_lna_op1db[gain_band][bw_idx][path],
+ LNA_GAIN_NUM + 1);
+
+ memcpy(h2c_gain->rpl_bias_comp_bw[tab_idx]._20M,
+ gain->rpl_ofst_20[gain_band][path],
+ RTW89_BW20_SC_20M);
+ memcpy(h2c_gain->rpl_bias_comp_bw[tab_idx]._40M,
+ gain->rpl_ofst_40[gain_band][path],
+ RTW89_BW20_SC_40M);
+ memcpy(h2c_gain->rpl_bias_comp_bw[tab_idx]._80M,
+ gain->rpl_ofst_80[gain_band][path],
+ RTW89_BW20_SC_80M);
+ memcpy(h2c_gain->rpl_bias_comp_bw[tab_idx]._160M,
+ gain->rpl_ofst_160[gain_band][path],
+ RTW89_BW20_SC_160M);
+ }
+}
+
+int rtw89_fw_h2c_lps_ml_cmn_info_v1(struct rtw89_dev *rtwdev,
+ struct rtw89_vif *rtwvif)
+{
+ static const u8 bcn_bw_ofst[] = {0, 0, 0, 3, 6, 9, 0, 12};
+ const struct rtw89_chip_info *chip = rtwdev->chip;
+ struct rtw89_efuse *efuse = &rtwdev->efuse;
+ struct rtw89_h2c_lps_ml_cmn_info_v1 *h2c;
+ struct rtw89_vif_link *rtwvif_link;
+ const struct rtw89_chan *chan;
+ struct rtw89_bb_ctx *bb;
+ u32 len = sizeof(*h2c);
+ unsigned int link_id;
+ struct sk_buff *skb;
+ u8 beacon_bw_ofst;
+ u32 done;
+ int ret;
+
+ if (chip->chip_gen != RTW89_CHIP_BE)
+ return 0;
+
+ skb = rtw89_fw_h2c_alloc_skb_with_hdr(rtwdev, len);
+ if (!skb) {
+ rtw89_err(rtwdev, "failed to alloc skb for h2c lps_ml_cmn_info_v1\n");
+ return -ENOMEM;
+ }
+ skb_put(skb, len);
+ h2c = (struct rtw89_h2c_lps_ml_cmn_info_v1 *)skb->data;
+
+ h2c->fmt_id = 0x20;
+
+ h2c->mlo_dbcc_mode = cpu_to_le32(rtwdev->mlo_dbcc_mode);
+ h2c->rfe_type = efuse->rfe_type;
+ h2c->rssi_main = U8_MAX;
+
+ memset(h2c->link_id, 0xfe, RTW89_BB_PS_LINK_BUF_MAX);
+
+ rtw89_vif_for_each_link(rtwvif, rtwvif_link, link_id) {
+ u8 phy_idx = rtwvif_link->phy_idx;
+
+ bb = rtw89_get_bb_ctx(rtwdev, phy_idx);
+ chan = rtw89_chan_get(rtwdev, rtwvif_link->chanctx_idx);
+
+ h2c->link_id[phy_idx] = phy_idx;
+ h2c->central_ch[phy_idx] = chan->channel;
+ h2c->pri_ch[phy_idx] = chan->primary_channel;
+ h2c->band[phy_idx] = chan->band_type;
+ h2c->bw[phy_idx] = chan->band_width;
+
+ if (rtwvif_link->bcn_bw_idx < ARRAY_SIZE(bcn_bw_ofst)) {
+ beacon_bw_ofst = bcn_bw_ofst[rtwvif_link->bcn_bw_idx];
+ h2c->dup_bcn_ofst[phy_idx] = beacon_bw_ofst;
+ }
+
+ if (h2c->rssi_main > bb->ch_info.rssi_min)
+ h2c->rssi_main = bb->ch_info.rssi_min;
+
+ rtw89_bb_lps_cmn_info_rx_gain_fill(rtwdev,
+ &h2c->rx_gain[phy_idx],
+ chan, phy_idx);
+ }
+
+ rtw89_h2c_pkt_set_hdr(rtwdev, skb, FWCMD_TYPE_H2C,
+ H2C_CAT_OUTSRC, H2C_CL_OUTSRC_DM,
+ H2C_FUNC_FW_LPS_ML_CMN_INFO, 0, 0, len);
+
+ rtw89_phy_write32_mask(rtwdev, R_CHK_LPS_STAT_BE4, B_CHK_LPS_STAT, 0);
+ ret = rtw89_h2c_tx(rtwdev, skb, false);
+ if (ret) {
+ rtw89_err(rtwdev, "failed to send h2c\n");
+ goto fail;
+ }
+
+ ret = read_poll_timeout(rtw89_phy_read32_mask, done, done, 50, 5000,
+ true, rtwdev, R_CHK_LPS_STAT_BE4, B_CHK_LPS_STAT);
+ if (ret)
+ rtw89_warn(rtwdev, "h2c_lps_ml_cmn_info done polling timeout\n");
+
+ return 0;
+fail:
+ dev_kfree_skb_any(skb);
+
+ return ret;
+}
+
#define H2C_P2P_ACT_LEN 20
int rtw89_fw_h2c_p2p_act(struct rtw89_dev *rtwdev,
struct rtw89_vif_link *rtwvif_link,
diff --git a/drivers/net/wireless/realtek/rtw89/fw.h b/drivers/net/wireless/realtek/rtw89/fw.h
index 12e798f01df7..146403d285b4 100644
--- a/drivers/net/wireless/realtek/rtw89/fw.h
+++ b/drivers/net/wireless/realtek/rtw89/fw.h
@@ -2017,6 +2017,66 @@ struct rtw89_h2c_lps_ml_cmn_info {
u8 dup_bcn_ofst[RTW89_PHY_NUM];
} __packed;
+#define BB_RX_GAIN_TB_RSSI_COMP_NUM 3
+#define BB_RX_GAIN_CCK_RPL_BIAS_COMP_NUM 2
+#define BB_GT2_GS_IDX_NUM 11
+#define BB_GT2_WB_GIDX_ELNA_NUM 16
+#define BB_GT2_G_ELNA_NUM 2
+
+enum rtw89_bb_link_rx_gain_table_type {
+ RTW89_BB_PS_LINK_RX_GAIN_TAB_BCN_PATH_A = 0x00,
+ RTW89_BB_PS_LINK_RX_GAIN_TAB_BCN_PATH_B = 0x01,
+ RTW89_BB_PS_LINK_RX_GAIN_TAB_NOR_PATH_A = 0x02,
+ RTW89_BB_PS_LINK_RX_GAIN_TAB_NOR_PATH_B = 0x03,
+ RTW89_BB_PS_LINK_RX_GAIN_TAB_MAX,
+};
+
+enum rtw89_bb_ps_link_buf_id {
+ RTW89_BB_PS_LINK_BUF_0 = 0x00,
+ RTW89_BB_PS_LINK_BUF_1 = 0x01,
+ RTW89_BB_PS_LINK_BUF_2 = 0x02,
+ RTW89_BB_PS_LINK_BUF_MAX,
+};
+
+struct rtw89_bb_link_info_rx_gain {
+ u8 gain_ofst[RTW89_BB_PS_LINK_RX_GAIN_TAB_MAX];
+ __le16 rpl_bias_comp[RTW89_BB_PS_LINK_RX_GAIN_TAB_MAX];
+ u8 tb_rssi_m_bias_comp[RTW89_BB_PS_LINK_RX_GAIN_TAB_MAX]
+ [BB_RX_GAIN_TB_RSSI_COMP_NUM];
+ u8 cck_gain_ofst[RTW89_BB_PS_LINK_RX_GAIN_TAB_MAX];
+ u8 cck_rpl_bias_comp[RTW89_BB_PS_LINK_RX_GAIN_TAB_MAX]
+ [BB_RX_GAIN_CCK_RPL_BIAS_COMP_NUM];
+ u8 gain_err_lna[RTW89_BB_PS_LINK_RX_GAIN_TAB_MAX][LNA_GAIN_NUM];
+ __le16 gain_err_tia[RTW89_BB_PS_LINK_RX_GAIN_TAB_MAX][TIA_GAIN_NUM];
+ u8 op1db_lna[RTW89_BB_PS_LINK_RX_GAIN_TAB_MAX][LNA_GAIN_NUM];
+ u8 op1db_tia[RTW89_BB_PS_LINK_RX_GAIN_TAB_MAX][TIA_LNA_OP1DB_NUM];
+ struct {
+ u8 _20M[RTW89_BW20_SC_20M];
+ u8 _40M[RTW89_BW20_SC_40M];
+ u8 _80M[RTW89_BW20_SC_80M];
+ u8 _160M[RTW89_BW20_SC_160M];
+ } rpl_bias_comp_bw[RTW89_BB_PS_LINK_RX_GAIN_TAB_MAX];
+ u8 wb_gs[RTW89_BB_PS_LINK_RX_GAIN_TAB_MAX][BB_GT2_GS_IDX_NUM];
+ u8 bypass_lna[RTW89_BB_PS_LINK_RX_GAIN_TAB_MAX][LNA_GAIN_NUM];
+ u8 wb_lna_tia[RTW89_BB_PS_LINK_RX_GAIN_TAB_MAX][BB_GT2_WB_GIDX_ELNA_NUM];
+ u8 wb_g_elna[RTW89_BB_PS_LINK_RX_GAIN_TAB_MAX][BB_GT2_G_ELNA_NUM];
+} __packed;
+
+struct rtw89_h2c_lps_ml_cmn_info_v1 {
+ u8 fmt_id;
+ u8 rfe_type;
+ u8 rssi_main;
+ u8 rsvd0;
+ __le32 mlo_dbcc_mode;
+ u8 link_id[RTW89_BB_PS_LINK_BUF_MAX];
+ u8 central_ch[RTW89_BB_PS_LINK_BUF_MAX];
+ u8 pri_ch[RTW89_BB_PS_LINK_BUF_MAX];
+ u8 bw[RTW89_BB_PS_LINK_BUF_MAX];
+ u8 band[RTW89_BB_PS_LINK_BUF_MAX];
+ u8 dup_bcn_ofst[RTW89_BB_PS_LINK_BUF_MAX];
+ struct rtw89_bb_link_info_rx_gain rx_gain[RTW89_BB_PS_LINK_BUF_MAX];
+} __packed;
+
struct rtw89_h2c_trig_cpu_except {
__le32 w0;
} __packed;
@@ -5204,6 +5264,11 @@ int rtw89_fw_h2c_lps_parm(struct rtw89_dev *rtwdev,
int rtw89_fw_h2c_lps_ch_info(struct rtw89_dev *rtwdev, struct rtw89_vif *rtwvif);
int rtw89_fw_h2c_lps_ml_cmn_info(struct rtw89_dev *rtwdev,
struct rtw89_vif *rtwvif);
+void rtw89_bb_lps_cmn_info_rx_gain_fill(struct rtw89_dev *rtwdev,
+ struct rtw89_bb_link_info_rx_gain *h2c_gain,
+ const struct rtw89_chan *chan, u8 phy_idx);
+int rtw89_fw_h2c_lps_ml_cmn_info_v1(struct rtw89_dev *rtwdev,
+ struct rtw89_vif *rtwvif);
int rtw89_fw_h2c_fwips(struct rtw89_dev *rtwdev, struct rtw89_vif_link *rtwvif_link,
bool enable);
struct sk_buff *rtw89_fw_h2c_alloc_skb_with_hdr(struct rtw89_dev *rtwdev, u32 len);
diff --git a/drivers/net/wireless/realtek/rtw89/ps.c b/drivers/net/wireless/realtek/rtw89/ps.c
index abd8aee02b47..aad2ee7926d6 100644
--- a/drivers/net/wireless/realtek/rtw89/ps.c
+++ b/drivers/net/wireless/realtek/rtw89/ps.c
@@ -189,6 +189,8 @@ void rtw89_enter_lps(struct rtw89_dev *rtwdev, struct rtw89_vif *rtwvif,
if (RTW89_CHK_FW_FEATURE(LPS_CH_INFO, &rtwdev->fw))
rtw89_fw_h2c_lps_ch_info(rtwdev, rtwvif);
+ else if (RTW89_CHK_FW_FEATURE(LPS_ML_INFO_V1, &rtwdev->fw))
+ rtw89_fw_h2c_lps_ml_cmn_info_v1(rtwdev, rtwvif);
else
rtw89_fw_h2c_lps_ml_cmn_info(rtwdev, rtwvif);
diff --git a/drivers/net/wireless/realtek/rtw89/reg.h b/drivers/net/wireless/realtek/rtw89/reg.h
index efeb4507b1a9..14f4f9f7f10d 100644
--- a/drivers/net/wireless/realtek/rtw89/reg.h
+++ b/drivers/net/wireless/realtek/rtw89/reg.h
@@ -8551,6 +8551,7 @@
#define B_UPD_P0_EN BIT(31)
#define R_EMLSR 0x0044
#define B_EMLSR_PARM GENMASK(27, 12)
+#define R_CHK_LPS_STAT_BE4 0x3007C
#define R_CHK_LPS_STAT 0x0058
#define B_CHK_LPS_STAT BIT(0)
#define R_SPOOF_CG 0x00B4
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 2/9] wifi: rtw89: phy: handle C2H event for PS mode report
From: Ping-Ke Shih @ 2026-01-17 4:41 UTC (permalink / raw)
To: linux-wireless; +Cc: echuang, phhuang, kevin_yang
In-Reply-To: <20260117044157.2392958-1-pkshih@realtek.com>
From: Eric Huang <echuang@realtek.com>
Introduce support for processing the new PS C2H report, enabling
detailed debugging of low-power state hardware changes.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/debug.h | 1 +
drivers/net/wireless/realtek/rtw89/fw.h | 20 ++++++++
drivers/net/wireless/realtek/rtw89/phy.c | 59 ++++++++++++++++++++++
drivers/net/wireless/realtek/rtw89/phy.h | 1 +
4 files changed, 81 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw89/debug.h b/drivers/net/wireless/realtek/rtw89/debug.h
index a364e7adb079..7cdceb24f52d 100644
--- a/drivers/net/wireless/realtek/rtw89/debug.h
+++ b/drivers/net/wireless/realtek/rtw89/debug.h
@@ -31,6 +31,7 @@ enum rtw89_debug_mask {
RTW89_DBG_CHAN = BIT(20),
RTW89_DBG_ACPI = BIT(21),
RTW89_DBG_EDCCA = BIT(22),
+ RTW89_DBG_PS = BIT(23),
RTW89_DBG_UNEXP = BIT(31),
};
diff --git a/drivers/net/wireless/realtek/rtw89/fw.h b/drivers/net/wireless/realtek/rtw89/fw.h
index 018b3bed57d2..12e798f01df7 100644
--- a/drivers/net/wireless/realtek/rtw89/fw.h
+++ b/drivers/net/wireless/realtek/rtw89/fw.h
@@ -3829,6 +3829,26 @@ struct rtw89_c2h_ra_rpt {
#define RTW89_C2H_RA_RPT_W3_MD_SEL_B2 BIT(15)
#define RTW89_C2H_RA_RPT_W3_BW_B2 BIT(16)
+struct rtw89_c2h_lps_rpt {
+ struct rtw89_c2h_hdr hdr;
+ u8 type;
+ u8 cnt_bbcr;
+ u8 cnt_bbmcucr;
+ u8 cnt_rfcr;
+ u8 data[];
+ /*
+ * The layout of data:
+ * u8 info[][4], size = total_len - size of below fields
+ * __le16 bbcr_addr[], size = cnt_bbcr
+ * __le32 bbcr_data[], size = cnt_bbcr
+ * __le16 bbmcucr_addr[], size = cnt_bbmcucr
+ * __le32 bbmcucr_data[], size = cnt_bbmcucr
+ * __le16 rfcr_addr[], size = cnt_rfcr
+ * __le32 rfcr_data_a[], size = cnt_rfcr
+ * __le32 rfcr_data_b[], size = cnt_rfcr
+ */
+} __packed;
+
struct rtw89_c2h_fw_scan_rpt {
struct rtw89_c2h_hdr hdr;
u8 phy_idx;
diff --git a/drivers/net/wireless/realtek/rtw89/phy.c b/drivers/net/wireless/realtek/rtw89/phy.c
index 0b72d3dcf666..6059f40f34b3 100644
--- a/drivers/net/wireless/realtek/rtw89/phy.c
+++ b/drivers/net/wireless/realtek/rtw89/phy.c
@@ -3217,6 +3217,64 @@ rtw89_phy_c2h_lowrt_rty(struct rtw89_dev *rtwdev, struct sk_buff *c2h, u32 len)
{
}
+static void
+rtw89_phy_c2h_lps_rpt(struct rtw89_dev *rtwdev, struct sk_buff *c2h, u32 len)
+{
+ const struct rtw89_c2h_lps_rpt *c2h_rpt = (const void *)c2h->data;
+ const __le32 *data_a, *data_b;
+ u16 len_info, cr_len, idx;
+ const __le16 *addr;
+ const u8 *info;
+
+ /* elements size of BBCR/BBMCUCR/RFCR are 6/6/10 bytes respectively */
+ cr_len = c2h_rpt->cnt_bbcr * 6 +
+ c2h_rpt->cnt_bbmcucr * 6 +
+ c2h_rpt->cnt_rfcr * 10;
+ len_info = len - (sizeof(*c2h_rpt) + cr_len);
+
+ if (len < sizeof(*c2h_rpt) + cr_len || len_info % 4 != 0) {
+ rtw89_debug(rtwdev, RTW89_DBG_PS,
+ "Invalid LPS RPT len(%d) TYPE(%d) CRCNT: BB(%d) MCU(%d) RF(%d)\n",
+ len, c2h_rpt->type, c2h_rpt->cnt_bbcr,
+ c2h_rpt->cnt_bbmcucr, c2h_rpt->cnt_rfcr);
+ return;
+ }
+
+ rtw89_debug(rtwdev, RTW89_DBG_PS,
+ "LPS RPT TYPE(%d), CRCNT: BB(%d) MCU(%d) RF(%d)\n",
+ c2h_rpt->type, c2h_rpt->cnt_bbcr,
+ c2h_rpt->cnt_bbmcucr, c2h_rpt->cnt_rfcr);
+
+ info = &c2h_rpt->data[0];
+ for (idx = 0; idx < len_info; idx += 4, info += 4)
+ rtw89_debug(rtwdev, RTW89_DBG_PS,
+ "BB LPS INFO (%02d) - 0x%02x,0x%02x,0x%02x,0x%02x\n",
+ idx, info[3], info[2], info[1], info[0]);
+
+ addr = (const void *)(info);
+ data_a = (const void *)(addr + c2h_rpt->cnt_bbcr);
+ for (idx = 0; idx < c2h_rpt->cnt_bbcr; idx++, addr++, data_a++)
+ rtw89_debug(rtwdev, RTW89_DBG_PS,
+ "LPS BB CR - 0x%04x=0x%08x\n",
+ le16_to_cpu(*addr), le32_to_cpu(*data_a));
+
+ addr = (const void *)data_a;
+ data_a = (const void *)(addr + c2h_rpt->cnt_bbmcucr);
+ for (idx = 0; idx < c2h_rpt->cnt_bbmcucr; idx++, addr++, data_a++)
+ rtw89_debug(rtwdev, RTW89_DBG_PS,
+ "LPS BBMCU - 0x%04x=0x%08x\n",
+ le16_to_cpu(*addr), le32_to_cpu(*data_a));
+
+ addr = (const void *)data_a;
+ data_a = (const void *)(addr + c2h_rpt->cnt_rfcr);
+ data_b = (const void *)(data_a + c2h_rpt->cnt_rfcr);
+ for (idx = 0; idx < c2h_rpt->cnt_rfcr; idx++, addr++, data_a++, data_b++)
+ rtw89_debug(rtwdev, RTW89_DBG_PS,
+ "LPS RFCR - 0x%04x=0x%05x,0x%05x\n",
+ le16_to_cpu(*addr), le32_to_cpu(*data_a),
+ le32_to_cpu(*data_b));
+}
+
static void
rtw89_phy_c2h_fw_scan_rpt(struct rtw89_dev *rtwdev, struct sk_buff *c2h, u32 len)
{
@@ -3238,6 +3296,7 @@ void (* const rtw89_phy_c2h_dm_handler[])(struct rtw89_dev *rtwdev,
[RTW89_PHY_C2H_DM_FUNC_SIGB] = NULL,
[RTW89_PHY_C2H_DM_FUNC_LOWRT_RTY] = rtw89_phy_c2h_lowrt_rty,
[RTW89_PHY_C2H_DM_FUNC_MCC_DIG] = NULL,
+ [RTW89_PHY_C2H_DM_FUNC_LPS] = rtw89_phy_c2h_lps_rpt,
[RTW89_PHY_C2H_DM_FUNC_FW_SCAN] = rtw89_phy_c2h_fw_scan_rpt,
};
diff --git a/drivers/net/wireless/realtek/rtw89/phy.h b/drivers/net/wireless/realtek/rtw89/phy.h
index 9caacffd0af8..5c6df5bfbe10 100644
--- a/drivers/net/wireless/realtek/rtw89/phy.h
+++ b/drivers/net/wireless/realtek/rtw89/phy.h
@@ -165,6 +165,7 @@ enum rtw89_phy_c2h_dm_func {
RTW89_PHY_C2H_DM_FUNC_SIGB,
RTW89_PHY_C2H_DM_FUNC_LOWRT_RTY,
RTW89_PHY_C2H_DM_FUNC_MCC_DIG,
+ RTW89_PHY_C2H_DM_FUNC_LPS = 0x9,
RTW89_PHY_C2H_DM_FUNC_FW_SCAN = 0xc,
RTW89_PHY_C2H_DM_FUNC_NUM,
};
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 1/9] wifi: rtw89: phy: add chip_ops to calculate RX gain from efuse to support PS mode
From: Ping-Ke Shih @ 2026-01-17 4:41 UTC (permalink / raw)
To: linux-wireless; +Cc: echuang, phhuang, kevin_yang
In-Reply-To: <20260117044157.2392958-1-pkshih@realtek.com>
In PS mode, it needs to restore RX gain settings while waking up. Add to
get RX gain values from chip specific ops, and pass these data to firmware
when going to enter PS mode.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/core.h | 25 +++++++++++++++++++
drivers/net/wireless/realtek/rtw89/rtw8851b.c | 1 +
drivers/net/wireless/realtek/rtw89/rtw8852a.c | 1 +
drivers/net/wireless/realtek/rtw89/rtw8852b.c | 1 +
.../net/wireless/realtek/rtw89/rtw8852bt.c | 1 +
drivers/net/wireless/realtek/rtw89/rtw8852c.c | 1 +
drivers/net/wireless/realtek/rtw89/rtw8922a.c | 1 +
7 files changed, 31 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw89/core.h b/drivers/net/wireless/realtek/rtw89/core.h
index 1abd09d9d29c..5c3684064d38 100644
--- a/drivers/net/wireless/realtek/rtw89/core.h
+++ b/drivers/net/wireless/realtek/rtw89/core.h
@@ -23,6 +23,7 @@ struct rtw89_efuse_block_cfg;
struct rtw89_h2c_rf_tssi;
struct rtw89_fw_txpwr_track_cfg;
struct rtw89_phy_rfk_log_fmt;
+struct rtw89_phy_calc_efuse_gain;
struct rtw89_debugfs;
struct rtw89_regd_data;
struct rtw89_wow_cam_info;
@@ -3822,6 +3823,11 @@ struct rtw89_chip_ops {
s8 pw_ofst, enum rtw89_mac_idx mac_idx);
void (*digital_pwr_comp)(struct rtw89_dev *rtwdev,
enum rtw89_phy_idx phy_idx);
+ void (*calc_rx_gain_normal)(struct rtw89_dev *rtwdev,
+ const struct rtw89_chan *chan,
+ enum rtw89_rf_path path,
+ enum rtw89_phy_idx phy_idx,
+ struct rtw89_phy_calc_efuse_gain *calc);
int (*pwr_on_func)(struct rtw89_dev *rtwdev);
int (*pwr_off_func)(struct rtw89_dev *rtwdev);
void (*query_rxdesc)(struct rtw89_dev *rtwdev,
@@ -5887,6 +5893,12 @@ struct rtw89_phy_efuse_gain {
s8 comp[RF_PATH_MAX][RTW89_SUBBAND_NR]; /* S(8, 0) */
};
+struct rtw89_phy_calc_efuse_gain {
+ s8 cck_mean_gain_bias;
+ s8 cck_rpl_ofst;
+ s8 rssi_ofst;
+};
+
#define RTW89_MAX_PATTERN_NUM 18
#define RTW89_MAX_PATTERN_MASK_SIZE 4
#define RTW89_MAX_PATTERN_SIZE 128
@@ -7341,6 +7353,19 @@ static inline void rtw89_chip_digital_pwr_comp(struct rtw89_dev *rtwdev,
chip->ops->digital_pwr_comp(rtwdev, phy_idx);
}
+static inline
+void rtw89_chip_calc_rx_gain_normal(struct rtw89_dev *rtwdev,
+ const struct rtw89_chan *chan,
+ enum rtw89_rf_path path,
+ enum rtw89_phy_idx phy_idx,
+ struct rtw89_phy_calc_efuse_gain *calc)
+{
+ const struct rtw89_chip_info *chip = rtwdev->chip;
+
+ if (chip->ops->calc_rx_gain_normal)
+ chip->ops->calc_rx_gain_normal(rtwdev, chan, path, phy_idx, calc);
+}
+
static inline void rtw89_load_txpwr_table(struct rtw89_dev *rtwdev,
const struct rtw89_txpwr_table *tbl)
{
diff --git a/drivers/net/wireless/realtek/rtw89/rtw8851b.c b/drivers/net/wireless/realtek/rtw89/rtw8851b.c
index 0383d3b5c7bc..d6deb44a685b 100644
--- a/drivers/net/wireless/realtek/rtw89/rtw8851b.c
+++ b/drivers/net/wireless/realtek/rtw89/rtw8851b.c
@@ -2530,6 +2530,7 @@ static const struct rtw89_chip_ops rtw8851b_chip_ops = {
.cfg_txrx_path = rtw8851b_bb_cfg_txrx_path,
.set_txpwr_ul_tb_offset = rtw8851b_set_txpwr_ul_tb_offset,
.digital_pwr_comp = NULL,
+ .calc_rx_gain_normal = NULL,
.pwr_on_func = rtw8851b_pwr_on_func,
.pwr_off_func = rtw8851b_pwr_off_func,
.query_rxdesc = rtw89_core_query_rxdesc,
diff --git a/drivers/net/wireless/realtek/rtw89/rtw8852a.c b/drivers/net/wireless/realtek/rtw89/rtw8852a.c
index 329fc0a7b07b..5ea7a36ab5ab 100644
--- a/drivers/net/wireless/realtek/rtw89/rtw8852a.c
+++ b/drivers/net/wireless/realtek/rtw89/rtw8852a.c
@@ -2224,6 +2224,7 @@ static const struct rtw89_chip_ops rtw8852a_chip_ops = {
.cfg_txrx_path = NULL,
.set_txpwr_ul_tb_offset = rtw8852a_set_txpwr_ul_tb_offset,
.digital_pwr_comp = NULL,
+ .calc_rx_gain_normal = NULL,
.pwr_on_func = NULL,
.pwr_off_func = NULL,
.query_rxdesc = rtw89_core_query_rxdesc,
diff --git a/drivers/net/wireless/realtek/rtw89/rtw8852b.c b/drivers/net/wireless/realtek/rtw89/rtw8852b.c
index f44674a39e30..197e3f5fb21b 100644
--- a/drivers/net/wireless/realtek/rtw89/rtw8852b.c
+++ b/drivers/net/wireless/realtek/rtw89/rtw8852b.c
@@ -857,6 +857,7 @@ static const struct rtw89_chip_ops rtw8852b_chip_ops = {
.cfg_txrx_path = rtw8852bx_bb_cfg_txrx_path,
.set_txpwr_ul_tb_offset = rtw8852bx_set_txpwr_ul_tb_offset,
.digital_pwr_comp = NULL,
+ .calc_rx_gain_normal = NULL,
.pwr_on_func = rtw8852b_pwr_on_func,
.pwr_off_func = rtw8852b_pwr_off_func,
.query_rxdesc = rtw89_core_query_rxdesc,
diff --git a/drivers/net/wireless/realtek/rtw89/rtw8852bt.c b/drivers/net/wireless/realtek/rtw89/rtw8852bt.c
index ab60ed389ff7..92bbd6e5d699 100644
--- a/drivers/net/wireless/realtek/rtw89/rtw8852bt.c
+++ b/drivers/net/wireless/realtek/rtw89/rtw8852bt.c
@@ -703,6 +703,7 @@ static const struct rtw89_chip_ops rtw8852bt_chip_ops = {
.cfg_txrx_path = rtw8852bx_bb_cfg_txrx_path,
.set_txpwr_ul_tb_offset = rtw8852bx_set_txpwr_ul_tb_offset,
.digital_pwr_comp = NULL,
+ .calc_rx_gain_normal = NULL,
.pwr_on_func = rtw8852bt_pwr_on_func,
.pwr_off_func = rtw8852bt_pwr_off_func,
.query_rxdesc = rtw89_core_query_rxdesc,
diff --git a/drivers/net/wireless/realtek/rtw89/rtw8852c.c b/drivers/net/wireless/realtek/rtw89/rtw8852c.c
index d2138be3640d..de5d343f80a5 100644
--- a/drivers/net/wireless/realtek/rtw89/rtw8852c.c
+++ b/drivers/net/wireless/realtek/rtw89/rtw8852c.c
@@ -3065,6 +3065,7 @@ static const struct rtw89_chip_ops rtw8852c_chip_ops = {
.cfg_txrx_path = rtw8852c_bb_cfg_txrx_path,
.set_txpwr_ul_tb_offset = rtw8852c_set_txpwr_ul_tb_offset,
.digital_pwr_comp = NULL,
+ .calc_rx_gain_normal = NULL,
.pwr_on_func = rtw8852c_pwr_on_func,
.pwr_off_func = rtw8852c_pwr_off_func,
.query_rxdesc = rtw89_core_query_rxdesc,
diff --git a/drivers/net/wireless/realtek/rtw89/rtw8922a.c b/drivers/net/wireless/realtek/rtw89/rtw8922a.c
index 6d2cd914e16e..0a3c2207dd4b 100644
--- a/drivers/net/wireless/realtek/rtw89/rtw8922a.c
+++ b/drivers/net/wireless/realtek/rtw89/rtw8922a.c
@@ -2838,6 +2838,7 @@ static const struct rtw89_chip_ops rtw8922a_chip_ops = {
.cfg_txrx_path = rtw8922a_bb_cfg_txrx_path,
.set_txpwr_ul_tb_offset = NULL,
.digital_pwr_comp = rtw8922a_digital_pwr_comp,
+ .calc_rx_gain_normal = NULL,
.pwr_on_func = rtw8922a_pwr_on_func,
.pwr_off_func = rtw8922a_pwr_off_func,
.query_rxdesc = rtw89_core_query_rxdesc_v2,
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 0/9] wifi: rtw89: update PHY RX gain, EDCCA and TSSI, and MAC settings for RTL8922DE
From: Ping-Ke Shih @ 2026-01-17 4:41 UTC (permalink / raw)
To: linux-wireless; +Cc: echuang, phhuang, kevin_yang
First 6 patches are related to PHY, including RX gain associated with PS
mode, EDCCA log, digital compensation of fw_elements, and TSSI. The later
three patches are related to MAC, which can improve performance but we
missed these settings previously.
Eric Huang (3):
wifi: rtw89: phy: handle C2H event for PS mode report
wifi: rtw89: phy: add H2C command to send detail RX gain and link
parameters for PS mode
wifi: rtw89: phy: update edcca log parsing for RTL8922D
Ping-Ke Shih (4):
wifi: rtw89: phy: add chip_ops to calculate RX gain from efuse to
support PS mode
wifi: rtw89: phy: add firmware element of digital TX power
compensation
wifi: rtw89: mac: clear DTOP disable excluding CID7090 variant for
RTL8922D
wifi: rtw89: mac: set force MBA duration to 0
Po-Hao Huang (1):
wifi: rtw89: 8922a: add digital compensation for 2GHz
Zong-Zhe Yang (1):
wifi: rtw89: phy: update TSSI flow for RTL8922D
drivers/net/wireless/realtek/rtw89/chan.c | 23 +++
drivers/net/wireless/realtek/rtw89/core.h | 38 ++++
drivers/net/wireless/realtek/rtw89/debug.h | 1 +
drivers/net/wireless/realtek/rtw89/fw.c | 185 +++++++++++++++++-
drivers/net/wireless/realtek/rtw89/fw.h | 86 ++++++++
drivers/net/wireless/realtek/rtw89/mac_be.c | 6 +-
drivers/net/wireless/realtek/rtw89/phy.c | 125 ++++++++++--
drivers/net/wireless/realtek/rtw89/phy.h | 1 +
drivers/net/wireless/realtek/rtw89/ps.c | 2 +
drivers/net/wireless/realtek/rtw89/reg.h | 1 +
drivers/net/wireless/realtek/rtw89/rtw8851b.c | 1 +
drivers/net/wireless/realtek/rtw89/rtw8852a.c | 1 +
drivers/net/wireless/realtek/rtw89/rtw8852b.c | 1 +
.../net/wireless/realtek/rtw89/rtw8852bt.c | 1 +
drivers/net/wireless/realtek/rtw89/rtw8852c.c | 1 +
drivers/net/wireless/realtek/rtw89/rtw8922a.c | 58 +++++-
16 files changed, 499 insertions(+), 32 deletions(-)
base-commit: 5e632c7ca9e15a1bc1e114bcfd5210add909e7a4
--
2.25.1
^ permalink raw reply
* [wireless-next:main] BUILD SUCCESS 3d2515fdd336b2c785f0568c3b015920261cca10
From: kernel test robot @ 2026-01-16 20:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
branch HEAD: 3d2515fdd336b2c785f0568c3b015920261cca10 wifi: mac80211: add support for encryption/decryption of (Re)Association frames
elapsed time: 721m
configs tested: 213
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-22
arc defconfig gcc-15.2.0
arc haps_hs_defconfig gcc-15.2.0
arc hsdk_defconfig gcc-15.2.0
arc randconfig-001-20260116 gcc-13.4.0
arc randconfig-001-20260116 gcc-8.5.0
arc randconfig-001-20260117 gcc-12.5.0
arc randconfig-002-20260116 gcc-8.5.0
arc randconfig-002-20260116 gcc-9.5.0
arc randconfig-002-20260117 gcc-12.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm am200epdkit_defconfig clang-22
arm defconfig gcc-15.2.0
arm mxs_defconfig clang-22
arm randconfig-001-20260116 gcc-15.2.0
arm randconfig-001-20260116 gcc-8.5.0
arm randconfig-001-20260117 gcc-12.5.0
arm randconfig-002-20260116 gcc-8.5.0
arm randconfig-002-20260117 gcc-12.5.0
arm randconfig-003-20260116 clang-22
arm randconfig-003-20260116 gcc-8.5.0
arm randconfig-003-20260117 gcc-12.5.0
arm randconfig-004-20260116 gcc-8.5.0
arm randconfig-004-20260117 gcc-12.5.0
arm realview_defconfig clang-22
arm64 allmodconfig clang-22
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260116 clang-20
hexagon randconfig-001-20260117 clang-22
hexagon randconfig-002-20260116 clang-20
hexagon randconfig-002-20260117 clang-22
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260116 gcc-12
i386 buildonly-randconfig-002-20260116 gcc-12
i386 buildonly-randconfig-003-20260116 gcc-12
i386 buildonly-randconfig-004-20260116 gcc-12
i386 buildonly-randconfig-005-20260116 gcc-12
i386 buildonly-randconfig-006-20260116 gcc-12
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260116 clang-20
i386 randconfig-002-20260116 clang-20
i386 randconfig-003-20260116 clang-20
i386 randconfig-004-20260116 clang-20
i386 randconfig-005-20260116 clang-20
i386 randconfig-006-20260116 clang-20
i386 randconfig-007-20260116 clang-20
i386 randconfig-011-20260116 clang-20
i386 randconfig-011-20260117 gcc-14
i386 randconfig-012-20260116 clang-20
i386 randconfig-012-20260117 gcc-14
i386 randconfig-013-20260116 clang-20
i386 randconfig-013-20260117 gcc-14
i386 randconfig-014-20260116 clang-20
i386 randconfig-014-20260117 gcc-14
i386 randconfig-015-20260116 clang-20
i386 randconfig-015-20260117 gcc-14
i386 randconfig-016-20260116 clang-20
i386 randconfig-016-20260117 gcc-14
i386 randconfig-017-20260116 clang-20
i386 randconfig-017-20260117 gcc-14
loongarch allmodconfig clang-22
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260116 clang-20
loongarch randconfig-001-20260117 clang-22
loongarch randconfig-002-20260116 clang-20
loongarch randconfig-002-20260117 clang-22
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips bigsur_defconfig gcc-15.2.0
nios2 allmodconfig clang-22
nios2 allnoconfig clang-22
nios2 defconfig clang-19
nios2 randconfig-001-20260116 clang-20
nios2 randconfig-001-20260117 clang-22
nios2 randconfig-002-20260116 clang-20
nios2 randconfig-002-20260117 clang-22
openrisc allmodconfig clang-22
openrisc allnoconfig clang-22
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-22
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260116 clang-22
parisc randconfig-001-20260117 clang-22
parisc randconfig-002-20260116 clang-22
parisc randconfig-002-20260117 clang-22
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-22
powerpc bamboo_defconfig gcc-15.2.0
powerpc lite5200b_defconfig clang-22
powerpc mpc885_ads_defconfig gcc-15.2.0
powerpc pcm030_defconfig clang-22
powerpc ps3_defconfig clang-22
powerpc randconfig-001-20260116 clang-22
powerpc randconfig-001-20260117 clang-22
powerpc randconfig-002-20260116 clang-22
powerpc randconfig-002-20260117 clang-22
powerpc64 randconfig-001-20260116 clang-22
powerpc64 randconfig-001-20260117 clang-22
powerpc64 randconfig-002-20260116 clang-22
powerpc64 randconfig-002-20260117 clang-22
riscv allmodconfig clang-22
riscv allnoconfig clang-22
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260116 gcc-15.2.0
riscv randconfig-002-20260116 gcc-15.2.0
s390 allmodconfig clang-19
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260116 gcc-15.2.0
s390 randconfig-002-20260116 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-22
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260116 gcc-15.2.0
sh randconfig-002-20260116 gcc-15.2.0
sh rsk7269_defconfig clang-22
sh se7750_defconfig clang-22
sh se7750_defconfig gcc-15.2.0
sparc allnoconfig clang-22
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260116 gcc-10.5.0
sparc randconfig-001-20260117 gcc-14.3.0
sparc randconfig-002-20260116 gcc-10.5.0
sparc randconfig-002-20260117 gcc-14.3.0
sparc64 alldefconfig gcc-15.2.0
sparc64 allmodconfig clang-22
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260116 gcc-10.5.0
sparc64 randconfig-001-20260117 gcc-14.3.0
sparc64 randconfig-002-20260116 gcc-10.5.0
sparc64 randconfig-002-20260117 gcc-14.3.0
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260116 gcc-10.5.0
um randconfig-001-20260117 gcc-14.3.0
um randconfig-002-20260116 gcc-10.5.0
um randconfig-002-20260117 gcc-14.3.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260116 gcc-14
x86_64 buildonly-randconfig-002-20260116 gcc-14
x86_64 buildonly-randconfig-003-20260116 gcc-14
x86_64 buildonly-randconfig-004-20260116 gcc-14
x86_64 buildonly-randconfig-005-20260116 gcc-14
x86_64 buildonly-randconfig-006-20260116 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260116 clang-20
x86_64 randconfig-002-20260116 clang-20
x86_64 randconfig-003-20260116 clang-20
x86_64 randconfig-004-20260116 clang-20
x86_64 randconfig-005-20260116 clang-20
x86_64 randconfig-006-20260116 clang-20
x86_64 randconfig-011-20260116 clang-20
x86_64 randconfig-012-20260116 clang-20
x86_64 randconfig-013-20260116 clang-20
x86_64 randconfig-014-20260116 clang-20
x86_64 randconfig-015-20260116 clang-20
x86_64 randconfig-016-20260116 clang-20
x86_64 randconfig-071-20260116 clang-20
x86_64 randconfig-072-20260116 clang-20
x86_64 randconfig-073-20260116 clang-20
x86_64 randconfig-074-20260116 clang-20
x86_64 randconfig-075-20260116 clang-20
x86_64 randconfig-076-20260116 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-22
xtensa allyesconfig clang-22
xtensa randconfig-001-20260116 gcc-10.5.0
xtensa randconfig-001-20260117 gcc-14.3.0
xtensa randconfig-002-20260116 gcc-10.5.0
xtensa randconfig-002-20260117 gcc-14.3.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] wifi: wlcore: Add support for IGTK key
From: Peter Åstrand @ 2026-01-16 17:58 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 2003 bytes --]
This change re-applies commit 2b7aadd3b9e1 ("wlcore: Adding suppoprt for IGTK key in
wlcore driver") (sic), but only enables WLAN_CIPHER_SUITE_AES_CMAC with modern
firmware. This patch is required to support WPA3 connections.
Signed-off-by: Peter Åstrand <astrand@lysator.liu.se>
---
drivers/net/wireless/ti/wlcore/cmd.h | 1 +
drivers/net/wireless/ti/wlcore/main.c | 9 +++++++++
2 files changed, 10 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/cmd.h b/drivers/net/wireless/ti/wlcore/cmd.h
index d16afb35f9ee..f8160f372bc7 100644
--- a/drivers/net/wireless/ti/wlcore/cmd.h
+++ b/drivers/net/wireless/ti/wlcore/cmd.h
@@ -455,6 +455,7 @@ enum wl1271_cmd_key_type {
KEY_TKIP = 2,
KEY_AES = 3,
KEY_GEM = 4,
+ KEY_IGTK = 5,
};
struct wl1271_cmd_set_keys {
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 12f0167d7380..dce79bce2e3f 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -2419,6 +2419,11 @@ static int wl12xx_init_fw(struct wl1271 *wl)
strscpy(wiphy->fw_version, wl->chip.fw_ver_str,
sizeof(wiphy->fw_version));
+ /* WLAN_CIPHER_SUITE_AES_CMAC must be last in cipher_suites;
+ support only with firmware 8.9.1 and newer */
+ if (wl->chip.fw_ver[FW_VER_MAJOR] < 1)
+ wl->hw->wiphy->n_cipher_suites--;
+
/*
* Now we know if 11a is supported (info from the NVS), so disable
* 11a channels if not supported
@@ -3585,6 +3590,9 @@ int wlcore_set_key(struct wl1271 *wl, enum set_key_cmd cmd,
case WL1271_CIPHER_SUITE_GEM:
key_type = KEY_GEM;
break;
+ case WLAN_CIPHER_SUITE_AES_CMAC:
+ key_type = KEY_IGTK;
+ break;
default:
wl1271_error("Unknown key algo 0x%x", key_conf->cipher);
@@ -6196,6 +6204,7 @@ static int wl1271_init_ieee80211(struct wl1271 *wl)
WLAN_CIPHER_SUITE_TKIP,
WLAN_CIPHER_SUITE_CCMP,
WL1271_CIPHER_SUITE_GEM,
+ WLAN_CIPHER_SUITE_AES_CMAC,
};
/* The tx descriptor buffer */
--
2.30.2
Br,
Peter Åstrand
^ permalink raw reply related
* Re: [PATCH] wifi: mt76: Fix memory leak after mt76_connac_mcu_alloc_sta_req()
From: Markus Elfring @ 2026-01-16 16:56 UTC (permalink / raw)
To: Zilin Guan, linux-wireless, linux-mediatek, linux-arm-kernel,
Felix Fietkau
Cc: LKML, Angelo Gioacchino Del Regno, Jianhao Xu, Lorenzo Bianconi,
Matthias Brugger, Ryder Lee, Sean Wang, Shayne Chen
In-Reply-To: <20260116144919.1482558-1-zilin@seu.edu.cn>
…
> Fix this by explicitly freeing the skb in these error paths.
…
How do you think about to avoid a bit of duplicate source code here?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?h=v6.19-rc5#n526
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2 04/14] wifi: ath10k: snoc: support powering on the device via pwrseq
From: Krzysztof Kozlowski @ 2026-01-16 16:47 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Jeff Johnson, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Jeff Johnson,
Bjorn Andersson, Konrad Dybcio, Manivannan Sadhasivam, Vinod Koul,
Balakrishna Godavarthi, Matthias Kaehlcke, linux-arm-msm,
linux-kernel, devicetree, linux-bluetooth, linux-wireless, ath10k,
linux-pm, Bartosz Golaszewski
In-Reply-To: <d4ttsbhlw4c2fvgpfwgnc5mdh2egc6nwluj5pmkst2sunpn6m7@7b6by2eboob4>
On 16/01/2026 17:41, Dmitry Baryshkov wrote:
> On Fri, Jan 16, 2026 at 05:08:58PM +0100, Krzysztof Kozlowski wrote:
>> On 16/01/2026 16:18, Jeff Johnson wrote:
>>> On 1/15/2026 11:48 PM, Krzysztof Kozlowski wrote:
>>>> On 15/01/2026 23:30, Jeff Johnson wrote:
>>>>> On 1/5/2026 5:01 PM, Dmitry Baryshkov wrote:
>>>>>> The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading
>>>>>> voltages over internal rails. Implement support for using powersequencer
>>>>>> for this family of ATH10k devices in addition to using regulators.
>>>>>>
>>>>>> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>>>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>>>>> ---
>>>>>> drivers/net/wireless/ath/ath10k/snoc.c | 54 ++++++++++++++++++++++++++++++++--
>>>>>> drivers/net/wireless/ath/ath10k/snoc.h | 2 ++
>>>>>
>>>>> My automation flagged:
>>>>> * drivers/net/wireless/ath/ath10k/snoc.c has no QTI copyright
>>>>> * drivers/net/wireless/ath/ath10k/snoc.h has no QTI copyright
>>>>> * 2 copyright issues
>>>>>
>>>>> I'll add these manually in my 'pending' branch
>>>>>
>>>>
>>>> And why is this a problem? You are not here to impose Qualcomm rules, bu
>>>> care about Linux kernel. You cannot add copyrights based on what exactly?
>>>
>>> I am a maintainer that is paid by Qualcomm to perform that role, and hence I
>>> have a duty to enforce the legal guidance from Qualcomm when it comes to
>>> contributions from other Qualcomm employees.
>>
>> No, it's not your duty to enforce rules from some other departments or
>> business units. Especially not without agreement of that person. You
>> cannot just add copyrights to other people's commits just because you
>> think that such copyrights should be there. Only the copyright owner -
>> which you did not identify here and email address of contributor does
>> not imply that (you don't even know what work contract a person has) -
>> can add such copyrights.
>
> In this particular usecase Jeff has enough knowledge about me and my
> working place. I will have to resend the series anyway, but otherwise it
> was perfectly fine for him to correct the copyright.
Fine, but please do not add copyrights yourself to any of my code. It's
fine to point is a reviewing comment and expect clarifications on my
side, I don't find changing people's code and adding there copyrights as
right way.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 04/14] wifi: ath10k: snoc: support powering on the device via pwrseq
From: Dmitry Baryshkov @ 2026-01-16 16:41 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jeff Johnson, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Jeff Johnson,
Bjorn Andersson, Konrad Dybcio, Manivannan Sadhasivam, Vinod Koul,
Balakrishna Godavarthi, Matthias Kaehlcke, linux-arm-msm,
linux-kernel, devicetree, linux-bluetooth, linux-wireless, ath10k,
linux-pm, Bartosz Golaszewski
In-Reply-To: <f35b1380-b7d4-45e7-94ad-9f76973d3289@kernel.org>
On Fri, Jan 16, 2026 at 05:08:58PM +0100, Krzysztof Kozlowski wrote:
> On 16/01/2026 16:18, Jeff Johnson wrote:
> > On 1/15/2026 11:48 PM, Krzysztof Kozlowski wrote:
> >> On 15/01/2026 23:30, Jeff Johnson wrote:
> >>> On 1/5/2026 5:01 PM, Dmitry Baryshkov wrote:
> >>>> The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading
> >>>> voltages over internal rails. Implement support for using powersequencer
> >>>> for this family of ATH10k devices in addition to using regulators.
> >>>>
> >>>> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> >>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> >>>> ---
> >>>> drivers/net/wireless/ath/ath10k/snoc.c | 54 ++++++++++++++++++++++++++++++++--
> >>>> drivers/net/wireless/ath/ath10k/snoc.h | 2 ++
> >>>
> >>> My automation flagged:
> >>> * drivers/net/wireless/ath/ath10k/snoc.c has no QTI copyright
> >>> * drivers/net/wireless/ath/ath10k/snoc.h has no QTI copyright
> >>> * 2 copyright issues
> >>>
> >>> I'll add these manually in my 'pending' branch
> >>>
> >>
> >> And why is this a problem? You are not here to impose Qualcomm rules, bu
> >> care about Linux kernel. You cannot add copyrights based on what exactly?
> >
> > I am a maintainer that is paid by Qualcomm to perform that role, and hence I
> > have a duty to enforce the legal guidance from Qualcomm when it comes to
> > contributions from other Qualcomm employees.
>
> No, it's not your duty to enforce rules from some other departments or
> business units. Especially not without agreement of that person. You
> cannot just add copyrights to other people's commits just because you
> think that such copyrights should be there. Only the copyright owner -
> which you did not identify here and email address of contributor does
> not imply that (you don't even know what work contract a person has) -
> can add such copyrights.
In this particular usecase Jeff has enough knowledge about me and my
working place. I will have to resend the series anyway, but otherwise it
was perfectly fine for him to correct the copyright.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH wireless-next v2 00/34] wifi: inffmac: introducing a driver for Infineon's new generation chipsets
From: Gokul Sivakumar @ 2026-01-16 16:33 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-wireless, Johannes Berg, Arend van Spriel,
wlan-kernel-dev-list
In-Reply-To: <66e4ddb8-47ac-4b2a-8c4b-6f407aa1d8eb@nabladev.com>
On 01/15, Marek Vasut wrote:
> On 1/14/26 9:12 AM, Gokul Sivakumar wrote:
> > On 01/14, Marek Vasut wrote:
> > > On 1/13/26 9:33 PM, Gokul Sivakumar wrote:
> > > > Infineon(Cypress) is introducing a new INFFMAC (WLAN FULLMAC) Linux driver
> > > > specifically for its new-generation AIROC family of Wi-Fi Connectivity
> > > > Processor (CP) chipsets (CYW5591x), Wi-Fi + Bluetooth combo chipsets
> > > > (CYW5557x, CYW5551x, CYW5591x, CYW43022), and also for all future chipsets.
> > > Support for the CYW55572 can be easily added into the existing brcmfmac
> > > driver, I already posted a patch over a year ago [1], but it was blocked
> > > by an off-list email.
> >
> > > Frankly, I do not see any good reason why the brcmfmac driver shouldn't
> > > be extended when it is clearly easily doable. Adding new fork of the
> > > brcmfmac would only increase maintenance burden and prevent bugfixes
> > > from reaching the brcmfmac.
> > >
> > > [1] https://lore.kernel.org/all/20240909203133.74777-2-marex@denx.de/
> >
> > There are multiple reasons behind Infineon's proposal for this new INFFMAC
> > driver for its new-generation chips. Sharing a few here, and more info
> > is available in the v1 cover-letter [1]. For Example, the CYW5591x family
> > chipsets that is currently supported in this INFFMAC driver has a unique
> > Connected-MCU / Connectivtiy Processor (CP) Architecture [2], primarly
> > intended for IoT applications and it is completely different from any of
> > the legacy Broadcom architecture chipsets of Infineon supported currently
> > in upstream BRCMFMAC.
>
> This does not prevent them from being integrated in brcmfmac like many
> of the other already supported chips, there seems to be no technical
> reason here.
I hope you would have got a chance to look into the elaborate info provided
in v1 cover-letter about the challenges that we faced with that approach.
In Infineon's new architecture CYW5591x family of chipsets coming with an
onboard FLASH Memory, it does not follow the traditional Device firmware
download sequence used by any of the legacy Broadcom chipsets and it would
be appropriate to use a dedicated driver for Infineon's chipsets which were
developed and intended mainly for IoT use-cases.
Here it requires a Boot firmware download, and a host handshake with the
downloaded RAM boot firmware, followed by a CP Firmware image Download and
validation. Sharing here the sequence for coldboot image download to FLASH.
Host Driver Device
___________ ____________
| |
| Power UP and execute CP Firmware
| from FLASH if available
Attempt to enable SDIO F2 |
if fails, FLASH is empty, |
Need to Download Firmware |
| |
Wait for |
DFU_CP_D2H_MSG_BL_READY |
|<<======== DFU_CP_D2H_MSG_BL_READY <<============|
| |
Fetch Boot Firmware |
from Filesystem |
|======>> DFU_CP_H2D_MSG_BOOT_FWLOAD_START =====>>|
| |
|======>> Transfer Boot Firmware over SDIO =====>>|
| in multiple chunks |
| |
|======>> DFU_CP_H2D_MSG_BOOT_FWLOAD_DONE ======>>|
| Execute the downloaded
| RAM Bootloader
Wait for |
DFU_CP_D2H_MSG_BOOTFW_READY |
|<<========= DFU_CP_D2H_MSG_BOOTFW_READY <<=======|
| |
Fetch CP Firmware |
from Filesystem |
|=======>> Transfer CP Firmware over SDIO ======>>|
| in multiple chunks |
| Download CP Firmware
| to FLASH Memory
| |
|=======>> DFU_CP_H2D_MSG_BOOTFW_DATA_LOADED ====>|
| |
|=======>> DFU_CP_D2H_MSG_FW_VALIDAT_START ======>|
| |
Wait for Validate the CP Firmware
DFU_CP_D2H_MSG_FW_VALIDAT_DONE |
|<<======= DFU_CP_D2H_MSG_FW_VALIDAT_DONE <<======|
| |
| Execute the CP Firmware
Proceed with |
ctrl cmds to Device |
| |
Here there is no need to redownload the Device Firmware from the Host
filesystem everyime the Host or Device goes through a power cycle. Also the
device is capable of fully operating in an offloaded mode even when the
host is in suspended state or even if fully powered off. This is critical
to save power for extended durations in IoT use cases which are often
battery operated.
> > The CYW5591x family chipsets has dedicated MCU Core
> > in addition to the WLAN core and an onboard FLASH memory for the Firmware.
>
> It seems all brcmfmac devices have a cortex-M core in them since a long
> time.
We were intending to mention that CYW5591x Cortex-M33 core is dedicated to
function as a Co-Processor to the Host CPU/MCU and offload multiple wifi
and network operations if configured by the user before host goes to sleep.
You can refer the chipset block diagram in CYW55913/2/1 Product Brief [1]
The CYW5591x SoC Backplane interconnects are also different from any of the
legacy Broadcom chipsets.
> > And with respect to the support for the new-generation CYW5557x family of
> > Secure chipsets, that requires a Secure boot handshake with the Bootloader.
>
> It seems like the TRX firmware loading is trivial to add, and parts of
> it are already in the Linux kernel for other brcm components. It seems
> this TRX was used since old broadcom MIPS SoCs.
No, your understanding needs a correction. Infineon's TRXSE and TRXS Device
Bootloader handshake and Firmware formats are quite different from the old
Broadcom TRX formats that you are mentioning here. Being two individual
WLAN vendors, the chipset internals, firmware formats, Device Bootloader
handshake cannot be expected to be the same. Yet another reason why it is
not practically feasible to use upstream BRCMFMAC for the new-generation
chipsets and new firmware releases from Infineon.
> > Even if the enumeration and firmware download support for the CYW55572 is
> > somehow retro-fitted into the existing upstream BRCMFMAC driver, there are
> > multiple other features and aspects of the Driver-Device communication that
> > are unique to each WLAN vendor, which are not always practically feasible
> > to support in the same upstream driver.
>
> Why ?
As mentioned before, various aspects of the Driver-Device communication are
unique to each WLAN vendor. And it is not practically feasible to confine
them into a common upstream driver, also not sustainable to maintain it that
way througout the lifetime of the hardware.
> > Because currently BRCMFMAC driver
> > has a shared ownership with more than 3 WLAN vendor organizations and this
> > approach has its limitations.
>
> Yes, this means it is necessary to cooperate and coordinate with other
> people, on the mailing list.
Infineon is committed to coordinate with other vendors in managing upstream
BRCMFMAC driver and continuing the support for its legacy chipsets that
still follows the legacy Broadcom architecture. Like for example, we have
added support for CYW54591-PCIe in upstream BRCMFMAC few months back [2],
because it has many things in common with other legacy Broadcom chips.
But the same does not applies for all the new-generation Infineon chipsets.
> > For Example, the version of the PCIe and SDIO
> > BUS specific shared info in Device Memory is expected same from chipsets
> > from all vendors. There would be a complex need to maintain vendor specifc
> > as well as BUS specific Shared info version, vendor specific BUS Protocol
> > layers, vendor specific firmware event header OUIs (currently always expects
> > BRCM OUI even from other vendor chips) and even more.
>
> This sounds like code refactoring is necessary.
>
> > Confining different architecture chips from different WLAN vendors into the
> > same legacy BRCMFMAC driver codebase, may not be sustainable and could
> > potentially increase the maintainence effort and codebase complexity.
> > And not practically feasible to continue splitting this driver with more
> > vendor specific checks in the longer run. Since being different vendors,
> > each will only naturally diverge even more in the future with their chipset
> > Architecture, Driver-Device communication flow, etc. Infineon will continue
> > to support its legacy chipsets, already supported in the upstream BRCMFMAC.
> Maybe all the extra functionality can be added later, and the driver can
> be forked later, when it becomes clear that refactoring is not an option
> and it is becoming too difficult to maintain ?
Refactoring the existing upstream BRCMFMAC driver for the new-architecture
chipsets developed by Infineon is not a practical option now because these
devices are fairly new. In the lifetime of these devices, the functionality
of the Devices and Driver interaction are only going to evolve even more.
Eventually, it would become more cumbersome to maintain as well as to avoid
regressions for different architecture chips from different WLAN vendors
if same upstream driver is used.
We strongly believe that this is an appropriate time for thinking about a
proposal to proceed with a dedicated driver for the new-generation chips
developed individually by Infineon.
> So far, it seems the current generation chips can be easily added to
> brcmfmac, even if the feature set would be limited. Adding them would
We are not in the same page here. As mentioned earlier and as you might
know, there is infact much more to it than adding enumeration support for a
chip in a driver. Certainly not easy when eventually Infineon is required
to enable the end users with the actual capabilities of the chipset, also
Infineon has the responsibility to ensure driver compatibility with all the
newly shipped Device firmwares.
> allow the maintainers to review such a smaller patchset and get at least
> some hardware support in, step by step, instead of this mega-patchset.
We understood that review bandwidth is limited and have taken the feedback
received on v1 very seriously, so multiple features were already stripped
off in v2. Willing to skip even more functionality in the upcoming versions
and also ready to provide more information as needed to make the INFFMAC
driver review as much easy as possible.
[1] https://www.infineon.com/assets/row/public/documents/30/45/infineon-airoc-tm-cyw55913-2-1-connected-mcu-with-wi-fi-bluetooth-r-low-energy-5-productbrief-en.pdf
[2] https://lore.kernel.org/linux-wireless/20250624093453.7264-1-ian.lin@infineon.com/
Gokul
^ permalink raw reply
* Re: [PATCH v2 04/14] wifi: ath10k: snoc: support powering on the device via pwrseq
From: Krzysztof Kozlowski @ 2026-01-16 16:08 UTC (permalink / raw)
To: Jeff Johnson, Dmitry Baryshkov, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Jeff Johnson, Bjorn Andersson, Konrad Dybcio,
Manivannan Sadhasivam, Vinod Koul, Balakrishna Godavarthi,
Matthias Kaehlcke
Cc: linux-arm-msm, linux-kernel, devicetree, linux-bluetooth,
linux-wireless, ath10k, linux-pm, Bartosz Golaszewski
In-Reply-To: <132c34db-07c6-491b-bfda-f3c51462a184@oss.qualcomm.com>
On 16/01/2026 16:18, Jeff Johnson wrote:
> On 1/15/2026 11:48 PM, Krzysztof Kozlowski wrote:
>> On 15/01/2026 23:30, Jeff Johnson wrote:
>>> On 1/5/2026 5:01 PM, Dmitry Baryshkov wrote:
>>>> The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading
>>>> voltages over internal rails. Implement support for using powersequencer
>>>> for this family of ATH10k devices in addition to using regulators.
>>>>
>>>> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>>> ---
>>>> drivers/net/wireless/ath/ath10k/snoc.c | 54 ++++++++++++++++++++++++++++++++--
>>>> drivers/net/wireless/ath/ath10k/snoc.h | 2 ++
>>>
>>> My automation flagged:
>>> * drivers/net/wireless/ath/ath10k/snoc.c has no QTI copyright
>>> * drivers/net/wireless/ath/ath10k/snoc.h has no QTI copyright
>>> * 2 copyright issues
>>>
>>> I'll add these manually in my 'pending' branch
>>>
>>
>> And why is this a problem? You are not here to impose Qualcomm rules, bu
>> care about Linux kernel. You cannot add copyrights based on what exactly?
>
> I am a maintainer that is paid by Qualcomm to perform that role, and hence I
> have a duty to enforce the legal guidance from Qualcomm when it comes to
> contributions from other Qualcomm employees.
No, it's not your duty to enforce rules from some other departments or
business units. Especially not without agreement of that person. You
cannot just add copyrights to other people's commits just because you
think that such copyrights should be there. Only the copyright owner -
which you did not identify here and email address of contributor does
not imply that (you don't even know what work contract a person has) -
can add such copyrights.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] wifi: wlcore: avoid oops when reading tsf from debugfs
From: Peter Åstrand @ 2026-01-16 15:31 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]
In this case, read lock on dev_base_lock is active so calling pm_runtime_resume_and_get
or wl12xx_acx_tsf_info will cause Oops like:
[ 182.282540] BUG: scheduling while atomic: cat/269/0x00000002
Signed-off-by: Peter Åstrand <astrand@lysator.liu.se>
---
drivers/net/wireless/ti/wlcore/main.c | 6 ++++++
drivers/net/wireless/ti/wlcore/wlcore_i.h | 3 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 12f0167d7380..1e368050e5d7 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -2338,6 +2338,7 @@ static int wl12xx_init_vif_data(struct wl1271 *wl, struct ieee80211_vif *vif)
wlvif->bitrate_masks[NL80211_BAND_2GHZ] = wl->conf.tx.basic_rate;
wlvif->bitrate_masks[NL80211_BAND_5GHZ] = wl->conf.tx.basic_rate_5;
wlvif->beacon_int = WL1271_DEFAULT_BEACON_INT;
+ wlvif->debug_tsf = ULLONG_MAX;
/*
* mac80211 configures some values globally, while we treat them
@@ -4988,6 +4989,10 @@ static u64 wl1271_op_get_tsf(struct ieee80211_hw *hw,
wl1271_debug(DEBUG_MAC80211, "mac80211 get tsf");
+ /* Return cached value to debugfs */
+ if (!preemptible())
+ return wlvif->debug_tsf;
+
mutex_lock(&wl->mutex);
if (unlikely(wl->state != WLCORE_STATE_ON))
@@ -5000,6 +5005,7 @@ static u64 wl1271_op_get_tsf(struct ieee80211_hw *hw,
ret = wl12xx_acx_tsf_info(wl, wlvif, &mactime);
if (ret < 0)
goto out_sleep;
+ wlvif->debug_tsf = mactime;
out_sleep:
pm_runtime_put_autosuspend(wl->dev);
diff --git a/drivers/net/wireless/ti/wlcore/wlcore_i.h b/drivers/net/wireless/ti/wlcore/wlcore_i.h
index 5bdcb341629c..1b9bb131f470 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore_i.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore_i.h
@@ -490,6 +490,9 @@ struct wl12xx_vif {
*/
u64 total_freed_pkts;
+ /* cached tsf for debugfs */
+ u64 debug_tsf;
+
/*
* This struct must be last!
* data that has to be saved acrossed reconfigs (e.g. recovery)
--
2.30.2
Br,
Peter Åstrand
^ permalink raw reply related
* Re: [PATCH v2 04/14] wifi: ath10k: snoc: support powering on the device via pwrseq
From: Jeff Johnson @ 2026-01-16 15:18 UTC (permalink / raw)
To: Krzysztof Kozlowski, Dmitry Baryshkov, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Jeff Johnson, Bjorn Andersson, Konrad Dybcio,
Manivannan Sadhasivam, Vinod Koul, Balakrishna Godavarthi,
Matthias Kaehlcke
Cc: linux-arm-msm, linux-kernel, devicetree, linux-bluetooth,
linux-wireless, ath10k, linux-pm, Bartosz Golaszewski
In-Reply-To: <15470b51-d398-449d-9017-304df5ad7cef@kernel.org>
On 1/15/2026 11:48 PM, Krzysztof Kozlowski wrote:
> On 15/01/2026 23:30, Jeff Johnson wrote:
>> On 1/5/2026 5:01 PM, Dmitry Baryshkov wrote:
>>> The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading
>>> voltages over internal rails. Implement support for using powersequencer
>>> for this family of ATH10k devices in addition to using regulators.
>>>
>>> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/snoc.c | 54 ++++++++++++++++++++++++++++++++--
>>> drivers/net/wireless/ath/ath10k/snoc.h | 2 ++
>>
>> My automation flagged:
>> * drivers/net/wireless/ath/ath10k/snoc.c has no QTI copyright
>> * drivers/net/wireless/ath/ath10k/snoc.h has no QTI copyright
>> * 2 copyright issues
>>
>> I'll add these manually in my 'pending' branch
>>
>
> And why is this a problem? You are not here to impose Qualcomm rules, bu
> care about Linux kernel. You cannot add copyrights based on what exactly?
I am a maintainer that is paid by Qualcomm to perform that role, and hence I
have a duty to enforce the legal guidance from Qualcomm when it comes to
contributions from other Qualcomm employees.
/jeff
^ 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