linux-kernel - Re: [PATCH 1/3] timekeeping: Add persistent_clock

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: <20121214215651.GA31384@obsidianresearch.com>
Date:	Fri, 14 Dec 2012 14:56:51 -0700
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	John Stultz <john.stultz@...aro.org>
Cc:	Feng Tang <feng.tang@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	linux-kernel@...r.kernel.org, alek.du@...el.com
Subject: Re: [PATCH 1/3] timekeeping: Add persistent_clock_exist flag

On Fri, Dec 14, 2012 at 01:22:50PM -0800, John Stultz wrote:

> Although from a timekeeping perspective, the read_persistent_clock()
> interface is actually *much* preferred over the rtc HCTOSYS device.
> 
> Since read_persistent_clock() has the requirement that its safe to
> call with IRQs disabled, we can use it in the timekeeping
> suspend/resume code, which allows for better time accuracy.

Sure, but my view on this is that it has nothing to do with
read_persistent_clock. If the RTC driver can run with IRQs off is a
property of the RTC driver and RTC hardware - it has nothing to do
with the platform. ARM platforms will vary on a machine by machine
basis. The rtc-mv driver used on my ARM system is perfectly
re-entrant, lots of rtc on SOC drivers will be the same.

If this is the only thing keeping you on read_persistent_clock, for
real RTCs, then how about a RTC_DEV_SAFE_READ flag (or whatever) in
rtc_device.flags?

Reserve read_persistent_clock for things like that very specialized
non-RTC ARM counter.

> 
> While we're suggesting cleanups, the RTC Kconfig choices probably
> need a cleanup too, as  the list of all possible drivers can be
> confusing, when usually each architecture has only a few that they

That is a general pain with the new 'everything is a driver'..
However device tree enabled stuff is much nicer, just grep the tree
for the compatible string and you'll find a big clue about what
physical boards are using that driver.

For instance:
                rtc@...00 {
                        compatible = "marvell,kirkwood-rtc", "marvell,orion-rtc";
                        reg = <0x10300 0x20>;
                        interrupts = <53>;
                };
is matched to:

drivers/rtc/rtc-mv.c:

static struct of_device_id rtc_mv_of_match_table[] = {
        { .compatible = "marvell,orion-rtc", },

> exclusively support (I know there are exceptions to this).  It makes
> it hard to even figure out for a specific rtc driver what
> architecture one should look for in order to test with (I usually

With anything embedded the answer is 'anything and everything'
unfortunately. For example, our board has two bits of RTC capable
hardware - one inside the CPU SOC and one outside. We went through a
big analysis to pick the best one, based on battery selection and
battery life time. Even the presence of a RTC block in a SOC is not a
guarentee it will be used universally.

Regards,
Jason
--
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/