[PATCH v2] wifi: wilc1000: Keep slot powered on during suspend/resume

[PATCH v2] wifi: wilc1000: Keep slot powered on during suspend/resume

[Marek Vasut]

The WILC3000 can suspend and enter low power state. According to local
measurements, the WILC3000 consumes the same amount of power if the slot
is powered up and WILC3000 is suspended, and if the WILC3000 is powered
off. Use the former option, keep the WILC3000 powered up as that allows
for things like WoWlan to work.

Note that this is tested on WILC3000 only, not on WILC1000 .

Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Ajay Singh <ajay.kathat@microchip.com>
Cc: Alexis Lothoré <alexis.lothore@bootlin.com>
Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Cc: Kalle Valo <kvalo@kernel.org>
Cc: Marek Vasut <marex@denx.de>
Cc: linux-wireless@vger.kernel.org
---
V2: Rebase on next-20240926
---
 drivers/net/wireless/microchip/wilc1000/sdio.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/net/wireless/microchip/wilc1000/sdio.c b/drivers/net/wireless/microchip/wilc1000/sdio.c
index b4da05d5a498a..d67662b6b2a1a 100644
--- a/drivers/net/wireless/microchip/wilc1000/sdio.c
+++ b/drivers/net/wireless/microchip/wilc1000/sdio.c
@@ -969,7 +969,6 @@ static int wilc_sdio_suspend(struct device *dev)
 {
 	struct sdio_func *func = dev_to_sdio_func(dev);
 	struct wilc *wilc = sdio_get_drvdata(func);
-	int ret;
 
 	dev_info(dev, "sdio suspend\n");
 
@@ -983,13 +982,7 @@ static int wilc_sdio_suspend(struct device *dev)
 
 	wilc_sdio_disable_interrupt(wilc);
 
-	ret = wilc_sdio_reset(wilc);
-	if (ret) {
-		dev_err(&func->dev, "Fail reset sdio\n");
-		return ret;
-	}
-
-	return 0;
+	return sdio_set_host_pm_flags(func, MMC_PM_KEEP_POWER);
 }
 
 static int wilc_sdio_resume(struct device *dev)
-- 
2.45.2

Re: [PATCH v2] wifi: wilc1000: Keep slot powered on during suspend/resume

[Kalle Valo]

Marek Vasut <marex@denx.de> writes:

> The WILC3000 can suspend and enter low power state. According to local
> measurements, the WILC3000 consumes the same amount of power if the slot
> is powered up and WILC3000 is suspended, and if the WILC3000 is powered
> off. Use the former option, keep the WILC3000 powered up as that allows
> for things like WoWlan to work.
>
> Note that this is tested on WILC3000 only, not on WILC1000 .
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> ---
> Cc: Ajay Singh <ajay.kathat@microchip.com>
> Cc: Alexis Lothoré <alexis.lothore@bootlin.com>
> Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev>
> Cc: Kalle Valo <kvalo@kernel.org>
> Cc: Marek Vasut <marex@denx.de>
> Cc: linux-wireless@vger.kernel.org
> ---
> V2: Rebase on next-20240926

BTW I recommend using wireless-next as the baseline for wireless
patches. For example, wireless-next is not pulled to linux-next during
merge windows or other patches in linux-next might create unnecessary
conflicts. Of course most of the cases using linux-next is fine.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v2] wifi: wilc1000: Keep slot powered on during suspend/resume

[Marek Vasut]

On 9/28/24 1:18 PM, Kalle Valo wrote:
> Marek Vasut <marex@denx.de> writes:
> 
>> The WILC3000 can suspend and enter low power state. According to local
>> measurements, the WILC3000 consumes the same amount of power if the slot
>> is powered up and WILC3000 is suspended, and if the WILC3000 is powered
>> off. Use the former option, keep the WILC3000 powered up as that allows
>> for things like WoWlan to work.
>>
>> Note that this is tested on WILC3000 only, not on WILC1000 .
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> ---
>> Cc: Ajay Singh <ajay.kathat@microchip.com>
>> Cc: Alexis Lothoré <alexis.lothore@bootlin.com>
>> Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev>
>> Cc: Kalle Valo <kvalo@kernel.org>
>> Cc: Marek Vasut <marex@denx.de>
>> Cc: linux-wireless@vger.kernel.org
>> ---
>> V2: Rebase on next-20240926
> 
> BTW I recommend using wireless-next as the baseline for wireless
> patches. For example, wireless-next is not pulled to linux-next during
> merge windows or other patches in linux-next might create unnecessary
> conflicts. Of course most of the cases using linux-next is fine.
I didn't know there was one such tree, added to remotes, thanks !

Re: [PATCH v2] wifi: wilc1000: Keep slot powered on during suspend/resume

[Kalle Valo]

Marek Vasut <marex@denx.de> writes:

> On 9/28/24 1:18 PM, Kalle Valo wrote:
>
>> Marek Vasut <marex@denx.de> writes:
>> 
>>> The WILC3000 can suspend and enter low power state. According to local
>>> measurements, the WILC3000 consumes the same amount of power if the slot
>>> is powered up and WILC3000 is suspended, and if the WILC3000 is powered
>>> off. Use the former option, keep the WILC3000 powered up as that allows
>>> for things like WoWlan to work.
>>>
>>> Note that this is tested on WILC3000 only, not on WILC1000 .
>>>
>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>> ---
>>> Cc: Ajay Singh <ajay.kathat@microchip.com>
>>> Cc: Alexis Lothoré <alexis.lothore@bootlin.com>
>>> Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev>
>>> Cc: Kalle Valo <kvalo@kernel.org>
>>> Cc: Marek Vasut <marex@denx.de>
>>> Cc: linux-wireless@vger.kernel.org
>>> ---
>>> V2: Rebase on next-20240926
>>
>> BTW I recommend using wireless-next as the baseline for wireless
>> patches. For example, wireless-next is not pulled to linux-next during
>> merge windows or other patches in linux-next might create unnecessary
>> conflicts. Of course most of the cases using linux-next is fine.
>
> I didn't know there was one such tree, added to remotes, thanks !

Another tip for the Monday :) get_maintainer script is a handy way to
find what tree should be used:

$ scripts/get_maintainer.pl -f --scm drivers/net/wireless/microchip/wilc1000/wlan.c
Ajay Singh <ajay.kathat@microchip.com> (supporter:MICROCHIP WILC1000 WIFI DRIVER)
Claudiu Beznea <claudiu.beznea@tuxon.dev> (supporter:MICROCHIP WILC1000 WIFI DRIVER)
Kalle Valo <kvalo@kernel.org> (maintainer:NETWORKING DRIVERS (WIRELESS))
linux-wireless@vger.kernel.org (open list:MICROCHIP WILC1000 WIFI DRIVER)
linux-kernel@vger.kernel.org (open list)
git git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git
git git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git
git git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v2] wifi: wilc1000: Keep slot powered on during suspend/resume

[Alexis Lothoré]

On 9/29/24 17:23, Marek Vasut wrote:
> On 9/28/24 1:18 PM, Kalle Valo wrote:
>> Marek Vasut <marex@denx.de> writes:
>>
>>> The WILC3000 can suspend and enter low power state. According to local
>>> measurements, the WILC3000 consumes the same amount of power if the slot
>>> is powered up and WILC3000 is suspended, and if the WILC3000 is powered
>>> off. Use the former option, keep the WILC3000 powered up as that allows
>>> for things like WoWlan to work.
>>>
>>> Note that this is tested on WILC3000 only, not on WILC1000 .
>>>
>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>> ---
>>> Cc: Ajay Singh <ajay.kathat@microchip.com>
>>> Cc: Alexis Lothoré <alexis.lothore@bootlin.com>
>>> Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev>
>>> Cc: Kalle Valo <kvalo@kernel.org>
>>> Cc: Marek Vasut <marex@denx.de>
>>> Cc: linux-wireless@vger.kernel.org
>>> ---
>>> V2: Rebase on next-20240926
>>
>> BTW I recommend using wireless-next as the baseline for wireless
>> patches. For example, wireless-next is not pulled to linux-next during
>> merge windows or other patches in linux-next might create unnecessary
>> conflicts. Of course most of the cases using linux-next is fine.
> I didn't know there was one such tree, added to remotes, thanks !

+1, as already mentioned in previous revisions, I would gladly test wilc3000
changes on both wilc3000 and wilc1000 on my platform, and having the series on
top of wireless-next would allow to do it on top of any change also affecting
the driver in wireless-next :)

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v2] wifi: wilc1000: Keep slot powered on during suspend/resume

[Marek Vasut]

On 10/3/24 10:31 AM, Alexis Lothoré wrote:
> On 9/29/24 17:23, Marek Vasut wrote:
>> On 9/28/24 1:18 PM, Kalle Valo wrote:
>>> Marek Vasut <marex@denx.de> writes:
>>>
>>>> The WILC3000 can suspend and enter low power state. According to local
>>>> measurements, the WILC3000 consumes the same amount of power if the slot
>>>> is powered up and WILC3000 is suspended, and if the WILC3000 is powered
>>>> off. Use the former option, keep the WILC3000 powered up as that allows
>>>> for things like WoWlan to work.
>>>>
>>>> Note that this is tested on WILC3000 only, not on WILC1000 .
>>>>
>>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>>> ---
>>>> Cc: Ajay Singh <ajay.kathat@microchip.com>
>>>> Cc: Alexis Lothoré <alexis.lothore@bootlin.com>
>>>> Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev>
>>>> Cc: Kalle Valo <kvalo@kernel.org>
>>>> Cc: Marek Vasut <marex@denx.de>
>>>> Cc: linux-wireless@vger.kernel.org
>>>> ---
>>>> V2: Rebase on next-20240926
>>>
>>> BTW I recommend using wireless-next as the baseline for wireless
>>> patches. For example, wireless-next is not pulled to linux-next during
>>> merge windows or other patches in linux-next might create unnecessary
>>> conflicts. Of course most of the cases using linux-next is fine.
>> I didn't know there was one such tree, added to remotes, thanks !
> 
> +1, as already mentioned in previous revisions, I would gladly test wilc3000
> changes on both wilc3000 and wilc1000 on my platform, and having the series on
> top of wireless-next would allow to do it on top of any change also affecting
> the driver in wireless-next :)

I just had a look at a diff between wireless-next/main and next/master 
20241003 for drivers/net/wireless/microchip , there are no changes to 
the driver between the two trees, so it should be possible to test this 
patch on either tree. Can you give it a try ? Ideally test this patch 
separately on WILC1000 across suspend/resume and check if it works. You 
might need the MMC controller fix which sets struct mmc_host .pm_caps |= 
MMC_PM_KEEP_POWER for your controller , unless this is already upstream.

The WILC3000 series depends on this patch.

Re: [PATCH v2] wifi: wilc1000: Keep slot powered on during suspend/resume

[Alexis Lothoré]

On 10/3/24 12:49, Marek Vasut wrote:
> On 10/3/24 10:31 AM, Alexis Lothoré wrote:
>> On 9/29/24 17:23, Marek Vasut wrote:
>>> On 9/28/24 1:18 PM, Kalle Valo wrote:
>>>> Marek Vasut <marex@denx.de> writes:
>>>>
>>>>> The WILC3000 can suspend and enter low power state. According to local
>>>>> measurements, the WILC3000 consumes the same amount of power if the slot
>>>>> is powered up and WILC3000 is suspended, and if the WILC3000 is powered
>>>>> off. Use the former option, keep the WILC3000 powered up as that allows
>>>>> for things like WoWlan to work.
>>>>>
>>>>> Note that this is tested on WILC3000 only, not on WILC1000 .
>>>>>
>>>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>>>> ---
>>>>> Cc: Ajay Singh <ajay.kathat@microchip.com>
>>>>> Cc: Alexis Lothoré <alexis.lothore@bootlin.com>
>>>>> Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev>
>>>>> Cc: Kalle Valo <kvalo@kernel.org>
>>>>> Cc: Marek Vasut <marex@denx.de>
>>>>> Cc: linux-wireless@vger.kernel.org
>>>>> ---
>>>>> V2: Rebase on next-20240926
>>>>
>>>> BTW I recommend using wireless-next as the baseline for wireless
>>>> patches. For example, wireless-next is not pulled to linux-next during
>>>> merge windows or other patches in linux-next might create unnecessary
>>>> conflicts. Of course most of the cases using linux-next is fine.
>>> I didn't know there was one such tree, added to remotes, thanks !
>>
>> +1, as already mentioned in previous revisions, I would gladly test wilc3000
>> changes on both wilc3000 and wilc1000 on my platform, and having the series on
>> top of wireless-next would allow to do it on top of any change also affecting
>> the driver in wireless-next :)
> 
> I just had a look at a diff between wireless-next/main and next/master 20241003
> for drivers/net/wireless/microchip , there are no changes to the driver between
> the two trees, so it should be possible to test this patch on either tree. Can
> you give it a try ? Ideally test this patch separately on WILC1000 across
> suspend/resume and check if it works. You might need the MMC controller fix
> which sets struct mmc_host .pm_caps |= MMC_PM_KEEP_POWER for your controller ,
> unless this is already upstream.
> 
> The WILC3000 series depends on this patch.
> 
Meh, you are right, I have read too fast your answer to my initial question
about used base branch, and omitted the suspend/resume patch (I assumed it
conflicted because of some other patches in wireless-next).

Thanks,

Alexis

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v2] wifi: wilc1000: Keep slot powered on during suspend/resume

[Marek Vasut]

On 10/3/24 2:58 PM, Alexis Lothoré wrote:
> On 10/3/24 12:49, Marek Vasut wrote:
>> On 10/3/24 10:31 AM, Alexis Lothoré wrote:
>>> On 9/29/24 17:23, Marek Vasut wrote:
>>>> On 9/28/24 1:18 PM, Kalle Valo wrote:
>>>>> Marek Vasut <marex@denx.de> writes:
>>>>>
>>>>>> The WILC3000 can suspend and enter low power state. According to local
>>>>>> measurements, the WILC3000 consumes the same amount of power if the slot
>>>>>> is powered up and WILC3000 is suspended, and if the WILC3000 is powered
>>>>>> off. Use the former option, keep the WILC3000 powered up as that allows
>>>>>> for things like WoWlan to work.
>>>>>>
>>>>>> Note that this is tested on WILC3000 only, not on WILC1000 .
>>>>>>
>>>>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>>>>> ---
>>>>>> Cc: Ajay Singh <ajay.kathat@microchip.com>
>>>>>> Cc: Alexis Lothoré <alexis.lothore@bootlin.com>
>>>>>> Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev>
>>>>>> Cc: Kalle Valo <kvalo@kernel.org>
>>>>>> Cc: Marek Vasut <marex@denx.de>
>>>>>> Cc: linux-wireless@vger.kernel.org
>>>>>> ---
>>>>>> V2: Rebase on next-20240926
>>>>>
>>>>> BTW I recommend using wireless-next as the baseline for wireless
>>>>> patches. For example, wireless-next is not pulled to linux-next during
>>>>> merge windows or other patches in linux-next might create unnecessary
>>>>> conflicts. Of course most of the cases using linux-next is fine.
>>>> I didn't know there was one such tree, added to remotes, thanks !
>>>
>>> +1, as already mentioned in previous revisions, I would gladly test wilc3000
>>> changes on both wilc3000 and wilc1000 on my platform, and having the series on
>>> top of wireless-next would allow to do it on top of any change also affecting
>>> the driver in wireless-next :)
>>
>> I just had a look at a diff between wireless-next/main and next/master 20241003
>> for drivers/net/wireless/microchip , there are no changes to the driver between
>> the two trees, so it should be possible to test this patch on either tree. Can
>> you give it a try ? Ideally test this patch separately on WILC1000 across
>> suspend/resume and check if it works. You might need the MMC controller fix
>> which sets struct mmc_host .pm_caps |= MMC_PM_KEEP_POWER for your controller ,
>> unless this is already upstream.
>>
>> The WILC3000 series depends on this patch.
>>
> Meh, you are right, I have read too fast your answer to my initial question
> about used base branch, and omitted the suspend/resume patch (I assumed it
> conflicted because of some other patches in wireless-next).
Nope, it conflicted because I (again) didn't include cover letter with 
the WILC3000 series, which mentions this information. I really need to 
find some suitable tooling to manage the cover letters, branch 
description does not seem to cut it quite as I hoped it would.

Re: [PATCH v2] wifi: wilc1000: Keep slot powered on during suspend/resume

[Alexis Lothoré]

On 10/3/24 15:18, Marek Vasut wrote:
> On 10/3/24 2:58 PM, Alexis Lothoré wrote:
>> On 10/3/24 12:49, Marek Vasut wrote:
>>> On 10/3/24 10:31 AM, Alexis Lothoré wrote:
>>>> On 9/29/24 17:23, Marek Vasut wrote:
>>>>> On 9/28/24 1:18 PM, Kalle Valo wrote:
>>>>>> Marek Vasut <marex@denx.de> writes:
>>>>>>
>>>>>>> The WILC3000 can suspend and enter low power state. According to local
>>>>>>> measurements, the WILC3000 consumes the same amount of power if the slot
>>>>>>> is powered up and WILC3000 is suspended, and if the WILC3000 is powered
>>>>>>> off. Use the former option, keep the WILC3000 powered up as that allows
>>>>>>> for things like WoWlan to work.
>>>>>>>
>>>>>>> Note that this is tested on WILC3000 only, not on WILC1000 .
>>>>>>>
>>>>>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>>>>>> ---
>>>>>>> Cc: Ajay Singh <ajay.kathat@microchip.com>
>>>>>>> Cc: Alexis Lothoré <alexis.lothore@bootlin.com>
>>>>>>> Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev>
>>>>>>> Cc: Kalle Valo <kvalo@kernel.org>
>>>>>>> Cc: Marek Vasut <marex@denx.de>
>>>>>>> Cc: linux-wireless@vger.kernel.org
>>>>>>> ---
>>>>>>> V2: Rebase on next-20240926
>>>>>>
>>>>>> BTW I recommend using wireless-next as the baseline for wireless
>>>>>> patches. For example, wireless-next is not pulled to linux-next during
>>>>>> merge windows or other patches in linux-next might create unnecessary
>>>>>> conflicts. Of course most of the cases using linux-next is fine.
>>>>> I didn't know there was one such tree, added to remotes, thanks !
>>>>
>>>> +1, as already mentioned in previous revisions, I would gladly test wilc3000
>>>> changes on both wilc3000 and wilc1000 on my platform, and having the series on
>>>> top of wireless-next would allow to do it on top of any change also affecting
>>>> the driver in wireless-next :)
>>>
>>> I just had a look at a diff between wireless-next/main and next/master 20241003
>>> for drivers/net/wireless/microchip , there are no changes to the driver between
>>> the two trees, so it should be possible to test this patch on either tree. Can
>>> you give it a try ? Ideally test this patch separately on WILC1000 across
>>> suspend/resume and check if it works. You might need the MMC controller fix
>>> which sets struct mmc_host .pm_caps |= MMC_PM_KEEP_POWER for your controller ,
>>> unless this is already upstream.
>>>
>>> The WILC3000 series depends on this patch.
>>>
>> Meh, you are right, I have read too fast your answer to my initial question
>> about used base branch, and omitted the suspend/resume patch (I assumed it
>> conflicted because of some other patches in wireless-next).
> Nope, it conflicted because I (again) didn't include cover letter with the
> WILC3000 series, which mentions this information. I really need to find some
> suitable tooling to manage the cover letters, branch description does not seem
> to cut it quite as I hoped it would.

May I suggest b4 [0] for such task ? It really eases series submissions, taking
care of all the small details that can be easily forgotten :) Latest versions of
the tool will warn you during the sending phase if you forgot to create/update
your cover letter (which is stored by default as an empty commit, this can be
tuned). It is even able now to manage patch sets dependencies (but I still did
not have the opportunity to give this feature a try)

[0] https://b4.docs.kernel.org/en/latest/


-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v2] wifi: wilc1000: Keep slot powered on during suspend/resume

[Marek Vasut]

On 10/3/24 3:59 PM, Alexis Lothoré wrote:
> On 10/3/24 15:18, Marek Vasut wrote:
>> On 10/3/24 2:58 PM, Alexis Lothoré wrote:
>>> On 10/3/24 12:49, Marek Vasut wrote:
>>>> On 10/3/24 10:31 AM, Alexis Lothoré wrote:
>>>>> On 9/29/24 17:23, Marek Vasut wrote:
>>>>>> On 9/28/24 1:18 PM, Kalle Valo wrote:
>>>>>>> Marek Vasut <marex@denx.de> writes:
>>>>>>>
>>>>>>>> The WILC3000 can suspend and enter low power state. According to local
>>>>>>>> measurements, the WILC3000 consumes the same amount of power if the slot
>>>>>>>> is powered up and WILC3000 is suspended, and if the WILC3000 is powered
>>>>>>>> off. Use the former option, keep the WILC3000 powered up as that allows
>>>>>>>> for things like WoWlan to work.
>>>>>>>>
>>>>>>>> Note that this is tested on WILC3000 only, not on WILC1000 .
>>>>>>>>
>>>>>>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>>>>>>> ---
>>>>>>>> Cc: Ajay Singh <ajay.kathat@microchip.com>
>>>>>>>> Cc: Alexis Lothoré <alexis.lothore@bootlin.com>
>>>>>>>> Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev>
>>>>>>>> Cc: Kalle Valo <kvalo@kernel.org>
>>>>>>>> Cc: Marek Vasut <marex@denx.de>
>>>>>>>> Cc: linux-wireless@vger.kernel.org
>>>>>>>> ---
>>>>>>>> V2: Rebase on next-20240926
>>>>>>>
>>>>>>> BTW I recommend using wireless-next as the baseline for wireless
>>>>>>> patches. For example, wireless-next is not pulled to linux-next during
>>>>>>> merge windows or other patches in linux-next might create unnecessary
>>>>>>> conflicts. Of course most of the cases using linux-next is fine.
>>>>>> I didn't know there was one such tree, added to remotes, thanks !
>>>>>
>>>>> +1, as already mentioned in previous revisions, I would gladly test wilc3000
>>>>> changes on both wilc3000 and wilc1000 on my platform, and having the series on
>>>>> top of wireless-next would allow to do it on top of any change also affecting
>>>>> the driver in wireless-next :)
>>>>
>>>> I just had a look at a diff between wireless-next/main and next/master 20241003
>>>> for drivers/net/wireless/microchip , there are no changes to the driver between
>>>> the two trees, so it should be possible to test this patch on either tree. Can
>>>> you give it a try ? Ideally test this patch separately on WILC1000 across
>>>> suspend/resume and check if it works. You might need the MMC controller fix
>>>> which sets struct mmc_host .pm_caps |= MMC_PM_KEEP_POWER for your controller ,
>>>> unless this is already upstream.
>>>>
>>>> The WILC3000 series depends on this patch.
>>>>
>>> Meh, you are right, I have read too fast your answer to my initial question
>>> about used base branch, and omitted the suspend/resume patch (I assumed it
>>> conflicted because of some other patches in wireless-next).
>> Nope, it conflicted because I (again) didn't include cover letter with the
>> WILC3000 series, which mentions this information. I really need to find some
>> suitable tooling to manage the cover letters, branch description does not seem
>> to cut it quite as I hoped it would.
> 
> May I suggest b4 [0] for such task ? It really eases series submissions, taking
> care of all the small details that can be easily forgotten :) Latest versions of
> the tool will warn you during the sending phase if you forgot to create/update
> your cover letter (which is stored by default as an empty commit, this can be
> tuned). It is even able now to manage patch sets dependencies (but I still did
> not have the opportunity to give this feature a try)
> 
> [0] https://b4.docs.kernel.org/en/latest/
I haven't set up b4 yet, but empty commit might actually work in my 
workflow.

Re: [PATCH v2] wifi: wilc1000: Keep slot powered on during suspend/resume

[Alexis Lothoré]

On 9/26/24 21:50, Marek Vasut wrote:
> The WILC3000 can suspend and enter low power state. According to local
> measurements, the WILC3000 consumes the same amount of power if the slot
> is powered up and WILC3000 is suspended, and if the WILC3000 is powered
> off. Use the former option, keep the WILC3000 powered up as that allows
> for things like WoWlan to work.
> 
> Note that this is tested on WILC3000 only, not on WILC1000 .

So I have tested this change on wilc1000 over sdio (after enabling
MMC_PM_KEEP_POWER capability on my sdmmc controller), and LGTM, system properly
enters and leave suspend, and on resume module is working (ie in sta mode, chip
properly reconnects to configured AP).

The only concern I still have is about existing user who currently do not
declare MMC_PM_KEEP_POWER cap correctly on their platform (as it was the case
for me, and as Ajay eventually raised in the first revision):
- they can currently enter system suspend (and yes, for at least some Atmel
platforms, wilc chip still works on resume because it is "accidentally" kept
powered on)
- after this change, they will fail to do so (because of the failing call to
sdio_set_host_pm_flags, which makes the whole suspend method fail)

But I guess the issue is rather on the sdio host controller description on those
platforms, which should always have the MMC_PM_KEEP_POWER cap set ? If so:

Tested-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Tested-on: WILC1000SD 07 SDIO WILC_WIFI_FW_REL_16_1_2

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v2] wifi: wilc1000: Keep slot powered on during suspend/resume

[Kalle Valo]

Marek Vasut <marex@denx.de> wrote:

> The WILC3000 can suspend and enter low power state. According to local
> measurements, the WILC3000 consumes the same amount of power if the slot
> is powered up and WILC3000 is suspended, and if the WILC3000 is powered
> off. Use the former option, keep the WILC3000 powered up as that allows
> for things like WoWlan to work.
> 
> Note that this is tested on WILC3000 only, not on WILC1000 .
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Tested-by: Alexis Lothoré <alexis.lothore@bootlin.com>

Patch applied to wireless-next.git, thanks.

98ca3178ad79 wifi: wilc1000: Keep slot powered on during suspend/resume

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20240926195113.2823392-1-marex@denx.de/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches