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. > > 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 :) johannes
