All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@kernel.org>
To: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: Nuno Oliveira <nuno@eq.uc.pt>,
	 Sebastian Bachmann <hello@reox.at>,
	 wgong@codeaurora.org,  ath10k@lists.infradead.org,
	 "regressions\@lists.linux.dev" <regressions@lists.linux.dev>
Subject: Re: Compex WLE200NX: regdomain sanitized regression
Date: Mon, 20 Dec 2021 12:37:53 +0200	[thread overview]
Message-ID: <87v8zja7em.fsf@codeaurora.org> (raw)
In-Reply-To: <96b3682d-71b3-ada0-6fc7-686e51609968@leemhuis.info> (Thorsten Leemhuis's message of "Wed, 1 Dec 2021 10:06:59 +0100")

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

WARNING: multiple messages have this Message-ID
From: Kalle Valo <kvalo@kernel.org>
To: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: Nuno Oliveira <nuno@eq.uc.pt>, Sebastian Bachmann <hello@reox.at>,
	wgong@codeaurora.org, ath10k@lists.infradead.org,
	"regressions\@lists.linux.dev" <regressions@lists.linux.dev>
Subject: Re: Compex WLE200NX: regdomain sanitized regression
Date: Mon, 20 Dec 2021 12:37:53 +0200	[thread overview]
Message-ID: <87v8zja7em.fsf@codeaurora.org> (raw)
In-Reply-To: <96b3682d-71b3-ada0-6fc7-686e51609968@leemhuis.info> (Thorsten Leemhuis's message of "Wed, 1 Dec 2021 10:06:59 +0100")

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

  parent reply	other threads:[~2021-12-20 10:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-27  8:17 Sebastian Bachmann
2021-11-27 11:28 ` Thorsten Leemhuis
2021-11-27 11:28   ` Thorsten Leemhuis
2021-11-27 12:21 ` Nuno Oliveira
2021-11-27 13:25   ` Sebastian Bachmann
2021-12-01  9:06   ` Thorsten Leemhuis
2021-12-01  9:06     ` Thorsten Leemhuis
2021-12-06  7:18     ` Sebastian Bachmann
2021-12-20 10:37     ` Kalle Valo [this message]
2021-12-20 10:37       ` Kalle Valo
2021-12-20 18:31       ` Nuno Oliveira
2021-12-20 18:31         ` Nuno Oliveira
2022-02-18 11:47         ` Thorsten Leemhuis
2022-02-18 11:47           ` Thorsten Leemhuis
2022-02-24 16:22           ` Kalle Valo
2022-02-24 16:22             ` Kalle Valo
2022-02-24 16:38             ` Thorsten Leemhuis
2022-02-24 16:38               ` Thorsten Leemhuis
2022-02-24 16:47               ` Kalle Valo
2022-02-24 16:47                 ` Kalle Valo
2021-11-27 16:35 ` Bryce Allen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v8zja7em.fsf@codeaurora.org \
    --to=kvalo@kernel.org \
    --cc=ath10k@lists.infradead.org \
    --cc=hello@reox.at \
    --cc=nuno@eq.uc.pt \
    --cc=regressions@leemhuis.info \
    --cc=regressions@lists.linux.dev \
    --cc=wgong@codeaurora.org \
    --subject='Re: Compex WLE200NX: regdomain sanitized regression' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.