linux-toradex.git/drivers/rtc/rtc-cmos.c, branch v4.9-rc5

rtc: cmos: avoid unused function warning

2016-09-22T12:23:29+00:00

A bug fix for the ACPI side of this driver caused a harmless
build warning:

drivers/rtc/rtc-cmos.c:1115:13: error: 'cmos_check_acpi_rtc_status' defined but not used [-Werror=unused-function]
 static void cmos_check_acpi_rtc_status(struct device *dev,

We can avoid the warning and simplify the driver at the same time
by removing the #ifdef for CONFIG_PM and rely on the SIMPLE_DEV_PM_OPS()
to set everything up correctly. cmos_resume() has to get marked
as __maybe_unused so we don't introduce another warning, and
the two variants of cmos_poweroff() can get merged into one using
an IS_ENABLED() check.

Fixes: 983bf1256edb ("rtc: cmos: Clear ACPI-driven alarms upon resume")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Alexandre Belloni

rtc: cmos: Restore alarm after resume

2016-09-21T20:09:00+00:00

Some platform firmware may interfere with the RTC alarm over suspend,
resulting in the kernel and hardware having different ideas about system
state but also potentially causing problems with firmware that assumes the
OS will clean this case up.  This patch restores the RTC alarm on resume
to ensure that kernel and hardware are in sync.

The case we've seen is Intel Rapid Start, which is a firmware-mediated
feature that automatically transitions systems from suspend-to-RAM to
suspend-to-disk without OS involvement.  It does this by setting the RTC
alarm and a flag that indicates that on wake it should perform the
transition rather than re-starting the OS.  However, if the OS has set a
wakeup alarm that would wake the machine earlier, it refuses to overwrite
it and allows the system to wake instead.

This fails in the following situation:

1) User configures Intel Rapid Start to transition after (say) 15
minutes
2) User suspends to RAM. Firmware sets the wakeup alarm for 15 minutes
in the future
3) User resumes after 5 minutes. Firmware does not reset the alarm, and
as such it is still set for 10 minutes in the future
4) User suspends after 5 minutes. Firmware notices that the alarm is set
for 5 minutes in the future, which is less than the 15 minute transition
threshold. It therefore assumes that the user wants the machine to wake
in 5 minutes
5) System resumes after 5 minutes

The worst case scenario here is that the user may have put the system in a
bag between (4) and (5), resulting in it running in a confined space and
potentially overheating.  This seems reasonably important.  The Rapid
Start support code got added in 3.11, but it can be configured in the
firmware regardless of kernel support.

Signed-off-by: Gabriele Mazzotta 
Signed-off-by: Alexandre Belloni

rtc: cmos: Clear ACPI-driven alarms upon resume

2016-09-21T20:08:42+00:00

Currently ACPI-driven alarms are not cleared when they wake the
system. As consequence, expired alarms must be manually cleared to
program a new alarm. Fix this by correctly handling ACPI-driven
alarms.

More specifically, the ACPI specification [1] provides for two
alternative implementations of the RTC. Depending on the
implementation, the driver either clear the alarm from the resume
callback or from ACPI interrupt handler:

 - The platform has the RTC wakeup status fixed in hardware
   (ACPI_FADT_FIXED_RTC is 0). In this case the driver can determine
   if the RTC was the reason of the wakeup from the resume callback
   by reading the RTC status register.

 - The platform has no fixed hardware feature event bits. In this
   case a GPE is used to wake the system and the driver clears the
   alarm from its handler.

[1] http://www.acpi.info/DOWNLOADS/ACPI_5_Errata%20A.pdf

Signed-off-by: Gabriele Mazzotta 
Signed-off-by: Alexandre Belloni

rtc: cmos: Initialize hpet timer before irq is registered

2016-09-19T22:22:00+00:00

We have observed on few x86 machines with rtc-cmos device that
hpet_rtc_interrupt() is called just after irq registration and before
cmos_do_probe() could call hpet_rtc_timer_init().

So, neither hpet_default_delta nor hpet_t1_cmp is initialized by the time
interrupt is raised in the given situation, and this results in NMI
watchdog LOCKUP.

It has only been observed sporadically on kdump secondary kernels.

See the call trace:
---<-snip->---
[   27.913194] Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 0
[   27.915371] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-342.el7.x86_64 #1
[   27.917503] Hardware name: HP ProLiant DL160 Gen8, BIOS J03 02/10/2014
[   27.919455]  ffffffff8186a728 0000000059c82488 ffff880034e05af0 ffffffff81637bd4
[   27.921870]  ffff880034e05b70 ffffffff8163144a 0000000000000010 ffff880034e05b80
[   27.924257]  ffff880034e05b20 0000000059c82488 0000000000000000 0000000000000000
[   27.926599] Call Trace:
[   27.927352]    [] dump_stack+0x19/0x1b
[   27.929080]  [] panic+0xd8/0x1e7
[   27.930588]  [] ? restart_watchdog_hrtimer+0x50/0x50
[   27.932502]  [] watchdog_overflow_callback+0xc2/0xd0
[   27.934427]  [] __perf_event_overflow+0xa1/0x250
[   27.936232]  [] perf_event_overflow+0x14/0x20
[   27.937957]  [] intel_pmu_handle_irq+0x1e8/0x470
[   27.939799]  [] perf_event_nmi_handler+0x2b/0x50
[   27.941649]  [] nmi_handle.isra.0+0x69/0xb0
[   27.943348]  [] do_nmi+0x169/0x340
[   27.944802]  [] end_repeat_nmi+0x1e/0x2e
[   27.946424]  [] ? hpet_rtc_interrupt+0x85/0x380
[   27.948197]  [] ? hpet_rtc_interrupt+0x85/0x380
[   27.949992]  [] ? hpet_rtc_interrupt+0x85/0x380
[   27.951816]  <>    [] ? run_timer_softirq+0x43/0x340
[   27.954114]  [] handle_irq_event_percpu+0x3e/0x1e0
[   27.955962]  [] handle_irq_event+0x3d/0x60
[   27.957635]  [] handle_edge_irq+0x77/0x130
[   27.959332]  [] handle_irq+0xbf/0x150
[   27.960949]  [] do_IRQ+0x4f/0xf0
[   27.962434]  [] common_interrupt+0x6d/0x6d
[   27.964101]    [] ? _raw_spin_unlock_irqrestore+0x1b/0x40
[   27.966308]  [] __setup_irq+0x2a7/0x570
[   28.067859]  [] ? hpet_cpuhp_notify+0x140/0x140
[   28.069709]  [] request_threaded_irq+0xcc/0x170
[   28.071585]  [] cmos_do_probe+0x1e6/0x450
[   28.073240]  [] ? cmos_do_probe+0x450/0x450
[   28.074911]  [] cmos_pnp_probe+0xbb/0xc0
[   28.076533]  [] pnp_device_probe+0x65/0xd0
[   28.078198]  [] driver_probe_device+0x87/0x390
[   28.079971]  [] __driver_attach+0x93/0xa0
[   28.081660]  [] ? __device_attach+0x40/0x40
[   28.083662]  [] bus_for_each_dev+0x73/0xc0
[   28.085370]  [] driver_attach+0x1e/0x20
[   28.086974]  [] bus_add_driver+0x200/0x2d0
[   28.088634]  [] ? rtc_sysfs_init+0xe/0xe
[   28.090349]  [] driver_register+0x64/0xf0
[   28.091989]  [] pnp_register_driver+0x20/0x30
[   28.093707]  [] cmos_init+0x11/0x71
---<-snip->---

This patch moves hpet_rtc_timer_init() before IRQ registration, so that we
can gracefully handle such spurious interrupts. It also masks HPET RTC
interrupts, in case IRQ registration fails.

We were able to reproduce the problem in maximum 15 trials of kdump
secondary kernel boot on an hp-dl160gen8 FCoE host machine without this
patch.  However, more than 35 trials went fine after applying this patch.

Suggested-by: Thomas Gleixner 
Signed-off-by: Pratyush Anand 
Acked-by: Thomas Gleixner 
Signed-off-by: Alexandre Belloni

rtc: simplify implementations of read_alarm

2016-07-09T08:24:45+00:00

Since commit d68778b80dd7 ("rtc: initialize output parameter for read
alarm to "uninitialized"") there is no need to explicitly set
unsupported members to -1. So drop the respective assignments from
drivers.

Signed-off-by: Uwe Kleine-König 
Signed-off-by: Alexandre Belloni

mn10300: use RTC_DRV_CMOS instead of CONFIG_RTC

2016-06-25T23:20:08+00:00

nn10300 has a dependency on mc146818_get_time/mc146818_set_time,
which we want to move from the mc146818rtc.h header into the
rtc subsystem, which in turn is not usable on mn10300.

This changes mn10300 to use the modern rtc-cmos driver instead
of the old RTC driver, and that in turn lets us completely
remove the read_persistent_clock/update_persistent_clock callbacks.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Alexandre Belloni

rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h

2016-06-03T22:20:00+00:00

Drivers should not really include stuff from asm-generic directly,
and the PC-style cmos rtc driver does this in order to reuse the
mc146818 implementation of get_rtc_time/set_rtc_time rather than
the architecture specific one for the architecture it gets built for.

To make it more obvious what is going on, this moves and renames the
two functions into include/linux/mc146818rtc.h, which holds the
other mc146818 specific code. Ideally it would be in a .c file,
but that would require extra infrastructure as the functions are
called by multiple drivers with conflicting dependencies.

With this change, the asm-generic/rtc.h header also becomes much
more generic, so it can be reused more easily across any architecture
that still relies on the genrtc driver.

The only caller of the internal __get_rtc_time/__set_rtc_time
functions is in arch/alpha/kernel/rtc.c, and we just change those
over to the new naming.

Signed-off-by: Arnd Bergmann 
Acked-by: Geert Uytterhoeven 
Signed-off-by: Alexandre Belloni

rtc: Use IS_ENABLED() instead of checking for built-in or module

2016-05-20T10:33:51+00:00

The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either
built-in or as a module, use that macro instead of open coding the same.

Signed-off-by: Javier Martinez Canillas 
Signed-off-by: Alexandre Belloni

rtc: cmos: prevent kernel warning on IRQ flags mismatch

2016-01-11T19:38:50+00:00

The Microsoft Surface 3 tablet shares interrupt line between RTC and one of SPI
controllers. However, the rtc_cmos driver doesn't allow shared interrupts and
user sees the following warning

genirq: Flags mismatch irq 8. 00000080 (8086228E:02) vs. 00000000 (rtc0)
...
[] pxa2xx_spi_probe+0x151/0x600 [spi_pxa2xx_platform]

Allow RTC driver to use shared interrupts.

Seems we are on the safe side to do just this simple change since
cmos_interrupt() handler checks for the actual hardware status anyway.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Alexandre Belloni

rtc: cmos: clean up cmos_nvram_read()/cmos_nvram_write()

2015-09-05T11:19:09+00:00

The change removes redundant sysfs binary file boundary checks, since
this task is already done on caller side in fs/sysfs/file.c

Signed-off-by: Vladimir Zapolskiy 
Signed-off-by: Alexandre Belloni