linux-kernel - Re: [PATCH] timekeeping: Move persistent clock registration code from ARM to kernel

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: <alpine.DEB.2.11.1411132334400.3935@nanos>
Date:	Thu, 13 Nov 2014 23:46:28 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Anatol Pomozov <anatol.pomozov@...il.com>
cc:	Thierry Reding <thierry.reding@...il.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Russell King <linux@....linux.org.uk>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>,
	Mark Rutland <mark.rutland@....com>,
	John Stultz <john.stultz@...aro.org>
Subject: Re: [PATCH] timekeeping: Move persistent clock registration code
 from ARM to kernel

On Mon, 10 Nov 2014, Anatol Pomozov wrote:
> On Mon, Nov 10, 2014 at 1:53 AM, Thierry Reding
> <thierry.reding@...il.com> wrote:
> > On Fri, Nov 07, 2014 at 11:34:15AM -0800, Anatol Pomozov wrote:
> >> ARM timekeeping functionality allows to register persistent/boot clock dynamically.
> >> This code is arch-independent and can be useful on other plaforms as well.
> >>
> >> As a byproduct of this change, tegra20_timer becomes ARM64 compatible.
> >>
> >> Tested: backported the change to chromeos-3.14 kernel ran on tegra 64bit
> >> board, made sure high-resolution clock works.
> >
> > Using this on an upstream kernel doesn't work, though, because 64-bit
> > ARM doesn't implement struct delay_timer which the driver needs since
> > v3.17.
> >
> > But I suppose the delay timer infrastructure could be moved into the
> > core similar to the persistent and boot clock as this patch does.
> 
> Thanks. It makes sense, I will send it in a separate patch, once this
> one will be reviewed. On our kernel I haven't seen this issue as we
> still use 3.14.

That's why you should test/compile your stuff on latest greatest and
not on a year old conglomorate of unknown provenance. :)

Aside of that I really wonder why we need that persistent_clock stuff
at all. We already have mechanisms to register persistent clocks AKA
RTCs after the early boot process and update the wall clock time
before we actually need it. Nothing in early boot depends on correct
wall clock at all.

So instead of adding more extra persistent clock nonsense, can we just
move all of that to the place where it belongs, i.e. RTC?

Thanks,

	tglx

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