Announcements
IMPORTANT: Cypress Developer Community is transitioning on October 20th. To learn more and be prepared for this change, check out our latest announcement.
cancel
Showing results for 
Search instead for 
Did you mean: 

Wi-Fi Bluetooth for Linux

ApNa_2097886
New Contributor II

Hi,

While doing suspend and resume with the battra release of fmac driver on IMX7 Platform Linux ver 4.9, I am seeing the following failure messages.

All iovar calls inside the brcmf_cfg80211_resume function are failing.

Has anyone else seen this issue? Is there a fix available from cypress for this?

I am calling suspend by "echo mem > /sys/power/state"

04/18/18 06:15:30.441045 kernel: PM: late suspend of devices complete after 1.061 msecs

04/18/18 06:15:30.441093 kernel: PM: noirq suspend of devices complete after 0.981 msecs

04/18/18 06:15:30.441216 kernel: Disabling non-boot CPUs ...

04/18/18 06:15:30.441945 kernel: CPU1: shutdown

04/18/18 06:15:30.441971 kernel: Turn off Mega/Fast mix in DSM

04/18/18 06:15:30.442128 kernel: Suspended for 5.546 seconds

04/18/18 06:15:30.442150 kernel: Enabling non-boot CPUs ...

04/18/18 06:15:30.442409 kernel: CPU1 is up

04/18/18 06:15:30.442433 kernel: PM: noirq resume of devices complete after 0.549 msecs

04/18/18 06:15:30.442482 kernel: imx-sdma 30bd0000.sdma: loaded firmware 4.2

04/18/18 06:15:30.442503 kernel: PM: early resume of devices complete after 1.224 msecs

04/18/18 06:15:30.442566 kernel: brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.

04/18/18 06:15:30.442586 kernel: brcmfmac: brcmf_report_wowl_wakeind: Get wowl_wakeind failed, err = -5

04/18/18 06:15:30.442604 kernel: brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.

04/18/18 06:15:30.442622 kernel: brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.

04/18/18 06:15:30.442641 kernel: brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.

04/18/18 06:15:30.442687 kernel: brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.

04/18/18 06:15:30.442707 kernel: brcmfmac: brcmf_pktfilter_enable: disable packet filter id(100) failed, ret=-5

04/18/18 06:15:30.442747 kernel: brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.

04/18/18 06:15:30.442864 kernel: sitronix_power_up

04/18/18 06:15:30.442884 kernel: PM: resume of devices complete after 32.789 msecs

04/18/18 06:15:30.442928 kernel: PM: resume devices took 0.030 seconds

04/18/18 06:15:30.442948 kernel: PM: Finishing wakeup.

Thanks and regards,

Aparna

0 Likes
1 Solution
VinayakS_26
Moderator
Moderator

Hi,

You suspicion is right. The reason this is happening is because, the host(PCIE/SDIO) driver hasn't  come out of suspend yet.  The brcmf_cfg80211_resume is just a check function in the driver, that evaluates whether the host's (PCIE/SDIO) bus up/down. But this shouldn't be an issue once the bus driver is up/loaded.

Regards,

Vinayak

View solution in original post

8 Replies
VinayakS_26
Moderator
Moderator

Hi,

Does the entire kernel crash or is it just the wifi driver that crashes after resume.

Could you provide the complete log(dmesg log) of this crash?

-Vinayak

ApNa_2097886
New Contributor II

Hi vnak

There is no crash happening, neither kernel nor driver crashes on resume. However any IOCtl calls within the brcmf_cfg80211_resume function fail with the posted errors. All these IOVAR calls are from the native brcmfmac driver code.

Also, even though these calls fail, the driver is functional and we are also able to ping it from the outside and further ioctls which are not from within the cfg80211_resume function are successful.

It almost looks like the firmware or driver is not in the right state when IOCtl calls are made from within the resume function.

thanks and regards,

Aparna

0 Likes
VinayakS_26
Moderator
Moderator

Hi,

Could you give the firmware version? How is the resume being done?

What does the output of the following wl command show:

wl wowl_status

wl wowl_wakeup_reason

-Vinayak

ApNa_2097886
New Contributor II

Hi Vinayak,


Thanks for your response. The firmware version we are using is 7.45.151 (Battra driver on IMX7SABRE)

1.8 RC0.0

wl0: Feb  7 2018 02:58:50 version 7.45.151 (r683645 CY) FWID 01-baba21a4

wl wowl_wakeup_reason returns unsupported but the rest of the commands seem to indicate the correct status. I also ran the "wl wowl_wakeind" command

I am using "echo standby > /sys/power/state" to put the device to suspend. I have also tried "echo mem > /sys/power/state" with same results.

I ping the device from outside to wake it up.

Below is the output of those commands:

# wl wowl_status

Status of last wakeup:

flags:0x41c

Wake-on-Loss-of-Beacons enabled

Wake-on-Deauth enabled

Retrograde TSF enabled

wl wowl_wakeup_reason

04/24/18 19:27:27.356012 kernel: brcmfmac: brcmf_sdio_dpc Dongle reports CHIPACTIVE

04/24/18 19:27:27.356102 kernel: brcmfmac: brcmf_cfg80211_vndr_cmds_dcmd_handler error(-23), return -EPERM

wl: error -23

# wl wowl_wakeup_reason

04/24/18 19:27:30.976028 kernel: brcmfmac: brcmf_sdio_dpc Dongle reports CHIPACTIVE

wl: error -23

04/24/18 19:27:30.976158 kernel: brcmfmac: brcmf_cfg80211_vndr_cmds_dcmd_handler error(-23), return -EPERM

# 04/24/18 19:27:32.006030 kernel: brcmfmac: brcmf_sdio_dpc Dongle reports CHIPACTIVE

# wl wowl_wakeind

PCI Indication set

MAC Indication set

        Packet received with Netpattern

                Unicast frame received

DETAILED LOG BELOW:

# echo standby > /sys/power/state

PM: Syncing filesystems ... done.

Freezing user space processes ... (elapsed 0.001 seconds) done.

Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.

Suspending console(s) (use no_console_suspend to debug)

PM: suspend of devices complete after 83.862 msecs

PM: suspend devices took 0.080 seconds

PM: late suspend of devices complete after 1.021 msecs

PM: noirq suspend of devices complete after 0.936 msecs

Disabling non-boot CPUs ...

CPU1: shutdown

Suspended for 2.937 seconds

Enabling non-boot CPUs ...

CPU1 is up

PM: noirq resume of devices complete after 0.534 msecs

PM: early resume of devices complete after 0.555 msecs

brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.

brcmfmac: brcmf_report_wowl_wakeind: Get wowl_wakeind failed, err = -5

brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.

brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.

brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.

brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.

brcmfmac: brcmf_pktfilter_enable: disable packet filter id(100) failed, ret=-5

brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.

brcmfmac: brcmf_pktfilter_enable: disable packet filter id(101) failed, ret=-5

brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.

brcmfmac: brcmf_pktfilter_enable: disable packet filter id(102) failed, ret=-5

PM: resume of devices complete after 25.790 msecs

PM: resume devices took 0.020 seconds

Restarting tasks ... done.

PM: Syncing filesystems ... done.

# wl wowl_status

Status of last wakeup:

flags:0x41c

Wake-on-Loss-of-Beacons enabled

Wake-on-Deauth enabled

Retrograde TSF enabled

wl wowl_wakeup_reason

04/24/18 19:27:27.356012 kernel: brcmfmac: brcmf_sdio_dpc Dongle reports CHIPACTIVE

04/24/18 19:27:27.356102 kernel: brcmfmac: brcmf_cfg80211_vndr_cmds_dcmd_handler error(-23), return -EPERM

wl: error -23

# wl wowl_wakeup_reason

04/24/18 19:27:30.976028 kernel: brcmfmac: brcmf_sdio_dpc Dongle reports CHIPACTIVE

wl: error -23

04/24/18 19:27:30.976158 kernel: brcmfmac: brcmf_cfg80211_vndr_cmds_dcmd_handler error(-23), return -EPERM

# 04/24/18 19:27:32.006030 kernel: brcmfmac: brcmf_sdio_dpc Dongle reports CHIPACTIVE

# wl wowl_wakeind

PCI Indication set

MAC Indication set

        Packet received with Netpattern

                Unicast frame received

0 Likes
ApNa_2097886
New Contributor II

vnak

My suspicion is that the "drvr->bus_if->state" is not being updated or it is being updated a little after the brcmf_cfg80211_resume call is made as a result the iovar commands all return "bus is down error"

brcmf_fil_cmd_data(struct brcmf_if *ifp, u32 cmd, void *data, u32 len, bool set)

{

struct brcmf_pub *drvr = ifp->drvr;

s32 err;

if (drvr->bus_if->state != BRCMF_BUS_UP) {

brcmf_err("bus is down. we have nothing to do.\n");

return -EIO;

}

0 Likes
ApNa_2097886
New Contributor II

We are using the 1HK_43455 module

0 Likes
VinayakS_26
Moderator
Moderator

Hi,

You suspicion is right. The reason this is happening is because, the host(PCIE/SDIO) driver hasn't  come out of suspend yet.  The brcmf_cfg80211_resume is just a check function in the driver, that evaluates whether the host's (PCIE/SDIO) bus up/down. But this shouldn't be an issue once the bus driver is up/loaded.

Regards,

Vinayak

View solution in original post

ApNa_2097886
New Contributor II

Currently we are getting around this issue by implementing register_pm_notifiers and handling all the resume iovar calls under PM_POST_SUSPEND