linux-kernel - Re: [RFC PATCH] mmc: sdhci-of-at91: don't put device in suspend after probe

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: <56BB473B.2010105@intel.com>
Date:	Wed, 10 Feb 2016 16:20:43 +0200
From:	Adrian Hunter <adrian.hunter@...el.com>
To:	nicolas.ferre@...el.com, ulf.hansson@...aro.org,
	linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] mmc: sdhci-of-at91: don't put device in suspend after
 probe

On 10/02/16 16:16, Ludovic Desroches wrote:
> On Wed, Feb 10, 2016 at 03:00:09PM +0200, Adrian Hunter wrote:
>> On 10/02/16 14:51, Ludovic Desroches wrote:
>>> Hi Adrian,
>>>
>>> On Wed, Feb 10, 2016 at 01:50:44PM +0200, Adrian Hunter wrote:
>>>> On 10/02/16 11:58, Ludovic Desroches wrote:
>>>>> By putting the device in suspend at the end of the probe, it is
>>>>> impossible to wake up on non software event such as card
>>>>> insertion/removal.
>>>>>
>>>>> Signed-off-by: Ludovic Desroches <ludovic.desroches@...el.com>
>>>>> ---
>>>>>
>>>>> Hi,
>>>>>
>>>>> Since I had no feedback on this topic:
>>>>> http://permalink.gmane.org/gmane.linux.kernel.mmc/35160
>>>>>
>>>>> I would like to no more put the device in suspend at the end of the probe. If
>>>>> my device is suspended at the end of the probe, I have no issue to resume on
>>>>> a software event such as mounting my sdcard but hardware event such as card
>>>>> insertion and removal do not trigger a resume.
>>>>
>>>> You can't use runtime PM unless you have a way to wake-up.
>>>>
>>>
>>> Thanks for your feedback. I am a bit disappointed since Ulf advised me to use
>>> runtime PM instead of system PM.
>>>
>>>> Currently, sdhci disables card detect interrupts when runtime suspended,
>>>> and drivers use a card-detect GPIO to wake-up.
>>>>
>>>
>>> It is what I have seen going through the sdhci layer. So next question is:
>>> is it normal to not take care of card detect interrupts? We keep enabled
>>> some IRQs probably for SDIO modules IRQ but not for card detection. I
>>> don't understand the reason.
>>
>> Does sdhci-of-at91.c generate card detect interrupts while runtime suspended?
> 
> It could if I keep one or two clocks enabled (need extra tests to be
> sure about the clock needed to get this interrupt). I have tried to modify
> quickly sdhci_runtime_suspend_host() to enable card insertion/removal,
> there is an irq generated but the kernel complains this irq is not
> handled. I didn't dig further, it was only to do a simple test.

sdhci_irq() returns immediately if (host->runtime_suspended &&
!sdhci_sdio_irq_enabled(host))