On Fri, 2016-09-16 at 11:58 +0200, Arend Van Spriel wrote:
> On 15-9-2016 16:42, Dan Williams wrote:
> >
> > Hi,
> >
> > While refining NetworkManager's MAC address randomization behavior
> > we
> > came across two issues with brcmfmac:
> >
> > 1) when changing the MAC address, the driver schedules work for the
> > new
> > change and returns success, but doesn't actually change the MAC
> > until
> > the work is scheduled. Because it returns 0 from the
> > ndo_set_mac_address hook the net core will generate a
> > NETDEV_CHANGEADDR
> > event and rtnetlink will send out an RTM_NEWLINK with the old MAC
> > address. No event for the new address will be sent. So it's
> > pretty
> > hard to figure out when the address actually changed, and when its
> > safe
> > to associate, without polling the device's MAC address. Ugly.
> And apparently unnecessary. I recalled we had this as the
> ndo_set_mac_address callback could be called in atomic context. So we
> are using a worker because we are grabbing a mutex upon sending the
> control info to the device. Looking into the core network code it
> seems
> the callback is not called in atomic context so it seems we can get
> rid
> of the worker here. I made a patch
>
> >
> > 2) when closing the device (eg, set !IFF_UP) the driver
> > unconditionally
> > blocks for 500ms in __brcmf_cfg80211_down():
> >
> > if (check_vif_up(ifp->vif)) {
> > brcmf_link_down(ifp->vif, WLAN_REASON_UNSPECIFIED);
> >
> > /* Make sure WPA_Supplicant receives all the event
> > generated due to DISASSOC call to the fw to keep
> > the state fw and WPA_Supplicant state consistent
> > */
> > brcmf_delay(500);
> > }
> This is actually a bogus delay as we are under an RTNL lock here so I
> think the events will not go out until after the delay has finished.
> I
> did submit a patch long ago removing this delay, but the change was
> not
> accepted. Let me revisit that.
>
> >
> > Should I dump these into kernel bugzilla, or is there some internal
> > bug
> > tracker they could get stuffed into?
> Kernel bugzilla is fine although I check it rather infrequently.
Thanks for taking another look at these. Should I still file in
bugzilla, or are the patches going through the process already?
Dan