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]

Date:	Thu, 13 Dec 2012 21:10:24 -0700
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	Feng Tang <feng.tang@...el.com>
Cc:	John Stultz <john.stultz@...aro.org>,
	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 11:13:30AM +0800, Feng Tang wrote:

> > This seems like a great use of that hardware resource, and no doubt
> > those mach's also have a class RTC driver available talking to
> > different hardware.
> 
> Interesting to know this, thanks for the info. For the x86 desktop
> and mobile processors I've used, the read_persistent_clock and rtc
> are the same on-board device (always power on), so I see many time
> related code are execuated twice, like init/suspend/resume if
> HCTOSYS config is enabled, that's why I came up with the patches.

Ah, I see, there is some duplication here, my earlier comments about
update_persistent_clock are not quite right, some places like PCs
stick a RTC driver and then continue to access the same hardware
directly outside the rtc driver context! That seems ugly :|

I see the PC CMOS rtc driver does not implement the set_mmss
operation, instead running that code through update_persistent_clock..
That seems like a cleanup waiting to happen.

Regarding your problem - IMHO, it would be fantastic if the class RTC
driver could be used instead of read_persistent_clock on PC.

John mentioned that read_persistent_clock had a requirement to work
with IRQs off - that seems like it would be easy to incorporate into
class rtc - for hardware that supports it (and PC is not the only RTC
HW that can do this) Is that the only reason it still exists on pc?

I have to feel the long term direction should be to remove
*_persistent_clock in favor of class RTC?

> > Maybe Feng would be better off adjusting read_persistent_clock to
> > return ENODEV in such cases??
> 
> For mach's without read_persistent_clock capability, there is already
> a weakly defined 

This is used for arch's without the functionality, mach's are arch
specific things. ARM provides a function pointer indirection for it's
read_persistent_clock implementation.

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/