Thread (1 message) 1 message, 1 author, 2019-09-26

Re: [PATCH RFC] cfg80211: add new command for reporting wiphy crashes

From: Johannes Berg <johannes@sipsolutions.net>
Date: 2019-09-26 12:05:00
Also in: lkml, netdev

Possibly related (same subject, not in this thread)

On Thu, 2019-09-26 at 14:00 +0200, Rafał Miłecki wrote:
quoted
You can't seriously be suggesting that the driver doesn't *have* enough
information - everything passed through it :)
Precisely: it doesn't store (cache) enough info.
But nothing stops it (the driver) from doing so!
In brcmfmac on .add_virtual_intf() we:
1) Send request to the FullMAC firmware
2) Wait for a reply
3) On success we create interface
4) We wake up .add_virtual_intf() handler

I'll need to find a way to skip step 3 in recovery path since interface
on host side already exists.
Sure, we skip lots of things in all drivers, look at iwlwifi for example
with IWL_MVM_STATUS_IN_HW_RESTART.
OK, so basically I need to work on caching setup data. Should I try
doing that at my selected driver level (brcmfmac)? Or should I focus on
generic solution (cfg80211) and consider offloading mac80211 if
possible?
I think doing it generically will not work well, you have different code
paths and different formats, different data that you need etc.

Sometimes there's information cfg80211 doesn't even *have*, because the
driver is responsible for things (e.g. elements). I guess you can try,
but my gut feeling is that it'd simpler in the driver.

Now you can argue that everything passes through cfg80211 so it must
have enough data too (just like I'm arguing the driver certainly has
enough data), but ... it seems to me the cfg80211 is usually more
action-based, where the restore flow needs to keep the *state*, not
replay the series of actions that happened.

johannes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help