From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932237AbbLEA0D (ORCPT ); Fri, 4 Dec 2015 19:26:03 -0500 Received: from mail-vk0-f48.google.com ([209.85.213.48]:36733 "EHLO mail-vk0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755333AbbLEAZ7 (ORCPT ); Fri, 4 Dec 2015 19:25:59 -0500 MIME-Version: 1.0 In-Reply-To: References: <1449107584-3192-1-git-send-email-jwerner@chromium.org> Date: Fri, 4 Dec 2015 16:25:58 -0800 X-Google-Sender-Auth: KEiktigbk5GCNa75TA7jsgOq0dM Message-ID: Subject: Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st From: Julius Werner To: Doug Anderson Cc: Julius Werner , Andrew Morton , Alessandro Zummo , Sonny Rao , Chris Zhong , Heiko Stuebner , "linux-kernel@vger.kernel.org" , rtc-linux@googlegroups.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > If a device is in S3 for the whole day that the glitch occurs and then > we wake up then we'll end up thinking it's Dec 1st instead of Dec 2nd, > right? That case _could_ be handled by knowing that the last time we > read the clock it was before 12/1 and that this time it is after > 11/30. Then we add the extra day. In order to do this, we'd have to > know that we're on hardware with the glitch, which I guess could > either be done with a device tree property or by spending 1 second > probing the device at bootup (that would be a bit of a pain...). > > Obviously the trick above wouldn't handle if the clock ticked when the > device was in S5, but I'd imagine that most systems treat the RTC as > slightly questionable on an initial bootup anyway (though I'd imagine > that they rely on it working across S3). True, we could do that. I don't think it makes much sense to differentiate between S3 and S5 like that, though... the problem can happen just the same after both, and I don't think there's a practical difference in how systems treat that (if userspace has ways to double-check the system time, such as syncing to a network time source, it should really be doing that after both resume and reboot). Of course, building a work-around like that for S5 will become more complicated and requires persistent storage. For Chromium OS, we're already planning to improve tlsdated such that I don't think this will be an issue anymore (making it schedule a resync after resume, not just after reboot, which is a probably a good idea in general). For other systems that don't have any kind of network time sync, I think the best solution would be to handle this completely with a small userspace hook on boot and resume (because you probably need to access the file system to keep track of the last seen time anyway, you can do the device identification through /proc/device-tree just as well, and this avoids putting too much hacky workaround logic into the kernel). The other thing that would worry me about this approach is that it requires perfect identification of the problem, and Rockchip will hopefully eventually be able to fix this either in RK808 or a successor chip that might use the same RTC interface (and thus driver). Detecting it at boot is probably a bad idea because a crash/brownout at the wrong moment will permanently leave you with a bad time. I really think fixing this as best as we easily can and leaving the hard edge-cases to userspace is the best approach here. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com. [2607:f8b0:400c:c05::22a]) by gmr-mx.google.com with ESMTPS id 65si799804vkc.1.2015.12.04.16.25.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Dec 2015 16:25:59 -0800 (PST) Received: by vkbs1 with SMTP id s1so75489167vkb.1 for ; Fri, 04 Dec 2015 16:25:59 -0800 (PST) MIME-Version: 1.0 Sender: rtc-linux@googlegroups.com In-Reply-To: References: <1449107584-3192-1-git-send-email-jwerner@chromium.org> Date: Fri, 4 Dec 2015 16:25:58 -0800 Message-ID: Subject: [rtc-linux] Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st From: Julius Werner To: Doug Anderson Cc: Julius Werner , Andrew Morton , Alessandro Zummo , Sonny Rao , Chris Zhong , Heiko Stuebner , "linux-kernel@vger.kernel.org" , rtc-linux@googlegroups.com Content-Type: text/plain; charset=UTF-8 Reply-To: rtc-linux@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , > If a device is in S3 for the whole day that the glitch occurs and then > we wake up then we'll end up thinking it's Dec 1st instead of Dec 2nd, > right? That case _could_ be handled by knowing that the last time we > read the clock it was before 12/1 and that this time it is after > 11/30. Then we add the extra day. In order to do this, we'd have to > know that we're on hardware with the glitch, which I guess could > either be done with a device tree property or by spending 1 second > probing the device at bootup (that would be a bit of a pain...). > > Obviously the trick above wouldn't handle if the clock ticked when the > device was in S5, but I'd imagine that most systems treat the RTC as > slightly questionable on an initial bootup anyway (though I'd imagine > that they rely on it working across S3). True, we could do that. I don't think it makes much sense to differentiate between S3 and S5 like that, though... the problem can happen just the same after both, and I don't think there's a practical difference in how systems treat that (if userspace has ways to double-check the system time, such as syncing to a network time source, it should really be doing that after both resume and reboot). Of course, building a work-around like that for S5 will become more complicated and requires persistent storage. For Chromium OS, we're already planning to improve tlsdated such that I don't think this will be an issue anymore (making it schedule a resync after resume, not just after reboot, which is a probably a good idea in general). For other systems that don't have any kind of network time sync, I think the best solution would be to handle this completely with a small userspace hook on boot and resume (because you probably need to access the file system to keep track of the last seen time anyway, you can do the device identification through /proc/device-tree just as well, and this avoids putting too much hacky workaround logic into the kernel). The other thing that would worry me about this approach is that it requires perfect identification of the problem, and Rockchip will hopefully eventually be able to fix this either in RK808 or a successor chip that might use the same RTC interface (and thus driver). Detecting it at boot is probably a bad idea because a crash/brownout at the wrong moment will permanently leave you with a bad time. I really think fixing this as best as we easily can and leaving the hard edge-cases to userspace is the best approach here. -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.