From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752680AbbLEHR5 (ORCPT ); Sat, 5 Dec 2015 02:17:57 -0500 Received: from mail-vk0-f47.google.com ([209.85.213.47]:35897 "EHLO mail-vk0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752540AbbLEHRz (ORCPT ); Sat, 5 Dec 2015 02:17:55 -0500 MIME-Version: 1.0 In-Reply-To: References: <1449107584-3192-1-git-send-email-jwerner@chromium.org> Date: Fri, 4 Dec 2015 23:17:54 -0800 X-Google-Sender-Auth: WknAq8Y6aKG1sMl5UspM_8bZJwE 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 you set the alarm > for Dec 25th and it's currently Oct 31st then you'll have to adjust in > the alarm code and you'll really set it for Dec 24th. As per above, > we're in S3 (presumably) or have some persistent kernel state so we > know to adjust everything when we wake up (even if we wake up for a > non-alarm reason). How do you deal with the case where you set an alarm in late December, but you then power the system on earlier in December by other means? I think then you couldn't tell if the fix had already been applied? > You'll still get a failure if you set the alarm and then forcibly go > into S5 without software knowledge, then stay in S5 long enough to > cross over Nov 31st without seeing it (but somehow keep the RTC > state). ...but come on, that seems so incredibly rare! :-P I think you could just set it to "November 31st, disabled" at probe time (if it isn't already) and keep it like that indefinitely? I think as long as you don't need to actually use the alarm, that would work fine. Still, with the vast majority of practically existing devices with an RK808 almost constantly connected to some network, I'm not sure if a huge hack-around is really worth it here. (I guess we could still just do the S3 thing which is much less complicated, assuming we can guarantee correct identification.) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com. [2607:f8b0:400c:c05::229]) by gmr-mx.google.com with ESMTPS id g91si870054vki.3.2015.12.04.23.17.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Dec 2015 23:17:54 -0800 (PST) Received: by vkca188 with SMTP id a188so78840129vkc.0 for ; Fri, 04 Dec 2015 23:17:54 -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 23:17:54 -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 you set the alarm > for Dec 25th and it's currently Oct 31st then you'll have to adjust in > the alarm code and you'll really set it for Dec 24th. As per above, > we're in S3 (presumably) or have some persistent kernel state so we > know to adjust everything when we wake up (even if we wake up for a > non-alarm reason). How do you deal with the case where you set an alarm in late December, but you then power the system on earlier in December by other means? I think then you couldn't tell if the fix had already been applied? > You'll still get a failure if you set the alarm and then forcibly go > into S5 without software knowledge, then stay in S5 long enough to > cross over Nov 31st without seeing it (but somehow keep the RTC > state). ...but come on, that seems so incredibly rare! :-P I think you could just set it to "November 31st, disabled" at probe time (if it isn't already) and keep it like that indefinitely? I think as long as you don't need to actually use the alarm, that would work fine. Still, with the vast majority of practically existing devices with an RK808 almost constantly connected to some network, I'm not sure if a huge hack-around is really worth it here. (I guess we could still just do the S3 thing which is much less complicated, assuming we can guarantee correct identification.) -- -- 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.