linux-kernel - Re: [PATCH 2/3 v2] RFC: timekeeping: rtc: Introduce new kernel parameter hctosys

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: <51BA1FF7.4000206@ahsoftware.de>
Date:	Thu, 13 Jun 2013 21:39:35 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Alexander Holler <holler@...oftware.de>
CC:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	John Stultz <john.stultz@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	rtc-linux@...glegroups.com
Subject: Re: [PATCH 2/3 v2] RFC: timekeeping: rtc: Introduce new kernel parameter
 hctosys

Am 06.06.2013 12:51, schrieb Alexander Holler:
> hctosys= specifies the driver (RTC) name which sets the system clock at
> boot, if and only if userspace hasn't set the time before the driver will
> be loaded.
>
> If hctosys will not be specified, the first available hardware clock
> with a valid time will be used (again, if and only if ...).
>
> If you don't want that the system clock will be set by any hardware clock,
> just specify a non-existent RTC driver name, e.g. with hctosys=none.
>
> Currently there exist a special name "persistent" for the persistent clock
> found on some systems (e.g. the CMOS clock on x86 platforms which might be
> handled by the driver named rtc_cmos too).
>
> This will replace the existent driver/mechanism hctosys and the kernel
> config options CONFIG_RTC_HCTOSYS and CONFIG_RTC_HCTOSYS_DEVICE (done
> with one of the following patches)
>
> Signed-off-by: Alexander Holler <holler@...oftware.de>

While implementing support for high resolution (read-only) clocks (e.g. 
radio or GPS) for the new hctosys, I've found another bug in my (quickly 
done) RFC hctosys implementation.

Instead of posting the whole patch or the whole series again, here is 
the small diff which should be added to patch2/3:

----------
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 49dd97c..e101468 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -795,7 +795,7 @@ void __init timekeeping_init(void)
         struct timekeeper *tk = &timekeeper;
         struct clocksource *clock;
         unsigned long flags;
-       struct timespec now, boot, tmp;
+       struct timespec now = {0, 0}, boot, tmp;

         if (!hctosys_name[0] || !strcasecmp(hctosys_name, "persistent")) {
                 read_persistent_clock(&now);
----------

I now have 4 additional patches here:

rtc: rtc-hid-sensor-time: delay registering as rtc into a work
rtc: implement rtc_read_timeval()
rtc: hctosys: support rtc_read_timeval() for high precision clocks
rtc: rtc-hid-sensor-time: add support for rtc_read_timeval()

The first oatch is necessary because registering a rtc wants to read the 
clock (for hctosys) and in case of the HID RTC this only works after the 
HID device is actually registered. Therefor registering should not 
happen in probe().

The other 3 new patches do add a read_timeval to rtc_ops and use it, if 
available, instead of read_time to retrieve and set the system clock 
with hctosys using a higher precision timestamp (us).

I requested, I will post the whole series or the just the 
additional/fixed patches.

Regards,

Alexander Holler

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