1. 07 Nov, 2018 1 commit
    • Hans de Goede's avatar
      rtc: cmos: Do not export alarm rtc_ops when we do not support alarms · fbb974ba
      Hans de Goede authored
      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: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
  2. 04 Oct, 2018 2 commits
    • Maciej W. Rozycki's avatar
      rtc: cmos: Remove the `use_acpi_alarm' module parameter for !ACPI · bc51098c
      Maciej W. Rozycki authored
      Fix a problem with commit 311ee9c1
       ("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: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Fixes: 311ee9c1
       ("rtc: cmos: allow using ACPI for RTC alarm instead of HPET")
      Cc: stable@vger.kernel.org # 4.18+
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
    • Maciej W. Rozycki's avatar
      rtc: cmos: Fix non-ACPI undefined reference to `hpet_rtc_interrupt' · d197a253
      Maciej W. Rozycki authored
      Fix a commit 311ee9c1
       ("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: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Fixes: 311ee9c1
       ("rtc: cmos: allow using ACPI for RTC alarm instead of HPET")
      Cc: stable@vger.kernel.org # 4.18+
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
  3. 19 Apr, 2018 3 commits
    • Zhang Rui's avatar
      rtc: cmos: introduce quirks to enable use_acpi_alarm mode · 36d91a4d
      Zhang Rui authored
      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: default avatarZhang Rui <rui.zhang@intel.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
    • Zhang Rui's avatar
      rtc: cmos: acknowledge ACPI driven wake alarms upon resume · c6d3a278
      Zhang Rui authored
      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
      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: default avatarZhang Rui <rui.zhang@intel.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
    • Zhang Rui's avatar
      rtc: cmos: allow using ACPI for RTC alarm instead of HPET · 311ee9c1
      Zhang Rui authored
      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.
      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
      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
      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: default avatarZhang Rui <rui.zhang@intel.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
  4. 09 Mar, 2018 1 commit
  5. 01 Mar, 2018 3 commits
  6. 14 May, 2017 1 commit
  7. 14 Apr, 2017 1 commit
    • Hans de Goede's avatar
      rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqs · a1e23a42
      Hans de Goede authored
      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: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
  8. 29 Nov, 2016 1 commit
    • Chen Yu's avatar
      timekeeping: Ignore the bogus sleep time if pm_trace is enabled · ba58d102
      Chen Yu authored
      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 a4f8f666
       ("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: default avatarChen Yu <yu.c.chen@intel.com>
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Acked-by: default avatarPavel Machek <pavel@ucw.cz>
      Acked-by: default avatarThomas 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: default avatarThomas Gleixner <tglx@linutronix.de>
  9. 20 Oct, 2016 1 commit
    • Ville Syrjälä's avatar
      rtc: cmos: Don't enable interrupts in the middle of the interrupt handler · 368e21ae
      Ville Syrjälä authored
      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: 983bf125
       ("rtc: cmos: Clear ACPI-driven alarms upon resume")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
  10. 19 Oct, 2016 3 commits
    • Christoph Hellwig's avatar
      rtc: cmos: don't refer to asm-generic/rtc.h · 290cd0f0
      Christoph Hellwig authored
      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: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
    • Gabriele Mazzotta's avatar
      rtc: cmos: Reject unsupported alarm values · 6a6af3d0
      Gabriele Mazzotta authored
      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: default avatarGabriele Mazzotta <gabriele.mzt@gmail.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
    • LABBE Corentin's avatar
      rtc: cmos: remove all __exit_p annotations · a3a0673b
      LABBE Corentin authored
      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
      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: default avatarCorentin Labbe <clabbe.montjoie@gmail.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
  11. 22 Sep, 2016 1 commit
    • Arnd Bergmann's avatar
      rtc: cmos: avoid unused function warning · 00f7f90c
      Arnd Bergmann authored
      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: 983bf125
       ("rtc: cmos: Clear ACPI-driven alarms upon resume")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
  12. 21 Sep, 2016 2 commits
    • Gabriele Mazzotta's avatar
      rtc: cmos: Restore alarm after resume · 68669d55
      Gabriele Mazzotta authored
      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
      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: default avatarGabriele Mazzotta <gabriele.mzt@gmail.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
    • Gabriele Mazzotta's avatar
      rtc: cmos: Clear ACPI-driven alarms upon resume · 983bf125
      Gabriele Mazzotta authored
      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
      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: default avatarGabriele Mazzotta <gabriele.mzt@gmail.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
  13. 19 Sep, 2016 1 commit
    • Pratyush Anand's avatar
      rtc: cmos: Initialize hpet timer before irq is registered · 970fc7f4
      Pratyush Anand authored
      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:
      [   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
      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: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarPratyush Anand <panand@redhat.com>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
  14. 09 Jul, 2016 1 commit
  15. 25 Jun, 2016 1 commit
  16. 03 Jun, 2016 1 commit
    • Arnd Bergmann's avatar
      rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h · 5ab788d7
      Arnd Bergmann authored
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
  17. 20 May, 2016 1 commit
  18. 11 Jan, 2016 1 commit
  19. 05 Sep, 2015 3 commits
    • Vladimir Zapolskiy's avatar
      rtc: cmos: clean up cmos_nvram_read()/cmos_nvram_write() · a3781639
      Vladimir Zapolskiy authored
      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: default avatarVladimir Zapolskiy <vz@mleia.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
    • Adrian Huang's avatar
      rtc: cmos: Revert "rtc-cmos: Add an alarm disable quirk" · 8109d44f
      Adrian Huang authored
      Commit d5a1c7e3
       ("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: default avatarAdrian Huang <ahuang12@lenovo.com>
      Tested-by: default avatarEgbert Eich <eich@suse.de>
      Tested-by: default avatarDiego Ercolani <diego.ercolani@gmail.com>
      Cc: Borislav Petkov <bp@suse.de>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
    • Adrian Huang's avatar
      rtc: cmos: Cancel alarm timer if alarm time is equal to now+1 seconds · 88b8d33b
      Adrian Huang authored
      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
      	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: default avatarAdrian Huang <ahuang12@lenovo.com>
      Tested-by: default avatarEgbert Eich <eich@suse.de>
      Tested-by: default avatarDiego Ercolani <diego.ercolani@gmail.com>
      Cc: Borislav Petkov <bp@suse.de>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
  20. 17 Apr, 2015 1 commit
  21. 15 Apr, 2015 1 commit
  22. 14 Oct, 2014 1 commit
  23. 06 Jun, 2014 1 commit
    • Maciej W. Rozycki's avatar
      drivers/rtc/rtc-cmos.c: drivers/char/rtc.c features for DECstation support · 31632dbd
      Maciej W. Rozycki authored
      This brings in drivers/char/rtc.c functionality required for DECstation
      and, should the maintainers decide to switch, Alpha systems to use
      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: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  24. 03 Apr, 2014 1 commit
  25. 24 Jan, 2014 2 commits
  26. 23 Dec, 2013 1 commit
  27. 13 Nov, 2013 2 commits
  28. 11 Sep, 2013 1 commit
    • Shuah Khan's avatar
      rtc: convert rtc-cmos to dev_pm_ops from legacy pm_ops · a8a3808b
      Shuah Khan authored
      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
      Signed-off-by: default avatarShuah 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>