From: Francesco Dolcini <francesco.dolcini(a)toradex.com>
This reverts commit 34253084291cb210b251d64657958b8041ce4ab1.
That commit introduces a regression, when HT40 mode is enabled,
received packets are lost, this was experience with W8997 with both
SDIO-UART and SDIO-SDIO variants. From an initial investigation the
issue solves on its own after some time, but it's not clear what is
the reason. Given that this was just a performance optimization, let's
revert it till we have a better understanding of the issue and a proper
fix.
Cc: Jeff Chen <jeff.chen_1(a)nxp.com>
Cc: stable(a)vger.kernel.org
Fixes: 34253084291c ("wifi: mwifiex: Fix HT40 bandwidth issue.")
Closes: https://lore.kernel.org/all/20250603203337.GA109929@francesco-nb/
Signed-off-by: Francesco Dolcini <francesco.dolcini(a)toradex.com>
---
drivers/net/wireless/marvell/mwifiex/11n.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/11n.c b/drivers/net/wireless/marvell/mwifiex/11n.c
index 738bafc3749b..66f0f5377ac1 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n.c
+++ b/drivers/net/wireless/marvell/mwifiex/11n.c
@@ -403,14 +403,12 @@ mwifiex_cmd_append_11n_tlv(struct mwifiex_private *priv,
if (sband->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40 &&
bss_desc->bcn_ht_oper->ht_param &
- IEEE80211_HT_PARAM_CHAN_WIDTH_ANY) {
- chan_list->chan_scan_param[0].radio_type |=
- CHAN_BW_40MHZ << 2;
+ IEEE80211_HT_PARAM_CHAN_WIDTH_ANY)
SET_SECONDARYCHAN(chan_list->chan_scan_param[0].
radio_type,
(bss_desc->bcn_ht_oper->ht_param &
IEEE80211_HT_PARAM_CHA_SEC_OFFSET));
- }
+
*buffer += struct_size(chan_list, chan_scan_param, 1);
ret_len += struct_size(chan_list, chan_scan_param, 1);
}
--
2.39.5
On Tue, 2024-10-22 at 17:30 -0500, Bjorn Helgaas wrote:
> On Mon, Oct 07, 2024 at 08:59:17AM +0530, Ajay Agarwal wrote:
> > The current sequence in the driver for L1ss update is as follows.
> >
> > Disable L1ss
> > Disable L1
> > Enable L1ss as required
> > Enable L1 if required
> >
> > With this sequence, a bus hang is observed during the L1ss
> > disable sequence when the RC CPU attempts to clear the RC L1ss
> > register after clearing the EP L1ss register. It looks like the
> > RC attempts to enter L1ss again and at the same time, access to
> > RC L1ss register fails because aux clk is still not active.
> >
> > PCIe spec r6.2, section 5.5.4, recommends that setting either
> > or both of the enable bits for ASPM L1 PM Substates must be done
> > while ASPM L1 is disabled. My interpretation here is that
> > clearing L1ss should also be done when L1 is disabled. Thereby,
> > change the sequence as follows.
> >
> > Disable L1
> > Disable L1ss
> > Enable L1ss as required
> > Enable L1 if required
> >
> > Signed-off-by: Ajay Agarwal <ajayagarwal(a)google.com>
>
> Applied to pci/aspm for v6.13, thank you, Ajay!
Thanks! MediaTek also found this issue will happen on some old kernel,
for example 6.11 or 6.12. would you please pick this patch also to some
stable tree?
LINK:https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commi…
Thanks a lot.
Macpaul Lin