On November 4, 2024 1:18:44 PM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
On Mon, 2024-11-04 at 12:59 +0100, Stefan Wahren wrote:
[ 384.292071] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have
nothing to do.
[ 384.292079] ieee80211 phy0: brcmf_cfg80211_get_tx_power: error (-5)
These errors are not new and I assume they have always been there. I'm
not an expert here, so I want to know is the problem here that the SDIO
interface is shutdown before brcmfmac is suspended or lies the issue
within brcmfmac suspend itself?
Upon suspend we execute the remove path and cleaning the interfaces.
We notify cfg80211 about the removal, which in turn will notify
userspace, but is tries to obtain the tx power from brcmfmac.
I guess "it tries to obtain" is some sort of event path that wants to
include the TX power in an event. That doesn't seem to make all that
much sense on removal events though, so perhaps we could remove the
get_channel and get_tx_power calls for NL80211_CMD_DEL_INTERFACE.
That's what I was considering.
However,
at this stage the communication with the dongle is already gone. These
messages are also seen in the module unload scenario. It seems a bit
redundant to query a device that is going to be removed. So it could
be fixed by chiming down those message or avoid it completely by
changing the behavior in cfg80211.
chiming down all the affected messages (i reported only one example
here) sounds strange to me. Maybe Johannes has also a opinion about this.
Dunno about the messages, I mean it's still possible to get those
messages when e.g. userspace manages to query just while it died, so
perhaps you wouldn't want to print it for all cases, but OTOH that's not
going to happen all the time.
But I don't have much opinion on driver messages :)
Sure. The two messages mentioned above are the ones I meant with coming
down. Not all driver messages. At least the message in brcmf_fil_cmd_data()
is not very useful. Could just be a debug print iso error print.
Regards,
Arend
