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 Content-Length: 2750 Lines: 47 > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/