Ulf Hansson <ulf.hansson@xxxxxxxxxx> writes:
> + Yann, Christophe
>
> On Mon, 20 Mar 2023 at 13:22, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
>>
>> After commit 92cadedd9d5f ("brcmfmac: Avoid keeping power to SDIO card
>> unless WOWL is used"), the wifi adapter by default is turned off on suspend
>> and then re-probed on resume.
>>
>> In at least 2 model x86/acpi tablets with brcmfmac43430a1 wifi adapters,
>> the newly added re-probe on resume fails like this:
>>
>> brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
>> ieee80211 phy1: brcmf_bus_started: failed: -110
>> ieee80211 phy1: brcmf_attach: dongle is not responding: err=-110
>> brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach failed
>>
>> It seems this specific brcmfmac model does not like being reprobed without
>> it actually being turned off first.
>>
>> And the adapter is not being turned off during suspend because of
>> commit f0992ace680c ("brcmfmac: prohibit ACPI power management for brcmfmac
>> driver").
>>
>> Now that the driver is being reprobed on resume, the disabling of ACPI
>> pm is no longer necessary, except when WOWL is used (in which case there
>> is no-reprobe).
>>
>> Move the dis-/en-abling of ACPI pm to brcmf_sdio_wowl_config(), this fixes
>> the brcmfmac43430a1 suspend/resume regression and should help save some
>> power when suspended.
>>
>> This change means that the code now also may re-enable ACPI pm when WOWL
>> gets disabled. ACPI pm should only be re-enabled if it was enabled by
>> the ACPI core originally. Add a brcmf_sdiod_acpi_save_power_manageable()
>> to save the original state for this.
>>
>> This has been tested on the following devices:
>>
>> Asus T100TA brcmfmac43241b4-sdio
>> Acer Iconia One 7 B1-750 brcmfmac43340-sdio
>> Chuwi Hi8 brcmfmac43430a0-sdio
>> Chuwi Hi8 brcmfmac43430a1-sdio
>>
>> (the Asus T100TA is the device for which the prohibiting of ACPI pm
>> was originally added)
>>
>> Fixes: 92cadedd9d5f ("brcmfmac: Avoid keeping power to SDIO card unless WOWL is used")
>> Cc: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
>> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
>
> Seems reasonable to me, thanks for fixing this! Feel free to add:
>
> Reviewed-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
As this is an older regression from v5.19 should I take this to
wireless-next to get more testing time?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
