1. 22 9月, 2016 3 次提交
    • G
      rtc: cmos: Restore alarm after resume · 68669d55
      Gabriele 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: NGabriele Mazzotta <gabriele.mzt@gmail.com>
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
      68669d55
    • G
      rtc: cmos: Clear ACPI-driven alarms upon resume · 983bf125
      Gabriele 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.pdfSigned-off-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
      983bf125
    • M
      rtc: omap: Support ext_wakeup configuration · 97ea1906
      Marcin Niestroj 提交于
      Support configuration of ext_wakeup sources. This patch makes it
      possible to enable ext_wakeup and set it's polarity, depending on board
      configuration. AM335x's dedicated PMIC (tps65217) uses ext_wakeup to
      notify about power-button presses. Handling power-button presses enables
      to recover from RTC-only power states correctly.
      Signed-off-by: NMarcin Niestroj <m.niestroj@grinn-global.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
      97ea1906
  2. 20 9月, 2016 1 次提交
    • P
      rtc: cmos: Initialize hpet timer before irq is registered · 970fc7f4
      Pratyush 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: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NPratyush Anand <panand@redhat.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
      970fc7f4
  3. 05 9月, 2016 2 次提交
  4. 02 9月, 2016 1 次提交
  5. 01 9月, 2016 10 次提交
  6. 08 8月, 2016 2 次提交
  7. 28 7月, 2016 6 次提交
  8. 27 7月, 2016 1 次提交
  9. 26 7月, 2016 1 次提交
  10. 22 7月, 2016 2 次提交
  11. 20 7月, 2016 4 次提交
  12. 19 7月, 2016 4 次提交
  13. 12 7月, 2016 3 次提交