On 2/5/25 1:49 PM, Ulf Hansson wrote:
On Tue, 4 Feb 2025 at 17:25, Matthias Proske <email@xxxxxxxxxxxxxxxxxx> wrote:
On 2/4/25 4:26 PM, Ulf Hansson wrote:
On Wed, 29 Jan 2025 at 12:05, Matthias Proske <email@xxxxxxxxxxxxxxxxxx> 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 had a look at the corresponding code in
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c. Yes, it
seems there is a complete cleanup and re-probe being done during
system suspend/resume (it looks heavy and prone to errors, but that's
a different story).
Anyway, it would also be interesting to know if the SDIO
card/interface is failing to be re-initialized correctly by the mmc
core during system resume. Typically, mmc_sdio_resume() in
drivers/mmc/core/sdio.c should not return an error code, but it sounds
like that is the case too, right?
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.
With HW revisions, are you referring to different platform revisions
or revisions of the WiFi module? Or both?
Anyway, in the past we have seen many issues with incorrect HW
descriptions in DT in regards to the mmc-pwrseq. The mmc-pwrseq may be
different both from the platform point of view and from the WiFi
module point of view.
For example, maybe those GPIOs were routed differently on some
platforms, but not correctly described in DT? Or perhaps different
variants of the WiFi module need different power-sequences?
Just wanted to be sure that we really have a broken HW and not just
the description of it. :-)
With HW revisions I'm talking about our own PCB. WiFi module remains
unchanged.
And the GPIO handling works with our different HW revision. Also
modifying the GPIOs to some different timing did not change anything. I
just need to keep the GPIOs "on".
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?
Correct. The one that is registered with sdio_register_driver().
I guess I would just write a patch for the corresponding SDIO
func-driver, adding a DeviceTree property directly in that SDIO
func-driver (not the mmc host driver) so this can be enabled just for
these specific boards, or would you suggest a different solution?
Matthias
