kernel.git/drivers/thermal/intel/intel_hfi.c, branch linux-rolling-stable

syscore: Pass context data to callbacks

2025-11-14T09:01:52Z

Several drivers can benefit from registering per-instance data along with the syscore operations. To achieve this, move the modifiable fields out of the syscore_ops structure and into a separate struct syscore that can be registered with the framework. Add a void * driver data field for drivers to store contextual data that will be passed to the syscore ops. Acked-by: Rafael J. Wysocki (Intel) Signed-off-by: Thierry Reding

x86/msr: Rename 'wrmsrl()' to 'wrmsrq()'

2025-04-10T09:58:33Z

Suggested-by: "H. Peter Anvin" Signed-off-by: Ingo Molnar Acked-by: Peter Zijlstra (Intel) Cc: Juergen Gross Cc: Dave Hansen Cc: Xin Li Cc: Linus Torvalds

x86/msr: Rename 'rdmsrl()' to 'rdmsrq()'

2025-04-10T09:58:27Z

Suggested-by: "H. Peter Anvin" Signed-off-by: Ingo Molnar Acked-by: Peter Zijlstra (Intel) Cc: Juergen Gross Cc: Dave Hansen Cc: Xin Li Cc: Linus Torvalds

thermal: intel: hfi: Give HFI instances package scope

2024-07-09T16:29:07Z

The Intel Software Developer's Manual defines the scope of HFI (registers and memory buffer) as a package. Use package scope(*) in the software representation of an HFI instance. Using die scope in HFI instances has the effect of creating multiple conflicting instances for the same package: each instance allocates its own memory buffer and configures the same package-level registers. Specifically, only one of the allocated memory buffers can be set in the MSR_IA32_HW_FEEDBACK_PTR register. CPUs get incorrect HFI data from the table. The problem does not affect current HFI-capable platforms because they all have single-die processors. (*) We used die scope for HFI instances because there had been processors with packages enumerated as dies. None of those systems supported HFI, though. If such a system emerged, it would need to be quirked. Co-developed-by: Chen Yu Signed-off-by: Chen Yu Signed-off-by: Zhang Rui Reviewed-by: Ricardo Neri Link: https://patch.msgid.link/20240703055445.125362-1-rui.zhang@intel.com [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki

thermal: intel: hfi: Increase the number of CPU capabilities per netlink event

2024-05-08T12:02:02Z

The number of updated CPU capabilities per netlink event is hard-coded to 16. On systems with more than 16 CPUs (a common case), it takes more than one thermal netlink event to relay all the new capabilities after an HFI interrupt. This adds unnecessary overhead to both the kernel and user space entities. Increase the number of CPU capabilities updated per event to 64. Any system with 64 CPUs or less can now update all the capabilities in a single thermal netlink event. Signed-off-by: Ricardo Neri Acked-by: Zhang Rui Signed-off-by: Rafael J. Wysocki

thermal: intel: hfi: Rename HFI_MAX_THERM_NOTIFY_COUNT

2024-05-08T12:02:02Z

When processing a hardware update, HFI generates as many thermal netlink events as needed to relay all the updated CPU capabilities to user space. The constant HFI_MAX_THERM_NOTIFY_COUNT is the number of CPU capabilities updated per each of those events. Give this constant a more descriptive name. Signed-off-by: Ricardo Neri Acked-by: Zhang Rui Signed-off-by: Rafael J. Wysocki

thermal: intel: hfi: Shorten the thermal netlink event delay to 100ms

2024-05-08T12:02:02Z

The delay between an HFI interrupt and its corresponding thermal netlink event has so far been hard-coded to CONFIG_HZ jiffies (1 second). This delay is too long for hardware that generates updates every tens of milliseconds. The HFI driver uses a delayed workqueue to send thermal netlink events. No subsequent events will be sent if there is pending work. As a result, much of the information of consecutive hardware updates will be lost if the workqueue delay is too long. User space entities may act on obsolete data. If the delay is too short, multiple events may overwhelm listeners. Set the delay to 100ms to strike a balance between too many and too few events. Use milliseconds instead of jiffies to improve readability. Signed-off-by: Ricardo Neri Acked-by: Zhang Rui Signed-off-by: Rafael J. Wysocki

thermal: intel: hfi: Rename HFI_UPDATE_INTERVAL

2024-05-08T12:02:02Z

The name of the constant HFI_UPDATE_INTERVAL is misleading. It is not a periodic interval at which HFI updates are processed. It is the delay in the processing of an HFI update after the arrival of an HFI interrupt. Acked-by: Zhang Rui Signed-off-by: Ricardo Neri Signed-off-by: Rafael J. Wysocki

thermal: intel: hfi: Enable HFI only when required

2024-03-27T13:50:26Z

Enable and disable hardware feedback interface (HFI) when user space handler is present. For example, enable HFI, when intel-speed-select or Intel Low Power daemon is running and subscribing to thermal netlink events. When user space handlers exit or remove subscription for thermal netlink events, disable HFI. Summary of changes: - Register a thermal genetlink notifier - In the notifier, process THERMAL_NOTIFY_BIND and THERMAL_NOTIFY_UNBIND reason codes to count number of thermal event group netlink multicast clients. If thermal netlink group has any listener enable HFI on all packages. If there are no listener disable HFI on all packages. - When CPU is online, instead of blindly enabling HFI, check if the thermal netlink group has any listener. This will make sure that HFI is not enabled by default during boot time. - Actual processing to enable/disable matches what is done in suspend/resume callbacks. Create two functions hfi_enable_instance() and hfi_disable_instance(), which can be called from the netlink notifier callback and suspend/resume callbacks. Signed-off-by: Stanislaw Gruszka Signed-off-by: Rafael J. Wysocki

x86/cpu/topology: Rename topology_max_die_per_package()

2024-02-15T21:07:45Z

The plural of die is dies. Signed-off-by: Thomas Gleixner Tested-by: Michael Kelley Tested-by: Sohil Mehta Link: https://lore.kernel.org/r/20240213210253.065874205@linutronix.de