linux-kernel - Re: [PATCH] mmc/sdio: don't allow interface to runtime-suspend until probe is finished.

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]

Message-ID: <20111216162139.5a6c3751@notabene.brown>
Date:	Fri, 16 Dec 2011 16:21:39 +1100
From:	NeilBrown <neilb@...e.de>
To:	Bing Zhao <bzhao@...vell.com>
Cc:	Ohad Ben-Cohen <ohad@...ery.com>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Daniel Drake <dsd@...top.org>,
	Joe Woodward <jw@...rafix.co.uk>, Chris Ball <cjb@...top.org>
Subject: Re: [PATCH] mmc/sdio: don't allow interface to runtime-suspend
 until probe is finished.

On Thu, 15 Dec 2011 20:39:28 -0800 Bing Zhao <bzhao@...vell.com> wrote:

> Hi Neil,
> 
> > In the other case where I do let it suspend early (And it never recovers
> > without the reset line being toggled) I see:
> > 
> > [ 2170.100982] mmc_wait_for_cmd 52 -> -110
> > [ 2170.105407] mmc_wait_for_cmd 52 -> -110
> > [ 2170.110260] mmc_wait_for_cmd 0 -> 0
> > [ 2170.115509] mmc_wait_for_cmd 8 -> -110
> > [ 2170.119842] mmc_wait_for_cmd 5 -> 0
> > [ 2170.123901] mmc_wait_for_cmd 5 -> 0
> > [ 2170.127929] mmc_wait_for_cmd 3 -> 0
> > [ 2170.131958] mmc_wait_for_cmd 7 -> 0
> 
> This works when reset line toggling was applied.

Yep.

> 
> > [ 2170.135986] mmc_wait_for_cmd 52 -> 0
> > [ 2170.140136] mmc_wait_for_cmd 52 -> 0
> > [ 2170.144226] mmc_wait_for_cmd 52 -> 0
> > [ 2170.148376] mmc_wait_for_cmd 52 -> 0
> > [ 2170.152465] mmc_wait_for_cmd 52 -> 0
> > 
> > 
> > which is much the same but then one second later:
> > 
> > [ 2171.166656] mmc_wait_for_cmd 52 -> 0
> > [ 2171.170806] mmc_wait_for_cmd 52 -> 0
> > [ 2171.175384] mmc_wait_for_cmd 0 -> 0
> > [ 2171.180603] mmc_wait_for_cmd 8 -> -110
> > [ 2171.185943] mmc_wait_for_cmd 5 -> -110
> 
> Here the CMD5 timeout is expected because SD8686 has already been initialized with CMD5,5,3,7.
> If you are able to skip re-initialization at this point, like what "powered_resume" does, you will probably get SD8686 continue to run.
> 

OK... I think we are nearly there.

If I configure the regulator to turn off on suspend and back on for resume, I
don't need to toggle the reset line.  I just works.
Previously I had the regulator permanently on.
So it seems we need one of:
  - remove/restore power
  - toggle reset
  - don't sent the CMD5,5,3,7 sequence again

I can neither guarantee that the regulator will be powered off or
that it will stay on.  That regulator is shared with bluetooth (on the same
package and wired together) so if the bluetooth is inactive the regulator
will drop-out when the wifi is suspended, but if bluetooth is active it won't.

What I could do is create a 'gpio-regulator' which is feed by the real
regulator and give it the reset line as its gpio.
Then when the wifi enters pm_suspend it will reset the wifi chip and release
the regulator which will power down if bluetooth is inactive.  When it
pm_resumes the regulator will be powered up and the reset line released.
(at least, that is the  theory).

So that will work for me, but I suspect more people will fall into this trap.
Is there some way would could detect this particular situation from the
libertas driver and print a message about needing a hard reset or a power off,
and pointing to documentation.

Or maybe the mmc layer could somehow ask if a reset is needed and not bother
if the device doesn't seem to have been powered down.
Just guessing here.

Thanks,
NeilBrown

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)