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  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:	Sat, 15 Nov 2014 02:38:00 +0100 (CET)
From:	Thomas Gleixner <>
To:	Anatol Pomozov <>
cc:	Thierry Reding <>,
	Stephen Warren <>,
	Daniel Lezcano <>,
	Russell King <>,
	LKML <>,
	"" <>,
	Tony Lindgren <>,
	Mark Rutland <>,
	John Stultz <>
Subject: Re: [PATCH] timekeeping: Move persistent clock registration code
 from ARM to kernel

On Sat, 15 Nov 2014, Thomas Gleixner wrote:
> On Fri, 14 Nov 2014, Anatol Pomozov wrote:
> > On Fri, Nov 14, 2014 at 4:18 PM, Thomas Gleixner <> wrote:
> > >> So what I suppose to do with my patch? If it does not work could
> > >> anyone provide patch that removes ARM arch dependency from
> > >> tegra20_timer.c?
> > >
> > > Huch? You want other people to solve your problems?
> > 
> > This is not the point. I provided patch that fixes the issue. Other
> > people said that they have ideas how to do it different (and better)
> > way. So I am asking to share these ideas represented as a patch.
> That's not the way it works.
> You sent a patch to solve an problem which you are facing.
> Now the people who review the patch think that there is a better
> approach than moving code from arm/ to the timekeeping core code.
> So it's up to you to come up with a patch which solves the problem in
> the right way.

And just for the record this whole thing is just hilarious.

ARM64 selects ARM_ARCH_TIMER which registers the architected timer as
the primary clocksource.

Now that timer has the following flag set:


And that flag causes the core timekeeping code to use the clocksource
to figure out the time which the machine spent in suspend.

So registering that tegra RTC as persistent clock does not have any
value at all. Simply because it is completely irrelevant at boot time
whether the RTC can be accessed right at timekeeping init or
not. Nothing in early boot needs wall clock time. It's good enough to
set wall clock time late in the boot process as the first use case is
when the root file system gets mounted. And the RTC driver which
obviously deals with the same hardware is initialized before that.

So you are trying to move something which is outright pointless to the
core code just because you carry that patch in your ChromeOS support



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists