lwn.git/arch/x86/kernel/hpet.c, branch docs-6.8

x86/msi: Fix compile error caused by CONFIG_GENERIC_MSI_IRQ=y && !CONFIG_X86_LOCAL_APIC

2023-10-12T06:13:27+00:00

When compiling the x86 kernel, if X86_LOCAL_APIC is not enabled but GENERIC_MSI_IRQ is selected in '.config', the following compilation error will occur: include/linux/gpio/driver.h:38:19: error: field 'msiinfo' has incomplete type kernel/irq/msi.c:752:5: error: invalid use of incomplete typedef 'msi_alloc_info_t' {aka 'struct irq_alloc_info'} kernel/irq/msi.c:740:1: error: control reaches end of non-void function This is because file such as 'kernel/irq/msi.c' only depends on 'GENERIC_MSI_IRQ', and uses 'struct msi_alloc_info_t'. However, this struct depends on 'X86_LOCAL_APIC'. When enable 'GENERIC_MSI_IRQ' or 'X86_LOCAL_APIC' will select 'IRQ_DOMAIN_HIERARCHY', so exposing this struct using 'IRQ_DOMAIN_HIERARCHY' rather than 'X86_LOCAL_APIC'. Under the above conditions, if 'HPET_TIMER' is selected, the following compilation error will occur: arch/x86/kernel/hpet.c:550:13: error: ‘x86_vector_domain’ undeclared arch/x86/kernel/hpet.c:600:9: error: implicit declaration of function ‘init_irq_alloc_info’ This is because 'x86_vector_domain' is defined in 'kernel/apic/vector.c' which is compiled only when 'X86_LOCAL_APIC' is enabled. Besides, function 'msi_domain_set_affinity' is defined in 'include/linux/msi.h' which depends on 'GENERIC_MSI_IRQ'. So use 'X86_LOCAL_APIC' and 'GENERIC_MSI_IRQ' to expose these code. Reported-by: kernel test robot Signed-off-by: Lu Yao Signed-off-by: Ingo Molnar Acked-by: Randy Dunlap Tested-by: Randy Dunlap Cc: Thomas Gleixner Link: https://lore.kernel.org/r/20231012032659.323251-1-yaolu@kylinos.cn

x86/hpet: Refactor code using deprecated strncpy() interface to use strscpy()

2023-08-24T19:22:40+00:00

`strncpy` is deprecated for use on NUL-terminated destination strings [1]. A suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on its destination buffer argument which is _not_ the case for `strncpy`! In this case, it is a simple swap from `strncpy` to `strscpy`. There is one slight difference, though. If NUL-padding is a functional requirement here we should opt for `strscpy_pad`. It seems like this shouldn't be needed as I see no obvious signs of any padding being required. Signed-off-by: Justin Stitt Signed-off-by: Ingo Molnar Link: www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings[1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Link: https://lore.kernel.org/r/20230822-strncpy-arch-x86-kernel-hpet-v1-1-2c7d3be86f4a@google.com

clocksource: Verify HPET and PMTMR when TSC unverified

2023-02-02T22:23:02+00:00

On systems with two or fewer sockets, when the boot CPU has CONSTANT_TSC, NONSTOP_TSC, and TSC_ADJUST, clocksource watchdog verification of the TSC is disabled. This works well much of the time, but there is the occasional production-level system that meets all of these criteria, but which still has a TSC that skews significantly from atomic-clock time. This is usually attributed to a firmware or hardware fault. Yes, the various NTP daemons do express their opinions of userspace-to-atomic-clock time skew, but they put them in various places, depending on the daemon and distro in question. It would therefore be good for the kernel to have some clue that there is a problem. The old behavior of marking the TSC unstable is a non-starter because a great many workloads simply cannot tolerate the overheads and latencies of the various non-TSC clocksources. In addition, NTP-corrected systems sometimes can tolerate significant kernel-space time skew as long as the userspace time sources are within epsilon of atomic-clock time. Therefore, when watchdog verification of TSC is disabled, enable it for HPET and PMTMR (AKA ACPI PM timer). This provides the needed in-kernel time-skew diagnostic without degrading the system's performance. Signed-off-by: Paul E. McKenney Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: "H. Peter Anvin" Cc: Daniel Lezcano Cc: Waiman Long Cc: Tested-by: Feng Tang

rtc: Check return value from mc146818_get_time()

2021-12-16T20:50:06+00:00

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:13+00:00

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:21+00:00

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:28+00:00

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:25+00:00

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:59+00:00

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:32+00:00

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