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  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, 02 Apr 2014 11:09:32 -0700
From:	Stephen Boyd <>
To:	Lei Wen <>,
	Daniel Lezcano <>,
	Thomas Gleixner <>,
Subject: Re: [PATCH] clocksource: register persistent clock for arm arch_timer

On 04/02/14 04:02, Lei Wen wrote:
> Since arm's arch_timer's counter would keep accumulated even in the
> low power mode, including suspend state, it is very suitable to be
> the persistent clock instead of RTC.
> While read_persistent_clock calling place shall be rare, like only
> suspend/resume place? So we shall don't care for its performance
> very much, so use direclty divided by frequency should be accepted
> for this reason. Actually archtimer's counter read performance already
> be very good, since it is directly access from core's bus, not from
> soc, so this is another reason why we choose use divide here.
> Final reason for why we don't use multi+shift way is for we may not
> call read_persistent_clock for long time, like system long time
> not enter into suspend, so that the accumulated cycle difference value
> may larger than we used for calculate the multi+shift, thus precise
> would be highly affected in such corner case.
> Signed-off-by: Lei Wen <>
> ---
> I am not sure whether it is good to add something like
> generic_persistent_clock_read in the new added kernel/time/sched_clock.c?
> Since from arch timer's perspective, all it need to do is to pick
> the suspend period from the place where sched_clock being stopped/restarted.
> Any idea for make the persistent clock reading as one generic function,
> like current sched_clock do?

Why do we need this? Don't we put the CLOCK_SOURCE_SUSPEND_NONSTOP flag
on the arm_arch_timer clocksource to handle this? The only reason I can
think of would be that you're calling read_persistent_clock() from
somewhere else besides the timekeeping core. If that's why, please use
the time functionality like ktime_get_boottime() or

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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