Right. netplan apply deletes the brcmfmac virtual interface
(brcmf_cfg80211_del_iface), disconnects form the network
(brcmf_cfg80211_disconnect) and then adds a new one
(brcmf_cfg80211_add_iface), before connecting to the network
(brcmf_cfg80211_connect).
I propose 2 possible fixes:
- We change the definitions of brcmf_setup_wiphybands and
brcmf_construct_chaninfo to have an arg which tells if it’s being called
during boot (inside brcmf_80211_attach) or not (an arg which defaults to
false unless it is in brcmf_80211_attach, where we set it to
true). If it is true, we do chan->orig_flags = chan->flags at the end of
brcmf_construct_chaninfo. Since the rest of the driver code
largely does not edit orig_flags, this should be fine. The flags can be
changed, so we are not losing any info here
- We do the
brcmf_setup_wiphy->wiphy_apply_custom_regulatory->wiphy_register->brcmf_setup_wiphybands
in
brcmf_cfg80211_add_iface instead of brcmf_80211_attach.
I am not sure what problems we might have with this approach, but this
completely avoids editing the orig_flags. I am unsure about
the wiphy_registration
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063365
Title:
brcmfmac: brcmf_set_channel: set chanspec 0x100c fail, reason -52
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2063365/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
