Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp986511ybn; Wed, 2 Oct 2019 09:09:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqxJ8uW3ui2nPAjnzo8sQ5qdm6BfgMok59axdL7JYqibtLgHn+nVaZIlNQzhCfRF1/KJHBzi X-Received: by 2002:a05:6402:1688:: with SMTP id a8mr4533935edv.225.1570032577149; Wed, 02 Oct 2019 09:09:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570032577; cv=none; d=google.com; s=arc-20160816; b=LWWwZJn+z0JPjehDG3d3DQyBs2TSorDKTK9BaB3i4nelcOhNVuyTsKBkoc5n7vGvME 093bbaejaNHhXrpUVM3jANdzMBGVg+VYufE9Am7r/EOgh5R/x7bQtVPB6i5A5EHv4fsg IcdYcKqS2qlRFQCL9KtdZf7Ed5OBpgeHwps2/0aglnWH5F5KSq1nhinr/+ey8eOtduY7 xf0WCoE2QeDCl5895J1zL307uDwuxyUOKGJ5OcNOxEg5+Ttd8ynpe6yzpIQk2SrEmjXW TEkHFQhqzRfw0vMBcDeA3rV4KnL2pvk9kcDiDiSVPW4YFianE4WpZjY9BBheZu3Nx37M SiAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Cm5y6/ru/C9I2VSusEbg3+NWiE1oNKxKWJ8nI5eVPpE=; b=Jrdh6c8GOWUZAku9MeL/z94CAKMY4AH7mLpDPVOB1yvZ6k5VgYiqryrhn0yjSqxaOG NG0wCiK/QSkX453a5wCY5+8wzoIUIn12D3tLagRduNE2m7PJaM2/isLk6lQeI0jWkjxd 7kp854xkq05x7rguWDVIVqP45Lx+KoGWkVB8a/U6vITbihRj1TMSJeSru457r7987z9b uqi3/yiSwvjaCvXxRyKbXnV0LEqq0rsuhIm5C4cRV0Z1mrRbD85KHshEmMz+jBasBwW4 xHsjx7zX+vWvDaUo/oQ68dnhtcPORAq60CRkq6ZPSwR4RvzFW8Ez9ruNu7H8D4OwRJDP +S0A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=e+HZAJr8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d29si11461077edb.203.2019.10.02.09.09.04; Wed, 02 Oct 2019 09:09:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=e+HZAJr8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728562AbfJBPUs (ORCPT + 99 others); Wed, 2 Oct 2019 11:20:48 -0400 Received: from mail-lf1-f65.google.com ([209.85.167.65]:33202 "EHLO mail-lf1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726708AbfJBPUr (ORCPT ); Wed, 2 Oct 2019 11:20:47 -0400 Received: by mail-lf1-f65.google.com with SMTP id y127so13071147lfc.0 for ; Wed, 02 Oct 2019 08:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cm5y6/ru/C9I2VSusEbg3+NWiE1oNKxKWJ8nI5eVPpE=; b=e+HZAJr8AzekfpjpvDICihE65P2buZXwIBxjnPwoZjUaa8DYIlZ411wS9EH2Wqx+L0 3IIG8qyNstNMWhX7MV1QihCRQKoZXXMGKTs4PWndclmhIsERWI2BlCQHgmm887jK/X4s 4LSh6oyFIbqiC5xhJtc71w2JGJd98PVfXjNlCN6GVR9bIWfwprqsxKpAl4Dh1GDOm4Uf KkFqAdqcObzoSOtmU6zUaXmwXz8h65j2MURhjZuxBvLZTZfX1GtpcYV+ZEof01IIQYYx E0dhPukf1KSSEJqO6kaaFkc1egOnoliejLLs3Culpb7JQAQvhqu/uJ4ixkijBLwVqoor bBdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Cm5y6/ru/C9I2VSusEbg3+NWiE1oNKxKWJ8nI5eVPpE=; b=UPpu/0gMPSFCgbfT8MxI8gFDQIKRR7HGk5wmPjfvkrj5MxhnMAb8x6LETIAzseGLfb mqiNY6DNjs9gslgccp1Gl/g10e3PNl1CKY3V4Qi5C3pLl57KjsVsIxUAqNo3WadgCQr5 5sV24FqXPSyf2RvQxGMfGg2z7QPtrpVHZlzc+pc5pe3gzi6TbTMbaLGCfCo8hx9wi7GG uqy4Srm1lqaMlrg99ar9wZsQW1yowrPQqJTlIFHy64+W7EKT0Q5PKNSAO36NI65JZ04Q wE4drXOe+UDfqwhW+tuP6MZM3sySVvpy/USQuZAYOFJGlS4CzBHNjx+EVPbK2Aw5ipB7 +7hg== X-Gm-Message-State: APjAAAUddh93lhwFli7OVGZAQRH+nyLCC6N/qQ0IJNBGpkNtHBWVRuGX coItZ8RCiLDkNWyTwbSQ8yuHANgIGVJpyg/cdhpCsA== X-Received: by 2002:ac2:4114:: with SMTP id b20mr2720783lfi.19.1570029645385; Wed, 02 Oct 2019 08:20:45 -0700 (PDT) MIME-Version: 1.0 References: <20190925203209.79941-1-ncrews@chromium.org> <20191001195342.GH4106@piout.net> <20191002103236.GM4106@piout.net> In-Reply-To: <20191002103236.GM4106@piout.net> From: Dmitry Torokhov Date: Wed, 2 Oct 2019 08:20:34 -0700 Message-ID: Subject: Re: [PATCH v3] rtc: wilco-ec: Handle reading invalid times To: Alexandre Belloni Cc: Nick Crews , Alessandro Zummo , linux-rtc@vger.kernel.org, lkml , Pavel Machek , enric.balletbo@collabora.com, Benson Leung , dlaurie@chromium.org, Daniel Kurtz Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 2, 2019 at 3:32 AM Alexandre Belloni wrote: > > On 01/10/2019 13:42:24-0700, Dmitry Torokhov wrote: > > On Tue, Oct 1, 2019 at 12:53 PM Alexandre Belloni > > wrote: > > > > > > Hi Nick, > > > > > > On 25/09/2019 14:32:09-0600, Nick Crews wrote: > > > > If the RTC HW returns an invalid time, the rtc_year_days() > > > > call would crash. This patch adds error logging in this > > > > situation, and removes the tm_yday and tm_wday calculations. > > > > These fields should not be relied upon by userspace > > > > according to man rtc, and thus we don't need to calculate > > > > them. > > > > > > > > Signed-off-by: Nick Crews > > > > --- > > > > drivers/rtc/rtc-wilco-ec.c | 13 +++++++++---- > > > > 1 file changed, 9 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/drivers/rtc/rtc-wilco-ec.c b/drivers/rtc/rtc-wilco-ec.c > > > > index 8ad4c4e6d557..53da355d996a 100644 > > > > --- a/drivers/rtc/rtc-wilco-ec.c > > > > +++ b/drivers/rtc/rtc-wilco-ec.c > > > > @@ -110,10 +110,15 @@ static int wilco_ec_rtc_read(struct device *dev, struct rtc_time *tm) > > > > tm->tm_mday = rtc.day; > > > > tm->tm_mon = rtc.month - 1; > > > > tm->tm_year = rtc.year + (rtc.century * 100) - 1900; > > > > - tm->tm_yday = rtc_year_days(tm->tm_mday, tm->tm_mon, tm->tm_year); > > > > - > > > > - /* Don't compute day of week, we don't need it. */ > > > > - tm->tm_wday = -1; > > > > + /* Ignore other tm fields, man rtc says userspace shouldn't use them. */ > > > > + > > > > + if (rtc_valid_tm(tm)) { > > > > + dev_err(dev, > > > > + "Time from RTC is invalid: second=%u, minute=%u, hour=%u, day=%u, month=%u, year=%u, century=%u", > > > > + rtc.second, rtc.minute, rtc.hour, rtc.day, rtc.month, > > > > + rtc.year, rtc.century); > > > > > > Do you mind using %ptR? At this point you already filled the tm struct > > > anyway and if you print century separately, you can infer tm_year. > > > > I do not think this is a good idea: we have just established that tm > > does not contain valid data. Does %ptR guarantee that it handles junk > > better than, let's say, rtc_year_days(), and does not crash when > > presented with garbage? > > > > It is safe to use. You can also use %ptRr if you want to ensure no > extra operations are done on the value before printing them out. OK, I'll keeo this in mind then. > > I'm still not convinced it is useful to have an error in dmesg when the > time is invalid, as long as userspace knows it is invalid. What is the > course of action for the end user when that happens? Report it, or, in our case, we will see it in the feedback logs. However I do agree that it is not the best option, even if we report error to userspace I am not sure if it will handle it properly. What userspace is supposed to do when presented with -EIO or similar? Nick, do we know the root cause of the EC/RTC reporting invalid time? Thanks, Dmitry