linux-kernel - Re: [RFC PATCH] mmc: Enable wakeup

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: <CAMbhsRQwGbpa4a1RziV92qnw4VFh6+=oQiadfqa17FANEiK8_Q@mail.gmail.com>
Date:	Tue, 18 Jun 2013 10:15:30 -0700
From:	Colin Cross <ccross@...roid.com>
To:	Ulf Hansson <ulf.hansson@...aro.org>
Cc:	Zoran Markovic <zoran.markovic@...aro.org>,
	lkml <linux-kernel@...r.kernel.org>, linux-mmc@...r.kernel.org,
	San Mehat <san@...gle.com>,
	John Stultz <john.stultz@...aro.org>,
	Chris Ball <cjb@...top.org>,
	Johan Rudholm <johan.rudholm@...ricsson.com>,
	Jaehoon Chung <jh80.chung@...sung.com>,
	Konstantin Dorfman <kdorfman@...eaurora.org>,
	Guennadi Liakhovetski <g.liakhovetski@....de>,
	Tejun Heo <tj@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH] mmc: Enable wakeup_sources for mmc core

On Tue, Jun 18, 2013 at 6:17 AM, Ulf Hansson <ulf.hansson@...aro.org> wrote:
> On 17 June 2013 20:33, Colin Cross <ccross@...roid.com> wrote:
>> This is a generic requirement for using a kernel with autosleep
>> enabled.  Autosleep will enter suspend whenever there is no wakeup
>> source/wakelock held.  Consider the following sequence:
>>
>> Kernel is suspended
>> Card is inserted, triggering a wakeup interrupt, which is an implicit
>> wakeup source until it is handled
>
> I don't think a card insert/remove irq need to be configured as a
> wakeup interrupt. As you say, it will force a resume to detect the
> card, but for what reason?
> Instead, I think it it better to leave the card detection to be
> handled at the next resume, thus not resuming the system when not
> needed.

That decision is going to be different on each device.  On Android
devices it has been configured as a wakeup interrupt.  This patch is
necessary on devices that want to handle the event as a wakeup event,
and has negligible impact on those that do not.

>> Kernel starts resuming, resumes the mmc driver
>> The mmc driver enables its interrupt, which is immediately handled and
>> queues an event to be handled by userspace
>> At this point the wakeup interrupt is handled and gone, and no wakeup
>> sources are being held, so the kernel can choose to go back to
>> suspend, so userspace can't handle the insertion event until the
>> kernel wakes up for another reason.
>
> Is this a problem? From my point of view it should be perfectly
> acceptable to let userspace handle the event at the next resume/wakeup
> instead. Don't you think so?

Depends what userspace is doing.  If userspace would like to provide
the user some feedback on the event, then it has to be a wakeup
interrupt, and it has to hold a wakelock until it has passed the event
to userspace.

>>
>> In general, an event that is triggered by a wakeup interrupt that is
>> being passed from the kernel to userspace needs to have a wakeup
>> source held while the event is queued.
>
> That's sounds reasonable. Would it then make sense to hold a generic
> wakeup source in the "suspend/resume core", once a wakeup interrupt is
> fetched?

No, the suspend/resume core can only hold a wakeup source until it has
handed the event off to the driver, at which point it is the driver's
responsibility to hold a wakeup source.  The suspend/resume core
cannot tell if the event was handled by the driver or will be passed
to userspace.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/