Sometimes, the WiFi adapter/interface of the SoM doesn’t appear after resuming from suspension. This doesn’t happen every time. The only way to get the WiFi working again is to power off or restart.
Here’s the sequence of actions I’ve taken to address this issue:
At system startup, I execute the following command to bring down the eth0 interface:
ip link set dev eth0 down
Before entering suspension, I remove the WiFi driver using the command:
modprobe -r mwifiex_sdio
echo deep > /sys/power/mem_sleep; echo mem > /sys/power/state
Upon resuming from suspension, I reload the WiFi driver with the command:
modprobe mwifiex_sdio
Despite these steps, the issue persists.
When the WiFi interface (mlan0) disappears, I’ve tried removing the driver and reloading it using the following commands:
modprobe -r mwifiex_sdio
modprobe mwifiex_sdio
However, even with this step, the issue persists.
I have a Dahlia v1.1B board with the Verdin iMX8M Mini Quad 2GB WB IT V1.1B based. The image used is your Linux Multimedia Reference 6.3.0+build.7.
Thank you for your response and the provided information. However, I wanted to point out that the “Linux Multimedia Reference 6.3.0+build.7” image we are using doesn’t seem to have these commands available.
The issue with the WiFi adapter/interface not appearing after resuming from suspension occurs intermittently. It doesn’t happen every time, but it occurs frequently enough to be noticeable. For example, sometimes I put the system into suspension and after 30 minutes, when I resume it, the WiFi fails to work. As for the frequency of the suspend-resume cycle, it varies depending on the usage scenario, but I estimate it to be several times a day.
Hello @ferranmc,
Does dmesg after the resume report any error related to the wifi driver / interface?
It could be that the firmware is freezing sometimes, and that would probably be reported by the driver as timeout errors after some commands were sent.
Hello @ferranmc,
it looks like the firmware stopped responding. I’ll have to report this to NXP and check if they can provide a solution for it.
In the meantime, we should start thinking about a workaround. Do you think you can detect this condition programmatically? If yes, we could try forcing a firmware reload when it happens, that could bring the interface back without a system reboot.
Yes, we are able to detect when this condition occurs. We’ve attempted to fix it by reloading the WiFi driver, but we haven’t been successful in resolving the issue. Could you please advise us on how to force a firmware reload?
