2019-05-19 15:08:55 +03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2016-06-01 17:46:23 +03:00
|
|
|
#include <linux/bcd.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/export.h>
|
|
|
|
#include <linux/mc146818rtc.h>
|
|
|
|
|
|
|
|
#ifdef CONFIG_ACPI
|
|
|
|
#include <linux/acpi.h>
|
|
|
|
#endif
|
|
|
|
|
2021-12-10 23:01:27 +03:00
|
|
|
/*
|
|
|
|
* Execute a function while the UIP (Update-in-progress) bit of the RTC is
|
|
|
|
* unset.
|
|
|
|
*
|
|
|
|
* Warning: callback may be executed more then once.
|
|
|
|
*/
|
|
|
|
bool mc146818_avoid_UIP(void (*callback)(unsigned char seconds, void *param),
|
|
|
|
void *param)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
unsigned long flags;
|
|
|
|
unsigned char seconds;
|
|
|
|
|
|
|
|
for (i = 0; i < 10; i++) {
|
|
|
|
spin_lock_irqsave(&rtc_lock, flags);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check whether there is an update in progress during which the
|
|
|
|
* readout is unspecified. The maximum update time is ~2ms. Poll
|
|
|
|
* every msec for completion.
|
|
|
|
*
|
|
|
|
* Store the second value before checking UIP so a long lasting
|
|
|
|
* NMI which happens to hit after the UIP check cannot make
|
|
|
|
* an update cycle invisible.
|
|
|
|
*/
|
|
|
|
seconds = CMOS_READ(RTC_SECONDS);
|
|
|
|
|
|
|
|
if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP) {
|
|
|
|
spin_unlock_irqrestore(&rtc_lock, flags);
|
|
|
|
mdelay(1);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Revalidate the above readout */
|
|
|
|
if (seconds != CMOS_READ(RTC_SECONDS)) {
|
|
|
|
spin_unlock_irqrestore(&rtc_lock, flags);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (callback)
|
|
|
|
callback(seconds, param);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check for the UIP bit again. If it is set now then
|
|
|
|
* the above values may contain garbage.
|
|
|
|
*/
|
|
|
|
if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP) {
|
|
|
|
spin_unlock_irqrestore(&rtc_lock, flags);
|
|
|
|
mdelay(1);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* A NMI might have interrupted the above sequence so check
|
|
|
|
* whether the seconds value has changed which indicates that
|
|
|
|
* the NMI took longer than the UIP bit was set. Unlikely, but
|
|
|
|
* possible and there is also virt...
|
|
|
|
*/
|
|
|
|
if (seconds != CMOS_READ(RTC_SECONDS)) {
|
|
|
|
spin_unlock_irqrestore(&rtc_lock, flags);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
spin_unlock_irqrestore(&rtc_lock, flags);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mc146818_avoid_UIP);
|
|
|
|
|
rtc: mc146818-lib: fix RTC presence check
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 determined broken by the kernel and not used by
rtc-cmos.c [3]. This problem was also reported in Fedora [4].
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 to
prevent an infinite loop there.
The functions mc146818_get_time() and mc146818_does_rtc_work() will be
refactored later in this patch series, in order to fix a separate
problem with reading / setting the RTC alarm time. This is done so to
avoid a confusion about what is being fixed when.
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
[3] Functions in arch/x86/kernel/rtc.c apparently were using it.
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1936688
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>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20211210200131.153887-5-mat.jonczyk@o2.pl
2021-12-10 23:01:26 +03:00
|
|
|
/*
|
|
|
|
* If the UIP (Update-in-progress) bit of the RTC is set for more then
|
|
|
|
* 10ms, the RTC is apparently broken or not present.
|
|
|
|
*/
|
|
|
|
bool mc146818_does_rtc_work(void)
|
|
|
|
{
|
2021-12-10 23:01:29 +03:00
|
|
|
return mc146818_avoid_UIP(NULL, NULL);
|
rtc: mc146818-lib: fix RTC presence check
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 determined broken by the kernel and not used by
rtc-cmos.c [3]. This problem was also reported in Fedora [4].
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 to
prevent an infinite loop there.
The functions mc146818_get_time() and mc146818_does_rtc_work() will be
refactored later in this patch series, in order to fix a separate
problem with reading / setting the RTC alarm time. This is done so to
avoid a confusion about what is being fixed when.
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
[3] Functions in arch/x86/kernel/rtc.c apparently were using it.
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1936688
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>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20211210200131.153887-5-mat.jonczyk@o2.pl
2021-12-10 23:01:26 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mc146818_does_rtc_work);
|
|
|
|
|
2021-12-10 23:01:28 +03:00
|
|
|
struct mc146818_get_time_callback_param {
|
|
|
|
struct rtc_time *time;
|
2016-06-01 17:46:23 +03:00
|
|
|
unsigned char ctrl;
|
2021-12-10 23:01:28 +03:00
|
|
|
#ifdef CONFIG_ACPI
|
|
|
|
unsigned char century;
|
|
|
|
#endif
|
2016-06-01 17:46:23 +03:00
|
|
|
#ifdef CONFIG_MACH_DECSTATION
|
|
|
|
unsigned int real_year;
|
|
|
|
#endif
|
2021-12-10 23:01:28 +03:00
|
|
|
};
|
2016-06-01 17:46:23 +03:00
|
|
|
|
2021-12-10 23:01:28 +03:00
|
|
|
static void mc146818_get_time_callback(unsigned char seconds, void *param_in)
|
|
|
|
{
|
|
|
|
struct mc146818_get_time_callback_param *p = param_in;
|
2016-06-01 17:46:23 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Only the values that we read from the RTC are set. We leave
|
|
|
|
* tm_wday, tm_yday and tm_isdst untouched. Even though the
|
|
|
|
* RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
|
|
|
|
* by the RTC when initially set to a non-zero value.
|
|
|
|
*/
|
2021-12-10 23:01:28 +03:00
|
|
|
p->time->tm_sec = seconds;
|
|
|
|
p->time->tm_min = CMOS_READ(RTC_MINUTES);
|
|
|
|
p->time->tm_hour = CMOS_READ(RTC_HOURS);
|
|
|
|
p->time->tm_mday = CMOS_READ(RTC_DAY_OF_MONTH);
|
|
|
|
p->time->tm_mon = CMOS_READ(RTC_MONTH);
|
|
|
|
p->time->tm_year = CMOS_READ(RTC_YEAR);
|
2016-06-01 17:46:23 +03:00
|
|
|
#ifdef CONFIG_MACH_DECSTATION
|
2021-12-10 23:01:28 +03:00
|
|
|
p->real_year = CMOS_READ(RTC_DEC_YEAR);
|
2016-06-01 17:46:23 +03:00
|
|
|
#endif
|
|
|
|
#ifdef CONFIG_ACPI
|
|
|
|
if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
|
2021-12-10 23:01:28 +03:00
|
|
|
acpi_gbl_FADT.century) {
|
|
|
|
p->century = CMOS_READ(acpi_gbl_FADT.century);
|
|
|
|
} else {
|
|
|
|
p->century = 0;
|
|
|
|
}
|
2016-06-01 17:46:23 +03:00
|
|
|
#endif
|
2020-12-07 00:46:14 +03:00
|
|
|
|
2021-12-10 23:01:28 +03:00
|
|
|
p->ctrl = CMOS_READ(RTC_CONTROL);
|
|
|
|
}
|
|
|
|
|
2022-01-11 10:19:22 +03:00
|
|
|
int mc146818_get_time(struct rtc_time *time)
|
2021-12-10 23:01:28 +03:00
|
|
|
{
|
|
|
|
struct mc146818_get_time_callback_param p = {
|
|
|
|
.time = time
|
|
|
|
};
|
2016-06-01 17:46:23 +03:00
|
|
|
|
2021-12-10 23:01:28 +03:00
|
|
|
if (!mc146818_avoid_UIP(mc146818_get_time_callback, &p)) {
|
|
|
|
memset(time, 0, sizeof(*time));
|
|
|
|
return -EIO;
|
|
|
|
}
|
2020-12-07 00:46:14 +03:00
|
|
|
|
2021-12-10 23:01:28 +03:00
|
|
|
if (!(p.ctrl & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
|
2016-06-01 17:46:23 +03:00
|
|
|
{
|
|
|
|
time->tm_sec = bcd2bin(time->tm_sec);
|
|
|
|
time->tm_min = bcd2bin(time->tm_min);
|
|
|
|
time->tm_hour = bcd2bin(time->tm_hour);
|
|
|
|
time->tm_mday = bcd2bin(time->tm_mday);
|
|
|
|
time->tm_mon = bcd2bin(time->tm_mon);
|
|
|
|
time->tm_year = bcd2bin(time->tm_year);
|
2021-12-10 23:01:28 +03:00
|
|
|
#ifdef CONFIG_ACPI
|
|
|
|
p.century = bcd2bin(p.century);
|
|
|
|
#endif
|
2016-06-01 17:46:23 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_MACH_DECSTATION
|
2021-12-10 23:01:28 +03:00
|
|
|
time->tm_year += p.real_year - 72;
|
2016-06-01 17:46:23 +03:00
|
|
|
#endif
|
|
|
|
|
2021-12-10 23:01:28 +03:00
|
|
|
#ifdef CONFIG_ACPI
|
2022-01-06 11:46:09 +03:00
|
|
|
if (p.century > 19)
|
2021-12-10 23:01:28 +03:00
|
|
|
time->tm_year += (p.century - 19) * 100;
|
|
|
|
#endif
|
2016-06-01 17:46:23 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Account for differences between how the RTC uses the values
|
|
|
|
* and how they are defined in a struct rtc_time;
|
|
|
|
*/
|
|
|
|
if (time->tm_year <= 69)
|
|
|
|
time->tm_year += 100;
|
|
|
|
|
|
|
|
time->tm_mon--;
|
|
|
|
|
2021-12-10 23:01:24 +03:00
|
|
|
return 0;
|
2016-06-01 17:46:23 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mc146818_get_time);
|
|
|
|
|
2022-01-12 01:57:50 +03:00
|
|
|
/* AMD systems don't allow access to AltCentury with DV1 */
|
|
|
|
static bool apply_amd_register_a_behavior(void)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_X86
|
|
|
|
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
|
|
|
|
boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
|
|
|
|
return true;
|
|
|
|
#endif
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-06-01 17:46:23 +03:00
|
|
|
/* Set the current date and time in the real time clock. */
|
|
|
|
int mc146818_set_time(struct rtc_time *time)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
unsigned char mon, day, hrs, min, sec;
|
|
|
|
unsigned char save_control, save_freq_select;
|
|
|
|
unsigned int yrs;
|
|
|
|
#ifdef CONFIG_MACH_DECSTATION
|
|
|
|
unsigned int real_yrs, leap_yr;
|
|
|
|
#endif
|
|
|
|
unsigned char century = 0;
|
|
|
|
|
|
|
|
yrs = time->tm_year;
|
|
|
|
mon = time->tm_mon + 1; /* tm_mon starts at zero */
|
|
|
|
day = time->tm_mday;
|
|
|
|
hrs = time->tm_hour;
|
|
|
|
min = time->tm_min;
|
|
|
|
sec = time->tm_sec;
|
|
|
|
|
|
|
|
if (yrs > 255) /* They are unsigned */
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
#ifdef CONFIG_MACH_DECSTATION
|
|
|
|
real_yrs = yrs;
|
|
|
|
leap_yr = ((!((yrs + 1900) % 4) && ((yrs + 1900) % 100)) ||
|
|
|
|
!((yrs + 1900) % 400));
|
|
|
|
yrs = 72;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We want to keep the year set to 73 until March
|
|
|
|
* for non-leap years, so that Feb, 29th is handled
|
|
|
|
* correctly.
|
|
|
|
*/
|
|
|
|
if (!leap_yr && mon < 3) {
|
|
|
|
real_yrs--;
|
|
|
|
yrs = 73;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef CONFIG_ACPI
|
|
|
|
if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
|
|
|
|
acpi_gbl_FADT.century) {
|
|
|
|
century = (yrs + 1900) / 100;
|
|
|
|
yrs %= 100;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* These limits and adjustments are independent of
|
|
|
|
* whether the chip is in binary mode or not.
|
|
|
|
*/
|
2020-12-07 00:46:15 +03:00
|
|
|
if (yrs > 169)
|
2016-06-01 17:46:23 +03:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (yrs >= 100)
|
|
|
|
yrs -= 100;
|
|
|
|
|
2022-02-20 12:04:03 +03:00
|
|
|
spin_lock_irqsave(&rtc_lock, flags);
|
|
|
|
save_control = CMOS_READ(RTC_CONTROL);
|
|
|
|
spin_unlock_irqrestore(&rtc_lock, flags);
|
|
|
|
if (!(save_control & RTC_DM_BINARY) || RTC_ALWAYS_BCD) {
|
2016-06-01 17:46:23 +03:00
|
|
|
sec = bin2bcd(sec);
|
|
|
|
min = bin2bcd(min);
|
|
|
|
hrs = bin2bcd(hrs);
|
|
|
|
day = bin2bcd(day);
|
|
|
|
mon = bin2bcd(mon);
|
|
|
|
yrs = bin2bcd(yrs);
|
|
|
|
century = bin2bcd(century);
|
|
|
|
}
|
|
|
|
|
2020-12-07 00:46:15 +03:00
|
|
|
spin_lock_irqsave(&rtc_lock, flags);
|
2016-06-01 17:46:23 +03:00
|
|
|
save_control = CMOS_READ(RTC_CONTROL);
|
|
|
|
CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
|
|
|
|
save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
|
2022-01-12 01:57:50 +03:00
|
|
|
if (apply_amd_register_a_behavior())
|
|
|
|
CMOS_WRITE((save_freq_select & ~RTC_AMD_BANK_SELECT), RTC_FREQ_SELECT);
|
|
|
|
else
|
|
|
|
CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
|
2016-06-01 17:46:23 +03:00
|
|
|
|
|
|
|
#ifdef CONFIG_MACH_DECSTATION
|
|
|
|
CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
|
|
|
|
#endif
|
|
|
|
CMOS_WRITE(yrs, RTC_YEAR);
|
|
|
|
CMOS_WRITE(mon, RTC_MONTH);
|
|
|
|
CMOS_WRITE(day, RTC_DAY_OF_MONTH);
|
|
|
|
CMOS_WRITE(hrs, RTC_HOURS);
|
|
|
|
CMOS_WRITE(min, RTC_MINUTES);
|
|
|
|
CMOS_WRITE(sec, RTC_SECONDS);
|
|
|
|
#ifdef CONFIG_ACPI
|
|
|
|
if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
|
|
|
|
acpi_gbl_FADT.century)
|
|
|
|
CMOS_WRITE(century, acpi_gbl_FADT.century);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
CMOS_WRITE(save_control, RTC_CONTROL);
|
|
|
|
CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&rtc_lock, flags);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mc146818_set_time);
|