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 C7A31ECAAD1 for ; Thu, 1 Sep 2022 11:57:33 +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:Subject:Cc:To:From:Date:References: In-Reply-To:Message-Id:Mime-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ERaaIxUrWf4SflloGMH4qZv6BugrDdxjbJW1YnbMQjI=; b=lD/KVqN2kqOQJ9 DPFGHecGjjy8yepHAzFUYhhslzwTky/6KczQHM3TQ/VHJocWZQJ7GY+YtxOeRE954bOhVetxiyI8n iMchhwKhJt55RM5/Ue2kEqqcIik1RP9wjEJqOI+vpp8/+tFdtKJ+fWPKIYaeQcc732Jos4NjIR35h m08YNOxSo3nO608Ats4UbB+gq2Qr+SxrWAOxz9iwk+D+3dTcMbkHNET/Yg9YVkDygD31XsIdFgKwe Eql5DIFFTReHI5zT8ubsBN+z6OPr2U6oCbdY07Qdcx5rt5ReLTKOFQ40+UoEWSyd7ysEV0X2Pj53c JHvhmT92Kkp3UBN+Drzg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTinr-00BSQm-BC; Thu, 01 Sep 2022 11:56:11 +0000 Received: from wnew2-smtp.messagingengine.com ([64.147.123.27]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTinn-00BSPJ-23 for linux-arm-kernel@lists.infradead.org; Thu, 01 Sep 2022 11:56:09 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.west.internal (Postfix) with ESMTP id 902102B059C9; Thu, 1 Sep 2022 07:56:00 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute3.internal (MEProxy); Thu, 01 Sep 2022 07:56:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1662033360; x=1662036960; bh=3sbMDYljxO k9xBe7KslTLc420jqg6Oa0HlvIQin+QO0=; b=D+N4skTsYPs2un75CZy7UFNeOj bIfgJ2+AjLlcH3RaORKddC3xM4VpWj0pWfYqlx62hd5XQvKcBxGbjaia6dUecjbo XlFMZ9rIKhWWm0P608kGFhjRH0brWsP67QtDzXYHMnuUHEX8sKRyW253CzeGU6iv MVmZ0sQC50ygZpEYFhWbq8jj4bhMNU/Z+s4/+vg8+NtAVnUo0neLfhoJbieJc1SS g4qKAnd4cLHCbxLFWoAyJJcNKZ4P6BWIC9tGnOJA2l4d1iAtUxww7x7Wsgj4fn7s 6q1W83/qoFzW6zyVXKXXDnMr/LGqM3OeLcSzlgAvkNoDNr9u6+l2GIJ45Jqg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= i56a14606.fm1; t=1662033360; x=1662036960; bh=3sbMDYljxOk9xBe7Ks lTLc420jqg6Oa0HlvIQin+QO0=; b=UIgJ3roIlI3Le9lFgXpcVVXtJz+CjgQ0qe hZVO5LnNCRb2PsydgqtxVBKIHKv3y0h+W/kmBh3jK92sHrF1nFd42vm8Dp421Kbg 8iRYynpcDj94EQUF3MO1Y48NblVcBnuKuSFsO9zYNUIKwj6bBcyzmqrSpDZkWqGG GIpzp7vH68i6161rj+Z1WfVB/thkZ/7vxbZcl8lB1noq/tBR5GjQ6Lxu1Lxps/5e hxtjAdTJ3r9D52IHHE49nTAzXyLiu6cPrG9gNneuTprUrZJrZC+zEf04BHff6QCF jlGZpa3LdkFSeXF7JgrAMRYQAbddnguy9PJEgBzKiau7FEh7W6sw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdekkedggeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrfgrth htvghrnhepjedvvddvudeludehjeeitdehheeivdejgfelleffiefgvefhhfeuudfhgeef feehnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrhhnugesrghrnhgusgdruggv X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id A6FECB60083; Thu, 1 Sep 2022 07:55:59 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-841-g7899e99a45-fm-20220811.002-g7899e99a Mime-Version: 1.0 Message-Id: <802ca9c8-4b61-4568-a946-8e6330807eb3@www.fastmail.com> In-Reply-To: References: Date: Thu, 01 Sep 2022 13:55:19 +0200 From: "Arnd Bergmann" To: linux-arm-kernel@lists.infradead.org Cc: "Alexandre Belloni" , y2038@lists.linaro.org Subject: Re: RTC hctosys disabled for 32-bit systems X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220901_045607_628997_21CDD4B1 X-CRM114-Status: GOOD ( 18.63 ) 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 Thu, Sep 1, 2022, at 1:31 PM, Reinier Kuipers wrote: > > I'm working to fix the y2038 issue for an existing sama5d3-based > product. This involves updating the kernel and glibc to appropriate > versions (5.10 and 2.35.1 respectively) and I got things running up to > a state where, from userspace, both date and hwclock commands have no > issue accepting dates beyond 2038. However, even with the RTC_HCTOSYS > and RTC_HCTOSYS_DEVICE options configured correctly, the RTC driver > fails to initialize the system clock at bootup. > > Some digging in rtc/class.c::rtc_hctosys() indicates that > do_settimeofday64() is deliberately not executed on systems with > BITS_PER_LONG==32 and a second counter higher than INT_MAX. I assumed > that the work on 64-bits timestamps was already fully implemented for > 32-bit systems as well, so my gut feel is that this > BITS_PER_LONG/INT_MAX check has become unnecessary. A test build with > these checks disabled results in correct time initialization at bootup > with, at a glance, no adverse effects. Does anybody here know whether > do_settimeofday64() is robust on 32-bit systems or that the checks > are still required to prevent further breakage? Please see commit b3a5ac42ab18 ("rtc: hctosys: Ensure system time doesn't overflow time_t") and https://github.com/systemd/systemd/issues/1143 for the problem that originally caused this to be added. Removing this check would probably break systemd again for machines that return a post-y2038 time with systemd built on 32-bit time_t. The only reliable fix I can see would be to disable CONFIG_RTC_HCTOSYS_DEVICE. I think this is Alexandre's plan for the long run anyway, but I don't know if there has been any progress in convincing distros to turn it off. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel