lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bfe4ee3e-a136-a7ed-5fcd-0377c9f35726@broadcom.com>
Date:   Mon, 23 Oct 2023 10:37:57 +0200
From:   Arend van Spriel <arend.vanspriel@...adcom.com>
To:     Daniel Berlin <dberlin@...rlin.org>,
        Arend van Spriel <aspriel@...il.com>,
        Franky Lin <franky.lin@...adcom.com>,
        Hante Meuleman <hante.meuleman@...adcom.com>
Cc:     linux-wireless@...r.kernel.org,
        brcm80211-dev-list.pdl@...adcom.com,
        SHA-cyfmac-dev-list@...ineon.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] [brcmfmac] Fix regulatory domain handling to reset
 bands properly

On 10/21/2023 4:40 PM, Daniel Berlin wrote:
> As an aside, the alternative would be to simply not ignore any
> attempts to set the regulatory domain, regardless of whether it's 00
> or the chip is already set to that country.
> It doesn't happen that often, so it's not clear it's worth avoiding it at all.
> There are some things i'd have to fix to make it work resiliently well
> (for example, i know we set the 2g bw cap where we do because it has
> to be done with the interface down), but i can fix those if needed.

Please do not top post.

The firmware has its own regulatory information (actually the CLM blob 
holds that information) which is independent of the wireless regulatory 
database in the kernel. As such trying to configure country '00' will 
simply fail as it is not known inside CLM blob. The firmware needs a 
country abbreviation *and* a revision. Hence we require a mapping of 
country code to <abbrev,rev> tuple. If that mapping is not in place we 
bail out setting the country in the regulatory notifier.

 From the description below it is not clear what problem is fixed here 
in terms of user experience.

Regards,
Arend

> On Thu, Oct 19, 2023 at 10:18 AM Daniel Berlin <dberlin@...rlin.org> wrote:
>>
>> Currently, we ignore the default country in the reg notifier.
>> We also register a custom regulatory domain, which is set
>> as the default.
>> As a result, the chip is likely to be set to the correct country,
>> but the regulatory domain will not match it.
>>
>> When the regulatory notifier is then called, we see the countries
>> are the same and do not change anything, even though the domain
>> is wrong.
>>
>> This patch forces us to reset the bands on the first country change
>> even if the chip is already set to that country.
>>
>> We also restore the original band info before reconstructing channel
>> info, as the new regdom power limits may be higher than what is
>> currently set.
>>
>> Signed-off-by: Daniel Berlin <dberlin@...rlin.org>
>> ---
>>   .../broadcom/brcm80211/brcmfmac/cfg80211.c    | 38 +++++++++++++++----
>>   .../broadcom/brcm80211/brcmfmac/cfg80211.h    |  2 +
>>   2 files changed, 33 insertions(+), 7 deletions(-)

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4219 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ