Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp812313pxb; Fri, 22 Apr 2022 11:41:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz74lCOIS0V6lEKYSPSdVwhsmmmmi3hyyESPPbtGpVOPy2gBefwjq0gQkPYYZIuvzFg0v9y X-Received: by 2002:a05:6a00:330a:b0:50a:cac1:7986 with SMTP id cq10-20020a056a00330a00b0050acac17986mr6379672pfb.4.1650652893682; Fri, 22 Apr 2022 11:41:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650652893; cv=none; d=google.com; s=arc-20160816; b=YpXWMp90+4TafJlo+4bQhfEojaQN27b0WCBxgS6Q4ZrTqxNVmovx2uOejXYDAL9lZt YFDhZPd82vl/SMPJalEhBhLrO32Mnc8dowZjd49wINd/p0xUJ/V2irSENkIEwWCn89J5 Hpd+XdgCIy8m8BXOKnRqFdTiZLz54abHoUQqvq5E0jD4ZYss/BWCwNikfGcLqwx2JnhF 6FrWNUSMx/SIIFcrZx3WIc8XQxVoNPgGViMCyIYnjEOuJ4shmlgz1tS615dZ3W765kol ZS8qG9fBQLVL9MDXJ5KJ5aTcWIQA1rCiwpA+MkzcZMeSrJdmd5AlKP8z2aujO7oXj1HF 4G5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=2/sM7JIlJ22t5YJpvU1AanN1CBxO4H/7QJWPjO4nc4E=; b=AxlKUgLlQky77ELxfXr4aqsyMKdCNlfc+h8wTMgHGJKtHLNY3QOyG0VkDuPw1Ei4kP XyENnK0YKSWHguv+ckIt4PSmRii1gibmlgzq8TdJOccZN39UZBYQaEGHmpthQ1WXQDQ1 DqFC9AV4vVKW533VktiEslRUHQOODNlHR0QWBz8gXSxgMNCQzgKTaNLSc/szY1c03Bgr /SSgHNMCL61SyaaNwpQKbNS8xNa31nof5Inf+fphRHIFZ+couyb/iKB7h/hOKkH3pday LTA+jCAndn1Nuw6Y1Uqm8mda+CZnPRf0Wo2R7prkw37M05OXqFEzuOZqJPfp7znry4tt Hhrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@o2.pl header.s=1024a header.b=VpQvY0W+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=o2.pl Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id l17-20020a170903121100b001583ec38334si9894883plh.533.2022.04.22.11.41.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 11:41:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@o2.pl header.s=1024a header.b=VpQvY0W+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=o2.pl Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D12001023CD; Fri, 22 Apr 2022 11:10:33 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1391659AbiDUT22 (ORCPT + 99 others); Thu, 21 Apr 2022 15:28:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37516 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1390623AbiDUT2Y (ORCPT ); Thu, 21 Apr 2022 15:28:24 -0400 Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E4B794CD61 for ; Thu, 21 Apr 2022 12:25:32 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 15717 invoked from network); 21 Apr 2022 21:25:26 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=o2.pl; s=1024a; t=1650569127; bh=2/sM7JIlJ22t5YJpvU1AanN1CBxO4H/7QJWPjO4nc4E=; h=From:To:Cc:Subject; b=VpQvY0W+2fHhiExPDX8Sqi4QUsnB61zqHO7sZvJCRzteLAmueqEkok8D0IV2niazZ MS0USbQu7Rj7ifkb7EULGcm+NKf9iXaVYWi4b2aOJcv/9+kk0PF3H/U2cS//Nz528I rTX+eRgQuK2bDK8h9bF4aaAuCbRXgqIVujjau4iQ= Received: from aafl13.neoplus.adsl.tpnet.pl (HELO localhost.localdomain) (mat.jonczyk@o2.pl@[83.4.141.13]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with SMTP for ; 21 Apr 2022 21:25:26 +0200 From: =?UTF-8?q?Mateusz=20Jo=C5=84czyk?= To: linux-kernel@vger.kernel.org, linux-rtc@vger.kernel.org Cc: =?UTF-8?q?Mateusz=20Jo=C5=84czyk?= , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Alessandro Zummo , Alexandre Belloni , Prarit Bhargava Subject: [PATCH v2 1/2] x86/rtc: rewrite mach_get_cmos_time to delete duplicated code Date: Thu, 21 Apr 2022 21:24:48 +0200 Message-Id: <20220421192449.11004-2-mat.jonczyk@o2.pl> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220421192449.11004-1-mat.jonczyk@o2.pl> References: <20220421192449.11004-1-mat.jonczyk@o2.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-WP-MailID: a7ff3857cd10bf8eceb9c703480a15c9 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [kQNk] X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org There are functions in drivers/rtc/rtc-mc146818-lib.c that handle reading from / writing to the CMOS RTC clock. mach_get_cmos_time() in arch/x86/kernel/rtc.c did not use them and was mostly a duplicate of mc146818_get_time(). Modify mach_get_cmos_time() to use mc146818_get_time() and remove the duplicated code. As a bonus, mach_get_cmos_time() after the modification does not hang indefinitely if the CMOS RTC is not present. mach_get_cmos_time() used a different algorithm than mc146818_get_time(), but these functions are equivalent. The major differences were: - mc146818_get_time() is better refined: it was updated in commit 05a0302c3548 ("rtc: mc146818: Prevent reading garbage") to take account of various edge conditions, - when the UIP ("Update in progress") bit of the RTC is set, mach_get_cmos_time() was busy waiting with cpu_relax() while mc146818_get_time() is now using mdelay(1) in every loop iteration, - mach_get_cmos_time() assumed that the RTC year must be >= 2000, which may not be true on some old boxes with a dead battery, - mach_get_cmos_time() was holding the rtc_lock for a long time. The RTC writing counterpart, mach_set_rtc_mmss() is already using mc146818_get_time() from drivers/rtc. This was done in commit 3195ef59cb42 ("x86: Do full rtc synchronization with ntp") It appears that mach_get_cmos_time() was simply forgotten. mach_get_cmos_time() is really used only in read_persistent_clock64(), which is called only in a few places in kernel/time/timekeeping.c . Signed-off-by: Mateusz Jończyk Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: x86@kernel.org Cc: "H. Peter Anvin" Cc: Alessandro Zummo Cc: Alexandre Belloni Cc: Prarit Bhargava --- v2: - use pr_err() in place of pr_err_ratelimited(). mach_get_cmos_time() is not called frequently, so ratelimiting is not necessary. - tweak commit description. arch/x86/kernel/rtc.c | 59 +++++-------------------------------------- 1 file changed, 7 insertions(+), 52 deletions(-) diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c index 586f718b8e95..1cadc8a15267 100644 --- a/arch/x86/kernel/rtc.c +++ b/arch/x86/kernel/rtc.c @@ -4,11 +4,8 @@ */ #include #include -#include -#include #include #include -#include #include #include @@ -20,15 +17,12 @@ /* * This is a special lock that is owned by the CPU and holds the index * register we are working with. It is required for NMI access to the - * CMOS/RTC registers. See include/asm-i386/mc146818rtc.h for details. + * CMOS/RTC registers. See arch/x86/include/asm/mc146818rtc.h for details. */ volatile unsigned long cmos_lock; EXPORT_SYMBOL(cmos_lock); #endif /* CONFIG_X86_32 */ -/* For two digit years assume time is always after that */ -#define CMOS_YEARS_OFFS 2000 - DEFINE_SPINLOCK(rtc_lock); EXPORT_SYMBOL(rtc_lock); @@ -62,8 +56,7 @@ int mach_set_rtc_mmss(const struct timespec64 *now) void mach_get_cmos_time(struct timespec64 *now) { - unsigned int status, year, mon, day, hour, min, sec, century = 0; - unsigned long flags; + struct rtc_time tm; /* * If pm_trace abused the RTC as storage, set the timespec to 0, @@ -74,51 +67,13 @@ void mach_get_cmos_time(struct timespec64 *now) return; } - spin_lock_irqsave(&rtc_lock, flags); - - /* - * If UIP is clear, then we have >= 244 microseconds before - * RTC registers will be updated. Spec sheet says that this - * is the reliable way to read RTC - registers. If UIP is set - * then the register access might be invalid. - */ - while ((CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP)) - cpu_relax(); - - sec = CMOS_READ(RTC_SECONDS); - min = CMOS_READ(RTC_MINUTES); - hour = CMOS_READ(RTC_HOURS); - day = CMOS_READ(RTC_DAY_OF_MONTH); - mon = CMOS_READ(RTC_MONTH); - year = CMOS_READ(RTC_YEAR); - -#ifdef CONFIG_ACPI - if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID && - acpi_gbl_FADT.century) - century = CMOS_READ(acpi_gbl_FADT.century); -#endif - - status = CMOS_READ(RTC_CONTROL); - WARN_ON_ONCE(RTC_ALWAYS_BCD && (status & RTC_DM_BINARY)); - - spin_unlock_irqrestore(&rtc_lock, flags); - - if (RTC_ALWAYS_BCD || !(status & RTC_DM_BINARY)) { - sec = bcd2bin(sec); - min = bcd2bin(min); - hour = bcd2bin(hour); - day = bcd2bin(day); - mon = bcd2bin(mon); - year = bcd2bin(year); + if (mc146818_get_time(&tm)) { + pr_err("Unable to read current time from RTC\n"); + now->tv_sec = now->tv_nsec = 0; + return; } - if (century) { - century = bcd2bin(century); - year += century * 100; - } else - year += CMOS_YEARS_OFFS; - - now->tv_sec = mktime64(year, mon, day, hour, min, sec); + now->tv_sec = rtc_tm_to_time64(&tm); now->tv_nsec = 0; } -- 2.25.1