(I was on vacation and inbox exploded again) Brian Norris <briannorris@xxxxxxxxxxxx> writes: > On Thu, Jun 22, 2017 at 03:02:34PM +0200, Johannes Berg wrote: >> On Wed, 2017-06-21 at 11:27 -0700, Brian Norris wrote: > >> > > Without checking the code now, it seems entirely plausible that >> > > this is >> > > holding some lock that would lock out the control path entirely, >> > > for >> > > the duration until the wiphy is actually unregistered? >> > > >> > > Actually, you can't unregister with the relevant locks held >> > > (without >> > > causing deadlocks), so perhaps it's marking the wiphy as >> > > unavailable so >> > > that all operations fail? >> > >> > One of the above two sounds along the right line. But it's something >> > I couldn't really figure out how to do quite right. >> > >> > Dumb question: how would I mark the wiphy as unavailable? Is there >> > something I can do at the cfg80211 level? Or would I really have to >> > guard all the cfg80211 entry points into mwifiex with a flag or lock? >> >> There isn't really a good way to do this. You can, of course, call >> wiphy_unregister(), but if you could do that you'd already have the >> problem solved, I think? > > That's probably along the right track. There are still some things we'd > need to do properly before that though, and this is where all the > problems are so far. (Also, this is what Kalle was already objecting to; > he didn't think we should be unregistering/recreating the wiphy, but I > think he ended up softening on that a bit.) Just to clarify I was more like hoping there would be a better way to do it, not really objecting the current method, but I didn't realise that of course it's harder to do a transparent firmware restart with fullmac design. And certainly what are you doing now is much much better than doing nothing after a firmware crash. -- Kalle Valo
