Commit Graph

148 Commits

Author SHA1 Message Date
Mario Limonciello 905d9e1c69 rtc: Adjust failure return code for cmos_set_alarm()
commit 1311a8f0d4b23f58bbababa13623aa40b8ad4e0c upstream.

When mc146818_avoid_UIP() fails to return a valid value, this is because
UIP didn't clear in the timeout period. Adjust the return code in this
case to -ETIMEDOUT.

Tested-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Reviewed-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Acked-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc:  <stable@vger.kernel.org>
Fixes: cdedc45c57 ("rtc: cmos: avoid UIP when reading alarm time")
Fixes: cd17420ebe ("rtc: cmos: avoid UIP when writing alarm time")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20231128053653.101798-3-mario.limonciello@amd.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-31 16:18:56 -08:00
Mario Limonciello 4845145802 rtc: cmos: Use ACPI alarm for non-Intel x86 systems too
commit 3d762e21d56370a43478b55e604b4a83dd85aafc upstream.

Intel systems > 2015 have been configured to use ACPI alarm instead
of HPET to avoid s2idle issues.

Having HPET programmed for wakeup causes problems on AMD systems with
s2idle as well.

One particular case is that the systemd "SuspendThenHibernate" feature
doesn't work properly on the Framework 13" AMD model. Switching to
using ACPI alarm fixes the issue.

Adjust the quirk to apply to AMD/Hygon systems from 2021 onwards.
This matches what has been tested and is specifically to avoid potential
risk to older systems.

Cc:  <stable@vger.kernel.org> # 6.1+
Reported-by:  <alvin.zhuge@gmail.com>
Reported-by:  <renzhamin@gmail.com>
Closes: https://github.com/systemd/systemd/issues/24279
Reported-by: Kelvie Wong <kelvie@kelvie.ca>
Closes: https://community.frame.work/t/systemd-suspend-then-hibernate-wakes-up-after-5-minutes/39392
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20231106162310.85711-1-mario.limonciello@amd.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-31 16:18:56 -08:00
Guenter Roeck 2546e7083f rtc: cmos: Report supported alarm limit to rtc infrastructure
The alarm window supported by the cmos RTC depends on the chip
and its configuration. Report the limit to the RTC core.

Cc: Brian Norris <briannorris@chromium.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20230817225537.4053865-5-linux@roeck-us.net
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2023-08-27 23:50:22 +02:00
Uwe Kleine-König 63c18a079b rtc: cmos: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230304133028.2135435-10-u.kleine-koenig@pengutronix.de
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2023-03-17 23:03:17 +01:00
Rafael J. Wysocki 83ebb7b303 rtc: cmos: Disable ACPI RTC event on removal
Make cmos_do_remove() drop the ACPI RTC fixed event handler so as to
prevent it from operating on stale data in case the event triggers
after driver removal.

Fixes: 311ee9c151 ("rtc: cmos: allow using ACPI for RTC alarm instead of HPET")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/2224609.iZASKD2KPV@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2022-11-15 21:07:14 +01:00
Rafael J. Wysocki d13e9ad9f5 rtc: cmos: Rename ACPI-related functions
The names of rtc_wake_setup() and cmos_wake_setup() don't indicate
that these functions are ACPI-related, which is the case, and the
former doesn't really reflect the role of the function.

Rename them to acpi_rtc_event_setup() and acpi_cmos_wake_setup(),
respectively, to address this shortcoming.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/3225614.44csPzL39Z@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2022-11-15 21:07:07 +01:00
Rafael J. Wysocki dca4d3b71c rtc: cmos: Eliminate forward declarations of some functions
Reorder the ACPI-related code before cmos_do_probe() so as to eliminate
excessive forward declarations of some functions.

While at it, for consistency, add the inline modifier to the
definitions of empty stub static funtions and remove it from the
corresponding definitions of functions with non-empty bodies.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/13157911.uLZWGnKmhe@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2022-11-15 21:06:49 +01:00
Rafael J. Wysocki 375bbba096 rtc: cmos: Call rtc_wake_setup() from cmos_do_probe()
To reduce code duplication, move the invocation of rtc_wake_setup()
into cmos_do_probe() and simplify the callers of the latter.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/2143522.irdbgypaU6@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2022-11-15 21:06:43 +01:00
Rafael J. Wysocki 508ccdfb86 rtc: cmos: Call cmos_wake_setup() from cmos_do_probe()
Notice that cmos_wake_setup() is the only user of acpi_rtc_info and it
can operate on the cmos_rtc variable directly, so it need not set the
platform_data pointer before cmos_do_probe() is called.  Instead, it
can be called by cmos_do_probe() in the case when the platform_data
pointer is not set to implement the default behavior (which is to use
the FADT information as long as ACPI support is enabled).

Modify the code accordingly.

While at it, drop a comment that doesn't really match the code it is
supposed to be describing.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/4803444.31r3eYUQgx@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2022-11-15 21:06:34 +01:00
Alexandre Belloni db4e955ae3 rtc: cmos: fix build on non-ACPI platforms
Now that rtc_wake_setup is called outside of cmos_wake_setup, it also need
to be defined on non-ACPI platforms.

Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20221018203512.2532407-1-alexandre.belloni@bootlin.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2022-10-18 22:36:54 +02:00
Rafael J. Wysocki 0782b66ed2 rtc: cmos: Fix wake alarm breakage
Commit 4919d3eb2e ("rtc: cmos: Fix event handler registration
ordering issue") overlooked the fact that cmos_do_probe() depended
on the preparations carried out by cmos_wake_setup() and the wake
alarm stopped working after the ordering of them had been changed.

Address this by partially reverting commit 4919d3eb2e so that
cmos_wake_setup() is called before cmos_do_probe() again and moving
the rtc_wake_setup() invocation from cmos_wake_setup() directly to the
callers of cmos_do_probe() where it will happen after a successful
completion of the latter.

Fixes: 4919d3eb2e ("rtc: cmos: Fix event handler registration ordering issue")
Reported-by: Zhang Rui <rui.zhang@intel.com>
Reported-by: Todd Brandt <todd.e.brandt@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/5887691.lOV4Wx5bFT@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2022-10-18 18:28:28 +02:00
Rafael J. Wysocki 4919d3eb2e rtc: cmos: Fix event handler registration ordering issue
Because acpi_install_fixed_event_handler() enables the event
automatically on success, it is incorrect to call it before the
handler routine passed to it is ready to handle events.

Unfortunately, the rtc-cmos driver does exactly the incorrect thing
by calling cmos_wake_setup(), which passes rtc_handler() to
acpi_install_fixed_event_handler(), before cmos_do_probe(), because
rtc_handler() uses dev_get_drvdata() to get to the cmos object
pointer and the driver data pointer is only populated in
cmos_do_probe().

This leads to a NULL pointer dereference in rtc_handler() on boot
if the RTC fixed event happens to be active at the init time.

To address this issue, change the initialization ordering of the
driver so that cmos_wake_setup() is always called after a successful
cmos_do_probe() call.

While at it, change cmos_pnp_probe() to call cmos_do_probe() after
the initial if () statement used for computing the IRQ argument to
be passed to cmos_do_probe() which is cleaner than calling it in
each branch of that if () (local variable "irq" can be of type int,
because it is passed to that function as an argument of type int).

Note that commit 6492fed7d8 ("rtc: rtc-cmos: Do not check
ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number
of systems, because previously it only affected systems with
ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that
commit.

Fixes: 6492fed7d8 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0")
Fixes: a474aaedac ("rtc-cmos: move wake setup from ACPI glue into RTC driver")
Link: https://lore.kernel.org/linux-acpi/20221010141630.zfzi7mk7zvnmclzy@techsingularity.net/
Reported-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Mel Gorman <mgorman@techsingularity.net>
Link: https://lore.kernel.org/r/5629262.DvuYhMxLoT@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2022-10-13 23:27:52 +02:00
Rafael J. Wysocki 6492fed7d8 rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0
The ACPI_FADT_LOW_POWER_S0 flag merely means that it is better to
use low-power S0 idle on the given platform than S3 (provided that
the latter is supported) and it doesn't preclude using either of
them (which of them will be used depends on the choices made by user
space).

For this reason, there is no benefit from checking that flag in
use_acpi_alarm_quirks().

First off, it cannot be a bug to do S3 with use_acpi_alarm set,
because S3 can be used on systems with ACPI_FADT_LOW_POWER_S0 and it
must work if really supported, so the ACPI_FADT_LOW_POWER_S0 check is
not needed to protect the S3-capable systems from failing.

Second, suspend-to-idle can be carried out on a system with
ACPI_FADT_LOW_POWER_S0 unset and it is expected to work, so if setting
use_acpi_alarm is needed to handle that case correctly, it should be
set regardless of the ACPI_FADT_LOW_POWER_S0 value.

Accordingly, drop the ACPI_FADT_LOW_POWER_S0 check from
use_acpi_alarm_quirks().

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/12054246.O9o76ZdvQC@kreacher
2022-08-08 20:36:01 +02:00
Mateusz Jończyk cd17420ebe rtc: cmos: avoid UIP when writing alarm time
Some Intel chipsets disconnect the time and date RTC registers when the
clock update is in progress: during this time reads may return bogus
values and writes fail silently. This includes the RTC alarm registers.
[1]

cmos_set_alarm() did not take account for that, fix it.

[1] 7th Generation Intel ® Processor Family I/O for U/Y Platforms [...]
Datasheet, Volume 1 of 2 (Intel's Document Number: 334658-006)
Page 208
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
        "If a RAM read from the ten time and date bytes is attempted
        during an update cycle, the value read do not necessarily
        represent the true contents of those locations. Any RAM writes
        under the same conditions are ignored."

Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
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-10-mat.jonczyk@o2.pl
2021-12-16 21:50:07 +01:00
Mateusz Jończyk cdedc45c57 rtc: cmos: avoid UIP when reading alarm time
Some Intel chipsets disconnect the time and date RTC registers when the
clock update is in progress: during this time reads may return bogus
values and writes fail silently. This includes the RTC alarm registers.
[1]

cmos_read_alarm() did not take account for that, which caused alarm time
reads to sometimes return bogus values. This can be shown with a test
patch that I am attaching to this patch series.

Fix this, by using mc146818_avoid_UIP().

[1] 7th Generation Intel ® Processor Family I/O for U/Y Platforms [...]
Datasheet, Volume 1 of 2 (Intel's Document Number: 334658-006)
Page 208
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
        "If a RAM read from the ten time and date bytes is attempted
        during an update cycle, the value read do not necessarily
        represent the true contents of those locations. Any RAM writes
        under the same conditions are ignored."

Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
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-9-mat.jonczyk@o2.pl
2021-12-16 21:50:07 +01:00
Mateusz Jończyk ea6fa4961a rtc: mc146818-lib: fix RTC presence check
To prevent an infinite loop in mc146818_get_time(),
commit 211e5db19d ("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: 211e5db19d ("rtc: mc146818: Detect and handle broken RTCs")
Fixes: ebb22a0594 ("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-16 21:50:06 +01:00
Mateusz Jończyk 0dd8d6cb9e rtc: Check return value from mc146818_get_time()
There are 4 users of mc146818_get_time() and none of them was checking
the return value from this function. Change this.

Print the appropriate warnings in callers of mc146818_get_time() instead
of in the function mc146818_get_time() itself, in order not to add
strings to rtc-mc146818-lib.c, which is kind of a library.

The callers of alpha_rtc_read_time() and cmos_read_time() may use the
contents of (struct rtc_time *) even when the functions return a failure
code. Therefore, set the contents of (struct rtc_time *) to 0x00,
which looks more sensible then 0xff and aligns with the (possibly
stale?) comment in cmos_read_time:

	/*
	 * If pm_trace abused the RTC for storage, set the timespec to 0,
	 * which tells the caller that this RTC value is unusable.
	 */

For consistency, do this in mc146818_get_time().

Note: hpet_rtc_interrupt() may call mc146818_get_time() many times a
second. It is very unlikely, though, that the RTC suddenly stops
working and mc146818_get_time() would consistently fail.

Only compile-tested on alpha.

Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-alpha@vger.kernel.org
Cc: x86@kernel.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20211210200131.153887-4-mat.jonczyk@o2.pl
2021-12-16 21:50:06 +01:00
Mateusz Jończyk 454f47ff46 rtc: cmos: take rtc_lock while reading from CMOS
Reading from the CMOS involves writing to the index register and then
reading from the data register. Therefore access to the CMOS has to be
serialized with rtc_lock. This invocation of CMOS_READ was not
serialized, which could cause trouble when other code is accessing CMOS
at the same time.

Use spin_lock_irq() like the rest of the function.

Nothing in kernel modifies the RTC_DM_BINARY bit, so there could be a
separate pair of spin_lock_irq() / spin_unlock_irq() before doing the
math.

Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Reviewed-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20211210200131.153887-2-mat.jonczyk@o2.pl
2021-12-16 21:50:06 +01:00
Chris Wilson 13be2efc39 rtc: cmos: Disable irq around direct invocation of cmos_interrupt()
As previously noted in commit 66e4f4a9cc ("rtc: cmos: Use
spin_lock_irqsave() in cmos_interrupt()"):

<4>[  254.192378] WARNING: inconsistent lock state
<4>[  254.192384] 5.12.0-rc1-CI-CI_DRM_9834+ #1 Not tainted
<4>[  254.192396] --------------------------------
<4>[  254.192400] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
<4>[  254.192409] rtcwake/5309 [HC0[0]:SC0[0]:HE1:SE1] takes:
<4>[  254.192429] ffffffff8263c5f8 (rtc_lock){?...}-{2:2}, at: cmos_interrupt+0x18/0x100
<4>[  254.192481] {IN-HARDIRQ-W} state was registered at:
<4>[  254.192488]   lock_acquire+0xd1/0x3d0
<4>[  254.192504]   _raw_spin_lock+0x2a/0x40
<4>[  254.192519]   cmos_interrupt+0x18/0x100
<4>[  254.192536]   rtc_handler+0x1f/0xc0
<4>[  254.192553]   acpi_ev_fixed_event_detect+0x109/0x13c
<4>[  254.192574]   acpi_ev_sci_xrupt_handler+0xb/0x28
<4>[  254.192596]   acpi_irq+0x13/0x30
<4>[  254.192620]   __handle_irq_event_percpu+0x43/0x2c0
<4>[  254.192641]   handle_irq_event_percpu+0x2b/0x70
<4>[  254.192661]   handle_irq_event+0x2f/0x50
<4>[  254.192680]   handle_fasteoi_irq+0x9e/0x150
<4>[  254.192693]   __common_interrupt+0x76/0x140
<4>[  254.192715]   common_interrupt+0x96/0xc0
<4>[  254.192732]   asm_common_interrupt+0x1e/0x40
<4>[  254.192750]   _raw_spin_unlock_irqrestore+0x38/0x60
<4>[  254.192767]   resume_irqs+0xba/0xf0
<4>[  254.192786]   dpm_resume_noirq+0x245/0x3d0
<4>[  254.192811]   suspend_devices_and_enter+0x230/0xaa0
<4>[  254.192835]   pm_suspend.cold.8+0x301/0x34a
<4>[  254.192859]   state_store+0x7b/0xe0
<4>[  254.192879]   kernfs_fop_write_iter+0x11d/0x1c0
<4>[  254.192899]   new_sync_write+0x11d/0x1b0
<4>[  254.192916]   vfs_write+0x265/0x390
<4>[  254.192933]   ksys_write+0x5a/0xd0
<4>[  254.192949]   do_syscall_64+0x33/0x80
<4>[  254.192965]   entry_SYSCALL_64_after_hwframe+0x44/0xae
<4>[  254.192986] irq event stamp: 43775
<4>[  254.192994] hardirqs last  enabled at (43775): [<ffffffff81c00c42>] asm_sysvec_apic_timer_interrupt+0x12/0x20
<4>[  254.193023] hardirqs last disabled at (43774): [<ffffffff81aa691a>] sysvec_apic_timer_interrupt+0xa/0xb0
<4>[  254.193049] softirqs last  enabled at (42548): [<ffffffff81e00342>] __do_softirq+0x342/0x48e
<4>[  254.193074] softirqs last disabled at (42543): [<ffffffff810b45fd>] irq_exit_rcu+0xad/0xd0
<4>[  254.193101]
                  other info that might help us debug this:
<4>[  254.193107]  Possible unsafe locking scenario:

<4>[  254.193112]        CPU0
<4>[  254.193117]        ----
<4>[  254.193121]   lock(rtc_lock);
<4>[  254.193137]   <Interrupt>
<4>[  254.193142]     lock(rtc_lock);
<4>[  254.193156]
                   *** DEADLOCK ***

<4>[  254.193161] 6 locks held by rtcwake/5309:
<4>[  254.193174]  #0: ffff888104861430 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x5a/0xd0
<4>[  254.193232]  #1: ffff88810f823288 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xe7/0x1c0
<4>[  254.193282]  #2: ffff888100cef3c0 (kn->active#285
<7>[  254.192706] i915 0000:00:02.0: [drm:intel_modeset_setup_hw_state [i915]] [CRTC:51:pipe A] hw state readout: disabled
<4>[  254.193307] ){.+.+}-{0:0}, at: kernfs_fop_write_iter+0xf0/0x1c0
<4>[  254.193333]  #3: ffffffff82649fa8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend.cold.8+0xce/0x34a
<4>[  254.193387]  #4: ffffffff827a2108 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x47/0x70
<4>[  254.193433]  #5: ffff8881019ea178 (&dev->mutex){....}-{3:3}, at: device_resume+0x68/0x1e0
<4>[  254.193485]
                  stack backtrace:
<4>[  254.193492] CPU: 1 PID: 5309 Comm: rtcwake Not tainted 5.12.0-rc1-CI-CI_DRM_9834+ #1
<4>[  254.193514] Hardware name: Google Soraka/Soraka, BIOS MrChromebox-4.10 08/25/2019
<4>[  254.193524] Call Trace:
<4>[  254.193536]  dump_stack+0x7f/0xad
<4>[  254.193567]  mark_lock.part.47+0x8ca/0xce0
<4>[  254.193604]  __lock_acquire+0x39b/0x2590
<4>[  254.193626]  ? asm_sysvec_apic_timer_interrupt+0x12/0x20
<4>[  254.193660]  lock_acquire+0xd1/0x3d0
<4>[  254.193677]  ? cmos_interrupt+0x18/0x100
<4>[  254.193716]  _raw_spin_lock+0x2a/0x40
<4>[  254.193735]  ? cmos_interrupt+0x18/0x100
<4>[  254.193758]  cmos_interrupt+0x18/0x100
<4>[  254.193785]  cmos_resume+0x2ac/0x2d0
<4>[  254.193813]  ? acpi_pm_set_device_wakeup+0x1f/0x110
<4>[  254.193842]  ? pnp_bus_suspend+0x10/0x10
<4>[  254.193864]  pnp_bus_resume+0x5e/0x90
<4>[  254.193885]  dpm_run_callback+0x5f/0x240
<4>[  254.193914]  device_resume+0xb2/0x1e0
<4>[  254.193942]  ? pm_dev_err+0x25/0x25
<4>[  254.193974]  dpm_resume+0xea/0x3f0
<4>[  254.194005]  dpm_resume_end+0x8/0x10
<4>[  254.194030]  suspend_devices_and_enter+0x29b/0xaa0
<4>[  254.194066]  pm_suspend.cold.8+0x301/0x34a
<4>[  254.194094]  state_store+0x7b/0xe0
<4>[  254.194124]  kernfs_fop_write_iter+0x11d/0x1c0
<4>[  254.194151]  new_sync_write+0x11d/0x1b0
<4>[  254.194183]  vfs_write+0x265/0x390
<4>[  254.194207]  ksys_write+0x5a/0xd0
<4>[  254.194232]  do_syscall_64+0x33/0x80
<4>[  254.194251]  entry_SYSCALL_64_after_hwframe+0x44/0xae
<4>[  254.194274] RIP: 0033:0x7f07d79691e7
<4>[  254.194293] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
<4>[  254.194312] RSP: 002b:00007ffd9cc2c768 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
<4>[  254.194337] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f07d79691e7
<4>[  254.194352] RDX: 0000000000000004 RSI: 0000556ebfc63590 RDI: 000000000000000b
<4>[  254.194366] RBP: 0000556ebfc63590 R08: 0000000000000000 R09: 0000000000000004
<4>[  254.194379] R10: 0000556ebf0ec2a6 R11: 0000000000000246 R12: 0000000000000004

which breaks S3-resume on fi-kbl-soraka presumably as that's slow enough
to trigger the alarm during the suspend.

Fixes: 6950d046eb ("rtc: cmos: Replace spin_lock_irqsave with spin_lock in hard IRQ")
References: 66e4f4a9cc ("rtc: cmos: Use spin_lock_irqsave() in cmos_interrupt()"):
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Xiaofei Tan <tanxiaofei@huawei.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20210305122140.28774-1-chris@chris-wilson.co.uk
2021-09-14 10:20:19 +02:00
Mateusz Jończyk e1aba37569 rtc: cmos: remove stale REVISIT comments
It appears mc146818_get_time() and mc146818_set_time() now correctly
use the century register as specified in the ACPI FADT table. It is not
clear what else could be done here.

These comments were introduced by
        commit 7be2c7c96a ("[PATCH] RTC framework driver for CMOS RTCs")
in 2007, which originally referenced function get_rtc_time() in
include/asm-generic/rtc.h .

Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20210716210437.29622-1-mat.jonczyk@o2.pl
2021-08-17 23:39:20 +02:00
Linus Torvalds 0328b5f2ef RTC for 5.12
Subsystem:
  - Introduce features bitfield and the first feature: RTC_FEATURE_ALARM
 
 Removed drivers:
  - ab3100
  - coh901331
  - tx4939
  - sirfsoc
 
 Drivers:
  - use rtc_lock and rtc_unlock instead of opencoding
  - constify all struct rtc_class_ops
  - quiet maybe-unused variable warning
  - replace spin_lock_irqsave with spin_lock in hard IRQ
  - pcf2127: disable Power-On Reset Override and run OTP refresh
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEycoQi/giopmpPgB12wIijOdRNOUFAmAzAIAACgkQ2wIijOdR
 NOXVDhAArDkq1P46RK6GDQV6w++RTwqMRTVTCZLG0r+gOv6BiAo8TjEb+VMlJFi5
 4D4qVEo5BDxMxNRsB/vyWIrvXDpGW/vxTH3W4G/4lGHZObYluAGeoZ+qswRPaPHU
 upJd4OXK7AThjf9lhOuhiuea6oAGfhIl4keTu3pVUAfYMYBlS9zmU45pF4KESXzm
 6Wmed2QKx3+iUcBdwToMaDpd4uJcZ9HSPP/SPlO0P1KwhfUolCfFrHjY2oGuRVCN
 dYDZ995c5jx1PU5AlEBWXcWG7mWVEpESearUCjEKYiRgpJu85EJpDmoROa4XjL49
 XJYbfnM/ZFMVJpAKPGBuOX/PYMMyOOkiYQ0GE5iHYWBctzQr3cm6D9SMynymsJHY
 mo0abVSmWU6FmUH2+n4je7ixXfuf/H0T4/xYw+1xejwGk3XpWEVYwzU6YznCXKMn
 djPO6hL+87vJC8BaQNwdAGACrO4ludJdsX2XTNg89U8eUseuFb+xJjQ06ZJCHeFL
 zrdmHdkJkLqp7Zu/HnVTT74ZQ+bp/hn9voR19HFrMqwKtbPQUfOZhWjwJOcft/rk
 jFOdPadE+OwHDB8rvBshdqNbeyJ5AUeP+6+C6xgVAuLHWtpgG4UibXp+9MWbFcgk
 219o0s2ZI/rkX9n1K/3gmgp2Y4HlSOrYIkGiybvFl0cOpLJqoZk=
 =bK2K
 -----END PGP SIGNATURE-----

Merge tag 'rtc-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux

Pull RTC updates from Alexandre Belloni:
 "Many cleanups and a few drivers removal this cycle.

  Subsystem:
   - Introduce features bitfield and the first feature: RTC_FEATURE_ALARM

  Removed drivers:
   - ab3100
   - coh901331
   - tx4939
   - sirfsoc

  Drivers:
   - use rtc_lock and rtc_unlock instead of opencoding
   - constify all struct rtc_class_ops
   - quiet maybe-unused variable warning
   - replace spin_lock_irqsave with spin_lock in hard IRQ
   - pcf2127: disable Power-On Reset Override and run OTP refresh"

* tag 'rtc-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (81 commits)
  rtc: abx80x: Add utility function for writing configuration key
  rtc: pcf2127: properly set flag WD_CD for rtc chips(pcf2129, pca2129)
  rtc: pcf8563: Add NXP PCA8565 compatible
  rtc: s3c: quiet maybe-unused variable warning
  rtc: s3c: stop setting bogus time
  rtc: sd3078: quiet maybe-unused variable warning
  rtc: s35390a: quiet maybe-unused variable warning
  rtc: rx8581: quiet maybe-unused variable warning
  rtc: rx8010: quiet maybe-unused variable warning
  rtc: rv8803: quiet maybe-unused variable warning
  rtc: rv3032: quiet maybe-unused variable warning
  rtc: rv3029: quiet maybe-unused variable warning
  rtc: rv3028: quiet maybe-unused variable warning
  rtc: rs5c372: quiet maybe-unused variable warning
  rtc: pcf85363: quiet maybe-unused variable warning
  rtc: pcf85063: quiet maybe-unused variable warnings
  rtc: meson: quiet maybe-unused variable warning
  rtc: m41t80: quiet maybe-unused variable warning
  rtc: isl1208: quiet maybe-unused variable warning
  rtc: ds3232: quiet maybe-unused variable warning
  ...
2021-02-22 09:54:19 -08:00
Xiaofei Tan 6950d046eb rtc: cmos: Replace spin_lock_irqsave with spin_lock in hard IRQ
It is redundant to do irqsave and irqrestore in hardIRQ context, where
it has been in a irq-disabled context.

Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/1612355981-6764-2-git-send-email-tanxiaofei@huawei.com
2021-02-06 00:50:47 +01:00
Thomas Gleixner ebb22a0594 rtc: mc146818: Dont test for bit 0-5 in Register D
The recent change to validate the RTC turned out to be overly tight.

While it cures the problem on the reporters machine it breaks machines
with Intel chipsets which use bit 0-5 of the D register. So check only
for bit 6 being 0 which is the case on these Intel machines as well.

Fixes: 211e5db19d ("rtc: mc146818: Detect and handle broken RTCs")
Reported-by: Serge Belyshev <belyshev@depni.sinp.msu.ru>
Reported-by: Dirk Gouders <dirk@gouders.net>
Reported-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dirk Gouders <dirk@gouders.net>
Tested-by: Len Brown <len.brown@intel.com>
Tested-by: Borislav Petkov <bp@suse.de>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/87zh0nbnha.fsf@nanos.tec.linutronix.de
2021-02-02 20:35:02 +01:00
Thomas Gleixner 211e5db19d rtc: mc146818: Detect and handle broken RTCs
The recent fix for handling the UIP bit unearthed another issue in the RTC
code. If the RTC is advertised but the readout is straight 0xFF because
it's not available, the old code just proceeded with crappy values, but the
new code hangs because it waits for the UIP bit to become low.

Add a sanity check in the RTC CMOS probe function which reads the RTC_VALID
register (Register D) which should have bit 0-6 cleared. If that's not the
case then fail to register the CMOS.

Add the same check to mc146818_get_time(), warn once when the condition
is true and invalidate the rtc_time data.

Reported-by: Mickaël Salaün <mic@digikod.net>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Mickaël Salaün <mic@linux.microsoft.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/87tur3fx7w.fsf@nanos.tec.linutronix.de
2021-01-27 09:36:22 +01:00
Alexandre Belloni 30f5bd537f rtc: cmos: remove cmos_rtc_ops_no_alarm
Clear RTC_FEATURE_ALARM to signal that alarms are not available instead of
having a supplementary struct rtc_class_ops with a NULL .set_alarm.

Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20210110231752.1418816-5-alexandre.belloni@bootlin.com
2021-01-16 23:19:26 +01:00
Linus Torvalds f4a2f7866f RTC for 5.11
Subsystem:
  - Remove nvram ABI. There was no complaints about the deprecation for the last
    3 years.
  - Improve RTC device allocation and registration
  - Now available for ARCH=um
 
 Drivers:
  - at91rm9200: correction and sam9x60 support
  - ds1307: improve ACPI support
  - mxc: now DT only
  - pcf2127: watchdog support now needs the reset-source property
  - pcf8523: set range
  - rx6110: i2c support
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEycoQi/giopmpPgB12wIijOdRNOUFAl/eeIQACgkQ2wIijOdR
 NOU06g//Xf2697Zc59SziSwhbEFCEyfhY4P+Qm24ymuOb2wkApmaWGifdCRclcvR
 VncDLhyW9u5SpJiQY0ZMryTOmuE2KtbGfJX/tY9AGgQZioCxUIxELREwnqkQ2/8c
 cOu0C8nrBCAnDNi3jTryPCyFJN1oLCztcbMGWXGG7Irkehq7ywQ1TCxxWzF+w3su
 z38UzB1664ULfYYj3M2m/+2MV2rkf81P/4BTokKkZ2RLL1Q19wM0rFE0aXcKedel
 pZy/DXGwBWK4fDR/Q2YYxRnpEf8UzYzgCQWAiaJGdRane9Tx6H8wy9TcHc5OQfjn
 gtDtXje9Xwb+UJ27Mz19hNMts96n2G9S1Y0Pq5n0DD4AO0pDchYL41V5Z4hEDgMW
 Fm/ZQG+khVJCllMUPbwPU2H7iDrH6IVsi2pjfdw1EeLW5Zx2/0jPfuAeQ1KdDKQt
 UZ1SNxLZy2O7QL5Y+00pHlVFizTyGITz1H2IBG1Fn62abh7H9G5wfsB4AEldR+tr
 9Di/o7Q1Oo5goBtVdmqn3xfOr1QWlfU+/7qSwiz2uqXMR/UWVMlLSp7k2Hav1m5H
 6osjgRI6oQYHIbBwAQ3Hf98y/jOiddK6Wov6+gZGauO6M1//Q5NouQOXTe7RHwuG
 R5JP6lgCoZJPky0156qApAH8I6r6xV1A7W7CEnNKOK1JITqj5Hw=
 =n8V2
 -----END PGP SIGNATURE-----

Merge tag 'rtc-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux

Pull RTC updates from Alexandre Belloni:
 "Subsystem:

   - Remove nvram ABI. There was no complaints about the deprecation for
     the last 3 years.

   - Improve RTC device allocation and registration

   - Now available for ARCH=um

  Drivers:

   - at91rm9200: correction and sam9x60 support

   - ds1307: improve ACPI support

   - mxc: now DT only

   - pcf2127: watchdog support now needs the reset-source property

   - pcf8523: set range

   - rx6110: i2c support"

* tag 'rtc-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (43 commits)
  rtc: pcf2127: only use watchdog when explicitly available
  dt-bindings: rtc: add reset-source property
  rtc: fix RTC removal
  rtc: s3c: Remove dead code related to periodic tick handling
  rtc: s3c: Disable all enable (RTC, tick) bits in the probe
  rtc: ep93xx: Fix NULL pointer dereference in ep93xx_rtc_read_time
  rtc: test: remove debug message
  rtc: mxc{,_v2}: enable COMPILE_TEST
  rtc: enable RTC framework on ARCH=um
  rtc: pcf8523: use BIT
  rtc: pcf8523: set range
  rtc: pcf8523: switch to devm_rtc_allocate_device
  rtc: destroy mutex when releasing the device
  rtc: shrink devm_rtc_allocate_device()
  rtc: rework rtc_register_device() resource management
  rtc: nvmem: emit an error message when nvmem registration fails
  rtc: add devm_ prefix to rtc_nvmem_register()
  rtc: nvmem: remove nvram ABI
  Documentation: list RTC devres helpers in devres.rst
  rtc: omap: use devm_pinctrl_register()
  ...
2020-12-20 10:12:06 -08:00
Thomas Gleixner 69eca258c8 ntp: Make the RTC sync offset less obscure
The current RTC set_offset_nsec value is not really intuitive to
understand. 

  tsched       twrite(t2.tv_sec - 1) 	 t2 (seconds increment)

The offset is calculated from twrite based on the assumption that t2 -
twrite == 1s. That means for the MC146818 RTC the offset needs to be
negative so that the write happens 500ms before t2.

It's easier to understand when the whole calculation is based on t2. That
avoids negative offsets and the meaning is obvious:

 t2 - twrite:     The time defined by the chip when seconds increment
      		  after the write.

 twrite - tsched: The time for the transport to the point where the chip
 	  	  is updated. 

==> set_offset_nsec =  t2 - tsched
    ttransport      =  twrite - tsched
    tRTCinc         =  t2 - twrite
==> set_offset_nsec =  ttransport + tRTCinc

tRTCinc is a chip property and can be obtained from the data sheet.

ttransport depends on how the RTC is connected. It is close to 0 for
directly accessible RTCs. For RTCs behind a slow bus, e.g. i2c, it's the
time required to send the update over the bus. This can be estimated or
even calibrated, but that's a different problem.

Adjust the implementation and update comments accordingly.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201206220542.263204937@linutronix.de
2020-12-11 10:40:53 +01:00
Thomas Gleixner b0ecd8e8c5 rtc: cmos: Make rtc_cmos sync offset correct
The offset for rtc_cmos must be -500ms to work correctly with the current
implementation of rtc_set_ntp_time() due to the following:

  tsched       twrite(t2.tv_sec - 1) 	 t2 (seconds increment)

twrite - tsched is the transport time for the write to hit the device,
which is negligible for this chip because it's accessed directly.

t2 - twrite = 500ms according to the datasheet.

But rtc_set_ntp_time() calculation of tsched is:

    tsched = t2 - 1sec - (t2 - twrite)

The default for the sync offset is 500ms which means that the write happens
at t2 - 1.5 seconds which is obviously off by a second for this device.

Make the offset -500ms so it works correct.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201206220541.830517160@linutronix.de
2020-12-11 10:40:52 +01:00
Bartosz Golaszewski fdcfd85433 rtc: rework rtc_register_device() resource management
rtc_register_device() is a managed interface but it doesn't use devres
by itself - instead it marks an rtc_device as "registered" and the devres
callback for devm_rtc_allocate_device() takes care of resource release.

This doesn't correspond with the design behind devres where managed
structures should not be aware of being managed. The correct solution
here is to register a separate devres callback for unregistering the
device.

While at it: rename rtc_register_device() to devm_rtc_register_device()
and add it to the list of managed interfaces in devres.rst. This way we
can avoid any potential confusion of driver developers who may expect
there to exist a corresponding unregister function.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201109163409.24301-8-brgl@bgdev.pl
2020-11-19 12:50:12 +01:00
Bartosz Golaszewski 6746bc095b rtc: nvmem: emit an error message when nvmem registration fails
Some users check the return value of devm_rtc_nvmem_register() only in
order to emit an error message and then continue probing. This is fine
as an rtc can function without exposing nvmem but let's generalize it:
let's make the registration function emit the error message so that
users don't have to.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201109163409.24301-7-brgl@bgdev.pl
2020-11-19 12:50:12 +01:00
Bartosz Golaszewski 3a905c2d95 rtc: add devm_ prefix to rtc_nvmem_register()
rtc_nvmem_register() is a managed interface. It doesn't require any
release function to be called at driver detach. To avoid confusing
driver authors, let's rename it to devm_rtc_nvmem_register() and add it
to the list of managed interfaces in Documentation/.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201109163409.24301-6-brgl@bgdev.pl
2020-11-19 12:50:11 +01:00
Alexandre Belloni 25ece30561 rtc: nvmem: remove nvram ABI
The nvram sysfs attributes have been deprecated at least since v4.13, more
than 3 years ago and nobody ever complained about the deprecation warning.

Remove the sysfs attributes now.

[Bartosz: remove the declaration of rtc_nvmem_unregister()]

Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20201109163409.24301-5-brgl@bgdev.pl
2020-11-19 12:50:11 +01:00
Victor Ding c254bcd723 rtc: cmos: zero-init wkalrm when reading from CMOS
cmos_read_alarm() may leave certain fields of a struct rtc_wkalrm
untouched; therefore, these fields contain garbage if not properly
initialized, leading to inconsistent values when converting into
time64_t. This patch to zero initialize the struct before calling
cmos_read_alarm().

Note that this patch is not intended to produce a correct time64_t, it
is only to produce a consistent value. In the case of suspend/resume, a
correct time64_t is not necessary; a consistent value is sufficient to
correctly perform an equality test for t_current_expires and
t_saved_expires. Logic to deduce a correct time64_t is expensive and
hence should be avoided.

Signed-off-by: Victor Ding <victording@google.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20200814191654.v2.1.Iaf7638a2f2a87ff68d85fcb8dec615e41340c97f@changeid
2020-08-21 00:10:33 +02:00
Linus Torvalds bdabb68931 RTC for 5.7
Subsystem:
  - The rtc_time_to_tm and rtc_tm_to_time wrappers have finally been removed and
    only the 64bit version remain.
  - hctosys now works with drivers compiled as modules
 
 New driver:
  - MediaTek MT2712 SoC based RTC
 
 Drivers:
  - set range for 88pm860x, au1xxx, cpcap, da9052, davinci, ds1305, ds1374,
    mcp5121, pl030, pl031, pm8xxx, puv3, sa1100, sirfsoc, starfire, sun6i
  - ds1307: DS1388 oscillator failure detection and watchdog support
  - jz4740: JZ4760 support
  - pcf85063: clock out pin support
  - sun6i: external 32k oscillator is now optional, the range is now handled by
    the core, providing a solution for 2034.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEycoQi/giopmpPgB12wIijOdRNOUFAl6IgdAACgkQ2wIijOdR
 NOVH9Q//evfZmRDQb9Lm8YuSOt+U6lBaCuvRP8H4s7i02jsw0tt1oT6+rGo+1N+k
 pi64+iwPqDj7h+eds06jVur7yWZDNNfCSywlMU8ODGLQcc/hXMTvaIeJtdXG+I+7
 dpIVTs9Artiey2Qb3qZalSMYzrE2rQG6Yuyb/tHx7Pohvje1wKnAE3T64W6sfvir
 zjAwAr/+s9n82mjGtGLapz0onao7dSN4p6b3UIkph9KxPdeHjItd7cRiJuzioysj
 LE8WRUek++uha32PzghK9MoUpRKf8PJtGbsAIRhdwvmwub1Pqs6Uvk5IHQvdiFZx
 af1Qnw/4qUH03HVUuq8VdEkwa8mdthcZ72b8uzUWOqP+uPkeTTlQOGOd1dRECijK
 Qic+SKlEznwgKC9WuDufUQg5i2WjFBnBlA+dCE12/t91SbSlZdYjb53nQLHve1b9
 e4VfyKnS5Ghn/dfizzzSPdcWuPW1rqq2dHTiOvFVqlLn1Fkt1AKaJzGAeCe6PWp4
 AJVqPu+D1eQ/qmvEPXI7dQpCxdI+p6FNJgQvQLMssaq7mpf2fiRoLx23ikFG0v0k
 BeNkNWpLz2ACwHpsOa/RWLwa/FC2+KBHaRWf+As7te63byeDQC8hUEi7F5K78lSS
 yhfZ8SJR04SIIGKjuwAzPmaaIJ0hJT+eaxkFAJU7P5hD7KElsuM=
 =6Veu
 -----END PGP SIGNATURE-----

Merge tag 'rtc-5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux

Pull RTC updates from Alexandre Belloni:
 "More cleanup this cycle, with the final goal of removing the
  rtc_time_to_tm and rtc_tm_to_time wrappers. All the drivers that have
  been modified for this now are ready for the end of times (whether it
  happens in 2033, 2038, 2106, 2127 or even 4052). There is also a
  single new driver and the usual fixes and features.

  Summary:

  Subsystem:

   - The rtc_time_to_tm and rtc_tm_to_time wrappers have finally been
     removed and only the 64bit version remain.

   - hctosys now works with drivers compiled as modules

  New driver:

   - MediaTek MT2712 SoC based RTC

  Drivers:

   - set range for 88pm860x, au1xxx, cpcap, da9052, davinci, ds1305,
     ds1374, mcp5121, pl030, pl031, pm8xxx, puv3, sa1100, sirfsoc,
     starfire, sun6i

   - ds1307: DS1388 oscillator failure detection and watchdog support

   - jz4740: JZ4760 support

   - pcf85063: clock out pin support

   - sun6i: external 32k oscillator is now optional, the range is now
     handled by the core, providing a solution for 2034"

* tag 'rtc-5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (87 commits)
  rtc: ds1307: check for failed memory allocation on wdt
  rtc: class: remove redundant assignment to variable err
  rtc: remove rtc_time_to_tm and rtc_tm_to_time
  rtc: sun6i: let the core handle rtc range
  rtc: sun6i: switch to rtc_time64_to_tm/rtc_tm_to_time64
  rtc: ds1307: add support for watchdog timer on ds1388
  rtc: da9052: switch to rtc_time64_to_tm/rtc_tm_to_time64
  rtc: da9052: set range
  rtc: da9052: convert to devm_rtc_allocate_device
  rtc: imx-sc: Align imx sc msg structs to 4
  rtc: fsl-ftm-alarm: report alarm to core
  rtc: pcf85063: Add pcf85063 clkout control to common clock framework
  rtc: make definitions in include/uapi/linux/rtc.h actually useful for user space
  rtc: class: avoid unnecessary lookup in hctosys
  dt-bindings: rtc: Convert and update jz4740-rtc doc to YAML
  rtc: jz4740: Rename vendor-specific DT properties
  rtc: jz4740: Add support for JZ4760 SoC
  rtc: class: support hctosys from modular RTC drivers
  rtc: pm8xxx: clear alarm register when alarm is not enabled
  rtc: omap: drop unused dt-bindings header
  ...
2020-04-04 10:38:01 -07:00
Corentin Labbe 8d4e59ec94 rtc: cmos: remove useless cast for driver_name
Now the pnp_driver name is "const char *", there are no need to cast
driver_name.

Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-03-17 18:32:07 +01:00
Ville Syrjälä 66e4f4a9cc rtc: cmos: Use spin_lock_irqsave() in cmos_interrupt()
cmos_interrupt() isn't always called from hardirq context, so
we must use spin_lock_irqsave() & co.

================================
WARNING: inconsistent lock state
5.6.0-rc2-CI-CI_DRM_7981+ #1 Tainted: G     U
--------------------------------
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
rtcwake/4315 [HC0[0]:SC0[0]:HE1:SE1] takes:
ffffffff82635198 (rtc_lock){?...}, at: cmos_interrupt+0x18/0x100
{IN-HARDIRQ-W} state was registered at:
  lock_acquire+0xa7/0x1c0
  _raw_spin_lock+0x2a/0x40
  cmos_interrupt+0x18/0x100
  rtc_handler+0x75/0xc0
  acpi_ev_fixed_event_detect+0xf9/0x132
  acpi_ev_sci_xrupt_handler+0xb/0x28
  acpi_irq+0x13/0x30
  __handle_irq_event_percpu+0x41/0x2c0
  handle_irq_event_percpu+0x2b/0x70
  handle_irq_event+0x2f/0x50
  handle_fasteoi_irq+0x8e/0x150
  do_IRQ+0x7e/0x160
  ret_from_intr+0x0/0x35
  mwait_idle+0x7e/0x200
  do_idle+0x1bb/0x260
  cpu_startup_entry+0x14/0x20
  start_secondary+0x15f/0x1b0
  secondary_startup_64+0xa4/0xb0
irq event stamp: 42003
hardirqs last  enabled at (42003): [<ffffffff81a36567>] _raw_spin_unlock_irqrestore+0x47/0x60
hardirqs last disabled at (42002): [<ffffffff81a362ed>] _raw_spin_lock_irqsave+0xd/0x50
softirqs last  enabled at (41848): [<ffffffff81e00385>] __do_softirq+0x385/0x47f
softirqs last disabled at (41841): [<ffffffff810bab3a>] irq_exit+0xba/0xc0

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(rtc_lock);
  <Interrupt>
    lock(rtc_lock);

 *** DEADLOCK ***

6 locks held by rtcwake/4315:
 #0: ffff888175dc9408 (sb_writers#5){.+.+}, at: vfs_write+0x1a4/0x1d0
 #1: ffff88817406ca80 (&of->mutex){+.+.}, at: kernfs_fop_write+0xdd/0x1b0
 #2: ffff888179be85e0 (kn->count#236){.+.+}, at: kernfs_fop_write+0xe6/0x1b0
 #3: ffffffff82641e00 (system_transition_mutex){+.+.}, at: pm_suspend+0xb3/0x3b0
 #4: ffffffff826b3ee0 (acpi_scan_lock){+.+.}, at: acpi_suspend_begin+0x47/0x80
 #5: ffff888178fc3960 (&dev->mutex){....}, at: device_resume+0x92/0x1c0

stack backtrace:
CPU: 3 PID: 4315 Comm: rtcwake Tainted: G     U            5.6.0-rc2-CI-CI_DRM_7981+ #1
Hardware name: Google Soraka/Soraka, BIOS MrChromebox-4.10 08/25/2019
Call Trace:
 dump_stack+0x71/0x9b
 mark_lock+0x49a/0x500
 ? print_shortest_lock_dependencies+0x200/0x200
 __lock_acquire+0x6d4/0x15d0
 ? __lock_acquire+0x460/0x15d0
 lock_acquire+0xa7/0x1c0
 ? cmos_interrupt+0x18/0x100
 _raw_spin_lock+0x2a/0x40
 ? cmos_interrupt+0x18/0x100
 cmos_interrupt+0x18/0x100
 cmos_resume+0x1fd/0x290
 ? __acpi_pm_set_device_wakeup+0x24/0x100
 pnp_bus_resume+0x5e/0x90
 ? pnp_bus_suspend+0x10/0x10
 dpm_run_callback+0x64/0x280
 device_resume+0xd4/0x1c0
 ? dpm_watchdog_set+0x60/0x60
 dpm_resume+0x106/0x410
 ? dpm_resume_early+0x38c/0x3e0
 dpm_resume_end+0x8/0x10
 suspend_devices_and_enter+0x16f/0xbe0
 ? rcu_read_lock_sched_held+0x4d/0x80
 pm_suspend+0x344/0x3b0
 state_store+0x78/0xe0
 kernfs_fop_write+0x112/0x1b0
 vfs_write+0xb9/0x1d0
 ksys_write+0x9f/0xe0
 do_syscall_64+0x4f/0x220
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7ff934307154
Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 b1 07 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5
RSP: 002b:00007ffe2647c168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007ff934307154
RDX: 0000000000000004 RSI: 000055de3ec4e5a0 RDI: 000000000000000a
RBP: 000055de3ec4e5a0 R08: 000055de3ec4c5e0 R09: 00007ff9349f3740
R10: 000055de3ec4a010 R11: 0000000000000246 R12: 000055de3ec4c500
R13: 0000000000000004 R14: 00007ff9345df2a0 R15: 00007ff9345de760

Fixes: c6d3a278cc ("rtc: cmos: acknowledge ACPI driven wake alarms upon resume")
Fixes: 311ee9c151 ("rtc: cmos: allow using ACPI for RTC alarm instead of HPET")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20200221144739.11746-1-ville.syrjala@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2020-03-03 11:56:42 +01:00
Andy Shevchenko 604c521259 rtc: cmos: Refactor code by using the new dmi_get_bios_year() helper
Refactor code by using the new dmi_get_bios_year() helper instead of
open coding its functionality. This also makes logic slightly clearer.

No changes intended.

Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200123131437.28157-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2020-01-25 21:55:14 +01:00
Andy Shevchenko 5848ad2f1b rtc: cmos: Use predefined value for RTC IRQ on legacy x86
When legacy devices are present on x86 machine, the RTC IRQ has
a dedicated pre-defined value. Use it instead of hard coded number.

Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200123131437.28157-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2020-01-25 21:55:12 +01:00
Andy Shevchenko b6da197a2e rtc: cmos: Stop using shared IRQ
As reported by Guilherme G. Piccoli:

---8<---8<---8<---

The rtc-cmos interrupt setting was changed in the commit 079062b28f
("rtc: cmos: prevent kernel warning on IRQ flags mismatch") in order
to allow shared interrupts; according to that commit's description,
some machine got kernel warnings due to the interrupt line being shared
between rtc-cmos and other hardware, and rtc-cmos didn't allow IRQ sharing
that time.

After the aforementioned commit though it was observed a huge increase
in lost HPET interrupts in some systems, observed through the following
kernel message:

[...] hpet1: lost 35 rtc interrupts

After investigation, it was narrowed down to the shared interrupts
usage when having the kernel option "irqpoll" enabled. In this case,
all IRQ handlers are called for non-timer interrupts, if such handlers
are setup in shared IRQ lines. The rtc-cmos IRQ handler could be set to
hpet_rtc_interrupt(), which will produce the kernel "lost interrupts"
message after doing work - lots of readl/writel to HPET registers, which
are known to be slow.

Although "irqpoll" is not a default kernel option, it's used in some contexts,
one being the kdump kernel (which is an already "impaired" kernel usually
running with 1 CPU available), so the performance burden could be considerable.
Also, the same issue would happen (in a shorter extent though) when using
"irqfixup" kernel option.

In a quick experiment, a virtual machine with uptime of 2 minutes produced
>300 calls to hpet_rtc_interrupt() when "irqpoll" was set, whereas without
sharing interrupts this number reduced to 1 interrupt. Machines with more
hardware than a VM should generate even more unnecessary HPET interrupts
in this scenario.

---8<---8<---8<---

After looking into the rtc-cmos driver history and DSDT table from
the Microsoft Surface 3, we may notice that Hans de Goede submitted
a correct fix (see dependency below). Thus, we simply revert
the culprit commit.

Fixes: 079062b28f ("rtc: cmos: prevent kernel warning on IRQ flags mismatch")
Depends-on: a1e23a42f1 ("rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqs")
Reported-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200123131437.28157-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2020-01-25 21:54:57 +01:00
Thomas Gleixner 2874c5fd28 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152
Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license or at
  your option any later version

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 3029 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-30 11:26:32 -07:00
Hans de Goede fbb974ba69 rtc: cmos: Do not export alarm rtc_ops when we do not support alarms
When there is no IRQ configured for the RTC, the rtc-cmos code does not
support alarms, all alarm rtc_ops fail with -EIO / -EINVAL.

The rtc-core expects a rtc driver which does not support rtc alarms to
not have alarm ops at all. Otherwise the wakealarm sysfs attr will read
as empty rather then returning an error, making it impossible for
userspace to find out beforehand if alarms are supported.

A system without an IRQ for the RTC before this patch:
[root@localhost ~]# cat /sys/class/rtc/rtc0/wakealarm
[root@localhost ~]#

After this patch:
[root@localhost ~]# cat /sys/class/rtc/rtc0/wakealarm
cat: /sys/class/rtc/rtc0/wakealarm: No such file or directory
[root@localhost ~]#

This fixes gnome-session + systemd trying to use suspend-then-hibernate,
which causes systemd to abort the suspend when writing the RTC alarm fails.

BugLink: https://github.com/systemd/systemd/issues/9988
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-11-07 17:13:55 +01:00
Maciej W. Rozycki bc51098cdd rtc: cmos: Remove the `use_acpi_alarm' module parameter for !ACPI
Fix a problem with commit 311ee9c151 ("rtc: cmos: allow using ACPI for
RTC alarm instead of HPET") defining `use_acpi_alarm' module parameter
even for non-ACPI platforms, which ignore it.  Wrap the definition into
#ifdef CONFIG_ACPI and use a static inline wrapper function, hardcoded
to return 0 and consequently optimized away for !ACPI, following the
existing pattern with HPET handling functions.

Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Fixes: 311ee9c151 ("rtc: cmos: allow using ACPI for RTC alarm instead of HPET")
Cc: stable@vger.kernel.org # 4.18+
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-10-04 11:15:57 +02:00
Maciej W. Rozycki d197a25385 rtc: cmos: Fix non-ACPI undefined reference to `hpet_rtc_interrupt'
Fix a commit 311ee9c151 ("rtc: cmos: allow using ACPI for RTC alarm
instead of HPET") `rtc-cmos' regression causing a link error:

drivers/rtc/rtc-cmos.o: In function `cmos_platform_probe':
rtc-cmos.c:(.init.text+0x33c): undefined reference to `hpet_rtc_interrupt'
rtc-cmos.c:(.init.text+0x3f4): undefined reference to `hpet_rtc_interrupt'

with non-ACPI platforms using this driver.  The cause is the change of
the condition guarding the use of `hpet_rtc_interrupt'.

Previously it was a call to `is_hpet_enabled'.  That function is static
inline and has a hardcoded 0 result for non-ACPI platforms, which imply
!HPET_EMULATE_RTC.  Consequently the compiler optimized the whole block
away including the reference to `hpet_rtc_interrupt', which never made
it to the link stage.

Now the guarding condition is a call to `use_hpet_alarm', which is not
static inline and therefore the compiler may not be able to prove that
it actually always returns 0 for non-ACPI platforms.  Consequently the
build breaks with an unsatisfied reference, because `hpet_rtc_interrupt'
is nowhere defined at link time.

Fix the problem by marking `use_hpet_alarm' inline.  As the `inline'
keyword serves as an optimization hint rather than a requirement the
compiler is still free to choose whether inlining will be beneficial or
not for ACPI platforms.

Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Fixes: 311ee9c151 ("rtc: cmos: allow using ACPI for RTC alarm instead of HPET")
Cc: stable@vger.kernel.org # 4.18+
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-10-04 11:15:55 +02:00
Zhang Rui 36d91a4d40 rtc: cmos: introduce quirks to enable use_acpi_alarm mode
Use ACPI for RTC Alarm only for Intel platforms
1. with Low Power S0 support
2. with HPET RTC emulation enabled
3. no earlier than 2015

Note that, during the test, it is found that this patch
1. works in 4.15-rc kernel
2. hangs the platform after suspend-to-idle for 2 or 3 times, in 4.15.0
3. works again in 4.16-rc3 kernel.
4. works in the latest 4.15.12 stable kernel.

Thus although this patch breaks 4.15.0 kernel for some unknown reason,
still, it is safe for both upstream and backport.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-04-19 18:01:50 +02:00
Zhang Rui c6d3a278cc rtc: cmos: acknowledge ACPI driven wake alarms upon resume
Previously, the RTC alarm is acknowledged either by the cmos rtc irq
handler, or by the hpet rtc irq handler.

When using ACPI RTC Fixed event as the RTC alarm, the RTC alarm is
acknowledged by the ACPI RTC event handler, as addressed in the previous
patch.
But, when resume from suspend-to-ram (ACPI S3), the ACPI SCI is cleared
right after resume, thus the ACPI RTC event handler is not invoked at all,
results in the RTC Alarm unacknowledged.

Handle this by comparing the current time and the RTC Alarm time in the
rtc_cmos driver .resume() callback
1. Assume the wakeup event has already been fired if the RTC Alarm time
   is earlier than/equal to the current time, and ACK the RTC Alarm.
2. Assume the wakeup event has not been fired if the RTC Alarm time
   is later than current time, and re-arm it if needed.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-04-19 18:01:50 +02:00
Zhang Rui 311ee9c151 rtc: cmos: allow using ACPI for RTC alarm instead of HPET
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.

This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
   never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
   RTC as the wakeup source.

To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.

Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.

Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
   handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.

There is no functional change made in this patch if the new mode is not
enabled.

Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-04-19 18:01:50 +02:00
Linus Torvalds fbe173e3ff RTC for 4.17
Subsystem:
  - Add tracepoints
  - Rework of the RTC/nvmem API to allow drivers to discard struct nvmem_config
    after registration
  - New range API, drivers can now expose the useful range of the RTC
  - New offset API the core is now able to add an offset to the RTC time,
    modifying the supported range.
  - Multiple rtc_time64_to_tm fixes
  - Handle time_t overflow on 32 bit platforms in the core instead of letting
    drivers do crazy things.
  - remove rtc_control API
 
 New driver:
  - Intersil ISL12026
 
 Drivers:
  - Drivers exposing the RTC non volatile memory have been converted to use nvmem
  - Removed useless time and date validation
  - Removed an indirection pattern that was a cargo cult from ancient drivers
  - Removed VLA usage
  - Fixed a possible race condition in probe functions
  - AB8540 support is dropped from ab8500
  - pcf85363 now has alarm support
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEXx9Viay1+e7J/aM4AyWl4gNJNJIFAlrL3s4ACgkQAyWl4gNJ
 NJI+MxAAgc56UEXi5chqKpHE6GHL2aPWan9duHB6FmGrKWt/FJmpJ8UGylLFlvaW
 dpRGvW0Dynz45UztegcrbHMU6+B2O0hboL4/GVZpYAkcNAcu7Lf0ULho2rsQSDmW
 WJpemmdRxyQY1IkWmw7z7KAkMzhAfYZiVmWmVwMRZfMcKJ3DLEldfgRtkN+g0UdB
 tayWQY3mS02ki16e2figsgwZRmUUhQslDfpKlesInXOzUMmLgVWhf1QxJSEUcfs0
 AMp75vD2YvVJ/RHy/6BilQbqP9EVnaG4NHqJGFSOddazA7u+3HGubEFboI8NuPXb
 2fCvfrNux7pgtQsBF9dnpCqWlukE7sF5aDyIUvjYnr0vUm2D/CwdXglGvQSQVWea
 5GxPTWBdaCL0V7GD5OSZcfUGyz1TN/7NSUItdLSr9YK13dL+tqhcYYm5ytXJLzvO
 Z4GyUEoCOMprMJ9j5KU/TXSjauDmPDl8YZ5B93lPcNOh7y+b/2r3umBaInyZrFzX
 1WJ6FWtuhbRfEwuQtgQHBsobt9eTwZfo8C2y22HBo/fdWfBv45feiiHNXt3OVrA+
 aws6pwfVf1H0UsvpQkXtlPthAx3sbOTndDKAUhntb/U/zA9c7fTrfUyVOQ1bArJy
 p6tl/cmlpq68AjZB+0d3zUXQkQH4Syu+EqZrWItkE6XxZm+khDE=
 =l9i8
 -----END PGP SIGNATURE-----

Merge tag 'rtc-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux

Pull RTC updates from Alexandre Belloni:
 "This contains a few series that have been in preparation for a while
  and that will help systems with RTCs that will fail in 2038, 2069 or
  2100.

  Subsystem:
   - Add tracepoints
   - Rework of the RTC/nvmem API to allow drivers to discard struct
     nvmem_config after registration
   - New range API, drivers can now expose the useful range of the RTC
   - New offset API the core is now able to add an offset to the RTC
     time, modifying the supported range.
   - Multiple rtc_time64_to_tm fixes
   - Handle time_t overflow on 32 bit platforms in the core instead of
     letting drivers do crazy things.
   - remove rtc_control API

  New driver:
   - Intersil ISL12026

  Drivers:
   - Drivers exposing the RTC non volatile memory have been converted to
     use nvmem
   - Removed useless time and date validation
   - Removed an indirection pattern that was a cargo cult from ancient
     drivers
   - Removed VLA usage
   - Fixed a possible race condition in probe functions
   - AB8540 support is dropped from ab8500
   - pcf85363 now has alarm support"

* tag 'rtc-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (128 commits)
  rtc: snvs: Fix usage of snvs_rtc_enable
  rtc: mt7622: fix module autoloading for OF platform drivers
  rtc: isl12022: use true and false for boolean values
  rtc: ab8500: Drop AB8540 support
  rtc: remove a warning during scripts/kernel-doc step
  rtc: 88pm860x: remove artificial limitation
  rtc: 88pm80x: remove artificial limitation
  rtc: st-lpc: remove artificial limitation
  rtc: mrst: remove artificial limitation
  rtc: mv: remove artificial limitation
  rtc: hctosys: Ensure system time doesn't overflow time_t
  parisc: time: stop validating rtc_time in .read_time
  rtc: pcf85063: fix clearing bits in pcf85063_start_clock
  rtc: at91sam9: Set name of regmap_config
  rtc: s5m: Remove VLA usage
  rtc: s5m: Move enum from rtc.h to rtc-s5m.c
  rtc: remove VLA usage
  rtc: Add useful timestamp definitions
  rtc: Add one offset seconds to expand RTC range
  rtc: Factor out the RTC range validation into rtc_valid_range()
  ...
2018-04-10 10:22:27 -07:00
David Howells 739d875dd6 mn10300: Remove the architecture
Remove the MN10300 arch as the hardware is defunct.

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Masahiro Yamada <yamada.masahiro@socionext.com>
cc: linux-am33-list@redhat.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-03-09 23:19:56 +01:00
Alexandre Belloni 812318a094 rtc: cmos: let the core handle invalid time
Setting the rtc to a valid time when the time is invalid is a bad practice,
because then userspace doesn't know it shouldn't trust the RTC.

Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-01 10:49:39 +01:00
Alexandre Belloni 8b5b7958fd rtc: cmos: use generic nvmem
Instead of adding a binary sysfs attribute from the driver, use the
core to register an nvmem device. This allows to use the in-kernel
interface to access the nvram.

Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-01 10:49:29 +01:00