From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 624B9ECAAD2 for ; Thu, 1 Sep 2022 21:12:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=+xmsNx+DMDuaw7lgaaSyHEKo/8Dm3iX9qG4bHofJ9C4=; b=p/+THFYNG7PBRr ipuReyk8VhQwStl/pVZsd1UugQhNWCrcrnzwPfOkD/PwQHfhI3CGLDsLNDBoU5QzO+TDqa3aUHuZR NlUCxcLzrQPD93JJZuh9Ws8ZQv2zOcZ6jGYKZqHugPgXdBkEcUlKQqM3Z5xULNSxWPS8JsDbrfXBI +F60zOqMmByQfzLqshkWgJHypWkdgd3ZmbEKF91/VQaU09SAb9KqZKwISan8zst4hSfZoD2oDQGcU EpLrI7wxSgWsCrpzgFVD1VQU7r0pVQ3BiK3dqzFDtXUwfv0FcuRzpDj3m46b8za/oORQ0KbIvNqyp Ggl9IgYh9dYkVo3YOyhQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTrSx-00EqWb-F2; Thu, 01 Sep 2022 21:11:11 +0000 Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTrSt-00EqUc-Hd for linux-arm-kernel@lists.infradead.org; Thu, 01 Sep 2022 21:11:09 +0000 Received: (Authenticated sender: alexandre.belloni@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id D7891C0008; Thu, 1 Sep 2022 21:11:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1662066663; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=BH94D9a7MPaeXelkKvBDdSNwMiN/qCgZ5sR6QgHncCw=; b=pEozU+CBcUxfwJVRP7O5eZBcWD6aGfKdxs2PXeic+NAijQYriBY6dxsAcEF93sJ2WYd7sH +hln0DZRORtAR2is7Azt8D2BwRtDF6unnp8jB/lO6Erev+aaXV4MRu8NdM1TyGbfLPzRck TRs+oR2ya0nD+lZu4/EhwFq2hr/44YFj1kqrTzXUL547DHYNHhHOj81JTS2uWOBfn6IaWm JL4wmo+aVDtTYFp+dt2+wiDDDV7kCu2wIqiJD4X5GiyMs9g9jNstC6TqZJwHHDLrv7u7iy C5K58P4fCY6c85cxJ+bJX9ATfq0pwr5VNgyPDY0+sEru5o7WD5gKZXKsVt2l6w== Date: Thu, 1 Sep 2022 23:11:02 +0200 From: Alexandre Belloni To: Arnd Bergmann Cc: Russell King , linux-arm-kernel@lists.infradead.org, y2038@lists.linaro.org, Reinier Kuipers Subject: Re: [Y2038] Re: RTC hctosys disabled for 32-bit systems Message-ID: References: <802ca9c8-4b61-4568-a946-8e6330807eb3@www.fastmail.com> <8eca48d9-bd10-4857-9e43-a5b20a8db625@www.fastmail.com> <511f86d8-eadf-40ba-9f0c-022cc4d251fb@www.fastmail.com> <316a07b5-bfd6-480f-b5a3-2d5fc9991252@www.fastmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <316a07b5-bfd6-480f-b5a3-2d5fc9991252@www.fastmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220901_141107_919921_C871FE8F X-CRM114-Status: GOOD ( 34.57 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 01/09/2022 22:33:46+0200, Arnd Bergmann wrote: > On Thu, Sep 1, 2022, at 6:02 PM, Russell King (Oracle) wrote: > > On Thu, Sep 01, 2022 at 05:48:01PM +0200, Arnd Bergmann wrote: > > > >> I think the systems that can send the timekeeping back into the early > >> 1900s (or at least after 1970) are fine, the problem is the systems > >> that can randomly send the timekeeping into the post-2038 future. > > > > I believe Armada 388 systems can do that - and since Armada 388 systems > > are involved in my connectivity, I would very much prefer it if someone > > doesn't patch stuff that causes them to explode when I decide to > > upgrade the kernel. > > > > (Yes, I've run into the broken systemd issue with them when the RTC > > was not correctly set on platform delivery.) > > Ok, good to know. I wonder if this patch would be sufficient for > this particular driver: > I'm pretty sure we don't want to play whack-a-mole with all the drivers, especially with those for RTCs that are available on both 32b and 64b systems. > diff --git a/drivers/rtc/rtc-armada38x.c b/drivers/rtc/rtc-armada38x.c > index cc542e6b1d5b..f2bbb8efed18 100644 > --- a/drivers/rtc/rtc-armada38x.c > +++ b/drivers/rtc/rtc-armada38x.c > @@ -219,7 +219,7 @@ static int armada38x_rtc_read_time(struct device *dev, struct rtc_time *tm) > time = rtc->data->read_rtc_reg(rtc, RTC_TIME); > spin_unlock_irqrestore(&rtc->lock, flags); > > - rtc_time64_to_tm(time, tm); > + rtc_time64_to_tm((s32)time, tm); You may as well just clamp the value here, the RTC subsystem specifically considers a timestamp to be positive and this is why it is not affected by y2038 with 32bit second counters. > > return 0; > } > @@ -541,7 +541,8 @@ static __init int armada38x_rtc_probe(struct platform_device *pdev) > rtc->data->update_mbus_timing(rtc); > > rtc->rtc_dev->ops = &armada38x_rtc_ops; > - rtc->rtc_dev->range_max = U32_MAX; > + rtc->rtc_dev->range_min = S32_MIN; > + rtc->rtc_dev->range_max = S32_MAX; > > return devm_rtc_register_device(rtc->rtc_dev); > } > > The effect of this is to interpret the RTC values as range > 1902...2038 instead of 1970...2106, which should make > systemd not crash any more on random input, but have no > other side-effects within the 1970...2038 range. > > Users that care about running systems beyond 2038 and > run a time64 userland can then set the wrap-around point > in DT e.g. to 2022...2156 using the 'start-year=<2022>;' > property, or any other value they like. If we can do the > equivalent for all RTC drivers that may suffer from the > same problem, the HCTOSYS hack for the S32_MAX value > can just get removed. > > Arnd > > [I accidentally dropped Rainier from Cc, adding him back now. For > reference, the other mail are archived at > https://lore.kernel.org/linux-arm-kernel/CAKYb531CyL8XRVRcRN30cC3xRgsd-1FzXUeS7o2LiZqALJ42qw@mail.gmail.com/] -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel