linux-kernel - Re: [PATCH V2] wlcore: sdio: Fixup power on/off sequence

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 18 Jan 2019 17:36:58 +0200
From:   Kalle Valo <kvalo@...eaurora.org>
To:     Anders Roxell <anders.roxell@...aro.org>
Cc:     Tony Lindgren <tony@...mide.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Eyal Reizer <eyalr@...com>, linux-wireless@...r.kernel.org,
        Ricardo Salveti <rsalveti@...lveti.net>,
        Kishon Vijay Abraham I <kishon@...com>,
        John Stultz <john.stultz@...aro.org>,
        Jan Kiszka <jan.kiszka@....de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-omap@...r.kernel.org
Subject: Re: [PATCH V2] wlcore: sdio: Fixup power on/off sequence

Anders Roxell <anders.roxell@...aro.org> writes:

> On Wed, 16 Jan 2019 at 16:43, Tony Lindgren <tony@...mide.com> wrote:
>>
>> * Ulf Hansson <ulf.hansson@...aro.org> [190116 11:37]:
>> > During "wlan-up", we are programming the FW into the WiFi-chip. However,
>> > re-programming the FW doesn't work, unless a power cycle of the WiFi-chip
>> > is made in-between the programmings.
>> >
>> > To conform to this requirement and to fix the regression in a simple way,
>> > let's start by allowing that the SDIO card (WiFi-chip) may stay powered on
>> > (runtime resumed) when wl12xx_sdio_power_off() returns. The intent with the
>> > current code is to treat this scenario as an error, but unfortunate this
>> > doesn't work as expected, so let's fix this.
>> >
>> > The other part is to guarantee that a power cycle of the SDIO card has been
>> > completed when wl12xx_sdio_power_on() returns, as to allow the FW
>> > programming to succeed. However, relying solely on runtime PM to deal with
>> > this isn't sufficient. For example, userspace may prevent runtime suspend
>> > via sysfs for the device that represents the SDIO card, leading to that the
>> > mmc core also keeps it powered on. For this reason, let's instead do a
>> > brute force power cycle in wl12xx_sdio_power_on().
>> >
>> > Fixes: 728a9dc61f13 ("wlcore: sdio: Fix flakey SDIO runtime PM handling")
>> > Signed-off-by: Ulf Hansson <ulf.hansson@...aro.org>
>> > ---
>> >
>> > Changes in v2:
>> >       - Keep the SDIO host claimed when calling mmc_hw_reset().
>> >       - Add a fixes tag.
>>
>> This v2 version works for me as tested with:
>>
>> # while [ 1 ]; do ifconfig wlan0 down; ifconfig wlan0 up; done
>> [  181.364990] wlcore: down
>> [  182.116424] wlcore: firmware booted (Rev 6.3.10.0.141)
>> [  182.151641] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> [  182.166778] wlcore: down
>> [  182.773132] wlcore: firmware booted (Rev 6.3.10.0.141)
>> [  182.811096] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> ...
>>
>> Thanks for fixing this issue properly, and feel free to add:
>>
>> Tested-by: Tony Lindgren <tony@...mide.com>
>
> Tested-by: Anders Roxell <anders.roxell@...aro.org>
>
> I tested it on a hikey-6220, and it worked.

So what's the conclusion, can I take this patch? I see that this didn't
help with Jan but as Tony and Anders provided positive test results I'm
inclined to take this now and Jan's problem can be fixed with another
patch. Do everyone agree?

-- 
Kalle Valo