[BUG] RTC warning after "rtc: mc146818: Detect and handle broken RTCs"

[BUG] RTC warning after "rtc: mc146818: Detect and handle broken RTCs"

[Mateusz Jończyk]

Hello,

On one of our home computers, the Linux RTC code since Linux 5.11 prints a warning message
with a stacktrace in mc146818_get_time():

[    0.351685] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.351685] futex hash table entries: 2048 (order: 5, 131072 bytes, linear)
[    0.351685] pinctrl core: initialized pinctrl subsystem
[    0.351685] ------------[ cut here ]------------
[    0.351685] WARNING: CPU: 0 PID: 1 at drivers/rtc/rtc-mc146818-lib.c:25 mc146818_get_time+0x1d5/0x230
[    0.351685] Modules linked in:
[    0.351685] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.11.0newdeb-mj4 #12
[    0.351685] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./A780GXH/128M, BIOS P1.70 05/14/2010
[    0.351685] RIP: 0010:mc146818_get_time+0x1d5/0x230
[    0.351685] Code: 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 4c 89 e6 48 c7 c7 b0 87 56 8f e8 6a 9e 2a 00 bf 58 89 41 00 e8 30 f8 d4 ff e9 43 fe ff ff <0f> 0b 48 c7 c7 b0 87 56 8f 4c 89 e6 e8 4a 9e 2a 00 48 c7 03 ff ff
[    0.351685] RSP: 0018:ffffb618c001fda8 EFLAGS: 00010002
[    0.351685] RAX: 00000000000000c0 RBX: ffffb618c001fde4 RCX: 0000000000000000
[    0.351685] RDX: 0000000000000001 RSI: ffff9378c0456940 RDI: 000000000000000d
[    0.351685] RBP: ffffb618c001fdd0 R08: ffff9378c0405b60 R09: 0000000000000000
[    0.351685] R10: 0000000000000000 R11: 605640c07893ffff R12: 0000000000000246
[    0.351685] R13: 0000000000000000 R14: ffffffff8f54f390 R15: 0000000000000000
[    0.351685] FS:  0000000000000000(0000) GS:ffff9379d8000000(0000) knlGS:0000000000000000
[    0.351685] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.351685] CR2: 0000000000000000 CR3: 0000000132810000 CR4: 00000000000006f0
[    0.351685] Call Trace:
[    0.351685]  ? wakeup_sources_sysfs_init+0x35/0x35
[    0.351685]  early_resume_init+0x25/0x9c
[    0.351685]  ? cn_proc_init+0x3f/0x3f
[    0.351685]  do_one_initcall+0x48/0x1d0
[    0.351685]  kernel_init_freeable+0x1dc/0x23a
[    0.351685]  ? rest_init+0xba/0xba
[    0.351685]  kernel_init+0xe/0x116
[    0.351685]  ret_from_fork+0x22/0x30
[    0.351685] ---[ end trace b30828ec3a66c652 ]---
[    0.351685] PM: RTC time: 18446744073709551615:18446744073709551615:18446744073709551615, date: 1899-00-18446744073709551615
[    0.351685] NET: Registered protocol family 16

This happens every boot on affected kernels. Surprisingly, it appears that the local
clock gets synchronized from the RTC code nonetheless.

I have isolated the issue to the following commit:

commit 211e5db19d15a721b2953ea54b8f26c2963720eb
Author: Thomas Gleixner<tglx@linutronix.de>
Date:   Tue Jan 26 18:02:11 2021 +0100

     rtc: mc146818: Detect and handle broken RTCs

which was modified later by commit ebb22a05943666155e6da04407cc6e913974c78c
     rtc: mc146818: Dont test for bit 0-5 in Register D

After reverting both commits on top of Linux 5.11, the warning disappears.

The sum of these commits causes Linux kernel to check whether bit 6 in CMOS
register 0x0D is unset and abort otherwise.

This computer is a desktop with an ASRock A780GXH/128M motherboard and
an AMD SB710 southbridge. The southbridge datasheet:
https://developer.amd.com/wordpress/media/2012/10/43009_sb7xx_rrg_pub_1.00.pdf
specifies (page 308) that bit 6 of register 0x0D is a scratchbit.
Apparently, something had set it to 1.

Reading CMOS register 0x0d with a test patch consistently returns 0xc0, even
when it is done multiple times consecutively.

Everything was tested on Ubuntu 20.04.

Greetings,
Mateusz Jończyk

Re: [BUG] RTC warning after "rtc: mc146818: Detect and handle broken RTCs"

[Mateusz Jończyk]

Last thought:

Instead of checking for bit 6 in the CMOS register 0x0d, it could be
better to check if the hours register (CMOS register 0x04)
contains a sane value (lower then 25). If it contained 0xff,
something would be strange.

Also the stacktrace below should be sanely formatted:

W dniu 01.07.2021 o 19:34, Mateusz Jończyk pisze:

> Hello,
> On one of our home computers, the Linux RTC code since Linux 5.11 prints a warning message
> with a stacktrace in mc146818_get_time():
> [    0.351685] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
> [    0.351685] futex hash table entries: 2048 (order: 5, 131072 bytes, linear)
> [    0.351685] pinctrl core: initialized pinctrl subsystem
> [    0.351685] ------------[ cut here ]------------
> [    0.351685] WARNING: CPU: 0 PID: 1 at drivers/rtc/rtc-mc146818-lib.c:25 mc146818_get_time+0x1d5/0x230
> [    0.351685] Modules linked in:
> [    0.351685] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.11.0newdeb-mj4 #12
> [    0.351685] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./A780GXH/128M, BIOS P1.70 05/14/2010
> [    0.351685] RIP: 0010:mc146818_get_time+0x1d5/0x230
> [    0.351685] Code: 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 4c 89 e6 48 c7 c7 b0 87 56 8f e8 6a 9e 2a 00 bf 58 89 41 00 e8 30 f8 d4 ff e9 43 fe ff ff <0f> 0b 48 c7 c7 b0 87 56 8f 4c 89 e6 e8 4a 9e 2a 00 48 c7 03 ff ff
> [    0.351685] RSP: 0018:ffffb618c001fda8 EFLAGS: 00010002
> [    0.351685] RAX: 00000000000000c0 RBX: ffffb618c001fde4 RCX: 0000000000000000
> [    0.351685] RDX: 0000000000000001 RSI: ffff9378c0456940 RDI: 000000000000000d
> [    0.351685] RBP: ffffb618c001fdd0 R08: ffff9378c0405b60 R09: 0000000000000000
> [    0.351685] R10: 0000000000000000 R11: 605640c07893ffff R12: 0000000000000246
> [    0.351685] R13: 0000000000000000 R14: ffffffff8f54f390 R15: 0000000000000000
> [    0.351685] FS:  0000000000000000(0000) GS:ffff9379d8000000(0000) knlGS:0000000000000000
> [    0.351685] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    0.351685] CR2: 0000000000000000 CR3: 0000000132810000 CR4: 00000000000006f0
> [    0.351685] Call Trace:
> [    0.351685]  ? wakeup_sources_sysfs_init+0x35/0x35
> [    0.351685]  early_resume_init+0x25/0x9c
> [    0.351685]  ? cn_proc_init+0x3f/0x3f
> [    0.351685]  do_one_initcall+0x48/0x1d0
> [    0.351685]  kernel_init_freeable+0x1dc/0x23a
> [    0.351685]  ? rest_init+0xba/0xba
> [    0.351685]  kernel_init+0xe/0x116
> [    0.351685]  ret_from_fork+0x22/0x30
> [    0.351685] ---[ end trace b30828ec3a66c652 ]---
> [    0.351685] PM: RTC time: 18446744073709551615:18446744073709551615:18446744073709551615, date: 1899-00-18446744073709551615
> [    0.351685] NET: Registered protocol family 16
> This happens every boot on affected kernels. Surprisingly, it appears that the local
> clock gets synchronized from the RTC code nonetheless.
> I have isolated the issue to the following commit:
> commit 211e5db19d15a721b2953ea54b8f26c2963720eb
> Author: Thomas Gleixner<tglx@linutronix.de>
> Date:   Tue Jan 26 18:02:11 2021 +0100
>      rtc: mc146818: Detect and handle broken RTCs
> which was modified later by commit ebb22a05943666155e6da04407cc6e913974c78c
>      rtc: mc146818: Dont test for bit 0-5 in Register D
> After reverting both commits on top of Linux 5.11, the warning disappears.
> The sum of these commits causes Linux kernel to check whether bit 6 in CMOS
> register 0x0D is unset and abort otherwise.
> This computer is a desktop with an ASRock A780GXH/128M motherboard and
> an AMD SB710 southbridge. The southbridge datasheet:
> https://developer.amd.com/wordpress/media/2012/10/43009_sb7xx_rrg_pub_1.00.pdf
> specifies (page 308) that bit 6 of register 0x0D is a scratchbit.
> Apparently, something had set it to 1.
> Reading CMOS register 0x0d with a test patch consistently returns 0xc0, even
> when it is done multiple times consecutively.
> Everything was tested on Ubuntu 20.04.
> Greetings,
> Mateusz Jończyk

[PATCH] rtc: mc146818: Use hours for checking RTC availability

[Mateusz Jończyk]

To prevent an infinite loop, it is necessary to ascertain the RTC is
present. Previous code was checking if bit 6 in register 0x0D is
cleared. This caused a false negative on a motherboard with an AMD SB710
southbridge; according to the specification [1], bit 6 of register 0x0D
on this chipset is a scratchbit.

Use the RTC_HOURS register instead, which is expected to contain a value
not larger then 24, in BCD format.

Caveat: when I was playing with
        while true; do cat /sys/class/rtc/rtc0/time; done
I sometimes triggered this mechanism on my HP laptop. It appears that
CMOS_READ(RTC_VALID) was sometimes reading the number of seconds from
previous loop iteration. This happens very rarely, though, and this patch
does not make it any more likely.

[1] AMD SB700/710/750 Register Reference Guide, page 308,
https://developer.amd.com/wordpress/media/2012/10/43009_sb7xx_rrg_pub_1.00.pdf

Fixes: 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs")
Fixes: ebb22a059436 ("rtc: mc146818: Dont test for bit 0-5 in Register D")
Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: stable@vger.kernel.org
---
 drivers/rtc/rtc-cmos.c         |  6 +++---
 drivers/rtc/rtc-mc146818-lib.c | 10 ++++++++--
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 670fd8a2970e..b0102fb31b3f 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -798,10 +798,10 @@ cmos_do_probe(struct device *dev, struct resource *ports, int rtc_irq)
 
 	spin_lock_irq(&rtc_lock);
 
-	/* Ensure that the RTC is accessible. Bit 6 must be 0! */
-	if ((CMOS_READ(RTC_VALID) & 0x40) != 0) {
+	/* Ensure that the RTC is accessible (RTC_HOURS is in BCD format) */
+	if (CMOS_READ(RTC_HOURS) > 0x24) {
 		spin_unlock_irq(&rtc_lock);
-		dev_warn(dev, "not accessible\n");
+		dev_warn(dev, "not accessible or not working correctly\n");
 		retval = -ENXIO;
 		goto cleanup1;
 	}
diff --git a/drivers/rtc/rtc-mc146818-lib.c b/drivers/rtc/rtc-mc146818-lib.c
index dcfaf09946ee..1d69c3c13257 100644
--- a/drivers/rtc/rtc-mc146818-lib.c
+++ b/drivers/rtc/rtc-mc146818-lib.c
@@ -21,9 +21,15 @@ unsigned int mc146818_get_time(struct rtc_time *time)
 
 again:
 	spin_lock_irqsave(&rtc_lock, flags);
-	/* Ensure that the RTC is accessible. Bit 6 must be 0! */
-	if (WARN_ON_ONCE((CMOS_READ(RTC_VALID) & 0x40) != 0)) {
+
+	/*
+	 * Ensure that the RTC is accessible, to avoid an infinite loop.
+	 * RTC_HOURS is in BCD format.
+	 */
+	if (CMOS_READ(RTC_HOURS) > 0x24) {
 		spin_unlock_irqrestore(&rtc_lock, flags);
+		pr_warn_once("Real-time clock is not accessible or not "
+				"working correctly\n");
 		memset(time, 0xff, sizeof(*time));
 		return 0;
 	}
-- 
2.25.1

Re: [PATCH] rtc: mc146818: Use hours for checking RTC availability

[Mateusz Jończyk]

Hello,
Please do not apply this patch, it causes trouble on my Intel Kaby Lake laptop.
(see below).

W dniu 07.07.2021 o 23:38, Mateusz Jończyk pisze:
> To prevent an infinite loop, it is necessary to ascertain the RTC is
> present. Previous code was checking if bit 6 in register 0x0D is
> cleared. This caused a false negative on a motherboard with an AMD SB710
> southbridge; according to the specification [1], bit 6 of register 0x0D
> on this chipset is a scratchbit.
>
> Use the RTC_HOURS register instead, which is expected to contain a value
> not larger then 24, in BCD format.
>
> Caveat: when I was playing with
>         while true; do cat /sys/class/rtc/rtc0/time; done
> I sometimes triggered this mechanism on my HP laptop. It appears that
> CMOS_READ(RTC_VALID) was sometimes reading the number of seconds from
> previous loop iteration. This happens very rarely, though, and this patch
> does not make it any more likely.

According to Intel's documentation [2]:

    The update cycle [of CMOS RTC registers, which happens every second]
    will start at least 488 μs after the UIP bit of register A is asserted, and
    the entire cycle does not take more than 1984 μs to complete. The time and date RAM
    locations (0–9) are disconnected from the external bus during this time.

Therefore, trying to access the RTC_HOURS register during the update time
is undefined behavior. In my tests, it frequently returned values from the
wrong register, such as the seconds or minutes register instead of the hours
register and the values failed the "< 24" comparison.

Indeed, the wrong readouts happen when the UIP bit is set.

I was not aware of this and blamed my firmware for accessing the RTC clock independently.


BTW, cmos_set_alarm() in drivers/rtc/rtc-cmos.c does not check for UIP bit.
As it writes to registers in the 0-9 range, it may fail to set the alarm time.

Greetings,

Mateusz

[2] 7th Generation Intel® Processor Family I/O for U/Y Platforms [...] Datasheet – Volume 1 of 2,
page 209
Intel's Document Number: 334658-006,
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/7th-and-8th-gen-core-family-mobile-u-y-processor-lines-i-o-datasheet-vol-1.pdf

> [1] AMD SB700/710/750 Register Reference Guide, page 308,
> https://developer.amd.com/wordpress/media/2012/10/43009_sb7xx_rrg_pub_1.00.pdf
>
> Fixes: 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs")
> Fixes: ebb22a059436 ("rtc: mc146818: Dont test for bit 0-5 in Register D")
> Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Alessandro Zummo <a.zummo@towertech.it>
> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Cc: stable@vger.kernel.org
> ---
>  drivers/rtc/rtc-cmos.c         |  6 +++---
>  drivers/rtc/rtc-mc146818-lib.c | 10 ++++++++--
>  2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index 670fd8a2970e..b0102fb31b3f 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -798,10 +798,10 @@ cmos_do_probe(struct device *dev, struct resource *ports, int rtc_irq)
>  
>  	spin_lock_irq(&rtc_lock);
>  
> -	/* Ensure that the RTC is accessible. Bit 6 must be 0! */
> -	if ((CMOS_READ(RTC_VALID) & 0x40) != 0) {
> +	/* Ensure that the RTC is accessible (RTC_HOURS is in BCD format) */
> +	if (CMOS_READ(RTC_HOURS) > 0x24) {
>  		spin_unlock_irq(&rtc_lock);
> -		dev_warn(dev, "not accessible\n");
> +		dev_warn(dev, "not accessible or not working correctly\n");
>  		retval = -ENXIO;
>  		goto cleanup1;
>  	}
> diff --git a/drivers/rtc/rtc-mc146818-lib.c b/drivers/rtc/rtc-mc146818-lib.c
> index dcfaf09946ee..1d69c3c13257 100644
> --- a/drivers/rtc/rtc-mc146818-lib.c
> +++ b/drivers/rtc/rtc-mc146818-lib.c
> @@ -21,9 +21,15 @@ unsigned int mc146818_get_time(struct rtc_time *time)
>  
>  again:
>  	spin_lock_irqsave(&rtc_lock, flags);
> -	/* Ensure that the RTC is accessible. Bit 6 must be 0! */
> -	if (WARN_ON_ONCE((CMOS_READ(RTC_VALID) & 0x40) != 0)) {
> +
> +	/*
> +	 * Ensure that the RTC is accessible, to avoid an infinite loop.
> +	 * RTC_HOURS is in BCD format.
> +	 */
> +	if (CMOS_READ(RTC_HOURS) > 0x24) {
>  		spin_unlock_irqrestore(&rtc_lock, flags);
> +		pr_warn_once("Real-time clock is not accessible or not "
> +				"working correctly\n");
>  		memset(time, 0xff, sizeof(*time));
>  		return 0;
>  	}

[PATCH] rtc-mc146818: fix RTC presence check

[Mateusz Jończyk]

To prevent an infinite loop in mc146818_get_time(),
commit 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs")
added a check for RTC availability. Together with a later fix, it
checked if bit 6 in register 0x0d is cleared. This, however, caused a
false negative on a motherboard with an AMD SB710 southbridge; according
to the specification [1], bit 6 of register 0x0d of this chipset is a
scratchbit.

This caused a regression in Linux 5.11 - the RTC was not used by the
kernel.

As a better alternative, check whether the UIP ("Update-in-progress")
bit is set for longer then 10ms. If that is the case, then apparently
the RTC is either absent (and all register reads return 0xff) or broken.
Also limit the number of loop iterations in mc146818_get_time() to 10.

In a previous approach to this problem, I implemented a check whether
the RTC_HOURS register contains a value <= 24. This, however, sometimes
did not work correctly on my Intel Kaby Lake laptop. According to
Intel's documentation [2], "the time and date RAM locations (0-9) are
disconnected from the external bus" during the update cycle so reading
this register without checking the UIP bit is incorrect.

[1] AMD SB700/710/750 Register Reference Guide, page 308,
https://developer.amd.com/wordpress/media/2012/10/43009_sb7xx_rrg_pub_1.00.pdf

[2] 7th Generation Intel ® Processor Family I/O for U/Y Platforms [...] Datasheet
Volume 1 of 2, page 209
Intel's Document Number: 334658-006,
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/7th-and-8th-gen-core-family-mobile-u-y-processor-lines-i-o-datasheet-vol-1.pdf

Fixes: 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs")
Fixes: ebb22a059436 ("rtc: mc146818: Dont test for bit 0-5 in Register D")
Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: stable@vger.kernel.org

---

Hello,
Please check this commit carefully as the RTC is a finicky beast and I'm
quite new to kernel development.

I have tested this on three computers, though, and found no problems.
Also, using the UIP (Update-in-progress) bit should be safe.

Greetings,
Mateusz

 drivers/rtc/rtc-cmos.c         | 10 ++++------
 drivers/rtc/rtc-mc146818-lib.c | 34 ++++++++++++++++++++++++++++++----
 include/linux/mc146818rtc.h    |  1 +
 3 files changed, 35 insertions(+), 10 deletions(-)

diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 670fd8a2970e..0fa66d1039b9 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -796,16 +796,14 @@ cmos_do_probe(struct device *dev, struct resource *ports, int rtc_irq)
 
 	rename_region(ports, dev_name(&cmos_rtc.rtc->dev));
 
-	spin_lock_irq(&rtc_lock);
-
-	/* Ensure that the RTC is accessible. Bit 6 must be 0! */
-	if ((CMOS_READ(RTC_VALID) & 0x40) != 0) {
-		spin_unlock_irq(&rtc_lock);
-		dev_warn(dev, "not accessible\n");
+	if (!mc146818_does_rtc_work()) {
+		dev_warn(dev, "broken or not accessible\n");
 		retval = -ENXIO;
 		goto cleanup1;
 	}
 
+	spin_lock_irq(&rtc_lock);
+
 	if (!(flags & CMOS_RTC_FLAGS_NOFREQ)) {
 		/* force periodic irq to CMOS reset default of 1024Hz;
 		 *
diff --git a/drivers/rtc/rtc-mc146818-lib.c b/drivers/rtc/rtc-mc146818-lib.c
index dcfaf09946ee..9175e11baf26 100644
--- a/drivers/rtc/rtc-mc146818-lib.c
+++ b/drivers/rtc/rtc-mc146818-lib.c
@@ -8,10 +8,35 @@
 #include <linux/acpi.h>
 #endif
 
+/*
+ * If the UIP (Update-in-progress) bit of the RTC is set for more then
+ * 10ms, the RTC apparently is broken or not present.
+ */
+unsigned int mc146818_does_rtc_work(void)
+{
+	int i;
+	unsigned char val;
+	unsigned long flags;
+
+	for (i = 0; i < 20; i++) {
+		spin_lock_irqsave(&rtc_lock, flags);
+		val = CMOS_READ(RTC_FREQ_SELECT);
+		spin_unlock_irqrestore(&rtc_lock, flags);
+
+		if ((val & RTC_UIP) == 0)
+			return 1;
+
+		udelay(500);
+	}
+
+	return 0;
+}
+
 unsigned int mc146818_get_time(struct rtc_time *time)
 {
 	unsigned char ctrl;
 	unsigned long flags;
+	unsigned int iter_count = 0;
 	unsigned char century = 0;
 	bool retry;
 
@@ -20,13 +45,14 @@ unsigned int mc146818_get_time(struct rtc_time *time)
 #endif
 
 again:
-	spin_lock_irqsave(&rtc_lock, flags);
-	/* Ensure that the RTC is accessible. Bit 6 must be 0! */
-	if (WARN_ON_ONCE((CMOS_READ(RTC_VALID) & 0x40) != 0)) {
-		spin_unlock_irqrestore(&rtc_lock, flags);
+	if (iter_count > 10) {
+		pr_err_ratelimited("Unable to read current time from RTC\n");
 		memset(time, 0xff, sizeof(*time));
 		return 0;
 	}
+	iter_count++;
+
+	spin_lock_irqsave(&rtc_lock, flags);
 
 	/*
 	 * Check whether there is an update in progress during which the
diff --git a/include/linux/mc146818rtc.h b/include/linux/mc146818rtc.h
index 0661af17a758..046a03df1e56 100644
--- a/include/linux/mc146818rtc.h
+++ b/include/linux/mc146818rtc.h
@@ -123,6 +123,7 @@ struct cmos_rtc_board_info {
 #define RTC_IO_EXTENT_USED      RTC_IO_EXTENT
 #endif /* ARCH_RTC_LOCATION */
 
+unsigned int mc146818_does_rtc_work(void);
 unsigned int mc146818_get_time(struct rtc_time *time);
 int mc146818_set_time(struct rtc_time *time);
 
-- 
2.25.1