From: "email@example.com" <firstname.lastname@example.org> To: Alvin Sipraga <ALSI@bang-olufsen.dk>, Jouni Malinen <email@example.com> Cc: "Félix Sipma" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org> Subject: Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain" Date: Mon, 21 Dec 2020 14:43:05 +0100 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Am 30.10.20 um 14:23 schrieb Alvin Sipraga: > Hi, > > On 10/30/20 8:20 AM, Jouni Malinen wrote: >> So the issue is in not being able to operate an AP on the 5 GHz band? >> That sounds like the expected behavior for any device that has not >> been calibrated and provisioned for a specific country where >> regulatory rules allow operation on the 5 GHz band. I understand that >> this may look like a regression since the commit removed >> functionality, but it feels like a bug fix to me since that >> functionality should not have been enabled by default in the first >> place. The goal here is to avoid inappropriate operation on the band >> without explicit configuration to enable such operation. In AP >> devices, the device should have been provisioned for a specific >> country to be able to enforce the correct frequency range >> restrictions. The safe default for a device that does not have such >> explicit configuration within the WLAN component itself is to use the >> world roaming mode which prevents initialization of radiation (i.e., >> does not allow AP mode to be started but allows station mode operation >> to connect to an already started AP) on the 5 GHz band. > This explanation makes perfect sense, but are you sure that that is what > the 0x0 regulatory domain means? For example the pages  state > unequivocally that 0x0 means US. > > If we assume 0x0 = US, do you agree that an EEPROM programmed with 0x0 > should imply that the device is suitably calibrated for operation in the > United States, and as such should permit initiating radiation on the 5 > GHz band (etc.)? Or have I missed something? > > I also tried to get the patch in question reverted based on this > rationale, see  for more info. I hope somebody can help clear up this > misunderstanding, since it seems to me that the main issue is: what is > the true meaning of 0x0? > > Btw, the hardware that Félix is referring to does have an FCC ID and > seems to be suitably certified for the US. > > Kind regards, > Alvin > >  > https://wireless.wiki.kernel.org/en/users/drivers/ath#the_0x0_regulatory_domain >  > https://web.archive.org/web/20150117040022/http://article.gmane.org/gmane.linux.kernel.wireless.general/38410 >  > https://email@example.com/ >  https://fccid.io/TK4WLE900VX > _______________________________________________ > ath10k mailing list > firstname.lastname@example.org > http://lists.infradead.org/mailman/listinfo/ath10k Hello, this is not correct... I have such a card with 0x0 in the eeprom due to the patch the complete midband in station mode is missing So the card can't see AP's in midband or connect to AP's either.... why are the cards mapped to 0x64 and not 0x6c? https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1895333 https://email@example.com/msg13040.html the patch has made the card unusable for me and I had to deal extensively with the thematics ... and yes my card also has a FCC ID and it would be new to me that there is no midband in the USA... best regards (sorry for breaking the list) _______________________________________________ ath10k mailing list firstname.lastname@example.org http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2020-12-21 13:44 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-22 17:21 Félix Sipma [not found] ` <CANe27jKpYm29QOjYOZ_jwHiRxuWx66J+th8-zgbXK4geiCU0_Q@mail.gmail.com> 2020-10-29 14:06 ` Félix Sipma 2020-10-30 7:20 ` Jouni Malinen 2020-10-30 8:51 ` Félix Sipma 2020-12-20 1:32 ` Julian Phillips 2020-10-30 13:23 ` Alvin Sipraga 2020-12-21 13:43 ` sparks71 [this message] -- strict thread matches above, loose matches on Subject: below -- 2020-12-21 12:15 sparks71 2020-07-30 12:49 Alvin Šipraga 2020-08-27 7:59 ` Alvin Šipraga 2020-08-27 10:12 ` Kalle Valo 2020-08-27 10:25 ` Alvin Šipraga 2020-05-27 16:57 Brian Norris 2020-05-28 12:02 ` Julian Calaby [not found] ` <CAJ-Vmomx0UFEa1w2HsGMQsZb+K8hyK=Zz9cKSo7tHv5GiMc1yw@mail.gmail.com> 2020-06-02 18:35 ` Brian Norris 2022-03-07 17:45 ` Kalle Valo 2022-04-23 10:52 ` Patrick Steinhardt 2022-04-25 18:54 ` Brian Norris 2022-05-09 18:16 ` Cale Collins 2022-05-11 22:52 ` Cale Collins
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 \ --email@example.com \ --firstname.lastname@example.org \ --cc=ALSI@bang-olufsen.dk \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain"' \ /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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).