* RE: [PATCH rtw-next v2 3/3] wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 17aa:b736
From: Ping-Ke Shih @ 2026-06-17 8:24 UTC (permalink / raw)
To: William Hansen-Baird
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260616141620.91081-4-william.hansen.baird@gmail.com>
William Hansen-Baird <william.hansen.baird@gmail.com> wrote:
> RTL8723BE outputs a large amount of PCIe AER errors during and
> after boot, even before probe and when driver is never loaded.
> This causes significant system slowdown.
>
> The errors are the same as reported by
> commit 77a6407c6ab2 ("wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723")
>
> Add the RTL8723BE with subsystem ID 17aa:b736 to the rtl_aspm_quirks
> table to stop the AER errors. AER errors can still be present prior to
> pci probe, as the device by default may have ASPM enabled.
>
> Testing on a Razer Blade 14 2017 which shipped from the
> OEM equipped with an RTL8723BE card with this subsystem ID
> confirms that this patch resolves the AER flood and allows the
> wireless card to function normally once the driver takes over.
>
> Signed-off-by: William Hansen-Baird <william.hansen.baird@gmail.com>
Only minor suggestion, so
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
> ---
> drivers/net/wireless/realtek/rtlwifi/pci.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c
> b/drivers/net/wireless/realtek/rtlwifi/pci.c
> index 9de396879806..9919c8588cbd 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/pci.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
> @@ -33,6 +33,7 @@ static const u8 ac_to_hwq[] = {
>
> static const struct pci_device_id rtl_aspm_quirks[] = {
> { PCI_DEVICE_SUB(PCI_VENDOR_ID_REALTEK, 0xb723, 0x11ad, 0x1723) },
> + { PCI_DEVICE_SUB(PCI_VENDOR_ID_REALTEK, 0xb723, 0x17aa, 0xb736) },
Would you like a comment "Razer Blade 14 2017"?
> { 0 }
> };
>
> --
> 2.54.0
^ permalink raw reply
* RE: [PATCH rtw-next v2 2/3] wifi: rtlwifi: convert pci if-statement to ID table
From: Ping-Ke Shih @ 2026-06-17 8:22 UTC (permalink / raw)
To: William Hansen-Baird
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260616141620.91081-3-william.hansen.baird@gmail.com>
William Hansen-Baird <william.hansen.baird@gmail.com> wrote:
> Refactor the ASUSTek quirk logic from an if-statement to a standard
> rtl_aspm_quirks pci_device_id table. This allows future devices with
> the same quirk to be added more easily while avoiding a large if-chain.
>
> Signed-off-by: William Hansen-Baird <william.hansen.baird@gmail.com>
> ---
> drivers/net/wireless/realtek/rtlwifi/pci.c | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c
> b/drivers/net/wireless/realtek/rtlwifi/pci.c
> index a5bab06f2b61..9de396879806 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/pci.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
> @@ -31,6 +31,11 @@ static const u8 ac_to_hwq[] = {
> BK_QUEUE
> };
>
> +static const struct pci_device_id rtl_aspm_quirks[] = {
> + { PCI_DEVICE_SUB(PCI_VENDOR_ID_REALTEK, 0xb723, 0x11ad, 0x1723) },
Would you leave a comment ASUSTek F441U/X555UQ?
> + { 0 }
Just "{}"
> +};
> +
> static u8 _rtl_mac_to_hwqueue(struct ieee80211_hw *hw, struct sk_buff *skb)
> {
> struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
> @@ -328,21 +333,17 @@ static void rtl_pci_parse_configuration(struct pci_dev *pdev,
>
> static void rtl_pci_init_aspm(struct ieee80211_hw *hw)
> {
> - struct rtl_priv *rtlpriv = rtl_priv(hw);
> struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
> struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
>
> _rtl_pci_update_default_setting(hw);
>
> - /* RTL8723BE found on some ASUSTek laptops, such as F441U and
> - * X555UQ with subsystem ID 11ad:1723 are known to output large
> + /* Certain pci devices are known to output large
Now we don't use net specific comment. Use below style:
/*
* (first line)
*/
(we should apply this style to patch 1/3 as well)
> * amounts of PCIe AER errors during and after boot up, causing
> * heavy lags, poor network throughput, and occasional lock-ups.
> */
> - if (rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8723BE &&
> - (rtlpci->pdev->subsystem_vendor == 0x11ad &&
> - rtlpci->pdev->subsystem_device == 0x1723)) {
> + if (pci_match_id(rtl_aspm_quirks, rtlpci->pdev)) {
> __rtl_pci_disable_aspm(hw);
> ppsc->support_aspm = false;
> }
>
> --
> 2.54.0
^ permalink raw reply
* RE: [PATCH rtw-next v2 1/3] wifi: rtlwifi: fix disabling of ASPM for RTL8723BE with AER flooding
From: Ping-Ke Shih @ 2026-06-17 8:18 UTC (permalink / raw)
To: William Hansen-Baird
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260616141620.91081-2-william.hansen.baird@gmail.com>
William Hansen-Baird <william.hansen.baird@gmail.com> wrote:
> commit 77a6407c6ab2 ("wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723")
> adds code which sets ppsc->support_aspm to false in
> _rtl_pci_update_default_setting() in order to disable ASPM.
> This does not, however, disable ASPM. Rather, it disables driver
> control of ASPM, and blocks calls to rtl_pci_enable_aspm()
> and rtl_pci_disable_aspm().
>
> In some cases, the pci device supplied to the probe function has
> ASPM enabled. The code would therefore not disable ASPM, as it means to,
> but rather just leave it enabled.
> This was discovered through testing on a Razer Blade 14 2017.
>
> Implement a new __rtl_pci_disable_aspm(hw) function which does not check
> ppsc->support_aspm before disabling and call it from
> rtl_pci_disable_aspm().
>
> Then move the code added in the previous commit to rtl_pci_init_aspm() to
> allow adding a call to __rtl_pci_disable_aspm(hw).
> This makes sure ASPM is disabled while still disabling
> driver control of ASPM to block it from being enabled later.
>
> Fixes: 77a6407c6ab2 ("wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723")
The commit can resolve problem from original report, so it seems like
this patch to refactor to resolve your case as well.
I'd remove this Fixes. How about you?
[...]
> @@ -330,10 +328,24 @@ static void rtl_pci_parse_configuration(struct pci_dev *pdev,
>
> static void rtl_pci_init_aspm(struct ieee80211_hw *hw)
> {
> + struct rtl_priv *rtlpriv = rtl_priv(hw);
> struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
> + struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
In reverse X'mas order.
>
> _rtl_pci_update_default_setting(hw);
>
> + /* RTL8723BE found on some ASUSTek laptops, such as F441U and
> + * X555UQ with subsystem ID 11ad:1723 are known to output large
> + * amounts of PCIe AER errors during and after boot up, causing
> + * heavy lags, poor network throughput, and occasional lock-ups.
> + */
> + if (rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8723BE &&
> + (rtlpci->pdev->subsystem_vendor == 0x11ad &&
> + rtlpci->pdev->subsystem_device == 0x1723)) {
> + __rtl_pci_disable_aspm(hw);
> + ppsc->support_aspm = false;
> + }
> +
> if (ppsc->reg_rfps_level & RT_RF_PS_LEVEL_ALWAYS_ASPM) {
> /*Always enable ASPM & Clock Req. */
> rtl_pci_enable_aspm(hw);
> --
> 2.54.0
^ permalink raw reply
* [PATCH] wifi: mt76: mt7925: fix msg len mismatch between driver and firmware
From: JB Tsai @ 2026-06-17 7:13 UTC (permalink / raw)
To: nbd, lorenzo
Cc: linux-wireless, linux-mediatek, Deren.Wu, Sean.Wang, Quan.Zhou,
Ryder.Lee, Leon.Yen, litien.chang, jared.huang, jb.tsai
From: "Jared.Huang" <jared.huang@mediatek.com>
The mt7925_tx_power_limit_tlv struct begins with a 4-byte rsv[] field
that acts as a UNI command header prefix. The firmware dispatcher did
not use the 4-byte rsv[] and will only check the payloads after the
4-byte rsv[] As a result, the total message length minus the 4-byte
prefix. Fix this by setting len to msg_len - 4.
Fixes: ccb1863 ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
Signed-off-by: Jared.Huang <jared.huang@mediatek.com>
---
drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
index e94fa544ff20..7d9b8ebf2889 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
@@ -3827,7 +3827,7 @@ mt7925_mcu_rate_txpower_band(struct mt76_phy *phy,
memcpy(tx_power_tlv->alpha2, dev->alpha2, sizeof(dev->alpha2));
tx_power_tlv->n_chan = num_ch;
tx_power_tlv->tag = cpu_to_le16(0x1);
- tx_power_tlv->len = cpu_to_le16(msg_len);
+ tx_power_tlv->len = cpu_to_le16(msg_len - 4);
switch (band) {
case NL80211_BAND_2GHZ:
--
2.45.2
^ permalink raw reply related
* [PATCH] wifi: mt76: mt7925: update clc before setting sar power table
From: JB Tsai @ 2026-06-17 7:13 UTC (permalink / raw)
To: nbd, lorenzo
Cc: linux-wireless, linux-mediatek, Deren.Wu, Sean.Wang, Quan.Zhou,
Ryder.Lee, Leon.Yen, litien.chang, jared.huang, jb.tsai
From: "Jared.Huang" <jared.huang@mediatek.com>
Fix the power table update sequence to ensure CLC is loaded before
setting SAR power table.
The firmware requires CLC baseline to be established first
to properly calculate the final power limit as min(clc_limit, rate_limit,sar_limit).
Fixes: 9557b6fe0c8b ("wifi: mt76: mt7925: refine the txpower initialization flow")
Signed-off-by: Jared.Huang <jared.huang@mediatek.com>
---
drivers/net/wireless/mediatek/mt76/mt7925/main.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
index a9059866b701..afb2b473bef7 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
@@ -1824,9 +1824,15 @@ static int mt7925_set_sar_specs(struct ieee80211_hw *hw,
int err;
mt792x_mutex_acquire(dev);
+ err = mt7925_mcu_set_clc(dev, dev->mt76.alpha2,
+ dev->country_ie_env);
+ if (err < 0)
+ goto out;
+
err = mt7925_set_tx_sar_pwr(hw, sar);
- mt792x_mutex_release(dev);
+out:
+ mt792x_mutex_release(dev);
return err;
}
--
2.45.2
^ permalink raw reply related
* Re: [PATCH ath-next] wifi: ath12k: expand UserPD ID mask to support up to 8 PDs
From: Baochen Qiang @ 2026-06-17 6:48 UTC (permalink / raw)
To: Aaradhana Sahu, ath12k; +Cc: linux-wireless
In-Reply-To: <20260604031551.4178754-1-aaradhana.sahu@oss.qualcomm.com>
On 6/4/2026 11:15 AM, Aaradhana Sahu wrote:
> Currently ATH12K_USERPD_ID_MASK uses GENMASK(9, 8), which defines a
> 2-bit field and limits supported UserPD IDs to values 0-3.
>
> Future IPQ5332 multi-PD platform variants support more than three
> UserPDs. Expand ATH12K_USERPD_ID_MASK to GENMASK(10, 8), increasing
> the field width to 3 bits and allowing UserPD IDs from 0-7.
>
> ATH12K_USERPD_ID_MASK is currently used only while constructing the
> ath12k AHB PAS ID, so this change does not affect existing platforms.
>
> Also remove the unused ATH12K_MAX_UPDS definition.
>
> Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath9k: drop static from local pdadc and vpdTable arrays
From: kernel test robot @ 2026-06-17 6:00 UTC (permalink / raw)
To: Rosen Penev, linux-wireless
Cc: oe-kbuild-all, Toke Høiland-Jørgensen, linux-kernel
In-Reply-To: <20260616030828.655310-1-rosenp@gmail.com>
Hi Rosen,
kernel test robot noticed the following build warnings:
[auto build test WARNING on ath/ath-next]
[also build test WARNING on wireless/main wireless-next/main linus/master v7.1 next-20260616]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Rosen-Penev/wifi-ath9k-drop-static-from-local-pdadc-and-vpdTable-arrays/20260616-114515
base: https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git ath-next
patch link: https://lore.kernel.org/r/20260616030828.655310-1-rosenp%40gmail.com
patch subject: [PATCH ath-next] wifi: ath9k: drop static from local pdadc and vpdTable arrays
config: arm-allyesconfig (https://download.01.org/0day-ci/archive/20260617/202606171341.zUckYxVR-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 16.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260617/202606171341.zUckYxVR-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606171341.zUckYxVR-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/net/wireless/ath/ath9k/eeprom.c: In function 'ath9k_hw_get_gain_boundaries_pdadcs':
>> drivers/net/wireless/ath/ath9k/eeprom.c:657:1: warning: the frame size of 1360 bytes is larger than 1280 bytes [-Wframe-larger-than=]
657 | }
| ^
vim +657 drivers/net/wireless/ath/ath9k/eeprom.c
a55f858852e4345 Sujith 2010-06-01 451
115277a3bc0683d Felix Fietkau 2010-12-12 452 void ath9k_hw_get_gain_boundaries_pdadcs(struct ath_hw *ah,
115277a3bc0683d Felix Fietkau 2010-12-12 453 struct ath9k_channel *chan,
115277a3bc0683d Felix Fietkau 2010-12-12 454 void *pRawDataSet,
115277a3bc0683d Felix Fietkau 2010-12-12 455 u8 *bChans, u16 availPiers,
115277a3bc0683d Felix Fietkau 2010-12-12 456 u16 tPdGainOverlap,
115277a3bc0683d Felix Fietkau 2010-12-12 457 u16 *pPdGainBoundaries, u8 *pPDADCValues,
115277a3bc0683d Felix Fietkau 2010-12-12 458 u16 numXpdGains)
115277a3bc0683d Felix Fietkau 2010-12-12 459 {
115277a3bc0683d Felix Fietkau 2010-12-12 460 int i, j, k;
115277a3bc0683d Felix Fietkau 2010-12-12 461 int16_t ss;
115277a3bc0683d Felix Fietkau 2010-12-12 462 u16 idxL = 0, idxR = 0, numPiers;
8e792d8755eaf1a Rosen Penev 2026-06-15 463 u8 vpdTableL[AR5416_NUM_PD_GAINS]
115277a3bc0683d Felix Fietkau 2010-12-12 464 [AR5416_MAX_PWR_RANGE_IN_HALF_DB];
8e792d8755eaf1a Rosen Penev 2026-06-15 465 u8 vpdTableR[AR5416_NUM_PD_GAINS]
115277a3bc0683d Felix Fietkau 2010-12-12 466 [AR5416_MAX_PWR_RANGE_IN_HALF_DB];
8e792d8755eaf1a Rosen Penev 2026-06-15 467 u8 vpdTableI[AR5416_NUM_PD_GAINS]
115277a3bc0683d Felix Fietkau 2010-12-12 468 [AR5416_MAX_PWR_RANGE_IN_HALF_DB];
115277a3bc0683d Felix Fietkau 2010-12-12 469
115277a3bc0683d Felix Fietkau 2010-12-12 470 u8 *pVpdL, *pVpdR, *pPwrL, *pPwrR;
115277a3bc0683d Felix Fietkau 2010-12-12 471 u8 minPwrT4[AR5416_NUM_PD_GAINS];
115277a3bc0683d Felix Fietkau 2010-12-12 472 u8 maxPwrT4[AR5416_NUM_PD_GAINS];
115277a3bc0683d Felix Fietkau 2010-12-12 473 int16_t vpdStep;
115277a3bc0683d Felix Fietkau 2010-12-12 474 int16_t tmpVal;
115277a3bc0683d Felix Fietkau 2010-12-12 475 u16 sizeCurrVpdTable, maxIndex, tgtIndex;
115277a3bc0683d Felix Fietkau 2010-12-12 476 bool match;
115277a3bc0683d Felix Fietkau 2010-12-12 477 int16_t minDelta = 0;
115277a3bc0683d Felix Fietkau 2010-12-12 478 struct chan_centers centers;
115277a3bc0683d Felix Fietkau 2010-12-12 479 int pdgain_boundary_default;
115277a3bc0683d Felix Fietkau 2010-12-12 480 struct cal_data_per_freq *data_def = pRawDataSet;
115277a3bc0683d Felix Fietkau 2010-12-12 481 struct cal_data_per_freq_4k *data_4k = pRawDataSet;
940cd2c12ebff68 Felix Fietkau 2010-12-12 482 struct cal_data_per_freq_ar9287 *data_9287 = pRawDataSet;
115277a3bc0683d Felix Fietkau 2010-12-12 483 bool eeprom_4k = AR_SREV_9285(ah) || AR_SREV_9271(ah);
940cd2c12ebff68 Felix Fietkau 2010-12-12 484 int intercepts;
940cd2c12ebff68 Felix Fietkau 2010-12-12 485
940cd2c12ebff68 Felix Fietkau 2010-12-12 486 if (AR_SREV_9287(ah))
940cd2c12ebff68 Felix Fietkau 2010-12-12 487 intercepts = AR9287_PD_GAIN_ICEPTS;
940cd2c12ebff68 Felix Fietkau 2010-12-12 488 else
940cd2c12ebff68 Felix Fietkau 2010-12-12 489 intercepts = AR5416_PD_GAIN_ICEPTS;
115277a3bc0683d Felix Fietkau 2010-12-12 490
115277a3bc0683d Felix Fietkau 2010-12-12 491 memset(&minPwrT4, 0, AR5416_NUM_PD_GAINS);
115277a3bc0683d Felix Fietkau 2010-12-12 492 ath9k_hw_get_channel_centers(ah, chan, ¢ers);
115277a3bc0683d Felix Fietkau 2010-12-12 493
115277a3bc0683d Felix Fietkau 2010-12-12 494 for (numPiers = 0; numPiers < availPiers; numPiers++) {
115277a3bc0683d Felix Fietkau 2010-12-12 495 if (bChans[numPiers] == AR5416_BCHAN_UNUSED)
115277a3bc0683d Felix Fietkau 2010-12-12 496 break;
115277a3bc0683d Felix Fietkau 2010-12-12 497 }
115277a3bc0683d Felix Fietkau 2010-12-12 498
115277a3bc0683d Felix Fietkau 2010-12-12 499 match = ath9k_hw_get_lower_upper_index((u8)FREQ2FBIN(centers.synth_center,
115277a3bc0683d Felix Fietkau 2010-12-12 500 IS_CHAN_2GHZ(chan)),
115277a3bc0683d Felix Fietkau 2010-12-12 501 bChans, numPiers, &idxL, &idxR);
115277a3bc0683d Felix Fietkau 2010-12-12 502
115277a3bc0683d Felix Fietkau 2010-12-12 503 if (match) {
940cd2c12ebff68 Felix Fietkau 2010-12-12 504 if (AR_SREV_9287(ah)) {
940cd2c12ebff68 Felix Fietkau 2010-12-12 505 for (i = 0; i < numXpdGains; i++) {
940cd2c12ebff68 Felix Fietkau 2010-12-12 506 minPwrT4[i] = data_9287[idxL].pwrPdg[i][0];
83d6f1f15f8cce8 Arnd Bergmann 2016-03-14 507 maxPwrT4[i] = data_9287[idxL].pwrPdg[i][intercepts - 1];
940cd2c12ebff68 Felix Fietkau 2010-12-12 508 ath9k_hw_fill_vpd_table(minPwrT4[i], maxPwrT4[i],
940cd2c12ebff68 Felix Fietkau 2010-12-12 509 data_9287[idxL].pwrPdg[i],
940cd2c12ebff68 Felix Fietkau 2010-12-12 510 data_9287[idxL].vpdPdg[i],
940cd2c12ebff68 Felix Fietkau 2010-12-12 511 intercepts,
940cd2c12ebff68 Felix Fietkau 2010-12-12 512 vpdTableI[i]);
940cd2c12ebff68 Felix Fietkau 2010-12-12 513 }
940cd2c12ebff68 Felix Fietkau 2010-12-12 514 } else if (eeprom_4k) {
115277a3bc0683d Felix Fietkau 2010-12-12 515 for (i = 0; i < numXpdGains; i++) {
115277a3bc0683d Felix Fietkau 2010-12-12 516 minPwrT4[i] = data_4k[idxL].pwrPdg[i][0];
83d6f1f15f8cce8 Arnd Bergmann 2016-03-14 517 maxPwrT4[i] = data_4k[idxL].pwrPdg[i][intercepts - 1];
115277a3bc0683d Felix Fietkau 2010-12-12 518 ath9k_hw_fill_vpd_table(minPwrT4[i], maxPwrT4[i],
115277a3bc0683d Felix Fietkau 2010-12-12 519 data_4k[idxL].pwrPdg[i],
115277a3bc0683d Felix Fietkau 2010-12-12 520 data_4k[idxL].vpdPdg[i],
940cd2c12ebff68 Felix Fietkau 2010-12-12 521 intercepts,
115277a3bc0683d Felix Fietkau 2010-12-12 522 vpdTableI[i]);
115277a3bc0683d Felix Fietkau 2010-12-12 523 }
115277a3bc0683d Felix Fietkau 2010-12-12 524 } else {
115277a3bc0683d Felix Fietkau 2010-12-12 525 for (i = 0; i < numXpdGains; i++) {
115277a3bc0683d Felix Fietkau 2010-12-12 526 minPwrT4[i] = data_def[idxL].pwrPdg[i][0];
83d6f1f15f8cce8 Arnd Bergmann 2016-03-14 527 maxPwrT4[i] = data_def[idxL].pwrPdg[i][intercepts - 1];
115277a3bc0683d Felix Fietkau 2010-12-12 528 ath9k_hw_fill_vpd_table(minPwrT4[i], maxPwrT4[i],
115277a3bc0683d Felix Fietkau 2010-12-12 529 data_def[idxL].pwrPdg[i],
115277a3bc0683d Felix Fietkau 2010-12-12 530 data_def[idxL].vpdPdg[i],
940cd2c12ebff68 Felix Fietkau 2010-12-12 531 intercepts,
115277a3bc0683d Felix Fietkau 2010-12-12 532 vpdTableI[i]);
115277a3bc0683d Felix Fietkau 2010-12-12 533 }
115277a3bc0683d Felix Fietkau 2010-12-12 534 }
115277a3bc0683d Felix Fietkau 2010-12-12 535 } else {
115277a3bc0683d Felix Fietkau 2010-12-12 536 for (i = 0; i < numXpdGains; i++) {
940cd2c12ebff68 Felix Fietkau 2010-12-12 537 if (AR_SREV_9287(ah)) {
940cd2c12ebff68 Felix Fietkau 2010-12-12 538 pVpdL = data_9287[idxL].vpdPdg[i];
940cd2c12ebff68 Felix Fietkau 2010-12-12 539 pPwrL = data_9287[idxL].pwrPdg[i];
940cd2c12ebff68 Felix Fietkau 2010-12-12 540 pVpdR = data_9287[idxR].vpdPdg[i];
940cd2c12ebff68 Felix Fietkau 2010-12-12 541 pPwrR = data_9287[idxR].pwrPdg[i];
940cd2c12ebff68 Felix Fietkau 2010-12-12 542 } else if (eeprom_4k) {
115277a3bc0683d Felix Fietkau 2010-12-12 543 pVpdL = data_4k[idxL].vpdPdg[i];
115277a3bc0683d Felix Fietkau 2010-12-12 544 pPwrL = data_4k[idxL].pwrPdg[i];
115277a3bc0683d Felix Fietkau 2010-12-12 545 pVpdR = data_4k[idxR].vpdPdg[i];
115277a3bc0683d Felix Fietkau 2010-12-12 546 pPwrR = data_4k[idxR].pwrPdg[i];
115277a3bc0683d Felix Fietkau 2010-12-12 547 } else {
115277a3bc0683d Felix Fietkau 2010-12-12 548 pVpdL = data_def[idxL].vpdPdg[i];
115277a3bc0683d Felix Fietkau 2010-12-12 549 pPwrL = data_def[idxL].pwrPdg[i];
115277a3bc0683d Felix Fietkau 2010-12-12 550 pVpdR = data_def[idxR].vpdPdg[i];
115277a3bc0683d Felix Fietkau 2010-12-12 551 pPwrR = data_def[idxR].pwrPdg[i];
115277a3bc0683d Felix Fietkau 2010-12-12 552 }
115277a3bc0683d Felix Fietkau 2010-12-12 553
115277a3bc0683d Felix Fietkau 2010-12-12 554 minPwrT4[i] = max(pPwrL[0], pPwrR[0]);
115277a3bc0683d Felix Fietkau 2010-12-12 555
115277a3bc0683d Felix Fietkau 2010-12-12 556 maxPwrT4[i] =
940cd2c12ebff68 Felix Fietkau 2010-12-12 557 min(pPwrL[intercepts - 1],
940cd2c12ebff68 Felix Fietkau 2010-12-12 558 pPwrR[intercepts - 1]);
115277a3bc0683d Felix Fietkau 2010-12-12 559
115277a3bc0683d Felix Fietkau 2010-12-12 560
115277a3bc0683d Felix Fietkau 2010-12-12 561 ath9k_hw_fill_vpd_table(minPwrT4[i], maxPwrT4[i],
115277a3bc0683d Felix Fietkau 2010-12-12 562 pPwrL, pVpdL,
940cd2c12ebff68 Felix Fietkau 2010-12-12 563 intercepts,
115277a3bc0683d Felix Fietkau 2010-12-12 564 vpdTableL[i]);
115277a3bc0683d Felix Fietkau 2010-12-12 565 ath9k_hw_fill_vpd_table(minPwrT4[i], maxPwrT4[i],
115277a3bc0683d Felix Fietkau 2010-12-12 566 pPwrR, pVpdR,
940cd2c12ebff68 Felix Fietkau 2010-12-12 567 intercepts,
115277a3bc0683d Felix Fietkau 2010-12-12 568 vpdTableR[i]);
115277a3bc0683d Felix Fietkau 2010-12-12 569
115277a3bc0683d Felix Fietkau 2010-12-12 570 for (j = 0; j <= (maxPwrT4[i] - minPwrT4[i]) / 2; j++) {
115277a3bc0683d Felix Fietkau 2010-12-12 571 vpdTableI[i][j] =
115277a3bc0683d Felix Fietkau 2010-12-12 572 (u8)(ath9k_hw_interpolate((u16)
115277a3bc0683d Felix Fietkau 2010-12-12 573 FREQ2FBIN(centers.
115277a3bc0683d Felix Fietkau 2010-12-12 574 synth_center,
115277a3bc0683d Felix Fietkau 2010-12-12 575 IS_CHAN_2GHZ
115277a3bc0683d Felix Fietkau 2010-12-12 576 (chan)),
115277a3bc0683d Felix Fietkau 2010-12-12 577 bChans[idxL], bChans[idxR],
115277a3bc0683d Felix Fietkau 2010-12-12 578 vpdTableL[i][j], vpdTableR[i][j]));
115277a3bc0683d Felix Fietkau 2010-12-12 579 }
115277a3bc0683d Felix Fietkau 2010-12-12 580 }
115277a3bc0683d Felix Fietkau 2010-12-12 581 }
115277a3bc0683d Felix Fietkau 2010-12-12 582
115277a3bc0683d Felix Fietkau 2010-12-12 583 k = 0;
115277a3bc0683d Felix Fietkau 2010-12-12 584
115277a3bc0683d Felix Fietkau 2010-12-12 585 for (i = 0; i < numXpdGains; i++) {
115277a3bc0683d Felix Fietkau 2010-12-12 586 if (i == (numXpdGains - 1))
115277a3bc0683d Felix Fietkau 2010-12-12 587 pPdGainBoundaries[i] =
115277a3bc0683d Felix Fietkau 2010-12-12 588 (u16)(maxPwrT4[i] / 2);
115277a3bc0683d Felix Fietkau 2010-12-12 589 else
115277a3bc0683d Felix Fietkau 2010-12-12 590 pPdGainBoundaries[i] =
115277a3bc0683d Felix Fietkau 2010-12-12 591 (u16)((maxPwrT4[i] + minPwrT4[i + 1]) / 4);
115277a3bc0683d Felix Fietkau 2010-12-12 592
115277a3bc0683d Felix Fietkau 2010-12-12 593 pPdGainBoundaries[i] =
115277a3bc0683d Felix Fietkau 2010-12-12 594 min((u16)MAX_RATE_POWER, pPdGainBoundaries[i]);
115277a3bc0683d Felix Fietkau 2010-12-12 595
115277a3bc0683d Felix Fietkau 2010-12-12 596 minDelta = 0;
115277a3bc0683d Felix Fietkau 2010-12-12 597
115277a3bc0683d Felix Fietkau 2010-12-12 598 if (i == 0) {
115277a3bc0683d Felix Fietkau 2010-12-12 599 if (AR_SREV_9280_20_OR_LATER(ah))
115277a3bc0683d Felix Fietkau 2010-12-12 600 ss = (int16_t)(0 - (minPwrT4[i] / 2));
115277a3bc0683d Felix Fietkau 2010-12-12 601 else
115277a3bc0683d Felix Fietkau 2010-12-12 602 ss = 0;
115277a3bc0683d Felix Fietkau 2010-12-12 603 } else {
115277a3bc0683d Felix Fietkau 2010-12-12 604 ss = (int16_t)((pPdGainBoundaries[i - 1] -
115277a3bc0683d Felix Fietkau 2010-12-12 605 (minPwrT4[i] / 2)) -
115277a3bc0683d Felix Fietkau 2010-12-12 606 tPdGainOverlap + 1 + minDelta);
115277a3bc0683d Felix Fietkau 2010-12-12 607 }
115277a3bc0683d Felix Fietkau 2010-12-12 608 vpdStep = (int16_t)(vpdTableI[i][1] - vpdTableI[i][0]);
115277a3bc0683d Felix Fietkau 2010-12-12 609 vpdStep = (int16_t)((vpdStep < 1) ? 1 : vpdStep);
115277a3bc0683d Felix Fietkau 2010-12-12 610
115277a3bc0683d Felix Fietkau 2010-12-12 611 while ((ss < 0) && (k < (AR5416_NUM_PDADC_VALUES - 1))) {
115277a3bc0683d Felix Fietkau 2010-12-12 612 tmpVal = (int16_t)(vpdTableI[i][0] + ss * vpdStep);
115277a3bc0683d Felix Fietkau 2010-12-12 613 pPDADCValues[k++] = (u8)((tmpVal < 0) ? 0 : tmpVal);
115277a3bc0683d Felix Fietkau 2010-12-12 614 ss++;
115277a3bc0683d Felix Fietkau 2010-12-12 615 }
115277a3bc0683d Felix Fietkau 2010-12-12 616
115277a3bc0683d Felix Fietkau 2010-12-12 617 sizeCurrVpdTable = (u8) ((maxPwrT4[i] - minPwrT4[i]) / 2 + 1);
115277a3bc0683d Felix Fietkau 2010-12-12 618 tgtIndex = (u8)(pPdGainBoundaries[i] + tPdGainOverlap -
115277a3bc0683d Felix Fietkau 2010-12-12 619 (minPwrT4[i] / 2));
115277a3bc0683d Felix Fietkau 2010-12-12 620 maxIndex = (tgtIndex < sizeCurrVpdTable) ?
115277a3bc0683d Felix Fietkau 2010-12-12 621 tgtIndex : sizeCurrVpdTable;
115277a3bc0683d Felix Fietkau 2010-12-12 622
115277a3bc0683d Felix Fietkau 2010-12-12 623 while ((ss < maxIndex) && (k < (AR5416_NUM_PDADC_VALUES - 1))) {
115277a3bc0683d Felix Fietkau 2010-12-12 624 pPDADCValues[k++] = vpdTableI[i][ss++];
115277a3bc0683d Felix Fietkau 2010-12-12 625 }
115277a3bc0683d Felix Fietkau 2010-12-12 626
115277a3bc0683d Felix Fietkau 2010-12-12 627 vpdStep = (int16_t)(vpdTableI[i][sizeCurrVpdTable - 1] -
115277a3bc0683d Felix Fietkau 2010-12-12 628 vpdTableI[i][sizeCurrVpdTable - 2]);
115277a3bc0683d Felix Fietkau 2010-12-12 629 vpdStep = (int16_t)((vpdStep < 1) ? 1 : vpdStep);
115277a3bc0683d Felix Fietkau 2010-12-12 630
115277a3bc0683d Felix Fietkau 2010-12-12 631 if (tgtIndex >= maxIndex) {
115277a3bc0683d Felix Fietkau 2010-12-12 632 while ((ss <= tgtIndex) &&
115277a3bc0683d Felix Fietkau 2010-12-12 633 (k < (AR5416_NUM_PDADC_VALUES - 1))) {
115277a3bc0683d Felix Fietkau 2010-12-12 634 tmpVal = (int16_t)((vpdTableI[i][sizeCurrVpdTable - 1] +
115277a3bc0683d Felix Fietkau 2010-12-12 635 (ss - maxIndex + 1) * vpdStep));
115277a3bc0683d Felix Fietkau 2010-12-12 636 pPDADCValues[k++] = (u8)((tmpVal > 255) ?
115277a3bc0683d Felix Fietkau 2010-12-12 637 255 : tmpVal);
115277a3bc0683d Felix Fietkau 2010-12-12 638 ss++;
115277a3bc0683d Felix Fietkau 2010-12-12 639 }
115277a3bc0683d Felix Fietkau 2010-12-12 640 }
115277a3bc0683d Felix Fietkau 2010-12-12 641 }
115277a3bc0683d Felix Fietkau 2010-12-12 642
115277a3bc0683d Felix Fietkau 2010-12-12 643 if (eeprom_4k)
115277a3bc0683d Felix Fietkau 2010-12-12 644 pdgain_boundary_default = 58;
115277a3bc0683d Felix Fietkau 2010-12-12 645 else
115277a3bc0683d Felix Fietkau 2010-12-12 646 pdgain_boundary_default = pPdGainBoundaries[i - 1];
115277a3bc0683d Felix Fietkau 2010-12-12 647
115277a3bc0683d Felix Fietkau 2010-12-12 648 while (i < AR5416_PD_GAINS_IN_MASK) {
115277a3bc0683d Felix Fietkau 2010-12-12 649 pPdGainBoundaries[i] = pdgain_boundary_default;
115277a3bc0683d Felix Fietkau 2010-12-12 650 i++;
115277a3bc0683d Felix Fietkau 2010-12-12 651 }
115277a3bc0683d Felix Fietkau 2010-12-12 652
115277a3bc0683d Felix Fietkau 2010-12-12 653 while (k < AR5416_NUM_PDADC_VALUES) {
115277a3bc0683d Felix Fietkau 2010-12-12 654 pPDADCValues[k] = pPDADCValues[k - 1];
115277a3bc0683d Felix Fietkau 2010-12-12 655 k++;
115277a3bc0683d Felix Fietkau 2010-12-12 656 }
115277a3bc0683d Felix Fietkau 2010-12-12 @657 }
115277a3bc0683d Felix Fietkau 2010-12-12 658
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH ath-next v2] wifi: ath12k: avoid setting 320MHZ support on non 6GHz band
From: Rameshkumar Sundaram @ 2026-06-17 5:03 UTC (permalink / raw)
To: Nicolas Escande, ath12k; +Cc: linux-wireless
In-Reply-To: <20260611084422.1511513-1-nico.escande@gmail.com>
On 6/11/2026 2:14 PM, Nicolas Escande wrote:
> On a split phy qcn9274 (2.4GHz + 5GHz low), "iw phy" reports 320MHz
> realated features on the 5GHz band while it should not:
s/realated/related
>
> Wiphy phy1
> [...]
> Band 2:
> [...]
> EHT Iftypes: managed
> [...]
> EHT PHY Capabilities: (0xe2ffdbe018778000):
> 320MHz in 6GHz Supported
> [...]
> Beamformee SS (320MHz): 7
> [...]
> Number Of Sounding Dimensions (320MHz): 3
> [...]
> EHT MCS/NSS: (0x22222222222222222200000000):
>
> This is also reflected in the beacons sent by a mesh interface started on
> that band. They erroneously advertise 320MHZ support too.
s/320MHZ/320MHz
>
> This should not happen as the spec at section 9.4.2.323.3 says we should
Reword the spec citation to: IEEE Std 802.11-2024, subclause 9.4.2.323.3 ...
> not set the 320MHz related fields when not operating on a 6GHz band.
> For example it says about Bit 0 "Support For 320 MHz In 6 GHz"
>
> "Reserved if the EHT Capabilities element is indicating capabilities for
> the 2.4 GHz or 5 GHz bands."
>
> Fix this by clearing the related bits when converting from WMI eht phy
> capabilities to mac80211 phy capabilities, for bands other than 6GHz.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00218-QCAHKSWPL_SILICONZ-1
>
The commit log mentions wrong `iw phy` output and wrong mesh beacon
advertisement, so this appears user visible. If that is the intended bug
being fixed, please add a Fixes tag.
> Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
> ---
> Changes from v1:
> - rebased on ath-next
> - clear all 6GHz / 320MHz related phy capabilities fields from the firmware
> ---
> drivers/net/wireless/ath/ath12k/wmi.c | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
> index 84a31b953db8..a8a4654c4f34 100644
> --- a/drivers/net/wireless/ath/ath12k/wmi.c
> +++ b/drivers/net/wireless/ath/ath12k/wmi.c
> @@ -5154,6 +5154,7 @@ static void ath12k_wmi_eht_caps_parse(struct ath12k_pdev *pdev, u32 band,
> __le32 cap_info_internal)
> {
> struct ath12k_band_cap *cap_band = &pdev->cap.band[band];
> + u8 *phy_cap = (u8 *)&cap_band->eht_cap_phy_info[0];
> u32 support_320mhz;
> u8 i;
>
> @@ -5167,8 +5168,22 @@ static void ath12k_wmi_eht_caps_parse(struct ath12k_pdev *pdev, u32 band,
> for (i = 0; i < WMI_MAX_EHTCAP_PHY_SIZE; i++)
> cap_band->eht_cap_phy_info[i] = le32_to_cpu(cap_phy_info[i]);
>
> - if (band == NL80211_BAND_6GHZ)
> + if (band == NL80211_BAND_6GHZ) {
> cap_band->eht_cap_phy_info[0] |= support_320mhz;
> + } else {
> + /*
> + * It seems the firmware can report capabilities specific to
> + * 6GHz also for 5GHz, so lets explicitely clear them out.
The code comment should be less tentative, how about:
/*
* Firmware may report 6 GHz/320 MHz specific capabilities for
* non-6 GHz bands, so explicitly clear them.
*/
> + */
> + phy_cap[0] &= ~IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ;
> + phy_cap[1] &= ~IEEE80211_EHT_PHY_CAP1_BEAMFORMEE_SS_320MHZ_MASK;
> + phy_cap[2] &= ~IEEE80211_EHT_PHY_CAP2_SOUNDING_DIM_320MHZ_MASK;
> + phy_cap[3] &= ~IEEE80211_EHT_PHY_CAP3_SOUNDING_DIM_320MHZ_MASK;
> + phy_cap[6] &= ~IEEE80211_EHT_PHY_CAP6_MCS15_SUPP_320MHZ;
> + phy_cap[6] &= ~IEEE80211_EHT_PHY_CAP6_EHT_DUP_6GHZ_SUPP;
> + phy_cap[7] &= ~IEEE80211_EHT_PHY_CAP7_NON_OFDMA_UL_MU_MIMO_320MHZ;
> + phy_cap[7] &= ~IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_320MHZ; ;
> + }
>
> cap_band->eht_mcs_20_only = le32_to_cpu(supp_mcs[0]);
> cap_band->eht_mcs_80 = le32_to_cpu(supp_mcs[1]);
checkpatch warnings:
ERROR: trailing whitespace
#61: FILE: drivers/net/wireless/ath/ath12k/wmi.c:5171:
+^Iif (band == NL80211_BAND_6GHZ) {^I$
WARNING: 'explicitely' may be misspelled - perhaps 'explicitly'?
#66: FILE: drivers/net/wireless/ath/ath12k/wmi.c:5176:
+ * 6GHz also for 5GHz, so lets explicitely clear them out.
^^^^^^^^^^^
WARNING: space prohibited before semicolon
#75: FILE: drivers/net/wireless/ath/ath12k/wmi.c:5185:
+ phy_cap[7] &=
~IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_320MHZ; ;
WARNING: Statements terminations use 1 semicolon
#75: FILE: drivers/net/wireless/ath/ath12k/wmi.c:5185:
+ phy_cap[7] &=
~IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_320MHZ; ;
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: expand UserPD ID mask to support up to 8 PDs
From: Rameshkumar Sundaram @ 2026-06-17 4:07 UTC (permalink / raw)
To: Aaradhana Sahu, ath12k; +Cc: linux-wireless
In-Reply-To: <20260604031551.4178754-1-aaradhana.sahu@oss.qualcomm.com>
On 6/4/2026 8:45 AM, Aaradhana Sahu wrote:
> Currently ATH12K_USERPD_ID_MASK uses GENMASK(9, 8), which defines a
> 2-bit field and limits supported UserPD IDs to values 0-3.
>
> Future IPQ5332 multi-PD platform variants support more than three
> UserPDs. Expand ATH12K_USERPD_ID_MASK to GENMASK(10, 8), increasing
> the field width to 3 bits and allowing UserPD IDs from 0-7.
>
> ATH12K_USERPD_ID_MASK is currently used only while constructing the
> ath12k AHB PAS ID, so this change does not affect existing platforms.
>
> Also remove the unused ATH12K_MAX_UPDS definition.
>
> Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* [PATCH wireless] wifi: rtw88: pci: fix resource leak on failed NAPI setup
From: Dawei Feng @ 2026-06-17 1:35 UTC (permalink / raw)
To: pkshih
Cc: leitao, linux-wireless, linux-kernel, jianhao.xu, zilin,
Dawei Feng, stable
rtw_pci_probe() allocates PCI resources through
rtw_pci_setup_resource() before it sets up NAPI. If
rtw_pci_napi_init() fails, the error path jumps straight to
err_pci_declaim and skips rtw_pci_destroy(), leaving the PCI
resources allocated by rtw_pci_setup_resource() behind.
Add a dedicated cleanup label for the NAPI setup failure path so probe
destroys the PCI resources.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing current
mainline kernels. The tool is still under development and is not yet
publicly available. Manual inspection confirms that the bug is still
present in v7.1-rc7.
An x86_64 allyesconfig build showed no new warnings. As we do not have a
suitable rtw88 PCI board to test with, no runtime testing was able to be
performed.
Fixes: d0bcb10e7b94 ("wifi: rtw88: Un-embed dummy device")
Cc: stable@vger.kernel.org
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
---
drivers/net/wireless/realtek/rtw88/pci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
index bba370ad510c..9eeb6cb31261 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -1825,7 +1825,7 @@ int rtw_pci_probe(struct pci_dev *pdev,
ret = rtw_pci_napi_init(rtwdev);
if (ret) {
rtw_err(rtwdev, "failed to setup NAPI\n");
- goto err_pci_declaim;
+ goto err_destroy_rsrc;
}
ret = rtw_chip_info_setup(rtwdev);
@@ -1857,6 +1857,8 @@ int rtw_pci_probe(struct pci_dev *pdev,
err_destroy_pci:
rtw_pci_napi_deinit(rtwdev);
+
+err_destroy_rsrc:
rtw_pci_destroy(rtwdev, pdev);
err_pci_declaim:
--
2.34.1
^ permalink raw reply related
* [PATCH] wifi: mt76: mt7925: fix crash in reset link replay
From: Sean Wang @ 2026-06-16 16:10 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi; +Cc: linux-wireless, linux-mediatek, Sean Wang
From: Sean Wang <sean.wang@mediatek.com>
During reset recovery, mt7925_vif_connect_iter() replays firmware state
for links tracked in mvif->valid_links. After MLO link changes or MCU
timeout recovery, the driver bitmap can temporarily contain a link whose
mac80211 bss_conf has already gone away.
This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching
the crash where x1, the second argument, is NULL:
pc : mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib]
lr : mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common]
x2 : ffffff80a77f6018 x1 : 0000000000000000 x0 : ffffff8099402080
Call trace:
mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib]
mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common]
mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common]
Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA
reset replay is unchanged because the helper still returns &vif->bss_conf
for the legacy link.
Fixes: 14061994184d ("wifi: mt76: mt7925: add link handling in mt7925_vif_connect_iter")
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
drivers/net/wireless/mediatek/mt76/mt7925/mac.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
index d7e4ebe92342..cee4e4b8ff41 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
@@ -1284,6 +1284,9 @@ mt7925_vif_connect_iter(void *priv, u8 *mac,
for_each_set_bit(i, &valid, IEEE80211_MLD_MAX_NUM_LINKS) {
bss_conf = mt792x_vif_to_bss_conf(vif, i);
+ if (!bss_conf)
+ continue;
+
mconf = mt792x_vif_to_link(mvif, i);
mt76_connac_mcu_uni_add_dev(&dev->mphy, bss_conf, &mconf->mt76,
--
2.43.0
^ permalink raw reply related
* [PATCH rtw-next v2 3/3] wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 17aa:b736
From: William Hansen-Baird @ 2026-06-16 14:16 UTC (permalink / raw)
To: pkshih; +Cc: linux-wireless, linux-kernel, William Hansen-Baird
In-Reply-To: <20260616141620.91081-1-william.hansen.baird@gmail.com>
RTL8723BE outputs a large amount of PCIe AER errors during and
after boot, even before probe and when driver is never loaded.
This causes significant system slowdown.
The errors are the same as reported by
commit 77a6407c6ab2 ("wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723")
Add the RTL8723BE with subsystem ID 17aa:b736 to the rtl_aspm_quirks
table to stop the AER errors. AER errors can still be present prior to
pci probe, as the device by default may have ASPM enabled.
Testing on a Razer Blade 14 2017 which shipped from the
OEM equipped with an RTL8723BE card with this subsystem ID
confirms that this patch resolves the AER flood and allows the
wireless card to function normally once the driver takes over.
Signed-off-by: William Hansen-Baird <william.hansen.baird@gmail.com>
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 9de396879806..9919c8588cbd 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -33,6 +33,7 @@ static const u8 ac_to_hwq[] = {
static const struct pci_device_id rtl_aspm_quirks[] = {
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_REALTEK, 0xb723, 0x11ad, 0x1723) },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_REALTEK, 0xb723, 0x17aa, 0xb736) },
{ 0 }
};
--
2.54.0
^ permalink raw reply related
* [PATCH rtw-next v2 2/3] wifi: rtlwifi: convert pci if-statement to ID table
From: William Hansen-Baird @ 2026-06-16 14:16 UTC (permalink / raw)
To: pkshih; +Cc: linux-wireless, linux-kernel, William Hansen-Baird
In-Reply-To: <20260616141620.91081-1-william.hansen.baird@gmail.com>
Refactor the ASUSTek quirk logic from an if-statement to a standard
rtl_aspm_quirks pci_device_id table. This allows future devices with
the same quirk to be added more easily while avoiding a large if-chain.
Signed-off-by: William Hansen-Baird <william.hansen.baird@gmail.com>
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
index a5bab06f2b61..9de396879806 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -31,6 +31,11 @@ static const u8 ac_to_hwq[] = {
BK_QUEUE
};
+static const struct pci_device_id rtl_aspm_quirks[] = {
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_REALTEK, 0xb723, 0x11ad, 0x1723) },
+ { 0 }
+};
+
static u8 _rtl_mac_to_hwqueue(struct ieee80211_hw *hw, struct sk_buff *skb)
{
struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
@@ -328,21 +333,17 @@ static void rtl_pci_parse_configuration(struct pci_dev *pdev,
static void rtl_pci_init_aspm(struct ieee80211_hw *hw)
{
- struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
_rtl_pci_update_default_setting(hw);
- /* RTL8723BE found on some ASUSTek laptops, such as F441U and
- * X555UQ with subsystem ID 11ad:1723 are known to output large
+ /* Certain pci devices are known to output large
* amounts of PCIe AER errors during and after boot up, causing
* heavy lags, poor network throughput, and occasional lock-ups.
*/
- if (rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8723BE &&
- (rtlpci->pdev->subsystem_vendor == 0x11ad &&
- rtlpci->pdev->subsystem_device == 0x1723)) {
+ if (pci_match_id(rtl_aspm_quirks, rtlpci->pdev)) {
__rtl_pci_disable_aspm(hw);
ppsc->support_aspm = false;
}
--
2.54.0
^ permalink raw reply related
* [PATCH rtw-next v2 1/3] wifi: rtlwifi: fix disabling of ASPM for RTL8723BE with AER flooding
From: William Hansen-Baird @ 2026-06-16 14:16 UTC (permalink / raw)
To: pkshih; +Cc: linux-wireless, linux-kernel, William Hansen-Baird
In-Reply-To: <20260616141620.91081-1-william.hansen.baird@gmail.com>
commit 77a6407c6ab2 ("wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723")
adds code which sets ppsc->support_aspm to false in
_rtl_pci_update_default_setting() in order to disable ASPM.
This does not, however, disable ASPM. Rather, it disables driver
control of ASPM, and blocks calls to rtl_pci_enable_aspm()
and rtl_pci_disable_aspm().
In some cases, the pci device supplied to the probe function has
ASPM enabled. The code would therefore not disable ASPM, as it means to,
but rather just leave it enabled.
This was discovered through testing on a Razer Blade 14 2017.
Implement a new __rtl_pci_disable_aspm(hw) function which does not check
ppsc->support_aspm before disabling and call it from
rtl_pci_disable_aspm().
Then move the code added in the previous commit to rtl_pci_init_aspm() to
allow adding a call to __rtl_pci_disable_aspm(hw).
This makes sure ASPM is disabled while still disabling
driver control of ASPM to block it from being enabled later.
Fixes: 77a6407c6ab2 ("wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723")
Signed-off-by: William Hansen-Baird <william.hansen.baird@gmail.com>
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 38 ++++++++++++++--------
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 73018a0498b4..a5bab06f2b61 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -156,15 +156,6 @@ static void _rtl_pci_update_default_setting(struct ieee80211_hw *hw)
PCI_EXP_LNKCTL_ASPM_L1 | PCI_EXP_LNKCTL_CCC))
ppsc->support_aspm = false;
- /* RTL8723BE found on some ASUSTek laptops, such as F441U and
- * X555UQ with subsystem ID 11ad:1723 are known to output large
- * amounts of PCIe AER errors during and after boot up, causing
- * heavy lags, poor network throughput, and occasional lock-ups.
- */
- if (rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8723BE &&
- (rtlpci->pdev->subsystem_vendor == 0x11ad &&
- rtlpci->pdev->subsystem_device == 0x1723))
- ppsc->support_aspm = false;
}
static bool _rtl_pci_platform_switch_device_pci_aspm(
@@ -203,7 +194,7 @@ static void _rtl_pci_switch_clk_req(struct ieee80211_hw *hw, u16 value)
}
/*Disable RTL8192SE ASPM & Disable Pci Bridge ASPM*/
-static void rtl_pci_disable_aspm(struct ieee80211_hw *hw)
+static void __rtl_pci_disable_aspm(struct ieee80211_hw *hw)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_pci_priv *pcipriv = rtl_pcipriv(hw);
@@ -215,9 +206,6 @@ static void rtl_pci_disable_aspm(struct ieee80211_hw *hw)
u16 aspmlevel = 0;
u16 tmp_u1b = 0;
- if (!ppsc->support_aspm)
- return;
-
if (pcibridge_vendor == PCI_BRIDGE_VENDOR_UNKNOWN) {
rtl_dbg(rtlpriv, COMP_POWER, DBG_TRACE,
"PCI(Bridge) UNKNOWN\n");
@@ -240,6 +228,16 @@ static void rtl_pci_disable_aspm(struct ieee80211_hw *hw)
_rtl_pci_platform_switch_device_pci_aspm(hw, linkctrl_reg);
}
+static void rtl_pci_disable_aspm(struct ieee80211_hw *hw)
+{
+ struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
+
+ if (!ppsc->support_aspm)
+ return;
+
+ __rtl_pci_disable_aspm(hw);
+}
+
/*Enable RTL8192SE ASPM & Enable Pci Bridge ASPM for
*power saving We should follow the sequence to enable
*RTL8192SE first then enable Pci Bridge ASPM
@@ -330,10 +328,24 @@ static void rtl_pci_parse_configuration(struct pci_dev *pdev,
static void rtl_pci_init_aspm(struct ieee80211_hw *hw)
{
+ struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
+ struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
_rtl_pci_update_default_setting(hw);
+ /* RTL8723BE found on some ASUSTek laptops, such as F441U and
+ * X555UQ with subsystem ID 11ad:1723 are known to output large
+ * amounts of PCIe AER errors during and after boot up, causing
+ * heavy lags, poor network throughput, and occasional lock-ups.
+ */
+ if (rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8723BE &&
+ (rtlpci->pdev->subsystem_vendor == 0x11ad &&
+ rtlpci->pdev->subsystem_device == 0x1723)) {
+ __rtl_pci_disable_aspm(hw);
+ ppsc->support_aspm = false;
+ }
+
if (ppsc->reg_rfps_level & RT_RF_PS_LEVEL_ALWAYS_ASPM) {
/*Always enable ASPM & Clock Req. */
rtl_pci_enable_aspm(hw);
--
2.54.0
^ permalink raw reply related
* [PATCH rtw-next v2 0/3] wifi: rtlwifi: fix ASPM AER flooding on RTL8723BE devices
From: William Hansen-Baird @ 2026-06-16 14:16 UTC (permalink / raw)
To: pkshih; +Cc: linux-wireless, linux-kernel, William Hansen-Baird
In-Reply-To: <20260614135508.70307-1-william.hansen.baird@gmail.com>
This series fixes AER error message flooding and system slowdown caused by
RTL8723BE with subsystem ID 17aa:b736. The flood is found to be caused
by ASPM, and disabling it stops the AER spam.
This flood of AER error messages for the RTL8723BE is not unique to
subsystem ID 17aa:b736.
Commit 77a6407c6ab2 ("wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723")
targets the same issue for subsystem ID 11ad:1723.
The fix applied in that commit, however, does not correctly
disable ASPM. It merely disables driver control of ASPM.
Patch 1 fixes the previous commit such that it properly disables ASPM for
subsystem ID 11ad:1723.
Patch 2 converts the if-statement check of subsystem IDs to a
rtl_aspm_quirks pci_device_id table matched with pci_match_id()
such that future devices can easily be added if they have the same error.
Patch 3 adds the RTL8723BE with subsystem ID 17aa:b736 to the
rtl_aspm_quirks table to disable ASPM for it. Testing on a
Razer Blade 14 2017 showed this stops the AER error message flood and
wifi works as it should.
---
v2:
- Implement __rtl_pci_disable_aspm() in patch 1 which disables ASPM
without checking ppsc->support_aspm.
This is called both by rtl_pci_disable_aspm(), guarded by the original
check of ppsc->support_aspm, and the new quirk code.
- Rename rtl8723be_aspm_quirks to rtl_aspm_quirks and fill out system
vendor and device ID alongside subsystem vendor and device ID in the
rtl_aspm_quirks table such that we can use pci_match_id() alone
without the RTL8723BE check.
William Hansen-Baird (3):
wifi: rtlwifi: fix disabling of ASPM for RTL8723BE with AER flooding
wifi: rtlwifi: convert pci if-statement to ID table
wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 17aa:b736
drivers/net/wireless/realtek/rtlwifi/pci.c | 40 +++++++++++++++-------
1 file changed, 27 insertions(+), 13 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [stable request] mt7921e: backport two mt76 fixes to 6.12.y
From: Ajrat Makhmutov @ 2026-06-16 13:21 UTC (permalink / raw)
To: Sasha Levin, stable
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, linux-wireless
In-Reply-To: <20260610-stable-reply-0014@kernel.org>
Hi Sasha,
> So taking these two alone would queue a deadlock. If d5059e52 lands
> upstream (or you can confirm it's headed to stable), please resend the
> request as all three together and I'll take them for 6.12.y.
d5059e52 is in mainline - it's already in v7.1-rc6, not just linux-next -
so here is the full set; please apply all three to 6.12.y together:
2425dc7beaadc ("wifi: mt76: mt7921: avoid undesired changes of the
preset regulatory domain")
5ed54896b6bd4 ("wifi: mt76: mt7921: fix a potential scan no APs")
d5059e52fd8bc ("wifi: mt76: mt7921: fix potential deadlock in
mt7921_roc_abort_sync")
One note for the 6.12.y backport of d5059e52: keep del_timer_sync() instead
of timer_delete_sync() - the timer API rename is not present in 6.12.y. The
other two cherry-pick cleanly.
Tested together on real MT7921e hardware (Acer Aspire 5 A517-52, ASUS
VivoBook S14, Lenovo IdeaPad Slim 5 14AHP9) on 6.12.
Thanks,
Ajrat
^ permalink raw reply
* Re: wifi: rtw88: 8822cs/bs: Issues migrating RTL8822CS/BS from downstream to upstream driver
From: Lucas Tanure @ 2026-06-16 11:02 UTC (permalink / raw)
To: Ping-Ke Shih
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
Krzysztof Opasiak, Anders Rønningen, Hilda Wu, Max Chou
In-Reply-To: <049000e56f004b4b9d58b74eaed17aef@realtek.com>
Hi Ping-Ke,
On Tue, Jun 16, 2026 at 4:30 AM Ping-Ke Shih <pkshih@realtek.com> wrote:
>
> Hi,
>
> Lucas Tanure <lucas.tanure@neat.no> wrote:
> > Hi Ping-Ke,
> >
> > We are bringing up an RTL8822BS / RTL8822CS combo on a Rockchip PX30
> > board (kernel 6.1.118), Wi-Fi over SDIO, BT on the same die over UART
> > via btrtl + hci_h5.
> >
> > We're deliberately migrating off Realtek's out-of-tree SDIO vendor
> > driver to mainline rtw88: the vendor driver hits memory-corruption
> > bugs we've been unable to get support on, and mainline is the better
> > long-term path.
> > That migration leaves us two gaps I'd appreciate your guidance on:
> >
> > 1) Power-parameter tables. Mainline carries the TX-power data as generated
> > C arrays in rtw88xxc_table.c, while the vendor driver ships the same
> > data as text files.
> >
> > The TX-power limits look like this (TXPWR_LMT.txt):
> >
> > ## 2.4G, 20M, 1T, CCK, //(1M;2M;5.5M;11M)
> > ## START
> > ## #3# FCC ETSI MKK
> > CH01 16 15 15
> > CH02 16 15 15
> > ## END
>
> The tool from .txt to C arrays for vendor driver is not maintained by my team,
> but I think it isn't too hard to use AI tool to convert the format.
If Realtek has an internal .txt -> C conversion tool, could you share it?
Otherwise, could you put us in contact with the team that can verify
our converted tables?
>
> The C array from vendor driver to rtw88 struct is also a simple conversion
> you can use AI to assist this.
>
> If you have traced rtw88, the struct for TX power limit is:
>
> struct rtw_txpwr_lmt_cfg_pair {
> u8 regd;
> u8 band;
> u8 bw;
> u8 rs;
> u8 ch;
> s8 txpwr_lmt;
> };
>
> >
> > and the power-by-rate like this (PHY_REG_PG.txt):
> >
> > #[2.4G][A]#
> > [1Tx] 0xc20 0xffffffff 18 19 19 19 // {11M 5.5M 2M 1M}
> > [1Tx] 0xc24 0xffffffff 18 18 18 18 // {18M 12M 9M 6M}
>
> TX power by rate is:
>
> struct rtw_phy_pg_cfg_pair {
> u32 band;
> u32 rf_path;
> u32 tx_num;
> u32 addr;
> u32 bitmask;
> u32 data;
> };
>
> >
> > Is there any way to convert these .TXT files into the C tables? It
> > seems the vendor driver and the mainline driver power configuration
> > don't have anything in common.
>
> The purpose is different. The .TXT is from human point of view to be easier
> to fill calibration data one by one. The design of C arrays is to look up table
> quickly (it isn't so quickly though).
I used Claude, and it converted our vendor TXPWR_LMT.txt /
PHY_REG_PG.txt into the rtw88 C arrays.
Here is exactly how Claude did it - please tell us if any step is wrong.
Row mapping (one TXPWR_LMT.txt line -> rtw_txpwr_lmt_cfg_pair rows):
header "## 2.4G, 20M, 1T, CCK" + "CH01 16 15 15" (columns FCC ETSI MKK)
-> { 0, 0, 0, 0, 1, 64 } FCC (regd 0)
{ 2, 0, 0, 0, 1, 60 } ETSI (regd 2)
{ 1, 0, 0, 0, 1, 60 } MKK (regd 1)
One line -> 3 rows (one per regulatory column). Fields {regd, band,
bw, rs, ch,
value}: regd FCC/MKK/ETSI = 0/1/2; band/bw/rs come from the header;
value = dBm*U.
Unit (value = real_dBm * U):
8822c, U=4 (max_power_index 0x7f):
bb_pg 0xc20 = 0x484c5054 = {18,19,20,21} (0x48=72=18*4)
txpwr_lmt ETSI/CCK/ch1 = 60 = 15 dBm
8822b, U=2 (max_power_index 0x3f):
txpwr_lmt FCC/CCK/ch1 = 32 = 16 dBm
Both equal our vendor .txt (real dBm), so txpwr_lmt = dBm * U and
bb_pg byte = codeword * U (packed high->low).
Is this correct?
>
> >
> > 2) Is there an upstream (linux-firmware) RTL8822BS firmware that
> > supports the UART transport (rtl_bt/rtl8822bs_fw.bin + config), or
> > does the 8822BS firmware still have to come from the vendor BSP?
>
> Currently, no.
>
> > Is there a problem using vendor firmware (not released at
> > linux-firmware) with the mainline driver?
>
> For BT part, I think it can work. But to work with WiFi, it needs
> BT-coexistence implemented in WiFi driver to support UART BT. Unfortunately
> current is only partially support UART BT.
>
> Ping-Ke
>
Thanks,
Lucas
^ permalink raw reply
* [PATCH ath-next v2] wifi: ath12k: correct monitor destination ring size
From: Aaradhana Sahu @ 2026-06-16 6:23 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, Aaradhana Sahu
The default memory profile configures rxdma_monitor_dst_ring_size as 8092,
which is a typo. The intended value is 8192, consistent with all other ring
sizes in the table being powers of two.
Correct the monitor destination ring size to 8192.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Fixes: defae535dd63 ("wifi: ath12k: Add a table of parameters entries impacting memory consumption")
Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
---
v2:
-Added fixes tag.
---
drivers/net/wireless/ath/ath12k/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
index 742d4fd1b598..b488bd8fea9a 100644
--- a/drivers/net/wireless/ath/ath12k/core.c
+++ b/drivers/net/wireless/ath/ath12k/core.c
@@ -49,7 +49,7 @@ ath12k_mem_profile_based_param ath12k_mem_profile_based_param[] = {
.dp_params = {
.tx_comp_ring_size = 32768,
.rxdma_monitor_buf_ring_size = 4096,
- .rxdma_monitor_dst_ring_size = 8092,
+ .rxdma_monitor_dst_ring_size = 8192,
.num_pool_tx_desc = 32768,
.rx_desc_count = 12288,
},
base-commit: 83f028be15fe071efbee8e27837538d6cca77e87
--
2.34.1
^ permalink raw reply related
* Re: [PATCH ath-next] wifi: ath12k: correct monitor destination ring size
From: Aaradhana Sahu @ 2026-06-16 6:02 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan, ath12k; +Cc: linux-wireless
In-Reply-To: <9ed73ed4-3c52-4841-821f-0fae12f452dc@oss.qualcomm.com>
On 6/16/2026 11:21 AM, Vasanthakumar Thiagarajan wrote:
>
>
> On 6/16/2026 9:36 AM, Aaradhana Sahu wrote:
>> The default memory profile configures rxdma_monitor_dst_ring_size as 8092,
>> which is a typo. The intended value is 8192, consistent with all other ring
>> sizes in the table being powers of two.
>>
>> Correct the monitor destination ring size to 8192.
>>
>> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
>>
>> Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
>
> fixes tag?
>
Sure, will add fixes tag and send next version.
> The rest LGTM
>
>> ---
>> drivers/net/wireless/ath/ath12k/core.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
>> index 742d4fd1b598..b488bd8fea9a 100644
>> --- a/drivers/net/wireless/ath/ath12k/core.c
>> +++ b/drivers/net/wireless/ath/ath12k/core.c
>> @@ -49,7 +49,7 @@ ath12k_mem_profile_based_param ath12k_mem_profile_based_param[] = {
>> .dp_params = {
>> .tx_comp_ring_size = 32768,
>> .rxdma_monitor_buf_ring_size = 4096,
>> - .rxdma_monitor_dst_ring_size = 8092,
>> + .rxdma_monitor_dst_ring_size = 8192,
>> .num_pool_tx_desc = 32768,
>> .rx_desc_count = 12288,
>> },
>>
>> base-commit: 83f028be15fe071efbee8e27837538d6cca77e87
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: correct monitor destination ring size
From: Vasanthakumar Thiagarajan @ 2026-06-16 5:51 UTC (permalink / raw)
To: Aaradhana Sahu, ath12k; +Cc: linux-wireless
In-Reply-To: <20260616040653.3985702-1-aaradhana.sahu@oss.qualcomm.com>
On 6/16/2026 9:36 AM, Aaradhana Sahu wrote:
> The default memory profile configures rxdma_monitor_dst_ring_size as 8092,
> which is a typo. The intended value is 8192, consistent with all other ring
> sizes in the table being powers of two.
>
> Correct the monitor destination ring size to 8192.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
fixes tag?
The rest LGTM
> ---
> drivers/net/wireless/ath/ath12k/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
> index 742d4fd1b598..b488bd8fea9a 100644
> --- a/drivers/net/wireless/ath/ath12k/core.c
> +++ b/drivers/net/wireless/ath/ath12k/core.c
> @@ -49,7 +49,7 @@ ath12k_mem_profile_based_param ath12k_mem_profile_based_param[] = {
> .dp_params = {
> .tx_comp_ring_size = 32768,
> .rxdma_monitor_buf_ring_size = 4096,
> - .rxdma_monitor_dst_ring_size = 8092,
> + .rxdma_monitor_dst_ring_size = 8192,
> .num_pool_tx_desc = 32768,
> .rx_desc_count = 12288,
> },
>
> base-commit: 83f028be15fe071efbee8e27837538d6cca77e87
^ permalink raw reply
* Re: [PATCH 5.15/6.1/6.6/6.12] wifi: iwlwifi: fix 22000 series SMEM parsing
From: Greg Kroah-Hartman @ 2026-06-16 4:19 UTC (permalink / raw)
To: Nazar Kalashnikov
Cc: stable, Miri Korenblit, Kalle Valo, Johannes Berg, linux-wireless,
linux-kernel, Gregory Greenman, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, Luca Coelho, Kalle Valo,
lvc-project
In-Reply-To: <20260615122100.137560-1-sivartiwe@gmail.com>
On Mon, Jun 15, 2026 at 03:20:58PM +0300, Nazar Kalashnikov wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> commit 58192b9ce09b0f0f86e2036683bd542130b91a98 upstream.
>
> If the firmware were to report three LMACs (which doesn't
> exist in hardware) then using "fwrt->smem_cfg.lmac[2]" is
> an overrun of the array. Reject such and use IWL_FW_CHECK
> instead of WARN_ON in this function.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
> Link: https://patch.msgid.link/20251110150012.16e8c2d70c26.Iadfcc1aedf43c5175b3f0757bea5aa232454f1ac@changeid
> Signed-off-by: Nazar Kalashnikov <sivartiwe@gmail.com>
> ---
> Backport fix for CVE-2026-43172
> drivers/net/wireless/intel/iwlwifi/fw/smem.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
This breaks the build, how did you test it?
thanks,
greg k-h
^ permalink raw reply
* [PATCH ath-next] wifi: ath12k: correct monitor destination ring size
From: Aaradhana Sahu @ 2026-06-16 4:06 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, Aaradhana Sahu
The default memory profile configures rxdma_monitor_dst_ring_size as 8092,
which is a typo. The intended value is 8192, consistent with all other ring
sizes in the table being powers of two.
Correct the monitor destination ring size to 8192.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
index 742d4fd1b598..b488bd8fea9a 100644
--- a/drivers/net/wireless/ath/ath12k/core.c
+++ b/drivers/net/wireless/ath/ath12k/core.c
@@ -49,7 +49,7 @@ ath12k_mem_profile_based_param ath12k_mem_profile_based_param[] = {
.dp_params = {
.tx_comp_ring_size = 32768,
.rxdma_monitor_buf_ring_size = 4096,
- .rxdma_monitor_dst_ring_size = 8092,
+ .rxdma_monitor_dst_ring_size = 8192,
.num_pool_tx_desc = 32768,
.rx_desc_count = 12288,
},
base-commit: 83f028be15fe071efbee8e27837538d6cca77e87
--
2.34.1
^ permalink raw reply related
* RE: wifi: rtw88: 8822cs/bs: Issues migrating RTL8822CS/BS from downstream to upstream driver
From: Ping-Ke Shih @ 2026-06-16 3:30 UTC (permalink / raw)
To: Lucas Tanure
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
Krzysztof Opasiak, Anders Rønningen, Hilda Wu, Max Chou
In-Reply-To: <CALt7t=EDVdn7eGbXgXWU8rgbek52+frbbeYMHwzbH7J0xGXWzg@mail.gmail.com>
Hi,
Lucas Tanure <lucas.tanure@neat.no> wrote:
> Hi Ping-Ke,
>
> We are bringing up an RTL8822BS / RTL8822CS combo on a Rockchip PX30
> board (kernel 6.1.118), Wi-Fi over SDIO, BT on the same die over UART
> via btrtl + hci_h5.
>
> We're deliberately migrating off Realtek's out-of-tree SDIO vendor
> driver to mainline rtw88: the vendor driver hits memory-corruption
> bugs we've been unable to get support on, and mainline is the better
> long-term path.
> That migration leaves us two gaps I'd appreciate your guidance on:
>
> 1) Power-parameter tables. Mainline carries the TX-power data as generated
> C arrays in rtw88xxc_table.c, while the vendor driver ships the same
> data as text files.
>
> The TX-power limits look like this (TXPWR_LMT.txt):
>
> ## 2.4G, 20M, 1T, CCK, //(1M;2M;5.5M;11M)
> ## START
> ## #3# FCC ETSI MKK
> CH01 16 15 15
> CH02 16 15 15
> ## END
The tool from .txt to C arrays for vendor driver is not maintained by my team,
but I think it isn't too hard to use AI tool to convert the format.
The C array from vendor driver to rtw88 struct is also a simple conversion
you can use AI to assist this.
If you have traced rtw88, the struct for TX power limit is:
struct rtw_txpwr_lmt_cfg_pair {
u8 regd;
u8 band;
u8 bw;
u8 rs;
u8 ch;
s8 txpwr_lmt;
};
>
> and the power-by-rate like this (PHY_REG_PG.txt):
>
> #[2.4G][A]#
> [1Tx] 0xc20 0xffffffff 18 19 19 19 // {11M 5.5M 2M 1M}
> [1Tx] 0xc24 0xffffffff 18 18 18 18 // {18M 12M 9M 6M}
TX power by rate is:
struct rtw_phy_pg_cfg_pair {
u32 band;
u32 rf_path;
u32 tx_num;
u32 addr;
u32 bitmask;
u32 data;
};
>
> Is there any way to convert these .TXT files into the C tables? It
> seems the vendor driver and the mainline driver power configuration
> don't have anything in common.
The purpose is different. The .TXT is from human point of view to be easier
to fill calibration data one by one. The design of C arrays is to look up table
quickly (it isn't so quickly though).
>
> 2) Is there an upstream (linux-firmware) RTL8822BS firmware that
> supports the UART transport (rtl_bt/rtl8822bs_fw.bin + config), or
> does the 8822BS firmware still have to come from the vendor BSP?
Currently, no.
> Is there a problem using vendor firmware (not released at
> linux-firmware) with the mainline driver?
For BT part, I think it can work. But to work with WiFi, it needs
BT-coexistence implemented in WiFi driver to support UART BT. Unfortunately
current is only partially support UART BT.
Ping-Ke
^ permalink raw reply
* [PATCH ath-next] wifi: ath9k: drop static from local pdadc and vpdTable arrays
From: Rosen Penev @ 2026-06-16 3:08 UTC (permalink / raw)
To: linux-wireless; +Cc: Toke Høiland-Jørgensen, open list
Remove the static qualifier from mutable local arrays in three EEPROM
power-calibration functions. These arrays are written to during normal
operation, so static storage is both unnecessary and misleading: it
implies sharing across calls when no such sharing is intended, and it
makes the code subtly non-reentrant. The sibling function in
eeprom_9287.c already uses an automatic (stack-local) pdadcValues,
confirming this is the correct pattern.
This keeps ~1 KB of data off the static data section at the cost of
stack usage, consistent with the rest of the driver's coding style.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/net/wireless/ath/ath9k/eeprom.c | 6 +++---
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 2 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.c b/drivers/net/wireless/ath/ath9k/eeprom.c
index df58dc02e104..fe5eb0d68b2e 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom.c
@@ -460,11 +460,11 @@ void ath9k_hw_get_gain_boundaries_pdadcs(struct ath_hw *ah,
int i, j, k;
int16_t ss;
u16 idxL = 0, idxR = 0, numPiers;
- static u8 vpdTableL[AR5416_NUM_PD_GAINS]
+ u8 vpdTableL[AR5416_NUM_PD_GAINS]
[AR5416_MAX_PWR_RANGE_IN_HALF_DB];
- static u8 vpdTableR[AR5416_NUM_PD_GAINS]
+ u8 vpdTableR[AR5416_NUM_PD_GAINS]
[AR5416_MAX_PWR_RANGE_IN_HALF_DB];
- static u8 vpdTableI[AR5416_NUM_PD_GAINS]
+ u8 vpdTableI[AR5416_NUM_PD_GAINS]
[AR5416_MAX_PWR_RANGE_IN_HALF_DB];
u8 *pVpdL, *pVpdR, *pPwrL, *pPwrR;
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
index 3e16cfe059f3..eec7efdc21c3 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
@@ -288,7 +288,7 @@ static void ath9k_hw_set_4k_power_cal_table(struct ath_hw *ah,
struct cal_data_per_freq_4k *pRawDataset;
u8 *pCalBChans = NULL;
u16 pdGainOverlap_t2;
- static u8 pdadcValues[AR5416_NUM_PDADC_VALUES];
+ u8 pdadcValues[AR5416_NUM_PDADC_VALUES];
u16 gainBoundaries[AR5416_PD_GAINS_IN_MASK];
u16 numPiers, i, j;
u16 numXpdGain, xpdMask;
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_def.c b/drivers/net/wireless/ath/ath9k/eeprom_def.c
index 5ba467cb7425..a1b10c826fe5 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_def.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_def.c
@@ -769,7 +769,7 @@ static void ath9k_hw_set_def_power_cal_table(struct ath_hw *ah,
struct cal_data_per_freq *pRawDataset;
u8 *pCalBChans = NULL;
u16 pdGainOverlap_t2;
- static u8 pdadcValues[AR5416_NUM_PDADC_VALUES];
+ u8 pdadcValues[AR5416_NUM_PDADC_VALUES];
u16 gainBoundaries[AR5416_PD_GAINS_IN_MASK];
u16 numPiers, i, j;
int16_t diff = 0;
--
2.54.0
^ permalink raw reply related
* [PATCH ath-next] wifi: ath9k: mark PN9Data as const
From: Rosen Penev @ 2026-06-16 3:06 UTC (permalink / raw)
To: linux-wireless; +Cc: Toke Høiland-Jørgensen, open list
PN9Data is a read-only lookup table and is never modified. Adding const
lets the compiler place it in .rodata and prevents accidental writes.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/net/wireless/ath/ath9k/tx99.c | 16 ++++++++--------
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/tx99.c b/drivers/net/wireless/ath/ath9k/tx99.c
index f2144fd39093..b52d84f6cbc9 100644
--- a/drivers/net/wireless/ath/ath9k/tx99.c
+++ b/drivers/net/wireless/ath/ath9k/tx99.c
@@ -39,14 +39,14 @@ static void ath9k_tx99_stop(struct ath_softc *sc)
static struct sk_buff *ath9k_build_tx99_skb(struct ath_softc *sc)
{
- static u8 PN9Data[] = {0xff, 0x87, 0xb8, 0x59, 0xb7, 0xa1, 0xcc, 0x24,
- 0x57, 0x5e, 0x4b, 0x9c, 0x0e, 0xe9, 0xea, 0x50,
- 0x2a, 0xbe, 0xb4, 0x1b, 0xb6, 0xb0, 0x5d, 0xf1,
- 0xe6, 0x9a, 0xe3, 0x45, 0xfd, 0x2c, 0x53, 0x18,
- 0x0c, 0xca, 0xc9, 0xfb, 0x49, 0x37, 0xe5, 0xa8,
- 0x51, 0x3b, 0x2f, 0x61, 0xaa, 0x72, 0x18, 0x84,
- 0x02, 0x23, 0x23, 0xab, 0x63, 0x89, 0x51, 0xb3,
- 0xe7, 0x8b, 0x72, 0x90, 0x4c, 0xe8, 0xfb, 0xc0};
+ static const u8 PN9Data[] = {0xff, 0x87, 0xb8, 0x59, 0xb7, 0xa1, 0xcc, 0x24,
+ 0x57, 0x5e, 0x4b, 0x9c, 0x0e, 0xe9, 0xea, 0x50,
+ 0x2a, 0xbe, 0xb4, 0x1b, 0xb6, 0xb0, 0x5d, 0xf1,
+ 0xe6, 0x9a, 0xe3, 0x45, 0xfd, 0x2c, 0x53, 0x18,
+ 0x0c, 0xca, 0xc9, 0xfb, 0x49, 0x37, 0xe5, 0xa8,
+ 0x51, 0x3b, 0x2f, 0x61, 0xaa, 0x72, 0x18, 0x84,
+ 0x02, 0x23, 0x23, 0xab, 0x63, 0x89, 0x51, 0xb3,
+ 0xe7, 0x8b, 0x72, 0x90, 0x4c, 0xe8, 0xfb, 0xc0};
u32 len = 1200;
struct ieee80211_tx_rate *rate;
struct ieee80211_hw *hw = sc->hw;
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 89d8b3178784..57e451548958 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -41,7 +41,7 @@
#define ATH9K_PWRTBL_11NG_HT_SHIFT 12
-static u16 bits_per_symbol[][2] = {
+static const u16 bits_per_symbol[][2] = {
/* 20MHz 40MHz */
{ 26, 54 }, /* 0: BPSK */
{ 52, 108 }, /* 1: QPSK 1/2 */
--
2.54.0
^ permalink raw reply related
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