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. :-)
>
>
> >
> >>
> >>
> >> 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().
>
> Thanks for the feedback
Np, I am happy to help!
>
> Matthias
>
Kind regards
Uffe
