Re: Compex WLE200NX: regdomain sanitized regression

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.

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

[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

[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

[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

[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

[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