linux-kernel - Re: [PATCH v2] RTC: Selectively enable PIE-Hrtimer emulation.

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: <1300823076.2731.123.camel@work-vm>
Date:	Tue, 22 Mar 2011 12:44:36 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	MyungJoo Ham <myungjoo.ham@...sung.com>
Cc:	rtc-linux@...glegroups.com, linux-kernel@...r.kernel.org,
	Alessandro Zummo <a.zummo@...ertech.it>,
	kyungmin.park@...sung.com, myungjoo.ham@...il.com
Subject: Re: [PATCH v2] RTC: Selectively enable PIE-Hrtimer emulation.

On Tue, 2011-03-22 at 17:08 +0900, MyungJoo Ham wrote:
> The patch of John Stultz, "RTC: Rework RTC code to use timerqueue for
> events", has enabled PIE interrupt emulation with hrtimer unconditionally.
> However, we do have RTC devices that support PIE and such devices are
> not meant to be emulated by hrtimer.

I guess the question I want to ask here, is what is the value of getting
PIE interrupts over the hrtimer? For most cases it is yet another
interrupt. Could you expand a bit more on why you need real PIE irqs?

> Besides, we sometimes need RTC-PIE
> to function while hrtimer does not; e.g., CPU's RTC PIE as a
> suspend-to-RAM wakeup source.

So this indeed is a limitation. hrtimer emulated PIE's won't wake the
system up.  So is this a "Besides...sometimes" sort of case, or is PIE
wakeups really the only issue here?

To better understand the scope of the issue, I'd like to know more about
your uage of PIE mode as a wakeup source. Given PIE mode is for sub 1HZ
irqs, do you really use suspend/resume at a periodic rate multiple times
a second? Is this done with the current mainline kernel? What would be
the penalty of moving to a 1HZ wakeup?

If this indeed a critical limitation, then it needs to be solved.
However, instead of just re-enabling the pie mode access to userland
(which will likely need more then the patch here provides to avoid
breaking the RTC event multiplexing), I'd much prefer to see the the
solution as extending the in-kernel RTC API to allow for sub-second
resolution alarms, then using a periodic mode rtc alarm to emulate PIE
mode irqs out to userland.

Alessandro: Your thoughts here? As it seems most RTC hardware can handle
it, any objections to extending the in-kernel interface to provide
sub-second resolution (it doesn't mean they will provide it, but it
doesn't limit the hardware at the interface level).

> This patch allows to selectively use the PIE emulation. If the rtc
> driver has implemented PIE related ops (irq_set_state and irq_set_freq),

So, both irq_set_state and irq_set_freq were removed upstream in the
2.6.39-rc1 merge window, so this patch def won't work upstream. 

Sorry for the trouble here! Hopefully we can get things resolved and
working shortly here.

thanks
-john

--
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/