On 2/13/2024 11:15 AM, Johannes Berg wrote:
On Tue, 2024-01-16 at 19:29 +0100, Arend Van Spriel wrote:I modified brcmf_construct_chaninfo() to store the IEEE80211_CHAN_DISABLED flag within orig_flags in case the flags had it. This avoid the issue. Not sure this is the proper solution.orig_flags are from when the wiphy is registered - does the driver only set up proper flags after that?Long time ago we discussed about this. So brcmfmac provides a superset of channels during wiphy_register() and none of them are disabled as they could never be enabled. After that the driver may disable a subset as it syncs with the device. I think we used strict custom reg flag, but that seems to have gone. Could that have the result Stefan is observing?All this confuses me way more than it should, I guess. We do still have REGULATORY_STRICT_REG, no? And that sets even orig_flags: if (lr->initiator == NL80211_REGDOM_SET_BY_DRIVER && request_wiphy && request_wiphy == wiphy && request_wiphy->regulatory_flags & REGULATORY_STRICT_REG) { /* * This guarantees the driver's requested regulatory domain * will always be used as a base for further regulatory * settings */ chan->flags = chan->orig_flags = map_regdom_flags(reg_rule->flags) | bw_flags; But brcmf_construct_chaninfo() looks a bit more like it really should be setting a custom regulatory with all the channels listed, a bit like what iwlwifi/mvm does, with REGULATORY_WIPHY_SELF_MANAGED? Maybe we should start from the beginning: what does this actually _want_?
Picking up this trail [1] after a long time (sorry). So the firmware has its own regulatory database. So upon connecting to an AP the firmware can change its country setting based on the country element the AP uses. In the driver we want to update the set of enabled channels. Maybe this is more or less what iwlwifi does?
Regards, Arend[1] https://lore.kernel.org/all/d9c9336a-6314-4de9-aead-8b865bb30f05@xxxxxxx/
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
