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 Content-Length: 1577 Lines: 31 > 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.) -- 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/