Compex WLE200NX: regdomain sanitized regression

Compex WLE200NX: regdomain sanitized regression

[Sebastian Bachmann]

Hello,

I recently upgraded my Debian based AP from buster to bullseye, just to 
find out that hostapd does not work any more, because all 5GHz channels 
are marked as No-IR. This regression was already discussed on this ML 
here: https://www.mail-archive.com/ath10k@lists.infradead.org/msg12018.html
and there is also an entry in Debian's bug tracker for the same issue: 
https://bugs.debian.org/959821

I have a slightly different card (branded Compex WLE200NX):
04:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network 
Adapter (PCI-Express) (rev 01)
         Subsystem: Qualcomm Atheros AR928X Wireless Network Adapter 
(PCI-Express)
         Kernel driver in use: ath9k
         Kernel modules: ath9k

But as you can see, also the EEPROM gets sanitized:
[   15.461755] ath9k 0000:04:00.0: enabling device (0000 -> 0002)
[   15.911600] ath: EEPROM regdomain sanitized
[   15.911612] ath: EEPROM regdomain: 0x64
[   15.911615] ath: EEPROM indicates we should expect a direct regpair map
[   15.911625] ath: Country alpha2 being used: 00
[   15.911628] ath: Regpair used: 0x64

I read in the other thread, that this is a regression, but the actual 
commit causing it was never reverted.
I tried to search for newer messages explaining the issue, however as 
far as I can tell, the thread ends in June 2020 with no solution available.

Therefore, I kindly want to ask if there is any workaround available to 
re-enable 5GHz channels in AP mode for my card? (expect sticking to a 
pre-5.6 kernel or manually patching and recompiling ath)

Best,
Sebastian

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Compex WLE200NX: regdomain sanitized regression

[Thorsten Leemhuis]

Hi, this is your Linux kernel regression tracker speaking.

Thanks for the report. CCing regression mailing list, which should be in
the loop for all regressions, as explained here:
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

Also adding the ath10k maintainer and the author of the likely culprit
of this regressions to the recipients.

On 27.11.21 09:17, Sebastian Bachmann wrote:
> 
> I recently upgraded my Debian based AP from buster to bullseye, just to
> find out that hostapd does not work any more, because all 5GHz channels
> are marked as No-IR. This regression was already discussed on this ML
> here: https://www.mail-archive.com/ath10k@lists.infradead.org/msg12018.html
> and there is also an entry in Debian's bug tracker for the same issue:
> https://bugs.debian.org/959821

TWIMC: To be sure this issue doesn't fall through the cracks unnoticed
again, I'm adding it to regzbot, my Linux kernel regression tracking bot:

#regzbot ^introduced 2dc016599cfa9672a147528ca26d70c3654a5423
#regzbot title net: wireless: ath10k: 5GHz channels are marked as No-IR
#regzbot monitor
https://lore.kernel.org/ath10k/5971a327-d11a-35e6-8295-8dfb8ae3a434@yandex.ru/
#regzbot monitor
https://lore.kernel.org/linux-wireless/20200730124923.271429-1-alsi@bang-olufsen.dk/
#regzbot monitor
https://lore.kernel.org/ath10k/19e636c1-fdbe-7222-a055-d668e4617070@gmx.de/
#regzbot monitor
https://lore.kernel.org/ath10k/20201022172113.GA1367233@capeo.gueux.org/
#regzbot link: https://bugs.debian.org/959821
#regzbot link: https://bbs.archlinux.org/viewtopic.php?id=254535
#regzbot link:
https://lore.kernel.org/ath10k/CA+ASDXNNfG3-ra8C2ou457J=Vj5eE83VCXgGsFPQQOixTcu7YA@mail.gmail.com/
#regzbot ignore-activity

Reminder for developers: when fixing this, please include a 'Link:' tag
pointing to the report (the parent of this mail), as explained here:
Documentation/process/submitting-patches.rst

> I have a slightly different card (branded Compex WLE200NX):
> 04:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network
> Adapter (PCI-Express) (rev 01)
>         Subsystem: Qualcomm Atheros AR928X Wireless Network Adapter
> (PCI-Express)
>         Kernel driver in use: ath9k
>         Kernel modules: ath9k
> 
> But as you can see, also the EEPROM gets sanitized:
> [   15.461755] ath9k 0000:04:00.0: enabling device (0000 -> 0002)
> [   15.911600] ath: EEPROM regdomain sanitized
> [   15.911612] ath: EEPROM regdomain: 0x64
> [   15.911615] ath: EEPROM indicates we should expect a direct regpair map
> [   15.911625] ath: Country alpha2 being used: 00
> [   15.911628] ath: Regpair used: 0x64
> 
> I read in the other thread, that this is a regression, but the actual
> commit causing it was never reverted.

:-/

> I tried to search for newer messages explaining the issue, however as
> far as I can tell, the thread ends in June 2020 with no solution available.
> 
> Therefore, I kindly want to ask if there is any workaround available to
> re-enable 5GHz channels in AP mode for my card? (expect sticking to a
> pre-5.6 kernel or manually patching and recompiling ath)

Ciao, Thorsten, your Linux kernel regression tracker.

P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
on my table. I can only look briefly into most of them. Unfortunately
therefore I sometimes will get things wrong or miss something important.
I hope that's not the case here; if you think it is, don't hesitate to
tell me about it in a public reply. That's in everyone's interest, as
what I wrote above might be misleading to everyone reading this; any
suggestion I gave they thus might sent someone reading this down the
wrong rabbit hole, which none of us wants.

BTW, I have no personal interest in this issue, which is tracked using
regzbot, my Linux kernel regression tracking bot
(https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
this mail to get things rolling again and hence don't need to be CC on
all further activities wrt to this regression.

P.P.S.: If you want to know more about regzbot, check out its
web-interface, the getting start guide, and/or the references documentation:

https://linux-regtracking.leemhuis.info/regzbot/
https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md
https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md

The last two documents will explain how you can interact with regzbot
yourself if your want to.

Hint for the reporter: when reporting a regression it's in your interest
to tell #regzbot about it in the report, as that will ensure the
regression gets on the radar of regzbot and the regression tracker.
That's in your interest, as they will make sure the report won't fall
through the cracks unnoticed.

Hint for developers: you normally don't need to care about regzbot, just
fix the issue as you normally would. Just remember to include a 'Link:'
tag to the report in the commit message, as explained in
Documentation/process/submitting-patches.rst
That aspect was recently was made more explicit in commit 1f57bd42b77c:
https://git.kernel.org/linus/1f57bd42b77c

Re: Compex WLE200NX: regdomain sanitized regression

[Thorsten Leemhuis]

Hi, this is your Linux kernel regression tracker speaking.

Thanks for the report. CCing regression mailing list, which should be in
the loop for all regressions, as explained here:
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

Also adding the ath10k maintainer and the author of the likely culprit
of this regressions to the recipients.

On 27.11.21 09:17, Sebastian Bachmann wrote:
> 
> I recently upgraded my Debian based AP from buster to bullseye, just to
> find out that hostapd does not work any more, because all 5GHz channels
> are marked as No-IR. This regression was already discussed on this ML
> here: https://www.mail-archive.com/ath10k@lists.infradead.org/msg12018.html
> and there is also an entry in Debian's bug tracker for the same issue:
> https://bugs.debian.org/959821

TWIMC: To be sure this issue doesn't fall through the cracks unnoticed
again, I'm adding it to regzbot, my Linux kernel regression tracking bot:

#regzbot ^introduced 2dc016599cfa9672a147528ca26d70c3654a5423
#regzbot title net: wireless: ath10k: 5GHz channels are marked as No-IR
#regzbot monitor
https://lore.kernel.org/ath10k/5971a327-d11a-35e6-8295-8dfb8ae3a434@yandex.ru/
#regzbot monitor
https://lore.kernel.org/linux-wireless/20200730124923.271429-1-alsi@bang-olufsen.dk/
#regzbot monitor
https://lore.kernel.org/ath10k/19e636c1-fdbe-7222-a055-d668e4617070@gmx.de/
#regzbot monitor
https://lore.kernel.org/ath10k/20201022172113.GA1367233@capeo.gueux.org/
#regzbot link: https://bugs.debian.org/959821
#regzbot link: https://bbs.archlinux.org/viewtopic.php?id=254535
#regzbot link:
https://lore.kernel.org/ath10k/CA+ASDXNNfG3-ra8C2ou457J=Vj5eE83VCXgGsFPQQOixTcu7YA@mail.gmail.com/
#regzbot ignore-activity

Reminder for developers: when fixing this, please include a 'Link:' tag
pointing to the report (the parent of this mail), as explained here:
Documentation/process/submitting-patches.rst

> I have a slightly different card (branded Compex WLE200NX):
> 04:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network
> Adapter (PCI-Express) (rev 01)
>         Subsystem: Qualcomm Atheros AR928X Wireless Network Adapter
> (PCI-Express)
>         Kernel driver in use: ath9k
>         Kernel modules: ath9k
> 
> But as you can see, also the EEPROM gets sanitized:
> [   15.461755] ath9k 0000:04:00.0: enabling device (0000 -> 0002)
> [   15.911600] ath: EEPROM regdomain sanitized
> [   15.911612] ath: EEPROM regdomain: 0x64
> [   15.911615] ath: EEPROM indicates we should expect a direct regpair map
> [   15.911625] ath: Country alpha2 being used: 00
> [   15.911628] ath: Regpair used: 0x64
> 
> I read in the other thread, that this is a regression, but the actual
> commit causing it was never reverted.

:-/

> I tried to search for newer messages explaining the issue, however as
> far as I can tell, the thread ends in June 2020 with no solution available.
> 
> Therefore, I kindly want to ask if there is any workaround available to
> re-enable 5GHz channels in AP mode for my card? (expect sticking to a
> pre-5.6 kernel or manually patching and recompiling ath)

Ciao, Thorsten, your Linux kernel regression tracker.

P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
on my table. I can only look briefly into most of them. Unfortunately
therefore I sometimes will get things wrong or miss something important.
I hope that's not the case here; if you think it is, don't hesitate to
tell me about it in a public reply. That's in everyone's interest, as
what I wrote above might be misleading to everyone reading this; any
suggestion I gave they thus might sent someone reading this down the
wrong rabbit hole, which none of us wants.

BTW, I have no personal interest in this issue, which is tracked using
regzbot, my Linux kernel regression tracking bot
(https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
this mail to get things rolling again and hence don't need to be CC on
all further activities wrt to this regression.

P.P.S.: If you want to know more about regzbot, check out its
web-interface, the getting start guide, and/or the references documentation:

https://linux-regtracking.leemhuis.info/regzbot/
https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md
https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md

The last two documents will explain how you can interact with regzbot
yourself if your want to.

Hint for the reporter: when reporting a regression it's in your interest
to tell #regzbot about it in the report, as that will ensure the
regression gets on the radar of regzbot and the regression tracker.
That's in your interest, as they will make sure the report won't fall
through the cracks unnoticed.

Hint for developers: you normally don't need to care about regzbot, just
fix the issue as you normally would. Just remember to include a 'Link:'
tag to the report in the commit message, as explained in
Documentation/process/submitting-patches.rst
That aspect was recently was made more explicit in commit 1f57bd42b77c:
https://git.kernel.org/linus/1f57bd42b77c

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Compex WLE200NX: regdomain sanitized regression

[Nuno Oliveira]

[-- Attachment #1: Type: text/plain, Size: 3354 bytes --]

Hi Sebastian,

* Sebastian Bachmann <hello@reox.at> [2021-11-27 08:17]:
>Hello,
>
>I recently upgraded my Debian based AP from buster to bullseye, just 
>to find out that hostapd does not work any more, because all 5GHz 
>channels are marked as No-IR. This regression was already discussed on 
>this ML here: 
>https://www.mail-archive.com/ath10k@lists.infradead.org/msg12018.html
>and there is also an entry in Debian's bug tracker for the same issue: 
>https://bugs.debian.org/959821
>
>I have a slightly different card (branded Compex WLE200NX):
>04:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network 
>Adapter (PCI-Express) (rev 01)
>        Subsystem: Qualcomm Atheros AR928X Wireless Network Adapter 
>(PCI-Express)
>        Kernel driver in use: ath9k
>        Kernel modules: ath9k
>
>But as you can see, also the EEPROM gets sanitized:
>[   15.461755] ath9k 0000:04:00.0: enabling device (0000 -> 0002)
>[   15.911600] ath: EEPROM regdomain sanitized
>[   15.911612] ath: EEPROM regdomain: 0x64
>[   15.911615] ath: EEPROM indicates we should expect a direct regpair map
>[   15.911625] ath: Country alpha2 being used: 00
>[   15.911628] ath: Regpair used: 0x64
>
>I read in the other thread, that this is a regression, but the actual 
>commit causing it was never reverted.
>I tried to search for newer messages explaining the issue, however as 
>far as I can tell, the thread ends in June 2020 with no solution 
>available.
>
>Therefore, I kindly want to ask if there is any workaround available 
>to re-enable 5GHz channels in AP mode for my card? (expect sticking to 
>a pre-5.6 kernel or manually patching and recompiling ath)

After June 2020 there were other users also affected by this change (see 
e.g., 
https://lists.infradead.org/pipermail/ath10k/2021-August/012802.html).
Users were complaining that this change was too restrictive since it 
meant that the intersection of restrictions for regdomains 0x00, 0x64,
US, and their local domain, together with a cumulative mode of applying 
these constraints meant that, in practice, they would not be able to use 
their world domain cards anymore as APs in the 5GHz band, for certain 
regdomains where they were located.

And several people pinpointed the exact source changes responsible for 
this. In my case, I ended up applying the attached patch, that just 
loads the parameters for the regdomain that I'm interested in 
(CTRY_PORTUGAL). I'm not in the US; and I care for their regulatory 
restrictions as much as they are interested in mine.

So I think that you might be able to use the attached changes, with the 
specific CTRY_xxx parameter suitable for your case. And then recompile 
the respective Debian kernel package, which takes a lot of CPU if you 
just recompile the whole package. Let me know if you need instructions.

A more robust option would be to go the OpenWRT way, and use their 
patches to make this country selection a parameter for the kernel 
module. This way, you would just reload the kernel module to change to a 
new regdomain, subject to the restrictions of your hardware / firmware. 
I have not looked into that. Please let me know if you isolate these 
patches.

In any case it seems difficult to escape a kernel recompile, due to this 
small, entirely legitimate, yet remarkable decision by the driver 
maintainers.

Regards,

Nuno.

[-- Attachment #2: ath-regd.c.patch --]
[-- Type: text/x-diff, Size: 793 bytes --]

--- linux-5.10.46/drivers/net/wireless/ath/regd.c.orig	2021-08-24 12:53:00.720758279 +0100
+++ linux-5.10.46/drivers/net/wireless/ath/regd.c	2021-08-24 12:54:10.524567276 +0100
@@ -675,8 +675,8 @@
 {
 	if (reg->current_rd != COUNTRY_ERD_FLAG && reg->current_rd != 0)
 		return;
-	printk(KERN_DEBUG "ath: EEPROM regdomain sanitized\n");
-	reg->current_rd = 0x64;
+	/* printk(KERN_DEBUG "ath: EEPROM regdomain sanitized\n");
+	reg->current_rd = 0x64; */
 }
 
 static int __ath_regd_init(struct ath_regulatory *reg)
@@ -703,7 +703,7 @@
 	    regdmn == CTRY_DEFAULT) {
 		printk(KERN_DEBUG "ath: EEPROM indicates default "
 		       "country code should be used\n");
-		reg->country_code = CTRY_UNITED_STATES;
+		reg->country_code = CTRY_PORTUGAL;
 	}
 
 	if (reg->country_code == CTRY_DEFAULT) {

[-- Attachment #3: Type: text/plain, Size: 146 bytes --]

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Compex WLE200NX: regdomain sanitized regression

[Sebastian Bachmann]

On 27.11.2021 13:21, Nuno Oliveira wrote:
> After June 2020 there were other users also affected by this change (see 
> e.g., 
> https://lists.infradead.org/pipermail/ath10k/2021-August/012802.html).
> Users were complaining that this change was too restrictive since it 
> meant that the intersection of restrictions for regdomains 0x00, 0x64,
> US, and their local domain, together with a cumulative mode of applying 
> these constraints meant that, in practice, they would not be able to use 
> their world domain cards anymore as APs in the 5GHz band, for certain 
> regdomains where they were located.

Thanks for hinting me to this thread, I have not seen that before. I 
read in this thread and the linked ones and understand the issue now a 
bit better.
It seems like that basically many (all ?) Compex cards are affected by 
this, and probably many pcengines users (like me).

Reading also this: 
https://web.archive.org/web/20150117040022/http://article.gmane.org/gmane.linux.kernel.wireless.general/38410
gives me the impression that in this case, I would have to ask 
pcengines/compex for a custom regulatory.bin. Has anyone tried that already?
It also sounds like that many vendors have used this value completely 
wrong. Does anyone know if new Compex cards have the same issue?
Or in other words: what would be the correct value to put there, because 
it seems there are only two options: ship a custom regulatory.bin or 
ship the card with the country burned in it, where the card shall be used.

> A more robust option would be to go the OpenWRT way, and use their 
> patches to make this country selection a parameter for the kernel 
> module. This way, you would just reload the kernel module to change to a 
> new regdomain, subject to the restrictions of your hardware / firmware. 
> I have not looked into that. Please let me know if you isolate these 
> patches.

There is this patch: 
https://github.com/openwrt/openwrt/blob/master/package/kernel/mac80211/patches/ath/402-ath_regd_optional.patch
However, it simply disables it completely.
I have not found the patch, which would enable a parameter to set it 
during loading of the module so far though.

> 
> In any case it seems difficult to escape a kernel recompile, due to this 
> small, entirely legitimate, yet remarkable decision by the driver 
> maintainers.

Yes, for me this is sad. My setup worked for over seven years and broke 
because of an update. Of course I can now start to build kernels every 
time...
It sounds like I should throw away the Compex card and buy an 
off-the-shelf access point... I was thinking about buying a new card, 
but as there are so many reports regarding Compex cards, I have no hope 
that it will work then.

Regards,
Sebastian

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Compex WLE200NX: regdomain sanitized regression

[Thorsten Leemhuis]

Hi, this is your Linux kernel regression tracker speaking.

On 27.11.21 13:21, Nuno Oliveira wrote:
> * Sebastian Bachmann <hello@reox.at> [2021-11-27 08:17]:
>
>> I recently upgraded my Debian based AP from buster to bullseye, just
>> to find out that hostapd does not work any more, because all 5GHz
>> channels are marked as No-IR. This regression was already discussed on
>> this ML here:
>> https://www.mail-archive.com/ath10k@lists.infradead.org/msg12018.html
>> and there is also an entry in Debian's bug tracker for the same issue:
>> https://bugs.debian.org/959821
>>
>> I have a slightly different card (branded Compex WLE200NX):
>> 04:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network
>> Adapter (PCI-Express) (rev 01)
>>        Subsystem: Qualcomm Atheros AR928X Wireless Network Adapter
>> (PCI-Express)
>>        Kernel driver in use: ath9k
>>        Kernel modules: ath9k
>>
>> But as you can see, also the EEPROM gets sanitized:
>> [   15.461755] ath9k 0000:04:00.0: enabling device (0000 -> 0002)
>> [   15.911600] ath: EEPROM regdomain sanitized
>> [   15.911612] ath: EEPROM regdomain: 0x64
>> [   15.911615] ath: EEPROM indicates we should expect a direct regpair
>> map
>> [   15.911625] ath: Country alpha2 being used: 00
>> [   15.911628] ath: Regpair used: 0x64
>>
>> I read in the other thread, that this is a regression, but the actual
>> commit causing it was never reverted.
>> I tried to search for newer messages explaining the issue, however as
>> far as I can tell, the thread ends in June 2020 with no solution
>> available.
>>
>> Therefore, I kindly want to ask if there is any workaround available
>> to re-enable 5GHz channels in AP mode for my card? (expect sticking to
>> a pre-5.6 kernel or manually patching and recompiling ath)
> 
> After June 2020 there were other users also affected by this change (see
> e.g.,
> https://lists.infradead.org/pipermail/ath10k/2021-August/012802.html).
> Users were complaining that this change was too restrictive since it
> meant that the intersection of restrictions for regdomains 0x00, 0x64,
> US, and their local domain, together with a cumulative mode of applying
> these constraints meant that, in practice, they would not be able to use
> their world domain cards anymore as APs in the 5GHz band, for certain
> regdomains where they were located.
> 
> And several people pinpointed the exact source changes responsible for
> this. In my case, I ended up applying the attached patch, that just
> loads the parameters for the regdomain that I'm interested in
> (CTRY_PORTUGAL). I'm not in the US; and I care for their regulatory
> restrictions as much as they are interested in mine.
> 
> So I think that you might be able to use the attached changes, with the
> specific CTRY_xxx parameter suitable for your case. And then recompile
> the respective Debian kernel package, which takes a lot of CPU if you
> just recompile the whole package. Let me know if you need instructions.
> 
> A more robust option would be to go the OpenWRT way, and use their
> patches to make this country selection a parameter for the kernel
> module. This way, you would just reload the kernel module to change to a
> new regdomain, subject to the restrictions of your hardware / firmware.
> I have not looked into that. Please let me know if you isolate these
> patches.
> 
> In any case it seems difficult to escape a kernel recompile, due to this
> small, entirely legitimate, yet remarkable decision by the driver
> maintainers.

This is a regression due to 2dc016599cfa ("ath: add support for special
0x0 regulatory domain") that seems to affect quite a few users, but
afaics was never properly addressed. I fully understand that this might
be a special case where Linus' "no regressions" rule can't be simply
applied.

But isn't there some way to provide users with a solution that doesn't
force users to compile a module or a kernel? Like a module-parameter
that only works if the the regulatory domain code in the EEPROM is empty
(as apparently used by OpenWRT?). Yes, module parameters are normally a
bad idea, but this case it might be a situation where it's the best
solution.

Ciao, Thorsten

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Compex WLE200NX: regdomain sanitized regression

[Thorsten Leemhuis]

Hi, this is your Linux kernel regression tracker speaking.

On 27.11.21 13:21, Nuno Oliveira wrote:
> * Sebastian Bachmann <hello@reox.at> [2021-11-27 08:17]:
>
>> I recently upgraded my Debian based AP from buster to bullseye, just
>> to find out that hostapd does not work any more, because all 5GHz
>> channels are marked as No-IR. This regression was already discussed on
>> this ML here:
>> https://www.mail-archive.com/ath10k@lists.infradead.org/msg12018.html
>> and there is also an entry in Debian's bug tracker for the same issue:
>> https://bugs.debian.org/959821
>>
>> I have a slightly different card (branded Compex WLE200NX):
>> 04:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network
>> Adapter (PCI-Express) (rev 01)
>>        Subsystem: Qualcomm Atheros AR928X Wireless Network Adapter
>> (PCI-Express)
>>        Kernel driver in use: ath9k
>>        Kernel modules: ath9k
>>
>> But as you can see, also the EEPROM gets sanitized:
>> [   15.461755] ath9k 0000:04:00.0: enabling device (0000 -> 0002)
>> [   15.911600] ath: EEPROM regdomain sanitized
>> [   15.911612] ath: EEPROM regdomain: 0x64
>> [   15.911615] ath: EEPROM indicates we should expect a direct regpair
>> map
>> [   15.911625] ath: Country alpha2 being used: 00
>> [   15.911628] ath: Regpair used: 0x64
>>
>> I read in the other thread, that this is a regression, but the actual
>> commit causing it was never reverted.
>> I tried to search for newer messages explaining the issue, however as
>> far as I can tell, the thread ends in June 2020 with no solution
>> available.
>>
>> Therefore, I kindly want to ask if there is any workaround available
>> to re-enable 5GHz channels in AP mode for my card? (expect sticking to
>> a pre-5.6 kernel or manually patching and recompiling ath)
> 
> After June 2020 there were other users also affected by this change (see
> e.g.,
> https://lists.infradead.org/pipermail/ath10k/2021-August/012802.html).
> Users were complaining that this change was too restrictive since it
> meant that the intersection of restrictions for regdomains 0x00, 0x64,
> US, and their local domain, together with a cumulative mode of applying
> these constraints meant that, in practice, they would not be able to use
> their world domain cards anymore as APs in the 5GHz band, for certain
> regdomains where they were located.
> 
> And several people pinpointed the exact source changes responsible for
> this. In my case, I ended up applying the attached patch, that just
> loads the parameters for the regdomain that I'm interested in
> (CTRY_PORTUGAL). I'm not in the US; and I care for their regulatory
> restrictions as much as they are interested in mine.
> 
> So I think that you might be able to use the attached changes, with the
> specific CTRY_xxx parameter suitable for your case. And then recompile
> the respective Debian kernel package, which takes a lot of CPU if you
> just recompile the whole package. Let me know if you need instructions.
> 
> A more robust option would be to go the OpenWRT way, and use their
> patches to make this country selection a parameter for the kernel
> module. This way, you would just reload the kernel module to change to a
> new regdomain, subject to the restrictions of your hardware / firmware.
> I have not looked into that. Please let me know if you isolate these
> patches.
> 
> In any case it seems difficult to escape a kernel recompile, due to this
> small, entirely legitimate, yet remarkable decision by the driver
> maintainers.

This is a regression due to 2dc016599cfa ("ath: add support for special
0x0 regulatory domain") that seems to affect quite a few users, but
afaics was never properly addressed. I fully understand that this might
be a special case where Linus' "no regressions" rule can't be simply
applied.

But isn't there some way to provide users with a solution that doesn't
force users to compile a module or a kernel? Like a module-parameter
that only works if the the regulatory domain code in the EEPROM is empty
(as apparently used by OpenWRT?). Yes, module parameters are normally a
bad idea, but this case it might be a situation where it's the best
solution.

Ciao, Thorsten

Re: Compex WLE200NX: regdomain sanitized regression

[Sebastian Bachmann]

Hi,

thanks everyone for the suggestions and hints to DKMS and patches!

On 01.12.2021 10:06, Thorsten Leemhuis wrote:
> This is a regression due to 2dc016599cfa ("ath: add support for special
> 0x0 regulatory domain") that seems to affect quite a few users, but
> afaics was never properly addressed. I fully understand that this might
> be a special case where Linus' "no regressions" rule can't be simply
> applied.

I asked the retailer where I bought the Compex card if they have heard 
of this issue and if the cards they are currently selling have the same 
problem.
They said, that all their cards they are selling have a region ID of 
0x00, which they assume to be "set your own region ID using crda".
Obviously this one anecdote cannot speak for all retailers, but it seems 
like this misconception affects manufacturer, retailers and users likewise.
I think blaming the manufacturer and having users suffer isn't the best 
idea, however I do not have a good solution either.

What I still haven't found out is what region ID would be "set your own 
region ID using crda", i.e., what region ID would give the old behaviour 
with a new kernel? Do I understood it correctly, that such cards must 
not exist?

I "solved" my issue now by buying an off-the-shelf access point...
Regardless, I would still love to get my hostapd based access point back 
online using a current mainline kernel.

Best,
Sebastian

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Compex WLE200NX: regdomain sanitized regression

[Kalle Valo]

Thorsten Leemhuis <regressions@leemhuis.info> writes:

> Hi, this is your Linux kernel regression tracker speaking.
>
> On 27.11.21 13:21, Nuno Oliveira wrote:
>> * Sebastian Bachmann <hello@reox.at> [2021-11-27 08:17]:
>>
>>> I recently upgraded my Debian based AP from buster to bullseye, just
>>> to find out that hostapd does not work any more, because all 5GHz
>>> channels are marked as No-IR. This regression was already discussed on
>>> this ML here:
>>> https://www.mail-archive.com/ath10k@lists.infradead.org/msg12018.html
>>> and there is also an entry in Debian's bug tracker for the same issue:
>>> https://bugs.debian.org/959821
>>>
>>> I have a slightly different card (branded Compex WLE200NX):
>>> 04:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network
>>> Adapter (PCI-Express) (rev 01)
>>>        Subsystem: Qualcomm Atheros AR928X Wireless Network Adapter
>>> (PCI-Express)
>>>        Kernel driver in use: ath9k
>>>        Kernel modules: ath9k
>>>
>>> But as you can see, also the EEPROM gets sanitized:
>>> [   15.461755] ath9k 0000:04:00.0: enabling device (0000 -> 0002)
>>> [   15.911600] ath: EEPROM regdomain sanitized
>>> [   15.911612] ath: EEPROM regdomain: 0x64
>>> [   15.911615] ath: EEPROM indicates we should expect a direct regpair
>>> map
>>> [   15.911625] ath: Country alpha2 being used: 00
>>> [   15.911628] ath: Regpair used: 0x64
>>>
>>> I read in the other thread, that this is a regression, but the actual
>>> commit causing it was never reverted.
>>> I tried to search for newer messages explaining the issue, however as
>>> far as I can tell, the thread ends in June 2020 with no solution
>>> available.
>>>
>>> Therefore, I kindly want to ask if there is any workaround available
>>> to re-enable 5GHz channels in AP mode for my card? (expect sticking to
>>> a pre-5.6 kernel or manually patching and recompiling ath)
>> 
>> After June 2020 there were other users also affected by this change (see
>> e.g.,
>> https://lists.infradead.org/pipermail/ath10k/2021-August/012802.html).
>> Users were complaining that this change was too restrictive since it
>> meant that the intersection of restrictions for regdomains 0x00, 0x64,
>> US, and their local domain, together with a cumulative mode of applying
>> these constraints meant that, in practice, they would not be able to use
>> their world domain cards anymore as APs in the 5GHz band, for certain
>> regdomains where they were located.
>> 
>> And several people pinpointed the exact source changes responsible for
>> this. In my case, I ended up applying the attached patch, that just
>> loads the parameters for the regdomain that I'm interested in
>> (CTRY_PORTUGAL). I'm not in the US; and I care for their regulatory
>> restrictions as much as they are interested in mine.
>> 
>> So I think that you might be able to use the attached changes, with the
>> specific CTRY_xxx parameter suitable for your case. And then recompile
>> the respective Debian kernel package, which takes a lot of CPU if you
>> just recompile the whole package. Let me know if you need instructions.
>> 
>> A more robust option would be to go the OpenWRT way, and use their
>> patches to make this country selection a parameter for the kernel
>> module. This way, you would just reload the kernel module to change to a
>> new regdomain, subject to the restrictions of your hardware / firmware.
>> I have not looked into that. Please let me know if you isolate these
>> patches.
>> 
>> In any case it seems difficult to escape a kernel recompile, due to this
>> small, entirely legitimate, yet remarkable decision by the driver
>> maintainers.
>
> This is a regression due to 2dc016599cfa ("ath: add support for special
> 0x0 regulatory domain") that seems to affect quite a few users, but
> afaics was never properly addressed. I fully understand that this might
> be a special case where Linus' "no regressions" rule can't be simply
> applied.

Yes, this is a tricky problem and I am taking a second look at this.
Regulatory rules are complicated and we do not want to break them in any
circumstance.

I see two ways to workaround this:

1) calibrate your board with a correct country code (which is impossible
   for an average user)

2) use 2.4 GHz band

> But isn't there some way to provide users with a solution that doesn't
> force users to compile a module or a kernel? Like a module-parameter
> that only works if the the regulatory domain code in the EEPROM is empty
> (as apparently used by OpenWRT?). Yes, module parameters are normally a
> bad idea, but this case it might be a situation where it's the best
> solution.

I don't think setting the country code via a module parameter would be
acceptable for the authorities, more info here:

https://wireless.wiki.kernel.org/en/developers/regulatory

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: Compex WLE200NX: regdomain sanitized regression

[Kalle Valo]

Thorsten Leemhuis <regressions@leemhuis.info> writes:

> Hi, this is your Linux kernel regression tracker speaking.
>
> On 27.11.21 13:21, Nuno Oliveira wrote:
>> * Sebastian Bachmann <hello@reox.at> [2021-11-27 08:17]:
>>
>>> I recently upgraded my Debian based AP from buster to bullseye, just
>>> to find out that hostapd does not work any more, because all 5GHz
>>> channels are marked as No-IR. This regression was already discussed on
>>> this ML here:
>>> https://www.mail-archive.com/ath10k@lists.infradead.org/msg12018.html
>>> and there is also an entry in Debian's bug tracker for the same issue:
>>> https://bugs.debian.org/959821
>>>
>>> I have a slightly different card (branded Compex WLE200NX):
>>> 04:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network
>>> Adapter (PCI-Express) (rev 01)
>>>        Subsystem: Qualcomm Atheros AR928X Wireless Network Adapter
>>> (PCI-Express)
>>>        Kernel driver in use: ath9k
>>>        Kernel modules: ath9k
>>>
>>> But as you can see, also the EEPROM gets sanitized:
>>> [   15.461755] ath9k 0000:04:00.0: enabling device (0000 -> 0002)
>>> [   15.911600] ath: EEPROM regdomain sanitized
>>> [   15.911612] ath: EEPROM regdomain: 0x64
>>> [   15.911615] ath: EEPROM indicates we should expect a direct regpair
>>> map
>>> [   15.911625] ath: Country alpha2 being used: 00
>>> [   15.911628] ath: Regpair used: 0x64
>>>
>>> I read in the other thread, that this is a regression, but the actual
>>> commit causing it was never reverted.
>>> I tried to search for newer messages explaining the issue, however as
>>> far as I can tell, the thread ends in June 2020 with no solution
>>> available.
>>>
>>> Therefore, I kindly want to ask if there is any workaround available
>>> to re-enable 5GHz channels in AP mode for my card? (expect sticking to
>>> a pre-5.6 kernel or manually patching and recompiling ath)
>> 
>> After June 2020 there were other users also affected by this change (see
>> e.g.,
>> https://lists.infradead.org/pipermail/ath10k/2021-August/012802.html).
>> Users were complaining that this change was too restrictive since it
>> meant that the intersection of restrictions for regdomains 0x00, 0x64,
>> US, and their local domain, together with a cumulative mode of applying
>> these constraints meant that, in practice, they would not be able to use
>> their world domain cards anymore as APs in the 5GHz band, for certain
>> regdomains where they were located.
>> 
>> And several people pinpointed the exact source changes responsible for
>> this. In my case, I ended up applying the attached patch, that just
>> loads the parameters for the regdomain that I'm interested in
>> (CTRY_PORTUGAL). I'm not in the US; and I care for their regulatory
>> restrictions as much as they are interested in mine.
>> 
>> So I think that you might be able to use the attached changes, with the
>> specific CTRY_xxx parameter suitable for your case. And then recompile
>> the respective Debian kernel package, which takes a lot of CPU if you
>> just recompile the whole package. Let me know if you need instructions.
>> 
>> A more robust option would be to go the OpenWRT way, and use their
>> patches to make this country selection a parameter for the kernel
>> module. This way, you would just reload the kernel module to change to a
>> new regdomain, subject to the restrictions of your hardware / firmware.
>> I have not looked into that. Please let me know if you isolate these
>> patches.
>> 
>> In any case it seems difficult to escape a kernel recompile, due to this
>> small, entirely legitimate, yet remarkable decision by the driver
>> maintainers.
>
> This is a regression due to 2dc016599cfa ("ath: add support for special
> 0x0 regulatory domain") that seems to affect quite a few users, but
> afaics was never properly addressed. I fully understand that this might
> be a special case where Linus' "no regressions" rule can't be simply
> applied.

Yes, this is a tricky problem and I am taking a second look at this.
Regulatory rules are complicated and we do not want to break them in any
circumstance.

I see two ways to workaround this:

1) calibrate your board with a correct country code (which is impossible
   for an average user)

2) use 2.4 GHz band

> But isn't there some way to provide users with a solution that doesn't
> force users to compile a module or a kernel? Like a module-parameter
> that only works if the the regulatory domain code in the EEPROM is empty
> (as apparently used by OpenWRT?). Yes, module parameters are normally a
> bad idea, but this case it might be a situation where it's the best
> solution.

I don't think setting the country code via a module parameter would be
acceptable for the authorities, more info here:

https://wireless.wiki.kernel.org/en/developers/regulatory

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Compex WLE200NX: regdomain sanitized regression

[Nuno Oliveira]

Hi Kalle,

Thanks for looking again into this.

* Kalle Valo <kvalo@kernel.org> [2021-12-20 10:38]:
>Thorsten Leemhuis <regressions@leemhuis.info> writes:
>
>> Hi, this is your Linux kernel regression tracker speaking.
>>
>> On 27.11.21 13:21, Nuno Oliveira wrote:
>>> * Sebastian Bachmann <hello@reox.at> [2021-11-27 08:17]:
>>>
>>>> I recently upgraded my Debian based AP from buster to bullseye, just
>>>> to find out that hostapd does not work any more, because all 5GHz
>>>> channels are marked as No-IR. This regression was already discussed on
>>>> this ML here:
>>>> https://www.mail-archive.com/ath10k@lists.infradead.org/msg12018.html
>>>> and there is also an entry in Debian's bug tracker for the same issue:
>>>> https://bugs.debian.org/959821
>>>>
>>>> I have a slightly different card (branded Compex WLE200NX):
>>>> 04:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network
>>>> Adapter (PCI-Express) (rev 01)
>>>>        Subsystem: Qualcomm Atheros AR928X Wireless Network Adapter
>>>> (PCI-Express)
>>>>        Kernel driver in use: ath9k
>>>>        Kernel modules: ath9k
>>>>
>>>> But as you can see, also the EEPROM gets sanitized:
>>>> [   15.461755] ath9k 0000:04:00.0: enabling device (0000 -> 0002)
>>>> [   15.911600] ath: EEPROM regdomain sanitized
>>>> [   15.911612] ath: EEPROM regdomain: 0x64
>>>> [   15.911615] ath: EEPROM indicates we should expect a direct regpair
>>>> map
>>>> [   15.911625] ath: Country alpha2 being used: 00
>>>> [   15.911628] ath: Regpair used: 0x64
>>>>
>>>> I read in the other thread, that this is a regression, but the actual
>>>> commit causing it was never reverted.
>>>> I tried to search for newer messages explaining the issue, however as
>>>> far as I can tell, the thread ends in June 2020 with no solution
>>>> available.
>>>>
>>>> Therefore, I kindly want to ask if there is any workaround available
>>>> to re-enable 5GHz channels in AP mode for my card? (expect sticking to
>>>> a pre-5.6 kernel or manually patching and recompiling ath)
>>>
>>> After June 2020 there were other users also affected by this change (see
>>> e.g.,
>>> https://lists.infradead.org/pipermail/ath10k/2021-August/012802.html).
>>> Users were complaining that this change was too restrictive since it
>>> meant that the intersection of restrictions for regdomains 0x00, 0x64,
>>> US, and their local domain, together with a cumulative mode of applying
>>> these constraints meant that, in practice, they would not be able to use
>>> their world domain cards anymore as APs in the 5GHz band, for certain
>>> regdomains where they were located.
>>>
>>> And several people pinpointed the exact source changes responsible for
>>> this. In my case, I ended up applying the attached patch, that just
>>> loads the parameters for the regdomain that I'm interested in
>>> (CTRY_PORTUGAL). I'm not in the US; and I care for their regulatory
>>> restrictions as much as they are interested in mine.
>>>
>>> So I think that you might be able to use the attached changes, with the
>>> specific CTRY_xxx parameter suitable for your case. And then recompile
>>> the respective Debian kernel package, which takes a lot of CPU if you
>>> just recompile the whole package. Let me know if you need instructions.
>>>
>>> A more robust option would be to go the OpenWRT way, and use their
>>> patches to make this country selection a parameter for the kernel
>>> module. This way, you would just reload the kernel module to change to a
>>> new regdomain, subject to the restrictions of your hardware / firmware.
>>> I have not looked into that. Please let me know if you isolate these
>>> patches.
>>>
>>> In any case it seems difficult to escape a kernel recompile, due to this
>>> small, entirely legitimate, yet remarkable decision by the driver
>>> maintainers.
>>
>> This is a regression due to 2dc016599cfa ("ath: add support for special
>> 0x0 regulatory domain") that seems to affect quite a few users, but
>> afaics was never properly addressed. I fully understand that this might
>> be a special case where Linus' "no regressions" rule can't be simply
>> applied.
>
>Yes, this is a tricky problem and I am taking a second look at this.
>Regulatory rules are complicated and we do not want to break them in any
>circumstance.
>
>I see two ways to workaround this:
>
>1) calibrate your board with a correct country code (which is impossible
>   for an average user)
>
>2) use 2.4 GHz band
>
>> But isn't there some way to provide users with a solution that doesn't
>> force users to compile a module or a kernel? Like a module-parameter
>> that only works if the the regulatory domain code in the EEPROM is empty
>> (as apparently used by OpenWRT?). Yes, module parameters are normally a
>> bad idea, but this case it might be a situation where it's the best
>> solution.
>
>I don't think setting the country code via a module parameter would be
>acceptable for the authorities, more info here:
>
>https://wireless.wiki.kernel.org/en/developers/regulatory

The issue involves finding a reasonable compromise between relative 
inconveniences, given the perspectives of both developers and users. As 
implemented currently, the restriction seems to affect both ath9k and 
ath10k (and probably ath11k -- I have not tried it, and frankly with the 
current status, I'm not eager to do it), but only when users try to run 
a 5 GHz AP. This is still reasonable (and legal) use, although not 
without many restrictions. Other drivers (e.g., iwlwifi) are much more 
restrictive relative to this, but at least they genuinely have made it 
completely clear from the beginning.

A common point of the previous messages was that, after these last 
changes, the boards with the 0x00 domain in the EEPROM were successively 
initialized with the 0x64 and later with UNITED_STATES domains by the 
driver. In practice this prevented their use as an AP when, later in 
userspace, the user tried to declare a 3rd local regdomain. My 
suggestion here would be to avoid this double interpretation of what 
default initialization would be appropriate. Either keep the old 
behavior (UNITED_STATES) which limited but did not originally prevented 
the AP usage, or replace it completely with the updated interpretation 
of what's applicable to this case (0x64); but please don't do both by 
default, or we will be in the current situation. Other users have asked 
for this before, and this sort of clarification seems to be the minimum 
to consider at this point, if anything is to be considered.

If this limiting double initialization is already achievable entirely 
through user configuration of default distribution kernels, please 
excuse my lack of knowledge. In this case, just documenting this better 
could also help other users.

Besides this consistent "safe" initialization, for users with special 
cases there's always the options of either providing alternative CRDAs 
or patching and recompiling the driver. This is a matter of relative 
inconveniences; as long as they remain feasible, it's always a weighting 
issue.

Thanks for your good work. Regards,

Nuno.

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Compex WLE200NX: regdomain sanitized regression

[Nuno Oliveira]

Hi Kalle,

Thanks for looking again into this.

* Kalle Valo <kvalo@kernel.org> [2021-12-20 10:38]:
>Thorsten Leemhuis <regressions@leemhuis.info> writes:
>
>> Hi, this is your Linux kernel regression tracker speaking.
>>
>> On 27.11.21 13:21, Nuno Oliveira wrote:
>>> * Sebastian Bachmann <hello@reox.at> [2021-11-27 08:17]:
>>>
>>>> I recently upgraded my Debian based AP from buster to bullseye, just
>>>> to find out that hostapd does not work any more, because all 5GHz
>>>> channels are marked as No-IR. This regression was already discussed on
>>>> this ML here:
>>>> https://www.mail-archive.com/ath10k@lists.infradead.org/msg12018.html
>>>> and there is also an entry in Debian's bug tracker for the same issue:
>>>> https://bugs.debian.org/959821
>>>>
>>>> I have a slightly different card (branded Compex WLE200NX):
>>>> 04:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network
>>>> Adapter (PCI-Express) (rev 01)
>>>>        Subsystem: Qualcomm Atheros AR928X Wireless Network Adapter
>>>> (PCI-Express)
>>>>        Kernel driver in use: ath9k
>>>>        Kernel modules: ath9k
>>>>
>>>> But as you can see, also the EEPROM gets sanitized:
>>>> [   15.461755] ath9k 0000:04:00.0: enabling device (0000 -> 0002)
>>>> [   15.911600] ath: EEPROM regdomain sanitized
>>>> [   15.911612] ath: EEPROM regdomain: 0x64
>>>> [   15.911615] ath: EEPROM indicates we should expect a direct regpair
>>>> map
>>>> [   15.911625] ath: Country alpha2 being used: 00
>>>> [   15.911628] ath: Regpair used: 0x64
>>>>
>>>> I read in the other thread, that this is a regression, but the actual
>>>> commit causing it was never reverted.
>>>> I tried to search for newer messages explaining the issue, however as
>>>> far as I can tell, the thread ends in June 2020 with no solution
>>>> available.
>>>>
>>>> Therefore, I kindly want to ask if there is any workaround available
>>>> to re-enable 5GHz channels in AP mode for my card? (expect sticking to
>>>> a pre-5.6 kernel or manually patching and recompiling ath)
>>>
>>> After June 2020 there were other users also affected by this change (see
>>> e.g.,
>>> https://lists.infradead.org/pipermail/ath10k/2021-August/012802.html).
>>> Users were complaining that this change was too restrictive since it
>>> meant that the intersection of restrictions for regdomains 0x00, 0x64,
>>> US, and their local domain, together with a cumulative mode of applying
>>> these constraints meant that, in practice, they would not be able to use
>>> their world domain cards anymore as APs in the 5GHz band, for certain
>>> regdomains where they were located.
>>>
>>> And several people pinpointed the exact source changes responsible for
>>> this. In my case, I ended up applying the attached patch, that just
>>> loads the parameters for the regdomain that I'm interested in
>>> (CTRY_PORTUGAL). I'm not in the US; and I care for their regulatory
>>> restrictions as much as they are interested in mine.
>>>
>>> So I think that you might be able to use the attached changes, with the
>>> specific CTRY_xxx parameter suitable for your case. And then recompile
>>> the respective Debian kernel package, which takes a lot of CPU if you
>>> just recompile the whole package. Let me know if you need instructions.
>>>
>>> A more robust option would be to go the OpenWRT way, and use their
>>> patches to make this country selection a parameter for the kernel
>>> module. This way, you would just reload the kernel module to change to a
>>> new regdomain, subject to the restrictions of your hardware / firmware.
>>> I have not looked into that. Please let me know if you isolate these
>>> patches.
>>>
>>> In any case it seems difficult to escape a kernel recompile, due to this
>>> small, entirely legitimate, yet remarkable decision by the driver
>>> maintainers.
>>
>> This is a regression due to 2dc016599cfa ("ath: add support for special
>> 0x0 regulatory domain") that seems to affect quite a few users, but
>> afaics was never properly addressed. I fully understand that this might
>> be a special case where Linus' "no regressions" rule can't be simply
>> applied.
>
>Yes, this is a tricky problem and I am taking a second look at this.
>Regulatory rules are complicated and we do not want to break them in any
>circumstance.
>
>I see two ways to workaround this:
>
>1) calibrate your board with a correct country code (which is impossible
>   for an average user)
>
>2) use 2.4 GHz band
>
>> But isn't there some way to provide users with a solution that doesn't
>> force users to compile a module or a kernel? Like a module-parameter
>> that only works if the the regulatory domain code in the EEPROM is empty
>> (as apparently used by OpenWRT?). Yes, module parameters are normally a
>> bad idea, but this case it might be a situation where it's the best
>> solution.
>
>I don't think setting the country code via a module parameter would be
>acceptable for the authorities, more info here:
>
>https://wireless.wiki.kernel.org/en/developers/regulatory

The issue involves finding a reasonable compromise between relative 
inconveniences, given the perspectives of both developers and users. As 
implemented currently, the restriction seems to affect both ath9k and 
ath10k (and probably ath11k -- I have not tried it, and frankly with the 
current status, I'm not eager to do it), but only when users try to run 
a 5 GHz AP. This is still reasonable (and legal) use, although not 
without many restrictions. Other drivers (e.g., iwlwifi) are much more 
restrictive relative to this, but at least they genuinely have made it 
completely clear from the beginning.

A common point of the previous messages was that, after these last 
changes, the boards with the 0x00 domain in the EEPROM were successively 
initialized with the 0x64 and later with UNITED_STATES domains by the 
driver. In practice this prevented their use as an AP when, later in 
userspace, the user tried to declare a 3rd local regdomain. My 
suggestion here would be to avoid this double interpretation of what 
default initialization would be appropriate. Either keep the old 
behavior (UNITED_STATES) which limited but did not originally prevented 
the AP usage, or replace it completely with the updated interpretation 
of what's applicable to this case (0x64); but please don't do both by 
default, or we will be in the current situation. Other users have asked 
for this before, and this sort of clarification seems to be the minimum 
to consider at this point, if anything is to be considered.

If this limiting double initialization is already achievable entirely 
through user configuration of default distribution kernels, please 
excuse my lack of knowledge. In this case, just documenting this better 
could also help other users.

Besides this consistent "safe" initialization, for users with special 
cases there's always the options of either providing alternative CRDAs 
or patching and recompiling the driver. This is a matter of relative 
inconveniences; as long as they remain feasible, it's always a weighting 
issue.

Thanks for your good work. Regards,

Nuno.

Re: Compex WLE200NX: regdomain sanitized regression

[Thorsten Leemhuis]

Hi, this is your Linux kernel regression tracker speaking. Top-posting
for once, to make this easy accessible to everyone.

Kalle, thx for looking into this, I'm well aware this is kinda tricky.
This is a gently reminder about the issue to ensure it doesn't fall
through the cracks. At the same time I know that it's not urgent, that
why I'm not putting it on backburner in regzbot now:

#regzbot backburner: tricky situation and around for a while, hence not
that urgent
#regzbot poke

I'll likely sent another gentle reminder after the next merge-window.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I'm getting a lot of
reports on my table. I can only look briefly into most of them and lack
knowledge about most of the areas they concern. I thus unfortunately
will sometimes get things wrong or miss something important. I hope
that's not the case here; if you think it is, don't hesitate to tell me
in a public reply, it's in everyone's interest to set the public record
straight.

On 20.12.21 19:31, Nuno Oliveira wrote:
> Hi Kalle,
> 
> Thanks for looking again into this.
> 
> * Kalle Valo <kvalo@kernel.org> [2021-12-20 10:38]:
>> Thorsten Leemhuis <regressions@leemhuis.info> writes:
>>
>>> Hi, this is your Linux kernel regression tracker speaking.
>>>
>>> On 27.11.21 13:21, Nuno Oliveira wrote:
>>>> * Sebastian Bachmann <hello@reox.at> [2021-11-27 08:17]:
>>>>
>>>>> I recently upgraded my Debian based AP from buster to bullseye, just
>>>>> to find out that hostapd does not work any more, because all 5GHz
>>>>> channels are marked as No-IR. This regression was already discussed on
>>>>> this ML here:
>>>>> https://www.mail-archive.com/ath10k@lists.infradead.org/msg12018.html
>>>>> and there is also an entry in Debian's bug tracker for the same issue:
>>>>> https://bugs.debian.org/959821
>>>>>
>>>>> I have a slightly different card (branded Compex WLE200NX):
>>>>> 04:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network
>>>>> Adapter (PCI-Express) (rev 01)
>>>>>        Subsystem: Qualcomm Atheros AR928X Wireless Network Adapter
>>>>> (PCI-Express)
>>>>>        Kernel driver in use: ath9k
>>>>>        Kernel modules: ath9k
>>>>>
>>>>> But as you can see, also the EEPROM gets sanitized:
>>>>> [   15.461755] ath9k 0000:04:00.0: enabling device (0000 -> 0002)
>>>>> [   15.911600] ath: EEPROM regdomain sanitized
>>>>> [   15.911612] ath: EEPROM regdomain: 0x64
>>>>> [   15.911615] ath: EEPROM indicates we should expect a direct regpair
>>>>> map
>>>>> [   15.911625] ath: Country alpha2 being used: 00
>>>>> [   15.911628] ath: Regpair used: 0x64
>>>>>
>>>>> I read in the other thread, that this is a regression, but the actual
>>>>> commit causing it was never reverted.
>>>>> I tried to search for newer messages explaining the issue, however as
>>>>> far as I can tell, the thread ends in June 2020 with no solution
>>>>> available.
>>>>>
>>>>> Therefore, I kindly want to ask if there is any workaround available
>>>>> to re-enable 5GHz channels in AP mode for my card? (expect sticking to
>>>>> a pre-5.6 kernel or manually patching and recompiling ath)
>>>>
>>>> After June 2020 there were other users also affected by this change
>>>> (see
>>>> e.g.,
>>>> https://lists.infradead.org/pipermail/ath10k/2021-August/012802.html).
>>>> Users were complaining that this change was too restrictive since it
>>>> meant that the intersection of restrictions for regdomains 0x00, 0x64,
>>>> US, and their local domain, together with a cumulative mode of applying
>>>> these constraints meant that, in practice, they would not be able to
>>>> use
>>>> their world domain cards anymore as APs in the 5GHz band, for certain
>>>> regdomains where they were located.
>>>>
>>>> And several people pinpointed the exact source changes responsible for
>>>> this. In my case, I ended up applying the attached patch, that just
>>>> loads the parameters for the regdomain that I'm interested in
>>>> (CTRY_PORTUGAL). I'm not in the US; and I care for their regulatory
>>>> restrictions as much as they are interested in mine.
>>>>
>>>> So I think that you might be able to use the attached changes, with the
>>>> specific CTRY_xxx parameter suitable for your case. And then recompile
>>>> the respective Debian kernel package, which takes a lot of CPU if you
>>>> just recompile the whole package. Let me know if you need instructions.
>>>>
>>>> A more robust option would be to go the OpenWRT way, and use their
>>>> patches to make this country selection a parameter for the kernel
>>>> module. This way, you would just reload the kernel module to change
>>>> to a
>>>> new regdomain, subject to the restrictions of your hardware / firmware.
>>>> I have not looked into that. Please let me know if you isolate these
>>>> patches.
>>>>
>>>> In any case it seems difficult to escape a kernel recompile, due to
>>>> this
>>>> small, entirely legitimate, yet remarkable decision by the driver
>>>> maintainers.
>>>
>>> This is a regression due to 2dc016599cfa ("ath: add support for special
>>> 0x0 regulatory domain") that seems to affect quite a few users, but
>>> afaics was never properly addressed. I fully understand that this might
>>> be a special case where Linus' "no regressions" rule can't be simply
>>> applied.
>>
>> Yes, this is a tricky problem and I am taking a second look at this.
>> Regulatory rules are complicated and we do not want to break them in any
>> circumstance.
>>
>> I see two ways to workaround this:
>>
>> 1) calibrate your board with a correct country code (which is impossible
>>   for an average user)
>>
>> 2) use 2.4 GHz band
>>
>>> But isn't there some way to provide users with a solution that doesn't
>>> force users to compile a module or a kernel? Like a module-parameter
>>> that only works if the the regulatory domain code in the EEPROM is empty
>>> (as apparently used by OpenWRT?). Yes, module parameters are normally a
>>> bad idea, but this case it might be a situation where it's the best
>>> solution.
>>
>> I don't think setting the country code via a module parameter would be
>> acceptable for the authorities, more info here:
>>
>> https://wireless.wiki.kernel.org/en/developers/regulatory
> 
> The issue involves finding a reasonable compromise between relative
> inconveniences, given the perspectives of both developers and users. As
> implemented currently, the restriction seems to affect both ath9k and
> ath10k (and probably ath11k -- I have not tried it, and frankly with the
> current status, I'm not eager to do it), but only when users try to run
> a 5 GHz AP. This is still reasonable (and legal) use, although not
> without many restrictions. Other drivers (e.g., iwlwifi) are much more
> restrictive relative to this, but at least they genuinely have made it
> completely clear from the beginning.
> 
> A common point of the previous messages was that, after these last
> changes, the boards with the 0x00 domain in the EEPROM were successively
> initialized with the 0x64 and later with UNITED_STATES domains by the
> driver. In practice this prevented their use as an AP when, later in
> userspace, the user tried to declare a 3rd local regdomain. My
> suggestion here would be to avoid this double interpretation of what
> default initialization would be appropriate. Either keep the old
> behavior (UNITED_STATES) which limited but did not originally prevented
> the AP usage, or replace it completely with the updated interpretation
> of what's applicable to this case (0x64); but please don't do both by
> default, or we will be in the current situation. Other users have asked
> for this before, and this sort of clarification seems to be the minimum
> to consider at this point, if anything is to be considered.
> 
> If this limiting double initialization is already achievable entirely
> through user configuration of default distribution kernels, please
> excuse my lack of knowledge. In this case, just documenting this better
> could also help other users.
> 
> Besides this consistent "safe" initialization, for users with special
> cases there's always the options of either providing alternative CRDAs
> or patching and recompiling the driver. This is a matter of relative
> inconveniences; as long as they remain feasible, it's always a weighting
> issue.
> 
> Thanks for your good work. Regards,
> 
> Nuno.
> 
> 

Re: Compex WLE200NX: regdomain sanitized regression

[Thorsten Leemhuis]

Hi, this is your Linux kernel regression tracker speaking. Top-posting
for once, to make this easy accessible to everyone.

Kalle, thx for looking into this, I'm well aware this is kinda tricky.
This is a gently reminder about the issue to ensure it doesn't fall
through the cracks. At the same time I know that it's not urgent, that
why I'm not putting it on backburner in regzbot now:

#regzbot backburner: tricky situation and around for a while, hence not
that urgent
#regzbot poke

I'll likely sent another gentle reminder after the next merge-window.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I'm getting a lot of
reports on my table. I can only look briefly into most of them and lack
knowledge about most of the areas they concern. I thus unfortunately
will sometimes get things wrong or miss something important. I hope
that's not the case here; if you think it is, don't hesitate to tell me
in a public reply, it's in everyone's interest to set the public record
straight.

On 20.12.21 19:31, Nuno Oliveira wrote:
> Hi Kalle,
> 
> Thanks for looking again into this.
> 
> * Kalle Valo <kvalo@kernel.org> [2021-12-20 10:38]:
>> Thorsten Leemhuis <regressions@leemhuis.info> writes:
>>
>>> Hi, this is your Linux kernel regression tracker speaking.
>>>
>>> On 27.11.21 13:21, Nuno Oliveira wrote:
>>>> * Sebastian Bachmann <hello@reox.at> [2021-11-27 08:17]:
>>>>
>>>>> I recently upgraded my Debian based AP from buster to bullseye, just
>>>>> to find out that hostapd does not work any more, because all 5GHz
>>>>> channels are marked as No-IR. This regression was already discussed on
>>>>> this ML here:
>>>>> https://www.mail-archive.com/ath10k@lists.infradead.org/msg12018.html
>>>>> and there is also an entry in Debian's bug tracker for the same issue:
>>>>> https://bugs.debian.org/959821
>>>>>
>>>>> I have a slightly different card (branded Compex WLE200NX):
>>>>> 04:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network
>>>>> Adapter (PCI-Express) (rev 01)
>>>>>        Subsystem: Qualcomm Atheros AR928X Wireless Network Adapter
>>>>> (PCI-Express)
>>>>>        Kernel driver in use: ath9k
>>>>>        Kernel modules: ath9k
>>>>>
>>>>> But as you can see, also the EEPROM gets sanitized:
>>>>> [   15.461755] ath9k 0000:04:00.0: enabling device (0000 -> 0002)
>>>>> [   15.911600] ath: EEPROM regdomain sanitized
>>>>> [   15.911612] ath: EEPROM regdomain: 0x64
>>>>> [   15.911615] ath: EEPROM indicates we should expect a direct regpair
>>>>> map
>>>>> [   15.911625] ath: Country alpha2 being used: 00
>>>>> [   15.911628] ath: Regpair used: 0x64
>>>>>
>>>>> I read in the other thread, that this is a regression, but the actual
>>>>> commit causing it was never reverted.
>>>>> I tried to search for newer messages explaining the issue, however as
>>>>> far as I can tell, the thread ends in June 2020 with no solution
>>>>> available.
>>>>>
>>>>> Therefore, I kindly want to ask if there is any workaround available
>>>>> to re-enable 5GHz channels in AP mode for my card? (expect sticking to
>>>>> a pre-5.6 kernel or manually patching and recompiling ath)
>>>>
>>>> After June 2020 there were other users also affected by this change
>>>> (see
>>>> e.g.,
>>>> https://lists.infradead.org/pipermail/ath10k/2021-August/012802.html).
>>>> Users were complaining that this change was too restrictive since it
>>>> meant that the intersection of restrictions for regdomains 0x00, 0x64,
>>>> US, and their local domain, together with a cumulative mode of applying
>>>> these constraints meant that, in practice, they would not be able to
>>>> use
>>>> their world domain cards anymore as APs in the 5GHz band, for certain
>>>> regdomains where they were located.
>>>>
>>>> And several people pinpointed the exact source changes responsible for
>>>> this. In my case, I ended up applying the attached patch, that just
>>>> loads the parameters for the regdomain that I'm interested in
>>>> (CTRY_PORTUGAL). I'm not in the US; and I care for their regulatory
>>>> restrictions as much as they are interested in mine.
>>>>
>>>> So I think that you might be able to use the attached changes, with the
>>>> specific CTRY_xxx parameter suitable for your case. And then recompile
>>>> the respective Debian kernel package, which takes a lot of CPU if you
>>>> just recompile the whole package. Let me know if you need instructions.
>>>>
>>>> A more robust option would be to go the OpenWRT way, and use their
>>>> patches to make this country selection a parameter for the kernel
>>>> module. This way, you would just reload the kernel module to change
>>>> to a
>>>> new regdomain, subject to the restrictions of your hardware / firmware.
>>>> I have not looked into that. Please let me know if you isolate these
>>>> patches.
>>>>
>>>> In any case it seems difficult to escape a kernel recompile, due to
>>>> this
>>>> small, entirely legitimate, yet remarkable decision by the driver
>>>> maintainers.
>>>
>>> This is a regression due to 2dc016599cfa ("ath: add support for special
>>> 0x0 regulatory domain") that seems to affect quite a few users, but
>>> afaics was never properly addressed. I fully understand that this might
>>> be a special case where Linus' "no regressions" rule can't be simply
>>> applied.
>>
>> Yes, this is a tricky problem and I am taking a second look at this.
>> Regulatory rules are complicated and we do not want to break them in any
>> circumstance.
>>
>> I see two ways to workaround this:
>>
>> 1) calibrate your board with a correct country code (which is impossible
>>   for an average user)
>>
>> 2) use 2.4 GHz band
>>
>>> But isn't there some way to provide users with a solution that doesn't
>>> force users to compile a module or a kernel? Like a module-parameter
>>> that only works if the the regulatory domain code in the EEPROM is empty
>>> (as apparently used by OpenWRT?). Yes, module parameters are normally a
>>> bad idea, but this case it might be a situation where it's the best
>>> solution.
>>
>> I don't think setting the country code via a module parameter would be
>> acceptable for the authorities, more info here:
>>
>> https://wireless.wiki.kernel.org/en/developers/regulatory
> 
> The issue involves finding a reasonable compromise between relative
> inconveniences, given the perspectives of both developers and users. As
> implemented currently, the restriction seems to affect both ath9k and
> ath10k (and probably ath11k -- I have not tried it, and frankly with the
> current status, I'm not eager to do it), but only when users try to run
> a 5 GHz AP. This is still reasonable (and legal) use, although not
> without many restrictions. Other drivers (e.g., iwlwifi) are much more
> restrictive relative to this, but at least they genuinely have made it
> completely clear from the beginning.
> 
> A common point of the previous messages was that, after these last
> changes, the boards with the 0x00 domain in the EEPROM were successively
> initialized with the 0x64 and later with UNITED_STATES domains by the
> driver. In practice this prevented their use as an AP when, later in
> userspace, the user tried to declare a 3rd local regdomain. My
> suggestion here would be to avoid this double interpretation of what
> default initialization would be appropriate. Either keep the old
> behavior (UNITED_STATES) which limited but did not originally prevented
> the AP usage, or replace it completely with the updated interpretation
> of what's applicable to this case (0x64); but please don't do both by
> default, or we will be in the current situation. Other users have asked
> for this before, and this sort of clarification seems to be the minimum
> to consider at this point, if anything is to be considered.
> 
> If this limiting double initialization is already achievable entirely
> through user configuration of default distribution kernels, please
> excuse my lack of knowledge. In this case, just documenting this better
> could also help other users.
> 
> Besides this consistent "safe" initialization, for users with special
> cases there's always the options of either providing alternative CRDAs
> or patching and recompiling the driver. This is a matter of relative
> inconveniences; as long as they remain feasible, it's always a weighting
> issue.
> 
> Thanks for your good work. Regards,
> 
> Nuno.
> 
> 

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Compex WLE200NX: regdomain sanitized regression

[Kalle Valo]

Thorsten Leemhuis <regressions@leemhuis.info> writes:

> Hi, this is your Linux kernel regression tracker speaking. Top-posting
> for once, to make this easy accessible to everyone.
>
> Kalle, thx for looking into this, I'm well aware this is kinda tricky.
> This is a gently reminder about the issue to ensure it doesn't fall
> through the cracks. At the same time I know that it's not urgent, that
> why I'm not putting it on backburner in regzbot now:
>
> #regzbot backburner: tricky situation and around for a while, hence not
> that urgent
> #regzbot poke
>
> I'll likely sent another gentle reminder after the next merge-window.

I now queued the revert to my pending branch:

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=dfc438d224e4ad756b276d79e5771c45b523156d

Thorsten, can you please check that the Link tag is correct so that
regzbot can automatically detect the fix?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: Compex WLE200NX: regdomain sanitized regression

[Kalle Valo]

Thorsten Leemhuis <regressions@leemhuis.info> writes:

> Hi, this is your Linux kernel regression tracker speaking. Top-posting
> for once, to make this easy accessible to everyone.
>
> Kalle, thx for looking into this, I'm well aware this is kinda tricky.
> This is a gently reminder about the issue to ensure it doesn't fall
> through the cracks. At the same time I know that it's not urgent, that
> why I'm not putting it on backburner in regzbot now:
>
> #regzbot backburner: tricky situation and around for a while, hence not
> that urgent
> #regzbot poke
>
> I'll likely sent another gentle reminder after the next merge-window.

I now queued the revert to my pending branch:

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=dfc438d224e4ad756b276d79e5771c45b523156d

Thorsten, can you please check that the Link tag is correct so that
regzbot can automatically detect the fix?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Compex WLE200NX: regdomain sanitized regression

[Thorsten Leemhuis]

On 24.02.22 17:22, Kalle Valo wrote:
> Thorsten Leemhuis <regressions@leemhuis.info> writes:
> 
>> Hi, this is your Linux kernel regression tracker speaking. Top-posting
>> for once, to make this easy accessible to everyone.
>>
>> Kalle, thx for looking into this, I'm well aware this is kinda tricky.
>> This is a gently reminder about the issue to ensure it doesn't fall
>> through the cracks. At the same time I know that it's not urgent, that
>> why I'm not putting it on backburner in regzbot now:
>>
>> #regzbot backburner: tricky situation and around for a while, hence not
>> that urgent
>> #regzbot poke
>>
>> I'll likely sent another gentle reminder after the next merge-window.
> 
> I now queued the revert to my pending branch:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=dfc438d224e4ad756b276d79e5771c45b523156d

Ohh, great, many thx!

> Thorsten, can you please check that the Link tag is correct so that
> regzbot can automatically detect the fix?

Yeah, it will, thx to the "Link:
https://lore.kernel.org/all/1c160dfb-6ccc-b4d6-76f6-4364e0adb6dd@reox.at/".

The kernel's docs say the redirector should be used in such cases (so
"/r/" instead of "/all/"), but regzbot doesn't care about it -- and I
wonder if that detail is actually important anyway now that we have
lore.kernel.org/all/.

Ciao, Thorsten

Re: Compex WLE200NX: regdomain sanitized regression

[Thorsten Leemhuis]

On 24.02.22 17:22, Kalle Valo wrote:
> Thorsten Leemhuis <regressions@leemhuis.info> writes:
> 
>> Hi, this is your Linux kernel regression tracker speaking. Top-posting
>> for once, to make this easy accessible to everyone.
>>
>> Kalle, thx for looking into this, I'm well aware this is kinda tricky.
>> This is a gently reminder about the issue to ensure it doesn't fall
>> through the cracks. At the same time I know that it's not urgent, that
>> why I'm not putting it on backburner in regzbot now:
>>
>> #regzbot backburner: tricky situation and around for a while, hence not
>> that urgent
>> #regzbot poke
>>
>> I'll likely sent another gentle reminder after the next merge-window.
> 
> I now queued the revert to my pending branch:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=dfc438d224e4ad756b276d79e5771c45b523156d

Ohh, great, many thx!

> Thorsten, can you please check that the Link tag is correct so that
> regzbot can automatically detect the fix?

Yeah, it will, thx to the "Link:
https://lore.kernel.org/all/1c160dfb-6ccc-b4d6-76f6-4364e0adb6dd@reox.at/".

The kernel's docs say the redirector should be used in such cases (so
"/r/" instead of "/all/"), but regzbot doesn't care about it -- and I
wonder if that detail is actually important anyway now that we have
lore.kernel.org/all/.

Ciao, Thorsten

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Compex WLE200NX: regdomain sanitized regression

[Kalle Valo]

Thorsten Leemhuis <regressions@leemhuis.info> writes:

> On 24.02.22 17:22, Kalle Valo wrote:
>> Thorsten Leemhuis <regressions@leemhuis.info> writes:
>> 
>>> Hi, this is your Linux kernel regression tracker speaking. Top-posting
>>> for once, to make this easy accessible to everyone.
>>>
>>> Kalle, thx for looking into this, I'm well aware this is kinda tricky.
>>> This is a gently reminder about the issue to ensure it doesn't fall
>>> through the cracks. At the same time I know that it's not urgent, that
>>> why I'm not putting it on backburner in regzbot now:
>>>
>>> #regzbot backburner: tricky situation and around for a while, hence not
>>> that urgent
>>> #regzbot poke
>>>
>>> I'll likely sent another gentle reminder after the next merge-window.
>> 
>> I now queued the revert to my pending branch:
>> 
>> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=dfc438d224e4ad756b276d79e5771c45b523156d
>
> Ohh, great, many thx!
>
>> Thorsten, can you please check that the Link tag is correct so that
>> regzbot can automatically detect the fix?
>
> Yeah, it will, thx to the "Link:
> https://lore.kernel.org/all/1c160dfb-6ccc-b4d6-76f6-4364e0adb6dd@reox.at/".

Great, thanks for checking.

> The kernel's docs say the redirector should be used in such cases (so
> "/r/" instead of "/all/"), but regzbot doesn't care about it -- and I
> wonder if that detail is actually important anyway now that we have
> lore.kernel.org/all/.

Funny that you ask, I was just few minutes ago updating my emacs
function which creates the lore link and was wondering the same. It
looks like '/r/' redirects to '/all/', so I guess we should use the
latter now:

$ curl --head https://lore.kernel.org/r/1c160dfb-6ccc-b4d6-76f6-4364e0adb6dd@reox.at/
HTTP/1.1 302 Found
Server: nginx
Date: Thu, 24 Feb 2022 16:43:32 GMT
Content-Type: text/plain
Connection: keep-alive
Location: https://lore.kernel.org/all/1c160dfb-6ccc-b4d6-76f6-4364e0adb6dd@reox.at/

But yeah, it shouldn't matter as hopefully all sane tools can handle
both.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: Compex WLE200NX: regdomain sanitized regression

[Kalle Valo]

Thorsten Leemhuis <regressions@leemhuis.info> writes:

> On 24.02.22 17:22, Kalle Valo wrote:
>> Thorsten Leemhuis <regressions@leemhuis.info> writes:
>> 
>>> Hi, this is your Linux kernel regression tracker speaking. Top-posting
>>> for once, to make this easy accessible to everyone.
>>>
>>> Kalle, thx for looking into this, I'm well aware this is kinda tricky.
>>> This is a gently reminder about the issue to ensure it doesn't fall
>>> through the cracks. At the same time I know that it's not urgent, that
>>> why I'm not putting it on backburner in regzbot now:
>>>
>>> #regzbot backburner: tricky situation and around for a while, hence not
>>> that urgent
>>> #regzbot poke
>>>
>>> I'll likely sent another gentle reminder after the next merge-window.
>> 
>> I now queued the revert to my pending branch:
>> 
>> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=dfc438d224e4ad756b276d79e5771c45b523156d
>
> Ohh, great, many thx!
>
>> Thorsten, can you please check that the Link tag is correct so that
>> regzbot can automatically detect the fix?
>
> Yeah, it will, thx to the "Link:
> https://lore.kernel.org/all/1c160dfb-6ccc-b4d6-76f6-4364e0adb6dd@reox.at/".

Great, thanks for checking.

> The kernel's docs say the redirector should be used in such cases (so
> "/r/" instead of "/all/"), but regzbot doesn't care about it -- and I
> wonder if that detail is actually important anyway now that we have
> lore.kernel.org/all/.

Funny that you ask, I was just few minutes ago updating my emacs
function which creates the lore link and was wondering the same. It
looks like '/r/' redirects to '/all/', so I guess we should use the
latter now:

$ curl --head https://lore.kernel.org/r/1c160dfb-6ccc-b4d6-76f6-4364e0adb6dd@reox.at/
HTTP/1.1 302 Found
Server: nginx
Date: Thu, 24 Feb 2022 16:43:32 GMT
Content-Type: text/plain
Connection: keep-alive
Location: https://lore.kernel.org/all/1c160dfb-6ccc-b4d6-76f6-4364e0adb6dd@reox.at/

But yeah, it shouldn't matter as hopefully all sane tools can handle
both.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Compex WLE200NX: regdomain sanitized regression

[Bryce Allen]

I have this issue on my two pcengines APs, one ALIX and one APU2. I 
created some dkms modules for patched ath9k/10k, setting the regdomain 
to CTRY_DEFAULT rather than 0x64. For me this results in US region, not 
sure if it will do the right thing in other regions or not. But you 
could use this as a starting point, and way better than rebuilding 
kernel from scratch each time:

https://github.com/bd4/athregd-dkms

I created trees for 5.10 from Debian Bullseye and for Ubuntu HWE 5.11 
kernel. This is based on tips and DKMS config from sparks71. At one 
point I tried a patch that added a region module parameter, but I got 
kernel faults and never got it to work - the CTRY_DEFAULT fix was 
simpler for me. You can see the patch here:

https://github.com/bd4/athregd-dkms/blob/main/patch-ath-sanitize-default.diff

-Bryce

On 11/27/21 03:17, Sebastian Bachmann wrote:
> Hello,
>
> I recently upgraded my Debian based AP from buster to bullseye, just 
> to find out that hostapd does not work any more, because all 5GHz 
> channels are marked as No-IR. This regression was already discussed on 
> this ML here: 
> https://www.mail-archive.com/ath10k@lists.infradead.org/msg12018.html
> and there is also an entry in Debian's bug tracker for the same issue: 
> https://bugs.debian.org/959821
>
> I have a slightly different card (branded Compex WLE200NX):
> 04:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network 
> Adapter (PCI-Express) (rev 01)
>         Subsystem: Qualcomm Atheros AR928X Wireless Network Adapter 
> (PCI-Express)
>         Kernel driver in use: ath9k
>         Kernel modules: ath9k
>
> But as you can see, also the EEPROM gets sanitized:
> [   15.461755] ath9k 0000:04:00.0: enabling device (0000 -> 0002)
> [   15.911600] ath: EEPROM regdomain sanitized
> [   15.911612] ath: EEPROM regdomain: 0x64
> [   15.911615] ath: EEPROM indicates we should expect a direct regpair 
> map
> [   15.911625] ath: Country alpha2 being used: 00
> [   15.911628] ath: Regpair used: 0x64
>
> I read in the other thread, that this is a regression, but the actual 
> commit causing it was never reverted.
> I tried to search for newer messages explaining the issue, however as 
> far as I can tell, the thread ends in June 2020 with no solution 
> available.
>
> Therefore, I kindly want to ask if there is any workaround available 
> to re-enable 5GHz channels in AP mode for my card? (expect sticking to 
> a pre-5.6 kernel or manually patching and recompiling ath)
>
> Best,
> Sebastian
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k