linux-kernel - Re: [stable] [patch 3/3] rtc: Limit frequency

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] [day] [month] [year] [list]

Date:	Sat, 06 Aug 2011 03:28:26 -0400
From:	Joshua Kinard <kumba@...too.org>
To:	John Stultz <john.stultz@...aro.org>
CC:	Willy Tarreau <w@....eu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ben Greear <greearb@...delatech.com>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>, stable@...nel.org
Subject: Re: [stable] [patch 3/3] rtc: Limit frequency

On 08/05/2011 05:04, John Stultz wrote:
> Yea, I submitted a slightly different version of Thomas' patch which set
> it to 8192Hz via the tip tree, but the original one went upstream first.
> I'm away from home right now, so I'll be re-submitting just that change
> probably next week.

Awesome, I'll look out for it if I get free time to look at the RTC driver I have.  It's broken now due to a loss of
__symbol_get(), as I was trying to find a way to make the driver determine if it was a module or not.

> I'm torn here. It would be good to have the functionality listed in some
> way so it is documented. However as we abstract the RTC to be more of an
> internal tool for the kernel, rather then hardware directly addressed
> from userland, the PIE mode is really not as useful (and quite messier
> to multiplex).  I'd much rather try to extend the alarm interfaces to
> allow for higher resolution, so it could be used as a alarmed highres
> oneshot timer if the hardware supports it.

That's why I think a wrapper would be best.  By default, it would use the hrtimer code and so, none of the existing
drivers would need to be modified.  Any driver that wants to, however, could override the base functions if they wanted
to provide that functionality separately.  It should probably be a CONFIG_* option, though.  Right now, consumers of
DS1685 are rare: old SGI O2 systems and some embedded board from 'electronic systems Gmbh', one of whose employees wrote
the original driver about 2 years ago.  The driver I have now handles older versions (DS1689/1693) and the more common
DS17x8y versions, and those I think are the most modern.  Not sure what systems use those, however.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@...too.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And our lives slip away, moment by moment, lost
in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
--
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/