[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<PAWPR04MB9910DD6135CDBBF46A4030879CD22@PAWPR04MB9910.eurprd04.prod.outlook.com>
Date: Fri, 14 Mar 2025 03:06:16 +0000
From: Jeff Chen <jeff.chen_1@....com>
To: Francesco Dolcini <francesco@...cini.it>
CC: "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"briannorris@...omium.org" <briannorris@...omium.org>, "kvalo@...nel.org"
<kvalo@...nel.org>, Pete Hsieh <tsung-hsien.hsieh@....com>,
"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>
Subject: RE: [EXT] Re: [PATCH v2 2/2] wifi: mwifiex: Fix HT40 bandwidth issue.
Hello Francesco,
Thank you for reviewing and providing great comments.
> -----Original Message-----
> From: Francesco Dolcini <francesco@...cini.it>
> Sent: Thursday, March 6, 2025 6:38 PM
> To: Jeff Chen <jeff.chen_1@....com>
> Cc: linux-wireless@...r.kernel.org; linux-kernel@...r.kernel.org;
> briannorris@...omium.org; kvalo@...nel.org; francesco@...cini.it; Pete
> Hsieh <tsung-hsien.hsieh@....com>; s.hauer@...gutronix.de
> Subject: [EXT] Re: [PATCH v2 2/2] wifi: mwifiex: Fix HT40 bandwidth issue.
>
>
> As you know this patch came after us (Toradex) reported some issue
> connecting to 2.4GHz network using IW416.
>
> However according to this commit message this actual fix is not related to the
> issue in which it was not possible to connect at all, but it's just an
> improvement. Can you confirm this?
>
You are correct that this patch primarily addresses an improvement rather than
resolving an outright failure to connect. It ensures that when the AP supports
40MHz bandwidth, the connection operates at the expected 40MHz instead of
being limited to 20MHz. This fix is not directly related to the reported issue
where the connection to the 2.4GHz network with IW416 was not possible at all.
> Can you please also answer the last comment I had in the previous version of
> this patch, see
> https://lore.ker/
> nel.org%2Fall%2FZ44vj59nWIiswq7s%40gaggiata.pivistrello.it%2F&data=05%7
> C02%7Cjeff.chen_1%40nxp.com%7C608bec5740f046d9409908dd5c9af5e1%7C
> 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638768542804304282%7
> CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA
> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7
> C&sdata=piD%2BBLUEqdCZgomWsxtKFGS7RAfj0nk0tTsQYu%2BEEwU%3D&res
> erved=0
> ?
>
> Reported here again for you convenience:
>
> setting `radio_type |= (CHAN_BW_40MHZ << 2)` seems the only real change
> on this
> patch, correct? Anything else is cosmetic, correct?
>
> would doing just this change be equivalent, right?
>
> SET_SECONDARYCHAN(chan_list->chan_scan_param[0].
> radio_type | (CHAN_BW_40MHZ << 2),
> (bss_desc->bcn_ht_oper->ht_param &
> IEEE80211_HT_PARAM_CHA_SEC_OFFSET));
>
>
Yes, the primary functional change in the patch is indeed the addition of
`radio_type |= (CHAN_BW_40MHZ << 2)`. The rest of the changes were
made to pass checkpatch and seem unnecessary. I will update to your
version.
Powered by blists - more mailing lists