linux-dev/arch/x86/kernel/hpet.c, branch linus/master

rtc: Check return value from mc146818_get_time()

2021-12-16T20:50:06Z

There are 4 users of mc146818_get_time() and none of them was checking the return value from this function. Change this. Print the appropriate warnings in callers of mc146818_get_time() instead of in the function mc146818_get_time() itself, in order not to add strings to rtc-mc146818-lib.c, which is kind of a library. The callers of alpha_rtc_read_time() and cmos_read_time() may use the contents of (struct rtc_time *) even when the functions return a failure code. Therefore, set the contents of (struct rtc_time *) to 0x00, which looks more sensible then 0xff and aligns with the (possibly stale?) comment in cmos_read_time: /* * If pm_trace abused the RTC for storage, set the timespec to 0, * which tells the caller that this RTC value is unusable. */ For consistency, do this in mc146818_get_time(). Note: hpet_rtc_interrupt() may call mc146818_get_time() many times a second. It is very unlikely, though, that the RTC suddenly stops working and mc146818_get_time() would consistently fail. Only compile-tested on alpha. Signed-off-by: Mateusz Jończyk Cc: Richard Henderson Cc: Ivan Kokshaysky Cc: Matt Turner Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: Alessandro Zummo Cc: Alexandre Belloni Cc: linux-alpha@vger.kernel.org Cc: x86@kernel.org Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20211210200131.153887-4-mat.jonczyk@o2.pl

x86/hpet: Use another crystalball to evaluate HPET usability

2021-10-01T11:38:13Z

On recent Intel systems the HPET stops working when the system reaches PC10 idle state. The approach of adding PCI ids to the early quirks to disable HPET on these systems is a whack a mole game which makes no sense. Check for PC10 instead and force disable HPET if supported. The check is overbroad as it does not take ACPI, intel_idle enablement and command line parameters into account. That's fine as long as there is at least PMTIMER available to calibrate the TSC frequency. The decision can be overruled by adding "hpet=force" on the kernel command line. Remove the related early PCI quirks for affected Ice Cake and Coffin Lake systems as they are not longer required. That should also cover all other systems, i.e. Tiger Rag and newer generations, which are most likely affected by this as well. Fixes: Yet another hardware trainwreck Reported-by: Jakub Kicinski Signed-off-by: Thomas Gleixner Tested-by: Jakub Kicinski Reviewed-by: Rafael J. Wysocki Cc: stable@vger.kernel.org Cc: Kai-Heng Feng Cc: Bjorn Helgaas

x86/msi: Force affinity setup before startup

2021-08-10T08:59:21Z

The X86 MSI mechanism cannot handle interrupt affinity changes safely after startup other than from an interrupt handler, unless interrupt remapping is enabled. The startup sequence in the generic interrupt code violates that assumption. Mark the irq chips with the new IRQCHIP_AFFINITY_PRE_STARTUP flag so that the default interrupt setting happens before the interrupt is started up for the first time. While the interrupt remapping MSI chip does not require this, there is no point in treating it differently as this might spare an interrupt to a CPU which is not in the default affinity mask. For the non-remapping case go to the direct write path when the interrupt is not yet started similar to the not yet activated case. Fixes: 18404756765c ("genirq: Expose default irq affinity mask (take 3)") Signed-off-by: Thomas Gleixner Tested-by: Marc Zyngier Reviewed-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210729222542.886722080@linutronix.de

x86/hpet: Use irq_find_matching_fwspec() to find remapping irqdomain

2020-10-28T19:26:28Z

All possible parent domains have a select method now. Make use of it. Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20201024213535.443185-28-dwmw2@infradead.org

x86/hpet: Move MSI support into hpet.c

2020-10-28T19:26:25Z

This isn't really dependent on PCI MSI; it's just generic MSI which is now supported by the generic x86_vector_domain. Move the HPET MSI support back into hpet.c with the rest of the HPET support. Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20201024213535.443185-11-dwmw2@infradead.org

remove ioremap_nocache and devm_ioremap_nocache

2020-01-06T08:45:59Z

ioremap has provided non-cached semantics by default since the Linux 2.6 days, so remove the additional ioremap_nocache interface. Signed-off-by: Christoph Hellwig Acked-by: Arnd Bergmann

x86/hpet: Undo the early counter is counting check

2019-07-25T10:21:32Z

Rui reported that on a Pentium D machine which has HPET forced enabled because it is not advertised by ACPI, the early counter is counting check leads to a silent boot hang. The reason is that the ordering of checking the counter first and then reconfiguring the HPET fails to work on that machine. As the HPET is not advertised and presumably not initialized by the BIOS the early enable and the following reconfiguration seems to bring it into a broken state. Adding clocksource=jiffies to the command line results in the following clocksource watchdog warning: clocksource: timekeeping watchdog on CPU1: Marking clocksource 'tsc-early' as unstable because the skew is too large: clocksource: 'hpet' wd_now: 33 wd_last: 33 mask: ffffffff That clearly shows that the HPET is not counting after it got reconfigured and reenabled. If the counter is not working then the HPET timer is not expiring either, which explains the boot hang. Move the counter is counting check after the full configuration again to unbreak these systems. Reported-by: Rui Salvaterra Fixes: 3222daf970f3 ("x86/hpet: Separate counter check out of clocksource register code") Signed-off-by: Thomas Gleixner Tested-by: Rui Salvaterra Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1907250810530.1791@nanos.tec.linutronix.de

x86/hpet: Use channel for legacy clockevent storage

2019-06-27T22:57:27Z

All preparations are done. Use the channel storage for the legacy clockevent and remove the static variable. Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Cc: Peter Zijlstra Cc: Ricardo Neri Cc: Ashok Raj Cc: Andi Kleen Cc: Suravee Suthikulpanit Cc: Stephane Eranian Cc: Ravi Shankar Link: https://lkml.kernel.org/r/20190623132436.737689919@linutronix.de

x86/hpet: Use common init for legacy clockevent

2019-06-27T22:57:27Z

Replace the static initialization of the legacy clockevent with runtime initialization utilizing the common init function as the last preparatory step to switch the legacy clockevent over to the channel 0 storage in hpet_base. This comes with a twist. The static clockevent initializer has selected support for periodic and oneshot mode unconditionally whether the HPET config advertised periodic mode or not. Even the pre clockevents code did this. But.... Using the conditional in hpet_init_clockevent() makes at least Qemu and one hardware machine fail to boot. There are two issues which cause the boot failure: #1 After the timer delivery test in IOAPIC and the IOAPIC setup the next interrupt is not delivered despite the HPET channel being programmed correctly. Reprogramming the HPET after switching to IOAPIC makes it work again. After fixing this, the next issue surfaces: #2 Due to the unconditional periodic mode 'availability' the Local APIC timer calibration can hijack the global clockevents event handler without causing damage. Using oneshot at this stage makes if hang because the HPET does not get reprogrammed due to the handler hijacking. Duh, stupid me! Both issues require major surgery and especially the kick HPET again after enabling IOAPIC results in really nasty hackery. This 'assume periodic works' magic has survived since HPET support got added, so it's questionable whether this should be fixed. Both Qemu and the failing hardware machine support periodic mode despite the fact that both don't advertise it in the configuration register and both need that extra kick after switching to IOAPIC. Seems to be a feature... Keep the 'assume periodic works' magic around and add a big fat comment. Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Cc: Peter Zijlstra Cc: Ricardo Neri Cc: Ashok Raj Cc: Andi Kleen Cc: Suravee Suthikulpanit Cc: Stephane Eranian Cc: Ravi Shankar Link: https://lkml.kernel.org/r/20190623132436.646565913@linutronix.de

x86/hpet: Carve out shareable parts of init_one_hpet_msi_clockevent()

2019-06-27T22:57:26Z

To finally remove the static channel0/clockevent storage and to utilize the channel 0 storage in hpet_base, it's required to run time initialize the clockevent. The MSI clockevents already have a run time init function. Carve out the parts which can be shared between the legacy and the MSI implementation. Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Cc: Peter Zijlstra Cc: Ricardo Neri Cc: Ashok Raj Cc: Andi Kleen Cc: Suravee Suthikulpanit Cc: Stephane Eranian Cc: Ravi Shankar Link: https://lkml.kernel.org/r/20190623132436.552451082@linutronix.de