linux-kernel - Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

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]

Date:	Wed, 30 Sep 2015 16:42:21 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	balbi@...com
Cc:	linux-arm-kernel@...ts.infradead.org,
	Tony Lindgren <tony@...mide.com>, daniel.lezcano@...aro.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	tglx@...utronix.de,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	linux-tegra@...r.kernel.org,
	Stephen Warren <swarren@...dotorg.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Alexandre Courbot <gnurou@...il.com>
Subject: Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

On Wednesday 30 September 2015 09:13:38 Felipe Balbi wrote:
> On Wed, Sep 30, 2015 at 10:22:46AM +0200, Arnd Bergmann wrote:
> > On Tuesday 29 September 2015 15:43:55 Felipe Balbi wrote:
> > > 
> > > the following patches de-obfuscate arch/arm/mach-omap2/timer.c
> > > and start moving code to drivers/clocksource. So far only counter32k
> > > has been moved over.
> > > 
> > > Note that we can't get rid of all the code (yet) because there are
> > > still platforms relying to legacy boot and because of the strong
> > > coupling with OMAP's hwmod layer.
> > > 
> > > This is, for now, an RFC and has be written on top of [1]. Boot tested
> > > with AM335x and AM437x.
> > > 
> > > [1] http://marc.info/?l=linux-omap&m=144354336924308&w=2
> > 
> > Looks very nice!
> > 
> > > ps: if anybody has a good idea on how to get rid of
> > > register_persistent_clock(), please let me know
> > 
> > I don't think we want to get rid of that, because it is the more
> > accurate interface. IIRC systems that have an RTC will use
> > timekeeping_inject_sleeptime64() in rtc_resume(). I don't know however
> > how the two methods are coordinated, i.e. how the kernel ensures that
> > exactly one of the two is used, but never both.
> 
> however register_persistent_clock() is an ARM-only thing, the question
> was more towards that. Do we want to continue using the ARM-only
> register_persistent_clock() or is there a more generic version of it ?

Ah, got it.

I wouldn't worry about it at the moment, the read_persistent_clock64
interface is very rarely used: only arm, ia64, mips/lasat and s390
define it at all, only arm has more than one implementation (omap
and tegra) and the tegra, ia64 and mips implementations should really
use timekeeping_inject_sleeptime64() instead.

read_boot_clock64() is even rarer: only s390 defines it, apparently
because it is the only architecture that uses a single register for
wall-clock time and high-resolution time (it has a 96-bit
quarternanosecond register that is synchronized before booting Linux).	

TEGRA folks: the tegra_read_persistent_clock() implementation apparently
predates the Tegra RTC driver and I wonder if they actually do the
right thing in combination. Could it be that the wall time forwards
twice as fast as it should during resume when the RTC driver is loaded?
Could it be that we can simply remove  tegra_read_persistent_clock()
and the register_persistent_clock() infrastructure?

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