[kvalo-ath:pending 34/37] drivers/net/wireless/ath/ath12k/wow.c:982:11: warning: enumeration value 'ATH12K_HW_STATE_TM' not handled in switch
tree: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pending
head: ff7f6be343c446ec89addc6abb99e83a6b98abfe
commit: 5e4b86c9b76950ec6bf056e17e80d6611df66182 [34/37] wifi: ath12k: add
factory test mode support
config: i386-buildonly-randconfig-003-20240627
(https://download.01.org/0day-ci/archive/20240627/202406271317.iyxb6yve-...@intel.com/config)
compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project
617a15a9eac96088ae5e9134248d8236e34b91b1)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240627/202406271317.iyxb6yve-...@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
| Closes:
https://lore.kernel.org/oe-kbuild-all/202406271317.iyxb6yve-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/net/wireless/ath/ath12k/wow.c:982:11: warning: enumeration value
>> 'ATH12K_HW_STATE_TM' not handled in switch [-Wswitch]
982 | switch (ah->state) {
| ^
1 warning generated.
vim +/ATH12K_HW_STATE_TM +982 drivers/net/wireless/ath/ath12k/wow.c
4a3c212eee0e36 Baochen Qiang 2024-06-19 929
4a3c212eee0e36 Baochen Qiang 2024-06-19 930 int ath12k_wow_op_resume(struct
ieee80211_hw *hw)
4a3c212eee0e36 Baochen Qiang 2024-06-19 931 {
4a3c212eee0e36 Baochen Qiang 2024-06-19 932 struct ath12k_hw *ah =
ath12k_hw_to_ah(hw);
4a3c212eee0e36 Baochen Qiang 2024-06-19 933 struct ath12k *ar =
ath12k_ah_to_ar(ah, 0);
4a3c212eee0e36 Baochen Qiang 2024-06-19 934 int ret;
4a3c212eee0e36 Baochen Qiang 2024-06-19 935
4a3c212eee0e36 Baochen Qiang 2024-06-19 936 mutex_lock(&ar->conf_mutex);
4a3c212eee0e36 Baochen Qiang 2024-06-19 937
4a3c212eee0e36 Baochen Qiang 2024-06-19 938 ret = ath12k_hif_resume(ar->ab);
4a3c212eee0e36 Baochen Qiang 2024-06-19 939 if (ret) {
4a3c212eee0e36 Baochen Qiang 2024-06-19 940 ath12k_warn(ar->ab,
"failed to resume hif: %d\n", ret);
4a3c212eee0e36 Baochen Qiang 2024-06-19 941 goto exit;
4a3c212eee0e36 Baochen Qiang 2024-06-19 942 }
4a3c212eee0e36 Baochen Qiang 2024-06-19 943
4a3c212eee0e36 Baochen Qiang 2024-06-19 944
ath12k_hif_ce_irq_enable(ar->ab);
4a3c212eee0e36 Baochen Qiang 2024-06-19 945 ath12k_hif_irq_enable(ar->ab);
4a3c212eee0e36 Baochen Qiang 2024-06-19 946
4a3c212eee0e36 Baochen Qiang 2024-06-19 947 ret = ath12k_wow_wakeup(ar);
16f474d6d49db5 Baochen Qiang 2024-06-04 948 if (ret) {
4a3c212eee0e36 Baochen Qiang 2024-06-19 949 ath12k_warn(ar->ab,
"failed to wakeup from wow: %d\n", ret);
16f474d6d49db5 Baochen Qiang 2024-06-04 950 goto exit;
16f474d6d49db5 Baochen Qiang 2024-06-04 951 }
16f474d6d49db5 Baochen Qiang 2024-06-04 952
16f474d6d49db5 Baochen Qiang 2024-06-04 953 ret =
ath12k_wow_nlo_cleanup(ar);
16f474d6d49db5 Baochen Qiang 2024-06-04 954 if (ret) {
16f474d6d49db5 Baochen Qiang 2024-06-04 955 ath12k_warn(ar->ab,
"failed to cleanup nlo: %d\n", ret);
16f474d6d49db5 Baochen Qiang 2024-06-04 956 goto exit;
16f474d6d49db5 Baochen Qiang 2024-06-04 957 }
4a3c212eee0e36 Baochen Qiang 2024-06-19 958
66a9448b1b8977 Baochen Qiang 2024-06-19 959 ret =
ath12k_wow_clear_hw_filter(ar);
66a9448b1b8977 Baochen Qiang 2024-06-19 960 if (ret) {
66a9448b1b8977 Baochen Qiang 2024-06-19 961 ath12k_warn(ar->ab,
"failed to clear hw filter: %d\n", ret);
66a9448b1b8977 Baochen Qiang 2024-06-19 962 goto exit;
66a9448b1b8977 Baochen Qiang 2024-06-19 963 }
66a9448b1b8977 Baochen Qiang 2024-06-19 964
1666108c74c438 Baochen Qiang 2024-06-19 965 ret =
ath12k_wow_protocol_offload(ar, false);
1666108c74c438 Baochen Qiang 2024-06-19 966 if (ret) {
1666108c74c438 Baochen Qiang 2024-06-19 967 ath12k_warn(ar->ab,
"failed to clear wow protocol offload events: %d\n",
1666108c74c438 Baochen Qiang 2024-06-19 968 ret);
1666108c74c438 Baochen Qiang 2024-06-19 969 goto exit;
1666108c74c438 Baochen Qiang 2024-06-19 970 }
1666108c74c438 Baochen Qiang 2024-06-19 971
7af01e56952954 Baochen Qiang 2024-06-19 972 ret =
ath12k_wow_set_keepalive(ar,
7af01e56952954 Baochen Qiang 2024-06-19 973
WMI_STA_KEEPALIVE_METHOD_NULL_FRAME,
7af01e56952954 Baochen Qiang 2024-06-19 974
WMI_STA_KEEPALIVE_INTERVAL_DISABLE);
7af01e56952954 Baochen Qiang 2024-06-19 975 if (ret) {
7af01e56952954 Baochen Qiang 2024-06-19 976 ath12k_warn(ar->ab,
"failed to disable wow keepalive: %d\n", ret);
7af01e56952954 Baochen Qiang 2024-06-19 977 goto exit;
7af01e56952954 Baochen Qiang 2024-06-19 978 }
7af01e56952954 Baochen Qiang 2024-06-19 979
4a3c212eee0e36 Baochen Qiang 2024-06-19 980 exit:
4a3c212eee0e36 Baoch
Re: ieee80211.h virtual_map splat
On 6/25/2024 8:02 AM, Jakub Kicinski wrote:
> On Tue, 25 Jun 2024 09:56:35 +0300 Kalle Valo wrote:
>>> Adding netdev to the initial message in the thread.
>>> https://lore.kernel.org/all/CAPh3n83zb1PwFBFijJKChBqY95zzpYh=2iPf8tmh=yts6e3...@mail.gmail.com/
>>>
>>> There was some discussion in the thread, with the observation that the
>>> splat
>>> is fixed by:
>>> 2ae5c9248e06 ("wifi: mac80211: Use flexible array in struct
>>> ieee80211_tim_ie")
>>>
>>> Followed by discussion if this should be backported.
>>>
>>> Kees said that "netdev [...] maintainers have asked that contributors not
>>> include "Cc: stable" tags, as they want to evaluate for themselves whether
>>> patches should go to stable or not"
>>
>> BTW this rule doesn't apply to wireless subsystem. For wireless patches
>> it's ok to "Cc: stable" in patches or anyone can send a request to
>> stable maintainers to pick a patch.
>
> It's an old rule. Quoting documentation:
>
> Stable tree
> ~~~
>
> While it used to be the case that netdev submissions were not supposed
> to carry explicit ``CC: sta...@vger.kernel.org`` tags that is no longer
> the case today. Please follow the standard stable rules in
> :ref:`Documentation/process/stable-kernel-rules.rst `,
> and make sure you include appropriate Fixes tags!
>
> See:
> https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#stable-tree
Thanks for the pointer.
I've now followed option 2 to notify the stable team to backport this patch
Re: ieee80211.h virtual_map splat
On Tue, Jun 25, 2024 at 08:02:48AM -0700, Jakub Kicinski wrote:
> On Tue, 25 Jun 2024 09:56:35 +0300 Kalle Valo wrote:
> > > Adding netdev to the initial message in the thread.
> > > https://lore.kernel.org/all/CAPh3n83zb1PwFBFijJKChBqY95zzpYh=2iPf8tmh=yts6e3...@mail.gmail.com/
> > >
> > > There was some discussion in the thread, with the observation that the
> > > splat
> > > is fixed by:
> > > 2ae5c9248e06 ("wifi: mac80211: Use flexible array in struct
> > > ieee80211_tim_ie")
> > >
> > > Followed by discussion if this should be backported.
> > >
> > > Kees said that "netdev [...] maintainers have asked that contributors not
> > > include "Cc: stable" tags, as they want to evaluate for themselves
> > > whether
> > > patches should go to stable or not"
> >
> > BTW this rule doesn't apply to wireless subsystem. For wireless patches
> > it's ok to "Cc: stable" in patches or anyone can send a request to
> > stable maintainers to pick a patch.
>
> It's an old rule. Quoting documentation:
>
> Stable tree
> ~~~
>
> While it used to be the case that netdev submissions were not supposed
> to carry explicit ``CC: sta...@vger.kernel.org`` tags that is no longer
> the case today. Please follow the standard stable rules in
> :ref:`Documentation/process/stable-kernel-rules.rst `,
> and make sure you include appropriate Fixes tags!
>
> See:
> https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#stable-tree
Ah-ha! Thanks. I will fix my brain. :)
--
Kees Cook
Re: [PATCH wireless] MAINTAINERS: wifi: update ath.git location
Kalle Valo wrote: > ath.git tree has moved to a new location. The old location will be an alias to > the new location and will work at least until end of 2024, but best to update > git trees already now. > > Signed-off-by: Kalle Valo > Acked-by: Jeff Johnson Patch applied to wireless.git, thanks. c40ff9b662d0 MAINTAINERS: wifi: update ath.git location -- https://patchwork.kernel.org/project/linux-wireless/patch/20240626102632.1554485-1-kv...@kernel.org/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH wireless] MAINTAINERS: wifi: update ath.git location
On 6/26/2024 3:26 AM, Kalle Valo wrote: > ath.git tree has moved to a new location. The old location will be an alias to > the new location and will work at least until end of 2024, but best to update > git trees already now. > > Signed-off-by: Kalle Valo Acked-by: Jeff Johnson
Re: invalid vht params rate 1920 100kbps nss 2 mcs 9
Paul Menzel writes: >> All firmware releases are available here: >> https://git.codelinaro.org/clo/ath-firmware/ath10k-firmware/-/tree/main/QCA6174/hw3.0/4.4.1?ref_type=heads >> And more info here: >> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/firmware > > Thank you. It looks like the latest firmware version is 309, and > Debian sid/unstable still ships version 288 in *firmware-atheros* > 20230625-2 [1]. > > Unfortunately, there does not seem to be a change-log for version 309 > (or any version for that matter). I am going to manually copy it > anyway, but it’d be nice, if I knew what to expect. ;-) Yeah, unfortunately there are no changelogs available for firmware releases but I do understand the need for those. There has been discussions to create them but no success yet. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: invalid vht params rate 1920 100kbps nss 2 mcs 9
Dear Kalle,
Am 26.06.24 um 12:16 schrieb Kalle Valo:
Paul Menzel writes:
Am 26.06.24 um 10:53 schrieb Baochen Qiang:
OK, there are two issues here:
1. invalid HT rate: "ath10k_pci :02:00.0: invalid ht params rate 1440 100kbps
nss 2 mcs 7".
As commented by Wen quite some time ago, this has been fixed from
firmware side, and firmware newer than [ver:241] has the fix
included.
I assume this means that the firmware version
WLAN.RM.4.4.1-00241-QCARMSWPZ-1 or newer has the fix.
2. invaid VHT rate: "ath10k_pci :3a:00.0: invalid vht params rate 1920 100kbps
nss 2 mcs 9".
After checking with firmware team, I thought this is because there is
a mismatch in rate definition between host and firmware: In host, the
rate for 'nss 2 mcs 9' is defined as {1560, 1733}, see
supported_vht_mcs_rate_nss2[]. While in firmware this is defined as
{1730, 1920}. So seems we can update host definition to avoid this
issue.
Looking through the logs since May 2024, I have four different logs:
1. invalid vht params rate 878 100kbps nss 3 mcs 2
2. invalid vht params rate 960 100kbps nss 1 mcs 9
3. invalid vht params rate 1730 100kbps nss 2 mcs 9
4. invalid vht params rate 1920 100kbps nss 2 mcs 9
I believe it’s only happening with Cisco networks. I am happy to test
a patch.
By the way, is the firmware version logged by Linux?
ath10k_pci :3a:00.0: qca6174 hw3.2 target 0x0503 chip_id
0x00340aff sub 1a56:1535
ath10k_pci :3a:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0
testmode 0
ath10k_pci :3a:00.0: firmware ver WLAN.RM.4.4.1-00288- api 6 features
wowlan,ignore-otp,mfp crc32 bf907c7c
ath10k_pci :3a:00.0: board_file api 2 bmi_id N/A crc32 d2863f91
ath10k_pci :3a:00.0: htt-ver 3.87 wmi-op 4 htt-op 3 cal otp max-sta 32
raw 0 hwcrypto 1
Is it 4.4.1-00288?
Yes, that should be WLAN.RM.4.4.1-00288-QCARMSWPZ-1. But I don't know
why 'QCARMSWPZ-1' is not printed by ath10k, maybe we have a bug
somewhere.
How can I find the file in `/lib/firmware/`?
It should be in ath10k/QCA6174/hw3.0/firmware-6.bin.
All firmware releases are available here:
https://git.codelinaro.org/clo/ath-firmware/ath10k-firmware/-/tree/main/QCA6174/hw3.0/4.4.1?ref_type=heads
And more info here:
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/firmware
Thank you. It looks like the latest firmware version is 309, and Debian
sid/unstable still ships version 288 in *firmware-atheros* 20230625-2 [1].
Unfortunately, there does not seem to be a change-log for version 309
(or any version for that matter). I am going to manually copy it anyway,
but it’d be nice, if I knew what to expect. ;-)
Kind regards,
Paul
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074308
"firmware-atheros: QCA 6174: Newest version 309 missing"
[PATCH wireless] MAINTAINERS: wifi: update ath.git location
ath.git tree has moved to a new location. The old location will be an alias to the new location and will work at least until end of 2024, but best to update git trees already now. Signed-off-by: Kalle Valo --- MAINTAINERS | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index d6c90161c7bf..969412b75c46 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -18376,7 +18376,7 @@ M: Jeff Johnson L: ath...@lists.infradead.org S: Supported W: https://wireless.wiki.kernel.org/en/users/Drivers/ath12k -T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git +T: git git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git F: drivers/net/wireless/ath/ath12k/ N: ath12k @@ -18386,7 +18386,7 @@ M: Jeff Johnson L: ath10k@lists.infradead.org S: Supported W: https://wireless.wiki.kernel.org/en/users/Drivers/ath10k -T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git +T: git git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git F: drivers/net/wireless/ath/ath10k/ N: ath10k @@ -18397,7 +18397,7 @@ L: ath...@lists.infradead.org S: Supported W: https://wireless.wiki.kernel.org/en/users/Drivers/ath11k B: https://wireless.wiki.kernel.org/en/users/Drivers/ath11k/bugreport -T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git +T: git git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git F: drivers/net/wireless/ath/ath11k/ N: ath11k @@ -18406,7 +18406,7 @@ M: Toke Høiland-Jørgensen L: linux-wirel...@vger.kernel.org S: Maintained W: https://wireless.wiki.kernel.org/en/users/Drivers/ath9k -T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git +T: git git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git F: Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml F: drivers/net/wireless/ath/ath9k/ base-commit: 321028bc45f01edb9e57b0ae5c11c5c3600d00ca -- 2.39.2
Re: invalid vht params rate 1920 100kbps nss 2 mcs 9
Paul Menzel writes:
> Am 26.06.24 um 10:53 schrieb Baochen Qiang:
>
>> OK, there are two issues here:
>> 1. invalid HT rate: "ath10k_pci :02:00.0: invalid ht params rate
>> 1440 100kbps nss 2 mcs 7".
>> As commented by Wen quite some time ago, this has been fixed from
>> firmware side, and firmware newer than [ver:241] has the fix
>> included.
I assume this means that the firmware version
WLAN.RM.4.4.1-00241-QCARMSWPZ-1 or newer has the fix.
>> 2. invaid VHT rate: "ath10k_pci :3a:00.0: invalid vht params
>> rate 1920 100kbps nss 2 mcs 9".
>> After checking with firmware team, I thought this is because there
>> is
>> a mismatch in rate definition between host and firmware: In host, the
>> rate for 'nss 2 mcs 9' is defined as {1560, 1733}, see
>> supported_vht_mcs_rate_nss2[]. While in firmware this is defined as
>> {1730, 1920}. So seems we can update host definition to avoid this
>> issue.
> Looking through the logs since May 2024, I have four different logs:
>
> 1. invalid vht params rate 878 100kbps nss 3 mcs 2
> 2. invalid vht params rate 960 100kbps nss 1 mcs 9
> 3. invalid vht params rate 1730 100kbps nss 2 mcs 9
> 4. invalid vht params rate 1920 100kbps nss 2 mcs 9
>
> I believe it’s only happening with Cisco networks. I am happy to test
> a patch.
>
> By the way, is the firmware version logged by Linux?
>
> ath10k_pci :3a:00.0: qca6174 hw3.2 target 0x0503 chip_id
> 0x00340aff sub 1a56:1535
> ath10k_pci :3a:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0
> testmode 0
> ath10k_pci :3a:00.0: firmware ver WLAN.RM.4.4.1-00288- api 6
> features wowlan,ignore-otp,mfp crc32 bf907c7c
> ath10k_pci :3a:00.0: board_file api 2 bmi_id N/A crc32 d2863f91
> ath10k_pci :3a:00.0: htt-ver 3.87 wmi-op 4 htt-op 3 cal otp
> max-sta 32 raw 0 hwcrypto 1
>
> Is it 4.4.1-00288?
Yes, that should be WLAN.RM.4.4.1-00288-QCARMSWPZ-1. But I don't know
why 'QCARMSWPZ-1' is not printed by ath10k, maybe we have a bug
somewhere.
> How can I find the file in `/lib/firmware/`?
It should be in ath10k/QCA6174/hw3.0/firmware-6.bin.
All firmware releases are available here:
https://git.codelinaro.org/clo/ath-firmware/ath10k-firmware/-/tree/main/QCA6174/hw3.0/4.4.1?ref_type=heads
And more info here:
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/firmware
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: invalid vht params rate 1920 100kbps nss 2 mcs 9
Dear Baochen,
Thank you for your reply.
Am 26.06.24 um 10:53 schrieb Baochen Qiang:
On 6/18/2024 6:33 PM, Kalle Valo wrote:
+ baochen
James Prestwood writes:
On 6/17/24 8:27 AM, Kalle Valo wrote:
James Prestwood writes:
On 6/16/24 6:10 AM, Paul Menzel wrote:
Linux 6.10-rc3 (commit a3e18a540541) logged the warning below when
connecting to a public WiFi:
ath10k_pci :3a:00.0: invalid vht params rate 1920 100kbps nss 2 mcs 9
This has been reported/discussed [1]. It was hinted that there was a
firmware fix for this, but none that I tried got rid of it. I got fed
up enough with the logs filling up with this I patched our kernel to
remove the warning. AFAICT it appears benign (?). Removing the warning
was purely "cosmetic" so other devs stopped complaining about it :)
[1] https://www.mail-archive.com/ath10k@lists.infradead.org/msg13406.html
More reliable link to the discussion:
https://lore.kernel.org/ath10k/76a816d983e6c4d636311738396f97971b5523fb.1612915444.git.sk...@linuxfoundation.org/
I think we should add this workaround I mentioned in 2021:
"If the firmware still keeps sending invalid rates we should add a
specific check to ignore the known invalid values, but not all of
them."
https://lore.kernel.org/ath10k/87h7mktjgi@codeaurora.org/
I guess that would be mcs == 7 and rate == 1440?
I think its more than this combination (Paul's are different).
Good point.
So how many combinations are we willing to add here? Seems like that
could get out of hand if there are more than a few invalid
combinations.
Yeah, but there haven't been that many different values reported yet,
right? And I expect that ath10k user base will just get smaller in the
future so the chances are that we will get less reports.
Would we also want to restrict the workaround to specific
hardware/firmware?
Good idea, limiting per hardware would be simple to implement using
hw_params. Of course we could even limit this per firmware version using
enum ath10k_fw_features, but not sure if that's worth all the extra work.
Baochen, do you know more about this firmware bug? Any suggestions?
OK, there are two issues here:
1. invalid HT rate: "ath10k_pci :02:00.0: invalid ht params rate 1440 100kbps
nss 2 mcs 7".
As commented by Wen quite some time ago, this has been fixed from
firmware side, and firmware newer than [ver:241] has the fix
included.
This is the issue from 2021, correct?
2. invaid VHT rate: "ath10k_pci :3a:00.0: invalid vht params rate 1920 100kbps
nss 2 mcs 9".
After checking with firmware team, I thought this is because there is
a mismatch in rate definition between host and firmware: In host, the
rate for 'nss 2 mcs 9' is defined as {1560, 1733}, see
supported_vht_mcs_rate_nss2[]. While in firmware this is defined as
{1730, 1920}. So seems we can update host definition to avoid this
issue.
Looking through the logs since May 2024, I have four different logs:
1. invalid vht params rate 878 100kbps nss 3 mcs 2
2. invalid vht params rate 960 100kbps nss 1 mcs 9
3. invalid vht params rate 1730 100kbps nss 2 mcs 9
4. invalid vht params rate 1920 100kbps nss 2 mcs 9
I believe it’s only happening with Cisco networks. I am happy to test a
patch.
By the way, is the firmware version logged by Linux?
ath10k_pci :3a:00.0: qca6174 hw3.2 target 0x0503 chip_id
0x00340aff sub 1a56:1535
ath10k_pci :3a:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0
testmode 0
ath10k_pci :3a:00.0: firmware ver WLAN.RM.4.4.1-00288- api 6
features wowlan,ignore-otp,mfp crc32 bf907c7c
ath10k_pci :3a:00.0: board_file api 2 bmi_id N/A crc32 d2863f91
ath10k_pci :3a:00.0: htt-ver 3.87 wmi-op 4 htt-op 3 cal otp
max-sta 32 raw 0 hwcrypto 1
Is it 4.4.1-00288? How can I find the file in `/lib/firmware/`?
Kind regards,
Paul
Re: invalid vht params rate 1920 100kbps nss 2 mcs 9
On 6/18/2024 6:33 PM, Kalle Valo wrote:
> + baochen
>
> James Prestwood writes:
>
>> Hi Kalle,
>>
>> On 6/17/24 8:27 AM, Kalle Valo wrote:
>>> James Prestwood writes:
>>>
Hi Paul,
On 6/16/24 6:10 AM, Paul Menzel wrote:
> Dear Linux folks,
>
>
> Linux 6.10-rc3 (commit a3e18a540541) logged the warning below when
> connecting to a public WiFi:
>
> ath10k_pci :3a:00.0: invalid vht params rate 1920 100kbps
> nss 2 mcs 9
This has been reported/discussed [1]. It was hinted that there was a
firmware fix for this, but none that I tried got rid of it. I got fed
up enough with the logs filling up with this I patched our kernel to
remove the warning. AFAICT it appears benign (?). Removing the warning
was purely "cosmetic" so other devs stopped complaining about it :)
[1] https://www.mail-archive.com/ath10k@lists.infradead.org/msg13406.html
>>> More reliable link to the discussion:
>>>
>>> https://lore.kernel.org/ath10k/76a816d983e6c4d636311738396f97971b5523fb.1612915444.git.sk...@linuxfoundation.org/
>>>
>>> I think we should add this workaround I mentioned in 2021:
>>>
>>> "If the firmware still keeps sending invalid rates we should add a
>>> specific check to ignore the known invalid values, but not all of
>>> them."
>>>
>>> https://lore.kernel.org/ath10k/87h7mktjgi@codeaurora.org/
>>>
>>> I guess that would be mcs == 7 and rate == 1440?
>>
>> I think its more than this combination (Paul's are different).
>
> Good point.
>
>> So how many combinations are we willing to add here? Seems like that
>> could get out of hand if there are more than a few invalid
>> combinations.
>
> Yeah, but there haven't been that many different values reported yet,
> right? And I expect that ath10k user base will just get smaller in the
> future so the chances are that we will get less reports.
>
>> Would we also want to restrict the workaround to specific
>> hardware/firmware?
>
> Good idea, limiting per hardware would be simple to implement using
> hw_params. Of course we could even limit this per firmware version using
> enum ath10k_fw_features, but not sure if that's worth all the extra work.
>
> Baochen, do you know more about this firmware bug? Any suggestions?
OK, there are two issues here:
1. invalid HT rate: "ath10k_pci :02:00.0: invalid ht params rate 1440
100kbps nss 2 mcs 7".
As commented by Wen quite some time ago, this has been fixed from firmware
side, and firmware newer than [ver:241] has the fix included.
2. invaid VHT rate: "ath10k_pci :3a:00.0: invalid vht params rate 1920
100kbps nss 2 mcs 9".
After checking with firmware team, I thought this is because there is a
mismatch in rate definition between host and firmware: In host, the rate for
'nss 2 mcs 9' is defined as {1560, 1733}, see supported_vht_mcs_rate_nss2[].
While in firmware this is defined as {1730, 1920}. So seems we can update host
definition to avoid this issue.
>
