Re: DT property keep-power-in-suspend and how WiFi drivers use it

On 2/4/25 4:26 PM, Ulf Hansson wrote:
> On Wed, 29 Jan 2025 at 12:05, Matthias Proske <[email protected]> wrote:
>>
>> Hello,
>>
>> I have a question regarding the usage of the Device Tree property
>> `keep-power-suspend`.
>>
>> In the Device Tree documentation it reads:
>> "SDIO only. Preserves card power during a suspend/resume cycle."
>>
>> Does that mean that the SDIO Host Controller will remain powered or
>> should this equally apply to anything that is connected to this SDIO
>> Host Controller?
> 
> Unfortunately the documentation isn't really clear.
> "keep-power-in-suspend" means that the platform is *capable* of
> keeping the SDIO card powered when the system is suspended.
> 
> Depending on what the SDIO func-driver (like the brcm_fmac driver)
> decides to do during system suspend/resume, the mmc core we may or may
> not keep the SDIO card powered.
> 
>>
>> To give a bit more background:
>>
>> I have an embedded board with a brcm_fmac WiFi module. It seems that due
>> to a hardware limitation we are not permitted to switch the module off.
>> It simply cannot be re-probed afterwards.
> 
> How did we manage to power it on and probe it in the first place?

Sorry if this was misleading. By "we" I meant whoever uses our hardware. 
I probably should have written "I" instead.

I have a hardware with the limitation that I can only power off WiFi 
whenever I power off the complete SoC.

Was it fixed it in newer HW designs? Yes.
Is there HW out there with the problem? Also yes.

How could I probe it in the first place?
The brcm_fmac module was responding because it was still in its initial 
phase after being booted.

> 
>>
>> The property `keep-power-in-suspend` was used and that used to work fine
>> until 92caded ("brcmfmac: Avoid keeping power to SDIO card
>> unless WOWL is used"), which made the wifi adapter by default turn off
>> on suspend to be re-probed on resume. Not working on our board...
> 
> Would you mind elaborating why it isn't working?

I can no longer probe the device after the resume.

[   61.390016] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[   61.390128] ieee80211 phy1: brcmf_bus_started: failed: -110
[   61.390294] ieee80211 phy1: brcmf_attach: dongle is not responding: 
err=-110
[   61.426594] brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach failed

I assume that I have this problem because I cannot power off the WiFi 
module using the two GPIOs, usually controlled by a mmc-pwrseq. In fact 
I don't see these errors with the newer HW revisions where I can toggle 
the GPIOs.


> 
>>
>>
>> I have also looked at other WiFi drivers with an SDIO interface and it
>> seems that none of them are really honoring the `keep-power-in-suspend`
>> flag. Is this flag for the SDIO Host Controller only?
> 
> See above.
> 
>>
>>
>> What would be proper way to implement it so that the brcm_fmac return to
>> its old behaviour if necessary?
>> Add a Device Tree property directly for the brcm_fmac driver..?
> 
> The corresponding SDIO func-driver may call
> sdio_set_host_pm_flags(func, MMC_PM_KEEP_POWER). In this way, the mmc
> core will leave the SDIO card powered-on during system suspend.
> Although, unless it's really necessary, it's ofcourse a bad idea as it
> would mean wasting energy when the system is suspended.

Just to get my understanding right: The brcm_fmac driver would be the 
SDIO func-driver in my case, right?

Thanks for the feedback

Matthias