summaryrefslogtreecommitdiff
path: root/drivers/rtc/rtc-cmos.c
AgeCommit message (Collapse)Author
2019-05-30treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152Thomas Gleixner
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>
2018-11-07rtc: cmos: Do not export alarm rtc_ops when we do not support alarmsHans de Goede
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-10-04rtc: cmos: Remove the `use_acpi_alarm' module parameter for !ACPIMaciej W. Rozycki
Fix a problem with commit 311ee9c151ad ("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: 311ee9c151ad ("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-04rtc: cmos: Fix non-ACPI undefined reference to `hpet_rtc_interrupt'Maciej W. Rozycki
Fix a commit 311ee9c151ad ("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: 311ee9c151ad ("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-04-19rtc: cmos: introduce quirks to enable use_acpi_alarm modeZhang Rui
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-19rtc: cmos: acknowledge ACPI driven wake alarms upon resumeZhang Rui
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-19rtc: cmos: allow using ACPI for RTC alarm instead of HPETZhang Rui
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-10Merge tag 'rtc-4.17' of ↵Linus Torvalds
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-03-09mn10300: Remove the architectureDavid Howells
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-01rtc: cmos: let the core handle invalid timeAlexandre Belloni
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-01rtc: cmos: use generic nvmemAlexandre Belloni
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-01rtc: cmos: fix possible race conditionAlexandre Belloni
The probe function is not allowed to fail after registering the RTC because the following may happen: CPU0: CPU1: sys_load_module() do_init_module() do_one_initcall() cmos_do_probe() rtc_device_register() __register_chrdev() cdev->owner = struct module* open("/dev/rtc0") rtc_device_unregister() module_put() free_module() module_free(mod->module_core) /* struct module *module is now freed */ chrdev_open() spin_lock(cdev_lock) cdev_get() try_module_get() module_is_live() /* dereferences already freed struct module* */ Switch to devm_rtc_allocate_device/rtc_register_device to register the rtc as late as possible. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2017-05-22Merge branches 'pm-sleep' and 'powercap'Rafael J. Wysocki
* pm-sleep: PM / hibernate: Declare variables as static RTC: rtc-cmos: Fix wakeup from suspend-to-idle PM / wakeup: Fix up wakeup_source_report_event() * powercap: PowerCap: Fix an error code in powercap_register_zone()
2017-05-14RTC: rtc-cmos: Fix wakeup from suspend-to-idleRafael J. Wysocki
Commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle) modified the core suspend-to-idle code to filter out spurious SCI interrupts received while suspended, which requires ACPI event source handlers to report wakeup events in a way that will trigger a wakeup from suspend to idle (or abort system suspends in progress, which is equivalent). That needs to be done in the rtc-cmos driver too, which was overlooked by the above commit, so do that now. Fixes: eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle) Reported-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-04-14rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqsHans de Goede
On some systems (e.g. Intel Bay Trail systems) the legacy PIC is not used, in this case virq 8 will be a random irq, rather then hw_irq 8 from the PIC. Requesting virq 8 in this case will not help us to get alarm irqs and may cause problems for other drivers which actually do need virq 8, for example on an Asus Transformer T100TA this leads to: [ 28.745155] genirq: Flags mismatch irq 8. 00000088 (mmc0) vs. 00000080 (rtc0) <snip oops> [ 28.753700] mmc0: Failed to request IRQ 8: -16 [ 28.975934] sdhci-acpi: probe of 80860F14:01 failed with error -16 This commit fixes this by making the rtc-cmos driver continue without using an irq rather then claiming irq 8 when no irq is specified in the pnp-info and there are no legacy-irqs. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2016-12-18Merge tag 'rtc-4.10' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux Pull RTC updates from Alexandre Belloni: "Subsystem: - non-modular drivers are now explicitly non-modular New driver: - Epson Toyocom rtc-7301sf/dg Drivers: - cmos: reject unsupported alarm values wrt the RTC capabilities - ds1307: ACPI support - jz4740: DT support, jz4780 handling, can now be used as a system power controller - mcp795: many fixes, in particular proper month handling - twl: driver is now DT only" * tag 'rtc-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (31 commits) rtc: mcp795: Fix whitespace and indentation. rtc: mcp795: Prefer using the BIT() macro. rtc: mcp795: fix month write resetting date to 1. rtc: mcp795: fix time range difference between linux and RTC chip. rtc: mcp795: fix bitmask value for leap year (LP). rtc: mcp795: use bcd2bin/bin2bcd. rtc: add support for EPSON TOYOCOM RTC-7301SF/DG rtc: ds1307: Add ACPI support rtc: imxdi: (trivial) fix a typo rtc: ds1374: Merge conditional + WARN_ON() rtc: twl: make driver DT only rtc: twl: kill static variables rtc: fix typos in Kconfig rtc: jz4740: make the driver builtin only rtc: jz4740: remove unused EXPORT_SYMBOL Documentation: bindings: fix twl-rtc documentation rtc: Enable compile testing for Maxim and Samsung drivers MIPS: jz4740: Remove obsolete code MIPS: qi_lb60: Probe RTC driver from DT and use it as power controller MIPS: jz4740: DTS: Probe the jz4740-rtc driver from devicetree ...
2016-12-12Merge branch 'timers-core-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer updates from Thomas Gleixner: "The time/timekeeping/timer folks deliver with this update: - Fix a reintroduced signed/unsigned issue and cleanup the whole signed/unsigned mess in the timekeeping core so this wont happen accidentaly again. - Add a new trace clock based on boot time - Prevent injection of random sleep times when PM tracing abuses the RTC for storage - Make posix timers configurable for real tiny systems - Add tracepoints for the alarm timer subsystem so timer based suspend wakeups can be instrumented - The usual pile of fixes and updates to core and drivers" * 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (23 commits) timekeeping: Use mul_u64_u32_shr() instead of open coding it timekeeping: Get rid of pointless typecasts timekeeping: Make the conversion call chain consistently unsigned timekeeping_Force_unsigned_clocksource_to_nanoseconds_conversion alarmtimer: Add tracepoints for alarm timers trace: Update documentation for mono, mono_raw and boot clock trace: Add an option for boot clock as trace clock timekeeping: Add a fast and NMI safe boot clock timekeeping/clocksource_cyc2ns: Document intended range limitation timekeeping: Ignore the bogus sleep time if pm_trace is enabled selftests/timers: Fix spelling mistake "Asyncrhonous" -> "Asynchronous" clocksource/drivers/bcm2835_timer: Unmap region obtained by of_iomap clocksource/drivers/arm_arch_timer: Map frame with of_io_request_and_map() arm64: dts: rockchip: Arch counter doesn't tick in system suspend clocksource/drivers/arm_arch_timer: Don't assume clock runs in suspend posix-timers: Make them configurable posix_cpu_timers: Move the add_device_randomness() call to a proper place timer: Move sys_alarm from timer.c to itimer.c ptp_clock: Allow for it to be optional Kconfig: Regenerate *.c_shipped files after previous changes ...
2016-11-29timekeeping: Ignore the bogus sleep time if pm_trace is enabledChen Yu
Power management suspend/resume tracing (ab)uses the RTC to store suspend/resume information persistently. As a consequence the RTC value is clobbered when timekeeping is resumed and tries to inject the sleep time. Commit a4f8f6667f09 ("timekeeping: Cap array access in timekeeping_debug") plugged a out of bounds array access in the timekeeping debug code which was caused by the clobbered RTC value, but we still use the clobbered RTC value for sleep time injection into kernel timekeeping, which will result in random adjustments depending on the stored "hash" value. To prevent this keep track of the RTC clobbering and ignore the invalid RTC timestamp at resume. If the system resumed successfully clear the flag, which marks the RTC as unusable, warn the user about the RTC clobber and recommend to adjust the RTC with 'ntpdate' or 'rdate'. [jstultz: Fixed up pr_warn formating, and implemented suggestions from Ingo] [ tglx: Rewrote changelog ] Originally-from: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Chen Yu <yu.c.chen@intel.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Acked-by: Pavel Machek <pavel@ucw.cz> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Prarit Bhargava <prarit@redhat.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Xunlei Pang <xlpang@redhat.com> Cc: Len Brown <lenb@kernel.org> Link: http://lkml.kernel.org/r/1480372524-15181-3-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2016-10-20rtc: cmos: Don't enable interrupts in the middle of the interrupt handlerVille Syrjälä
Using spin_lock_irq()/spin_unlock_irq() from within the interrupt handler is a no-no. Let's save/restore the flags to avoid turning on interrupts prematurely. We hit this in a bunch of our CI systems, but for whatever reason I wasn't able to reproduce on my own machine, so this fix is just based on the backtrace. [ 202.634918] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2729 trace_hardirqs_on_caller+0x113/0x1b0 [ 202.634919] DEBUG_LOCKS_WARN_ON(current->hardirq_context) [ 202.634929] Modules linked in: snd_hda_intel i915 x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel lpc_ich snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_codec snd_hwdep i2c_designware_platform i2c_designware_core snd_hda_core mei_me mei snd_pcm r8169 mii sdhci_acpi sdhci mmc_core i2c_hid [last unloaded: i915] [ 202.634930] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G U 4.9.0-rc1-CI-CI_DRM_1734+ #1 [ 202.634931] Hardware name: GIGABYTE M4HM87P-00/M4HM87P-00, BIOS F6 12/10/2014 [ 202.634933] ffff88011ea03d68 ffffffff8142dce5 ffff88011ea03db8 0000000000000000 [ 202.634934] ffff88011ea03da8 ffffffff8107e496 00000aa900000002 ffffffff81e249a0 [ 202.634935] ffffffff81815637 ffffffff82e7c280 0000000000000000 0000000000000004 [ 202.634936] Call Trace: [ 202.634939] <IRQ> [ 202.634939] [<ffffffff8142dce5>] dump_stack+0x67/0x92 [ 202.634941] [<ffffffff8107e496>] __warn+0xc6/0xe0 [ 202.634944] [<ffffffff81815637>] ? _raw_spin_unlock_irq+0x27/0x50 [ 202.634945] [<ffffffff8107e4fa>] warn_slowpath_fmt+0x4a/0x50 [ 202.634946] [<ffffffff810d6d83>] trace_hardirqs_on_caller+0x113/0x1b0 [ 202.634948] [<ffffffff810d6e2d>] trace_hardirqs_on+0xd/0x10 [ 202.634949] [<ffffffff81815637>] _raw_spin_unlock_irq+0x27/0x50 [ 202.634951] [<ffffffff81672042>] rtc_handler+0x32/0xa0 [ 202.634954] [<ffffffff814c08a3>] acpi_ev_fixed_event_detect+0xd4/0xfb [ 202.634956] [<ffffffff814c2ccb>] acpi_ev_sci_xrupt_handler+0xf/0x2d [ 202.634957] [<ffffffff814ab3ee>] acpi_irq+0x11/0x2c [ 202.634960] [<ffffffff810e5288>] __handle_irq_event_percpu+0x58/0x370 [ 202.634961] [<ffffffff810e55be>] handle_irq_event_percpu+0x1e/0x50 [ 202.634962] [<ffffffff810e5624>] handle_irq_event+0x34/0x60 [ 202.634963] [<ffffffff810e8906>] handle_fasteoi_irq+0xa6/0x170 [ 202.634966] [<ffffffff8101eef5>] handle_irq+0x15/0x20 [ 202.634967] [<ffffffff8101e548>] do_IRQ+0x68/0x130 [ 202.634968] [<ffffffff81816789>] common_interrupt+0x89/0x89 [ 202.634970] <EOI> [ 202.634970] [<ffffffff81814c73>] ? mwait_idle+0x93/0x210 [ 202.634971] [<ffffffff81814c6a>] ? mwait_idle+0x8a/0x210 [ 202.634972] [<ffffffff81026b0a>] arch_cpu_idle+0xa/0x10 [ 202.634973] [<ffffffff8181509e>] default_idle_call+0x1e/0x30 [ 202.634974] [<ffffffff810cbf6c>] cpu_startup_entry+0x17c/0x1f0 [ 202.634976] [<ffffffff8180ca87>] rest_init+0x127/0x130 [ 202.634978] [<ffffffff81f77f08>] start_kernel+0x3f6/0x403 [ 202.634980] [<ffffffff81f7728f>] x86_64_start_reservations+0x2a/0x2c [ 202.634981] [<ffffffff81f77404>] x86_64_start_kernel+0x173/0x186 [ 202.634982] ---[ end trace 293c99618fa08d34 ]--- Cc: Gabriele Mazzotta <gabriele.mzt@gmail.com> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com> Fixes: 983bf1256edb ("rtc: cmos: Clear ACPI-driven alarms upon resume") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2016-10-19rtc: cmos: don't refer to asm-generic/rtc.hChristoph Hellwig
That header has been gone for a while. I've fixed up the Kconfig comment, but the one in rtc-cmos.c doesn't make any sense to me even looking at its history. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2016-10-19rtc: cmos: Reject unsupported alarm valuesGabriele Mazzotta
Some platforms allows to specify the month and day of the month in which an alarm should go off, some others the day of the month and some others just the time. Currently any given value is accepted by the driver and only the supported fields are used to program the hardware. As consequence, alarms are potentially programmed to go off in the wrong moment. Fix this by rejecting any unsupported value. Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2016-10-19rtc: cmos: remove all __exit_p annotationsLABBE Corentin
I got the following stack trace under qemu: [ 7.575243] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [ 7.596098] IP: [<ffffffff814f5b08>] cmos_set_alarm+0x38/0x280 [ 7.615699] PGD 3ccbe067 [ 7.615923] PUD 3daf2067 [ 7.635156] PMD 0 [ 7.654358] Oops: 0000 [#1] SMP [ 7.673869] Modules linked in: [ 7.693235] CPU: 0 PID: 1701 Comm: hwclock Tainted: G W 4.9.0-rc1+ #24 [ 7.712455] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 [ 7.753569] task: ffff88003d88dc40 task.stack: ffffc90000224000 [ 7.773743] RIP: 0010:[<ffffffff814f5b08>] [<ffffffff814f5b08>] cmos_set_alarm+0x38/0x280 [ 7.794893] RSP: 0018:ffffc90000227c10 EFLAGS: 00010296 [ 7.815890] RAX: 000000000000001d RBX: ffffc90000227d28 RCX: ffffffff8182be78 [ 7.836057] RDX: 0000000000000001 RSI: 0000000000000202 RDI: 0000000000000202 [ 7.856612] RBP: ffffc90000227c48 R08: 0000000000000000 R09: 0000000000000001 [ 7.877561] R10: 00000000000001c0 R11: 00000000000001c0 R12: 0000000000000000 [ 7.897072] R13: ffff88003d96f400 R14: ffff88003dac6410 R15: ffff88003dac6420 [ 7.917403] FS: 00007f77f42d9700(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000 [ 7.938293] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7.958364] CR2: 0000000000000010 CR3: 000000003ccbb000 CR4: 00000000000006f0 [ 7.978028] Stack: [ 7.997120] ffff88003dac6000 ffff88003dac6410 0000000058049d01 ffffc90000227d28 [ 8.016993] ffff88003dac6000 ffff88003dac6410 ffff88003dac6420 ffffc90000227c98 [ 8.039505] ffffffff814f225d 0000001800227c98 000000090000002a 0000000900000011 [ 8.059985] Call Trace: [ 8.080110] [<ffffffff814f225d>] __rtc_set_alarm+0x8d/0xa0 [ 8.099421] [<ffffffff814f2389>] rtc_timer_enqueue+0x119/0x190 [ 8.119925] [<ffffffff814f2e6e>] rtc_update_irq_enable+0xbe/0x100 [ 8.140583] [<ffffffff814f3bb0>] rtc_dev_ioctl+0x3c0/0x480 [ 8.161162] [<ffffffff81146b6a>] ? user_path_at_empty+0x3a/0x50 [ 8.182717] [<ffffffff8114aa36>] do_vfs_ioctl+0x96/0x5c0 [ 8.204624] [<ffffffff8113e066>] ? vfs_stat+0x16/0x20 [ 8.225994] [<ffffffff8113e135>] ? SyS_newstat+0x15/0x30 [ 8.247043] [<ffffffff8114afa7>] SyS_ioctl+0x47/0x80 [ 8.267191] [<ffffffff815f5c77>] entry_SYSCALL_64_fastpath+0x1a/0xa9 [ 8.288719] Code: 6a 81 48 89 e5 41 57 41 56 41 55 49 89 fd 41 54 53 48 89 f3 48 c7 c6 20 c4 78 81 48 83 ec 10 e8 8f 00 ef ff 4d 8b a5 a0 00 00 00 <41> 8b 44 24 10 85 c0 0f 8e 2b 02 00 00 4c 89 ef 31 c0 b9 53 01 [ 8.335233] RIP [<ffffffff814f5b08>] cmos_set_alarm+0x38/0x280 [ 8.357096] RSP <ffffc90000227c10> [ 8.379051] CR2: 0000000000000010 [ 8.401736] ---[ end trace 5cbcd83a1f225ed3 ]--- This occur only when CONFIG_DEBUG_TEST_DRIVER_REMOVE is enabled and CONFIG_RTC_DRV_CMOS builtin. When cmos_set_alarm() is called dev is NULL and so trigger the deref via cmos->irq The problem comes from that the device is removed but no remove function are called due to _exit_p(). This patch remove all _exit_p() annotation. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2016-09-22rtc: cmos: avoid unused function warningArnd Bergmann
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 <arnd@arndb.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2016-09-21rtc: cmos: Restore alarm after resumeGabriele Mazzotta
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 <gabriele.mzt@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2016-09-21rtc: cmos: Clear ACPI-driven alarms upon resumeGabriele Mazzotta
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 <gabriele.mzt@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2016-09-20rtc: cmos: Initialize hpet timer before irq is registeredPratyush Anand
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] <NMI> [<ffffffff81637bd4>] dump_stack+0x19/0x1b [ 27.929080] [<ffffffff8163144a>] panic+0xd8/0x1e7 [ 27.930588] [<ffffffff8111d3e0>] ? restart_watchdog_hrtimer+0x50/0x50 [ 27.932502] [<ffffffff8111d4a2>] watchdog_overflow_callback+0xc2/0xd0 [ 27.934427] [<ffffffff811612c1>] __perf_event_overflow+0xa1/0x250 [ 27.936232] [<ffffffff81161d94>] perf_event_overflow+0x14/0x20 [ 27.937957] [<ffffffff81032ae8>] intel_pmu_handle_irq+0x1e8/0x470 [ 27.939799] [<ffffffff8164164b>] perf_event_nmi_handler+0x2b/0x50 [ 27.941649] [<ffffffff81640d99>] nmi_handle.isra.0+0x69/0xb0 [ 27.943348] [<ffffffff81640f49>] do_nmi+0x169/0x340 [ 27.944802] [<ffffffff816401d3>] end_repeat_nmi+0x1e/0x2e [ 27.946424] [<ffffffff81056ee5>] ? hpet_rtc_interrupt+0x85/0x380 [ 27.948197] [<ffffffff81056ee5>] ? hpet_rtc_interrupt+0x85/0x380 [ 27.949992] [<ffffffff81056ee5>] ? hpet_rtc_interrupt+0x85/0x380 [ 27.951816] <<EOE>> <IRQ> [<ffffffff8108f5a3>] ? run_timer_softirq+0x43/0x340 [ 27.954114] [<ffffffff8111e24e>] handle_irq_event_percpu+0x3e/0x1e0 [ 27.955962] [<ffffffff8111e42d>] handle_irq_event+0x3d/0x60 [ 27.957635] [<ffffffff811210c7>] handle_edge_irq+0x77/0x130 [ 27.959332] [<ffffffff8101704f>] handle_irq+0xbf/0x150 [ 27.960949] [<ffffffff8164a86f>] do_IRQ+0x4f/0xf0 [ 27.962434] [<ffffffff8163faed>] common_interrupt+0x6d/0x6d [ 27.964101] <EOI> [<ffffffff8163f43b>] ? _raw_spin_unlock_irqrestore+0x1b/0x40 [ 27.966308] [<fffff8111ff07>] __setup_irq+0x2a7/0x570 [ 28.067859] [<ffffffff81056e60>] ? hpet_cpuhp_notify+0x140/0x140 [ 28.069709] [<ffffffff8112032c>] request_threaded_irq+0xcc/0x170 [ 28.071585] [<ffffffff814b24a6>] cmos_do_probe+0x1e6/0x450 [ 28.073240] [<ffffffff814b2710>] ? cmos_do_probe+0x450/0x450 [ 28.074911] [<ffffffff814b27cb>] cmos_pnp_probe+0xbb/0xc0 [ 28.076533] [<ffffffff8139b245>] pnp_device_probe+0x65/0xd0 [ 28.078198] [<ffffffff813f8ca7>] driver_probe_device+0x87/0x390 [ 28.079971] [<ffffffff813f9083>] __driver_attach+0x93/0xa0 [ 28.081660] [<ffffffff813f8ff0>] ? __device_attach+0x40/0x40 [ 28.083662] [<ffffffff813f6a13>] bus_for_each_dev+0x73/0xc0 [ 28.085370] [<ffffffff813f86fe>] driver_attach+0x1e/0x20 [ 28.086974] [<ffffffff813f8250>] bus_add_driver+0x200/0x2d0 [ 28.088634] [<ffffffff81ade49a>] ? rtc_sysfs_init+0xe/0xe [ 28.090349] [<ffffffff813f9704>] driver_register+0x64/0xf0 [ 28.091989] [<ffffffff8139b070>] pnp_register_driver+0x20/0x30 [ 28.093707] [<ffffffff81ade4ab>] 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 <tglx@linutronix.de> Signed-off-by: Pratyush Anand <panand@redhat.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2016-07-09rtc: simplify implementations of read_alarmUwe Kleine-König
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 <uwe@kleine-koenig.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2016-06-26mn10300: use RTC_DRV_CMOS instead of CONFIG_RTCArnd Bergmann
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 <arnd@arndb.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2016-06-04rtc: cmos: move mc146818rtc code out of asm-generic/rtc.hArnd Bergmann
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 <arnd@arndb.de> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2016-05-20rtc: Use IS_ENABLED() instead of checking for built-in or moduleJavier Martinez Canillas
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 <javier@osg.samsung.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2016-01-11rtc: cmos: prevent kernel warning on IRQ flags mismatchAndy Shevchenko
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) ... [<ffffffffa004eb01>] 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 <andriy.shevchenko@linux.intel.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2015-09-05rtc: cmos: clean up cmos_nvram_read()/cmos_nvram_write()Vladimir Zapolskiy
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 <vz@mleia.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2015-09-05rtc: cmos: Revert "rtc-cmos: Add an alarm disable quirk"Adrian Huang
Commit d5a1c7e3fc38 ("rtc-cmos: Add an alarm disable quirk") that added a special quirk is not needed because [PATCH 1/2] of this patchset makes the kernel more robust: rtc-cmos: Cancel alarm timer if alarm time is equal to now+1 seconds Signed-off-by: Adrian Huang <ahuang12@lenovo.com> Tested-by: Egbert Eich <eich@suse.de> Tested-by: Diego Ercolani <diego.ercolani@gmail.com> Cc: Borislav Petkov <bp@suse.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2015-09-05rtc: cmos: Cancel alarm timer if alarm time is equal to now+1 secondsAdrian Huang
Steps to reproduce the problem: 1) Enable RTC wake-up option in BIOS Setup 2) Issue one of these commands in the OS: "poweroff" or "shutdown -h now" 3) System will shut down and then reboot automatically Root-cause of the issue: 1) During the shutdown process, the hwclock utility is used to save the system clock to hardware clock (RTC). 2) The hwclock utility invokes ioctl() with RTC_UIE_ON. The kernel configures the RTC alarm for the periodic interrupt (every 1 second). 3) The hwclock uitlity closes the /dev/rtc0 device, and the kernel disables the RTC alarm irq (AIE bit of Register B) via ioctl() with RTC_UIE_OFF. But, the configured alarm time is the current_time + 1. 4) After the next 1 second is elapsed, the AF (alarm interrupt flag) of Register C is set. 5) The S5 handler in BIOS is invoked to configure alarm registers (enable AIE bit and configure alarm date/time). But, BIOS does not clear the previous interrupt status during alarm configuration. Therefore, "AF=AIE=1" causes the rtc device to trigger an interrupt. 6) So, the machine reboots automatically right after shutdown. This patch cancels the alarm timer if the following condictions are met (suggested by Alexandre): 1) The configured alarm time is equal to current_time + 1 seconds. 2) The AIE timer is not in use. The member 'alarm_expires' is introduced in struct cmos_rtc because of the following reasons: 1) The configured alarm time can be retrieved from cmos_read_alarm(), but we need to take the 'wrapped timestamp' and 'time rollover' into consideration. The function __rtc_read_alarm() eliminates the concerns. To avoid the duplicated code in the lower level RTC driver, invoking __rtc_read_alarm from the lower level RTC driver is not encouraged. Moreover, the compilation error 'the undefined __rtc_read_alarm" is observed if the lower level RTC driver is compiled as a kernel module. 2) The uie_rtctimer.node.expires and aie_timer.node.expires can be retrieved for the configured alarm time. But, the problem is that either of them might configure the CMOS alarm time. We cannot make sure UIE timer or AIE tiemr configured the CMOS alarm time before. (uie_rtctimer or aie_timer is enabled and then is disabled). 3) The patch introduces the member 'alarm_expires' to keep the newly configured alarm time, so the above-mentioned concerns can be eliminated. The issue goes away after 20-time shutdown tests. Signed-off-by: Adrian Huang <ahuang12@lenovo.com> Tested-by: Egbert Eich <eich@suse.de> Tested-by: Diego Ercolani <diego.ercolani@gmail.com> Cc: Borislav Petkov <bp@suse.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2015-04-17rtc: use more standard kernel logging stylesJoe Perches
Neaten the logging a bit by adding #define pr_fmt Miscellanea: o Remove __FILE__/__func__ uses o Coalesce formats adding missing spaces o Align arguments o (rtc-cmos) Integrated 2 consecutive messages Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Joshua Kinard <kumba@gentoo.org> Cc: Chanwoo Choi <cw00.choi@samsung.com> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-15rtc: remove use of seq_printf return valueJoe Perches
The seq_printf return value, because it's frequently misused, will eventually be converted to void. See: commit 1f33c41c03da ("seq_file: Rename seq_overflow() to seq_has_overflowed() and make public") Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-10-14rtc-cmos: fix wakeup from S5 without CONFIG_PM_SLEEPDaniel Glöckner
Commit b5ada4600dfd ("drivers/rtc/rtc-cmos.c: fix compilation warning when !CONFIG_PM_SLEEP") broke wakeup from S5 by making cmos_poweroff a nop unless CONFIG_PM_SLEEP was defined. Fix this by restricting the #ifdef to cmos_resume and restoring the old dependency on CONFIG_PM for cmos_suspend and cmos_poweroff. Signed-off-by: Daniel Glöckner <daniel-gl@gmx.net> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-06drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation supportMaciej W. Rozycki
This brings in drivers/char/rtc.c functionality required for DECstation and, should the maintainers decide to switch, Alpha systems to use rtc-cmos. Specifically these features are made available: * RTC iomem rather than x86/PCI port I/O mapping, controlled with the RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all DECstation systems is mapped in the host bus address space as a contiguous block of 64 32-bit words of which the least significant byte accesses the RTC chip for both reads and writes. All the address and data window register accesses are made transparently by the chipset glue logic so that the device appears directly mapped on the host bus. * A way to set the size of the address space explicitly with the newly-added `address_space' member of the platform part of the RTC device structure. This avoids the unreliable heuristics that does not work in a setup where the RTC is not explicitly accessed with the usual address and data window register pair. * The ability to use the RTC periodic interrupt as a system clock device, which is implemented by arch/mips/kernel/cevt-ds1287.c for DECstation systems and takes the RTC interrupt away from the RTC driver. Eventually hooking back to the clock device's interrupt handler should be possible for the purpose of the alarm clock and possibly also update-in-progress interrupt, but this is not done by this change. o To avoid interfering with the clock interrupt all the places where the RTC interrupt mask is fiddled with are only executed if and IRQ has been assigned to the RTC driver. o To avoid changing the clock setup Register A is not fiddled with if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of the platform part of the RTC device structure. Originally, in drivers/char/rtc.c, this was keyed with the absence of the RTC interrupt, just like the interrupt mask, but there only the periodic interrupt frequency is set, whereas rtc-cmos also sets the divider bits. Therefore a new flag is introduced so that systems where the RTC interrupt is not usable rather than used as a system clock device can fully initialise the RTC. * A small clean-up is made to the IRQ assignment code that makes the IRQ number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error happens to be returned by platform_get_irq) where no IRQ has been assigned to the RTC driver (NO_IRQ might be another candidate, but it looks like this macro has inconsistent or missing definitions and limited use and might therefore be unsafe). Verified to work correctly with a DECstation 5000/240 system. [akpm@linux-foundation.org: fix weird code layout] Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-04-03drivers/rtc/rtc-cmos.c: fix compilation warning when !CONFIG_PM_SLEEPMika Westerberg
CONFIG_PM will be set also if only CONFIG_PM_RUNTIME is set which causes the compiler to emit following warning: drivers/rtc/rtc-cmos.c:845:12: warning: =E2=80=98cmos_resume=E2=80=99 defined but not used [-Wunused-function] Fix this by using CONFIG_PM_SLEEP instead of CONFIG_PM and removing it from the driver pm ops as this has been taken care by SIMPLE_DEV_PM_OPS() already. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-01-23drivers/rtc/rtc-cmos.c: propagate hpet_register_irq_handler() failureAndrew Morton
If hpet_register_irq_handler() fails, cmos_do_probe() will incorrectly return 0. Reported-by: Julia Lawall <julia.lawall@lip6.fr> Cc: John Stultz <john.stultz@linaro.org> Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-01-23drivers/rtc/rtc-cmos.c: remove superfluous name castGeert Uytterhoeven
device_driver.name is "const char *" Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-12-23rtc-cmos: Add an alarm disable quirkBorislav Petkov
41c7f7424259f ("rtc: Disable the alarm in the hardware (v2)") added the functionality to disable the RTC wake alarm when shutting down the box. However, there are at least two b0rked BIOSes we know about: https://bugzilla.novell.com/show_bug.cgi?id=812592 https://bugzilla.novell.com/show_bug.cgi?id=805740 where, when wakeup alarm is enabled in the BIOS, the machine reboots automatically right after shutdown, regardless of what wakeup time is programmed. Bisecting the issue lead to this patch so disable its functionality with a DMI quirk only for those boxes. Cc: Brecht Machiels <brecht@mos6581.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: John Stultz <john.stultz@linaro.org> Cc: Rabin Vincent <rabin.vincent@stericsson.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Borislav Petkov <bp@suse.de> [jstultz: Changed variable name for clarity, added extra dmi entry] Tested-by: Brecht Machiels <brecht@mos6581.org> Tested-by: Borislav Petkov <bp@suse.de> Signed-off-by: John Stultz <john.stultz@linaro.org>
2013-11-13drivers/rtc/rtc-cmos.c: use dev_get_platdata()Jingoo Han
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. This is a cosmetic change to make the code simpler and enhance the readability. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-11-13drivers/rtc/rtc-cmos.c: remove redundant dev_set_drvdataSachin Kamat
Driver core sets the driver data to NULL upon device_release or on probe failure. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Cc: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-09-11rtc: convert rtc-cmos to dev_pm_ops from legacy pm_opsShuah Khan
Convert drivers/rtc/rtc-cmos to use dev_pm_ops instead of legacy pm_ops. This patch depends on pnp driver bus ops change to invoke pnp_driver dev_pm_ops. Signed-off-by: Shuah Khan <shuah.kh@samsung.com> Cc: Matthew Garrett <matthew.garrett@nebula.com> Cc: Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com> Cc: Ashley Lai <ashley@ashleylai.com> Cc: Rajiv Andrade <mail@srajiv.net> Cc: Marcel Selhorst <tpmdd@selhorst.net> Cc: Sirrix AG <tpmdd@sirrix.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <rob.herring@calxeda.com> Cc: Peter Hüwe <PeterHuewe@gmx.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-07-03drivers/rtc/rtc-cmos.c: work around bios clearing rtc controlDerek Basehore
The bios may clear the rtc control register when resuming the system. Since the cmos interrupt handler may now be run before the rtc_cmos is resumed, this can cause the interrupt handler to ignore an alarm since the alarm bit is not set in the rtc control register. To work around this, check if the rtc_cmos is suspended and use the stored value for the rtc control register. Signed-off-by: Derek Basehore <dbasehore@chromium.org> Reviewed-by: Sameer Nanda <snanda@chromium.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Jingoo Han <jg1.han@samsung.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: John Stultz <john.stultz@linaro.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-07-03drivers/rtc/rtc-cmos.c: fix whitespace related errorsSachin Kamat
Fixes the following types of issues: ERROR: space required after that ',' (ctx:VxV) WARNING: please, no spaces at the start of a line Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Cc: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-06-12drivers/rtc/rtc-cmos.c: fix accidentally enabling rtc channelDerek Basehore
During resume, we call hpet_rtc_timer_init after masking an irq bit in hpet. This will cause the call to hpet_disable_rtc_channel to be undone if RTC_AIE is the only bit not masked. Allowing the cmos interrupt handler to run before resuming caused some issues where the timer for the alarm was not removed. This would cause other, later timers to not be cleared, so utilities such as hwclock would time out when waiting for the update interrupt. [akpm@linux-foundation.org: coding-style tweak] Signed-off-by: Derek Basehore <dbasehore@chromium.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-29drivers/rtc/rtc-cmos.c: don't disable hpet emulation on suspendDerek Basehore
There's a bug where rtc alarms are ignored after the rtc cmos suspends but before the system finishes suspend. Since hpet emulation is disabled and it still handles the interrupts, a wake event is never registered which is done from the rtc layer. This patch reverts commit d1b2efa83fbf ("rtc: disable hpet emulation on suspend") which disabled hpet emulation. To fix the problem mentioned in that commit, hpet_rtc_timer_init() is called directly on resume. Signed-off-by: Derek Basehore <dbasehore@chromium.org> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-21rtc: rtc-cmos: use dev_warn()/dev_dbg() instead of printk()/pr_debug()Jingoo Han
Fix the checkpatch warning as below: WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ... Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>