On 26.09.2019 13:55, Johannes Berg wrote:

On Thu, 2019-09-26 at 13:52 +0200, Rafał Miłecki wrote:

quoted

Indeed my main concert is AP mode. I'm afraid that cfg80211 doesn't
cache all settings, consider e.g. nl80211_start_ap(). It builds
struct cfg80211_ap_settings using info from nl80211 message and
passes it to the driver (rdev_start_ap()). Once it's done it
caches only a small subset of all setup data.

In other words driver doesn't have enough info to recover interfaces
setup.

So the driver can cache it, just like mac80211.

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.

quoted

I meant that hardware has been recovered & is operational again (driver
can talk to it). I expected user space to reconfigure all interfaces
using the same settings that were used on previous run.

If driver were able to recover interfaces setup on its own (with a help
of cfg80211) then user space wouldn't need to be involved.

The driver can do it, mac80211 does. It's just a matter of what the
driver will do or not.

quoted

First of all I was wondering how to handle interfaces creation. After a
firmware crash we have:
1) Interfaces created in Linux
2) No corresponsing interfaces in firmware

quoted

Syncing that (re-creating in-firmware firmwares) may be a bit tricky
depending on a driver and hardware.

We do that in mac80211, it works fine. Why would it be tricky?

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.

If something fails, I think we force that interface to go down.

quoted

For some cases it could be easier to
delete all interfaces and ask user space to setup wiphy (create required
interfaces) again. I'm not sure if that's acceptable though?

If we agree interfaces should stay and driver simply should configure
firmware properly, then we need all data as explained earlier. struct
cfg80211_ap_settings is not available during runtime. How should we
handle that problem?

You can cache it in the driver in whatever format makes sense.

quoted

I was aiming for a brutal force solution: just make user space
interfaces need a full setup just at they were just created.

You can still do that btw, just unregister and re-register the wiphy.

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?