Krishna Chomal [Wed, 21 Jan 2026 18:28:58 +0000 (23:58 +0530)]
platform/x86: hp-wmi: Add EC offsets to read Victus S thermal profile
The current implementation for Victus S thermal profiles only supports
setting the profile. The driver was missing the logic to read the
hardware state, meaning it would default to "Balanced" on driver load,
overriding the currently active profile. Furthermore, the driver could
not detect if the firmware reset the profile on a power source change.
Statically store the known EC offsets for reading thermal profile in the
new .ec_tp_offset field of struct thermal_profile_params. Implement
platform_profile_victus_s_get_ec() to use this offset to read the real
hardware state. Additionally, update the power source event notifier to
use the actual hardware state when re-triggering CPU power limits
actualization.
Testing on HP Omen 16-wf1xxx (board ID 8C78) confirmed that the thermal
profile is now persistent across driver loads and power source change
events.
platform: mellanox: mlx-platform: Add support DGX flavor of next-generation 800GB/s ethernet switch.
This system is based on Nvidia SN5600 Spectrum-4 Based 64x800Gb/s ETH
Switch System, with the following key changes:
Key changes:
1. New system SKU: HI174.
2. Power Supply: PSU AC replaiced with PDB board (added pdb/pwr
attributes).
3. CPLD: Update register map with new PDB related signals.
Signed-off-by: Oleksandr Shamray <oleksandrs@nvidia.com> Reviewed-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://patch.msgid.link/20260128075939.2704019-3-oleksandrs@nvidia.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform: mellanox: mlx-platform: Add support for new Nvidia DGX system based on class VMOD0010
This system is based on Nvidia QM9700 64x400G QTM-2 switch, with the
following key changes:
Key changes:
1. New system SKU: HI73.
2. Power Supply: PSU AC replaiced with PDB board (added pdb/pwr
attributes).
3. CPLD: Update register map with new PDB related signals.
Signed-off-by: Oleksandr Shamray <oleksandrs@nvidia.com> Reviewed-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://patch.msgid.link/20260128075939.2704019-2-oleksandrs@nvidia.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
HID: asus: add support for the asus-wmi brightness handler
If the asus-wmi brightness handler is available, send the
keyboard brightness events to it instead of passing them
to userspace. If it is not, fall back to sending them to it.
Reviewed-by: Luke D. Jones <luke@ljones.dev> Tested-by: Luke D. Jones <luke@ljones.dev> Reviewed-by: Denis Benato <benato.denis96@gmail.com> Acked-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev> Link: https://patch.msgid.link/20260122075044.5070-12-lkml@antheas.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The keyboard brightness control of Asus WMI keyboards is handled in
kernel, which leads to the shortcut going from brightness 0, to 1,
to 2, and 3.
However, for HID keyboards it is exposed as a key and handled by the
user's desktop environment. For the toggle button, this means that
brightness control becomes on/off. In addition, in the absence of a
DE, the keyboard brightness does not work.
Therefore, expose an event handler for the keyboard brightness control
which can then be used by hid-asus. Since this handler is called from
an interrupt context, defer the actual work to a workqueue.
In the process, introduce ASUS_EV_MAX_BRIGHTNESS to hold the constant
for maximum brightness since it is shared between hid-asus/asus-wmi.
Reviewed-by: Luke D. Jones <luke@ljones.dev> Tested-by: Luke D. Jones <luke@ljones.dev> Acked-by: Benjamin Tissoires <bentiss@kernel.org> Reviewed-by: Denis Benato <benato.denis96@gmail.com> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev> Link: https://patch.msgid.link/20260122075044.5070-11-lkml@antheas.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
HID: asus: listen to the asus-wmi brightness device instead of creating one
Some ROG laptops expose multiple interfaces for controlling the
keyboard/RGB brightness. This creates a name conflict under
asus::kbd_brightness, where the second device ends up being
named asus::kbd_brightness_1 and they are both broken.
Therefore, register a listener to the asus-wmi brightness device
instead of creating a new one.
Reviewed-by: Luke D. Jones <luke@ljones.dev> Reviewed-by: Benjamin Tissoires <bentiss@kernel.org> Reviewed-by: Denis Benato <benato.denis96@gmail.com> Acked-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev> Link: https://patch.msgid.link/20260122075044.5070-9-lkml@antheas.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: asus-wmi: Add support for multiple kbd led handlers
Some devices, such as the Z13 have multiple Aura devices connected
to them by USB. In addition, they might have a WMI interface for
RGB. In Windows, Armoury Crate exposes a unified brightness slider
for all of them, with 3 brightness levels.
Therefore, to be synergistic in Linux, and support existing tooling
such as UPower, allow adding listeners to the RGB device of the WMI
interface. If WMI does not exist, lazy initialize the interface.
Since hid-asus and asus-wmi can both interact with the led objects
including from an atomic context, protect the brightness access with a
spinlock and update the values from a workqueue. Use this workqueue to
also process WMI keyboard events, so they are handled asynchronously.
Acked-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev> Reviewed-by: Denis Benato <benato.denis96@gmail.com> Link: https://patch.msgid.link/20260122075044.5070-8-lkml@antheas.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Some ROG devices have a new dynamic backlight interface for control by
Windows. This interface does not create an ->input device, causing the
kernel to print an error message and to eject it. In addition, ROG
devices have proper HID names in their descriptors so renaming them is
not necessary.
Therefore, if a device is identified as ROG, early return from probe to
skip renaming and ->input checks.
Acked-by: Benjamin Tissoires <bentiss@kernel.org> Reviewed-by: Denis Benato <benato.denis96@gmail.com> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev> Link: https://patch.msgid.link/20260122075044.5070-7-lkml@antheas.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
ROG NKEY devices have multiple HID endpoints, around 3-4. One of those
endpoints has a usage page of 0xff31, and is the one that emits keyboard
shortcuts and controls RGB/backlight. Currently, this driver places
the usage page check under asus_input_mapping and then inits backlight
in asus_input_configured which is unnecessarily complicated and prevents
probe from performing customizations on the vendor endpoint.
Simplify the logic by introducing an is_vendor variable into probe that
checks for usage page 0xff31. Then, use this variable to move backlight
initialization into probe instead of asus_input_configured, and remove
the backlight check from asus_input_mapping.
Acked-by: Benjamin Tissoires <bentiss@kernel.org> Reviewed-by: Denis Benato <benato.denis96@gmail.com> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev> Link: https://patch.msgid.link/20260122075044.5070-6-lkml@antheas.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Handshaking with an Asus device involves sending it a feature report
with the string "ASUS Tech.Inc." and then reading it back to verify the
handshake was successful, under the feature ID the interaction will
take place.
Currently, the driver only does the first part. Add the readback to
verify the handshake was successful. As this could cause breakages,
allow the verification to fail with a dmesg error until we verify
all devices work with it (they seem to).
Since the response is more than 16 bytes, increase the buffer size
to 64 as well to avoid overflow errors. In addition, add the report
ID to prints, to help identify failed handshakes.
Reviewed-by: Benjamin Tissoires <bentiss@kernel.org> Reviewed-by: Denis Benato <benato.denis96@gmail.com> Acked-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev> Link: https://patch.msgid.link/20260122075044.5070-5-lkml@antheas.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Currently, asus_kbd_get_functions prods the device using feature
report report_id, but then is hardcoded to check the response through
FEATURE_KBD_REPORT_ID. This only works if report_id is that value
(currently true). So, use report_id in the response as well to
maintain functionality if that value changes in the future.
Reviewed-by: Denis Benato <benato.denis96@gmail.com> Acked-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev> Link: https://patch.msgid.link/20260122075044.5070-4-lkml@antheas.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
HID: asus: initialize additional endpoints only for certain devices
Currently, ID1/ID2 initializations are performed for all NKEY devices.
However, ID1 initializations are only required for RGB control and are
only supported for RGB capable devices. ID2 initializations are only
required for initializing the Anime display endpoint which is only
supported on devices with an Anime display. Both of these
initializations are for functionality that is not present on this driver
and are performed for devices which might not support them.
At the same time, there are older NKEY devices that have only been
tested with these initializations in the kernel and it is not possible
to recheck them. There is a possibility that especially with the ID1
initialization, certain laptop models might have their shortcuts stop
working (currently unproven).
To avoid sending unnecessary commands, change to only initialize ID1/ID2
for those NKEY devices suspected to be problematic without them by
introducing a quirk for them and replacing the NKEY quirk in the block
that performs the inits with that. Therefore, new devices that do not
need (and some do not support) these initializations will not have
them performed.
In addition, as these initializations might not be supported by the
affected devices, change the function to not bail if they fail.
Acked-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev> Reviewed-by: Denis Benato <benato.denis96@gmail.com> Link: https://patch.msgid.link/20260122075044.5070-3-lkml@antheas.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Currently, RGB initialization forks depending on whether a device is
NKEY. However, in reality both initialization forks are the same, other
than the NKEY initialization initializing the LED_REPORT_ID1,
LED_REPORT_ID2 endpoints, and the non-NKEY initialization having a
functionality check which is skipped for the NKEY path.
Therefore, merge the if blocks, gate the ID1/ID2 initializations
behind the NKEY quirk instead, and introduce the functionality check
for NKEY devices (it is supported by them).
There should be no functional change with this patch.
Acked-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev> Link: https://patch.msgid.link/20260122075044.5070-2-lkml@antheas.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Armin Wolf [Fri, 23 Jan 2026 21:15:37 +0000 (22:15 +0100)]
platform/wmi: string-kunit: Add missing oversized string test case
When compiling the WMI string kunit tests using llvm, the compiler
will issue a warning about "oversized_test_utf8_string" being unused.
This happens because the test case that was supposed to use said
variable was accidentally omitted when adding the kunit tests.
Fix this by adding the aforementioned test case.
Fixes: 0e1a8143e797 ("platform/wmi: Add kunit test for the string conversion code") Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/platform-driver-x86/20260122234521.GA413183@ax162/ Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260123211537.4448-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Werner Sembach [Thu, 15 Jan 2026 15:42:02 +0000 (16:42 +0100)]
platform/x86/uniwill: Implement cTGP setting
Uniwill offers user setable cTGP for their EC on devices using NVIDIA 3000
Series and newer GPUs. This patch implements this setting as a sysfs
attribute.
For one device, the TUXEDO InfinityBook Gen7, the variant with and without
NVIDIA GPU can't be differentiated using only the DMI strings, so the new
probe callback needs to be used to test a bit from the EC memory.
Co-developed-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260115154332.402873-2-wse@tuxedocomputers.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Armin Wolf [Thu, 15 Jan 2026 15:42:01 +0000 (16:42 +0100)]
platform/x86: uniwill-laptop: Introduce device descriptor system
Future additions to the driver will depend on device-specific
initialization steps. Extend the DMI-based feature detection system
to include device descriptors. Each descriptor contains a bitmap of
supported features and a set of callback for performing
device-specific initialization.
Signed-off-by: Armin Wolf <W_Armin@gmx.de> Co-developed-by: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260115154332.402873-1-wse@tuxedocomputers.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Zilin Guan [Tue, 6 Jan 2026 09:13:18 +0000 (09:13 +0000)]
platform/x86/amd: Use scope-based cleanup for wbrf_record()
Simplify resource management in wbrf_record() by using the scope-based
cleanup helper __free(). This ensures that the tmp and obj are
automatically freed when they go out of scope, eliminating the need for
explicit error handling labels and manual freeing.
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Suggested-by: Markus Elfring <Markus.Elfring@web.de> Co-developed-by: Jianhao Xu <jianhao.xu@seu.edu.cn> Signed-off-by: Jianhao Xu <jianhao.xu@seu.edu.cn> Signed-off-by: Zilin Guan <zilin@seu.edu.cn> Link: https://patch.msgid.link/20260106091318.747019-2-zilin@seu.edu.cn Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Benjamin Philip [Tue, 6 Jan 2026 18:48:29 +0000 (00:18 +0530)]
platform/x86: ideadpad-laptop: Clean up style warnings and checks
This commit makes some style changes to clean up the following
checkpatch warnings and checks at various places in ideapad.c:
- WARNING: quoted string split across lines
- WARNING: space prohibited between function name and open parenthesis '('
- WARNING: braces {} are not necessary for any arm of this statement
- CHECK: Alignment should match open parenthesis
We exceed the 80 column limit to fix the quoted string warning since
strings in question are user visible. See coding style, part 2 for
details.
Signed-off-by: Benjamin Philip <benjamin.philip495@gmail.com> Acked-by: Ike Panhc <ikepanhc@gmail.com> Link: https://patch.msgid.link/20260106184830.34426-1-benjamin.philip495@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Shyam Sundar S K [Thu, 15 Jan 2026 17:34:48 +0000 (09:34 -0800)]
platform/x86/amd/pmf: Introduce new interface to export NPU metrics
The PMF driver retrieves NPU metrics data from the PMFW. Introduce a new
interface to make NPU metrics accessible to other drivers like AMDXDNA
driver, which can access and utilize this information as needed.
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
[lizhi: save return value of is_npu_metrics_supported() and return it] Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260115173448.403826-1-lizhi.hou@amd.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
crypto: ccp - Send PSP_CMD_TEE_RING_DESTROY when PSP_CMD_TEE_RING_INIT fails
The hibernate resume sequence involves loading a resume kernel that is just
used for loading the hibernate image before shifting back to the existing
kernel.
During that hibernate resume sequence the resume kernel may have loaded
the ccp driver. If this happens the resume kernel will also have called
PSP_CMD_TEE_RING_INIT but it will never have called
PSP_CMD_TEE_RING_DESTROY.
This is problematic because the existing kernel needs to re-initialize the
ring. One could argue that the existing kernel should call destroy
as part of restore() but there is no guarantee that the resume kernel did
or didn't load the ccp driver. There is also no callback opportunity for
the resume kernel to destroy before handing back control to the existing
kernel.
Similar problems could potentially exist with the use of kdump and
crash handling. I actually reproduced this issue like this:
1) rmmod ccp
2) hibernate the system
3) resume the system
4) modprobe ccp
The resume kernel will have loaded ccp but never destroyed and then when
I try to modprobe it fails.
Because of these possible cases add a flow that checks the error code from
the PSP_CMD_TEE_RING_INIT call and tries to call PSP_CMD_TEE_RING_DESTROY
if it failed. If this succeeds then call PSP_CMD_TEE_RING_INIT again.
Fixes: f892a21f51162 ("crypto: ccp - use generic power management") Reported-by: Lars Francke <lars.francke@gmail.com> Closes: https://lore.kernel.org/platform-driver-x86/CAD-Ua_gfJnQSo8ucS_7ZwzuhoBRJ14zXP7s8b-zX3ZcxcyWePw@mail.gmail.com/ Tested-by: Yijun Shen <Yijun.Shen@Dell.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://patch.msgid.link/20260116041132.153674-6-superm1@kernel.org Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
crypto: ccp - Factor out ring destroy handling to a helper
The ring destroy command needs to be used in multiple places. Split
out the code to a helper.
Tested-by: Yijun Shen <Yijun.Shen@Dell.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://patch.msgid.link/20260116041132.153674-5-superm1@kernel.org Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The system will have lost power during S4. The ring used for TEE
communications needs to be initialized before use.
Fixes: f892a21f51162 ("crypto: ccp - use generic power management") Reported-by: Lars Francke <lars.francke@gmail.com> Closes: https://lore.kernel.org/platform-driver-x86/CAD-Ua_gfJnQSo8ucS_7ZwzuhoBRJ14zXP7s8b-zX3ZcxcyWePw@mail.gmail.com/ Tested-by: Yijun Shen <Yijun.Shen@Dell.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://patch.msgid.link/20260116041132.153674-4-superm1@kernel.org Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
crypto: ccp - Declare PSP dead if PSP_CMD_TEE_RING_INIT fails
tee_init_ring() only declares PSP dead if the command times out.
If there is any other failure it is still considered fatal though.
Set psp_dead for other failures as well.
Fixes: 949a0c8dd3c2 ("crypto: ccp - Move direct access to some PSP registers out of TEE") Tested-by: Yijun Shen <Yijun.Shen@Dell.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://patch.msgid.link/20260116041132.153674-3-superm1@kernel.org Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Shyam Sundar S K [Fri, 16 Jan 2026 04:11:28 +0000 (22:11 -0600)]
platform/x86/amd/pmf: Prevent TEE errors after hibernate
After resuming from hibernate, TEE commands can time out and cause PSP
disables. Fix this by reinitializing the Trusted Application (TA) and
cancelling the pb workqueue in the hibernate callbacks to avoid these
errors.
Rong Zhang [Tue, 20 Jan 2026 18:20:08 +0000 (02:20 +0800)]
platform/x86: lenovo-wmi-other: Add HWMON for fan reporting/tuning
Register an HWMON device for fan reporting/tuning according to
Capability Data 00 (capdata00) and Fan Test Data (capdata_fan) provided
by lenovo-wmi-capdata. The corresponding HWMON nodes are:
Information from capdata00 and capdata_fan are used to control the
visibility and constraints of HWMON attributes. Fan info from capdata00
is collected on bind, while fan info from capdata_fan is collected in a
callback. Once all fan info is collected, register the HWMON device.
Signed-off-by: Rong Zhang <i@rong.moe> Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com> Tested-by: Kurt Borja <kuurtb@gmail.com> Link: https://patch.msgid.link/20260120182104.163424-8-i@rong.moe Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Rong Zhang [Tue, 20 Jan 2026 18:20:07 +0000 (02:20 +0800)]
platform/x86: lenovo-wmi-capdata: Wire up Fan Test Data
A capdata00 attribute (0x04050000) describes the presence of Fan Test
Data. Query it, and bind Fan Test Data as a component of capdata00
accordingly. The component master of capdata00 may pass a callback while
binding to retrieve fan info from Fan Test Data.
The callback will be called once both the master and the sub-component
are bound to the sub-master (component).
This scheme is essential to solve these issues:
- The component framework only supports one aggregation per master
- A binding is only established until all components are found
- The Fan Test Data interface may be missing on some devices
- To get rid of queries for the presence of WMI GUIDs
- The notifier framework cannot cleanly connect capdata_fan to
lenovo-wmi-other without introducing assumptions on probing sequence
capdata00 is registered as a component and a sub-master on probe,
instead of chaining the registrations in one's bind callback. This is
because calling (un)registration methods of the component framework
causes deadlock in (un)bind callbacks, i.e., it's impossible to register
capdata00 as a sub-master/component in its component/sub-master bind
callback, and vice versa.
Signed-off-by: Rong Zhang <i@rong.moe> Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com> Tested-by: Derek J. Clark <derekjohn.clark@gmail.com> Link: https://patch.msgid.link/20260120182104.163424-7-i@rong.moe Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Rong Zhang [Tue, 20 Jan 2026 18:20:06 +0000 (02:20 +0800)]
platform/x86: lenovo-wmi-capdata: Add support for Fan Test Data
Add support for LENOVO_FAN_TEST_DATA WMI data block. Provides an
interface for querying the min/max fan speed RPM (reference data) of a
given fan ID.
This interface is optional. Hence, it does not bind to lenovo-wmi-other
and is not registered as a component for the moment. Appropriate binding
will be implemented in the subsequent patch.
Signed-off-by: Rong Zhang <i@rong.moe> Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com> Tested-by: Derek J. Clark <derekjohn.clark@gmail.com> Link: https://patch.msgid.link/20260120182104.163424-6-i@rong.moe Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Rong Zhang [Tue, 20 Jan 2026 18:20:05 +0000 (02:20 +0800)]
platform/x86: lenovo-wmi-capdata: Add support for Capability Data 00
Add support for LENOVO_CAPABILITY_DATA_00 WMI data block that comes on
"Other Mode" enabled hardware. Provides an interface for querying if a
given attribute is supported by the hardware, as well as its default
value.
capdata00 always presents on devices with capdata01. lenovo-wmi-other
now binds to both (no functional change intended).
Signed-off-by: Rong Zhang <i@rong.moe> Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com> Tested-by: Derek J. Clark <derekjohn.clark@gmail.com> Link: https://patch.msgid.link/20260120182104.163424-5-i@rong.moe Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Rong Zhang [Tue, 20 Jan 2026 18:20:04 +0000 (02:20 +0800)]
platform/x86: lenovo-wmi-{capdata,other}: Support multiple Capability Data
The current implementation are heavily bound to capdata01. Rewrite it so
that it is suitable to utilize other Capability Data as well.
No functional change intended.
Signed-off-by: Rong Zhang <i@rong.moe> Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com> Tested-by: Derek J. Clark <derekjohn.clark@gmail.com> Link: https://patch.msgid.link/20260120182104.163424-4-i@rong.moe Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Rong Zhang [Tue, 20 Jan 2026 18:20:03 +0000 (02:20 +0800)]
platform/x86: Rename lenovo-wmi-capdata01 to lenovo-wmi-capdata
Prepare for the upcoming changes to make it suitable to retrieve
and provide other Capability Data as well.
Signed-off-by: Rong Zhang <i@rong.moe> Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com> Tested-by: Derek J. Clark <derekjohn.clark@gmail.com> Link: https://patch.msgid.link/20260120182104.163424-3-i@rong.moe Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Rong Zhang [Tue, 20 Jan 2026 18:20:02 +0000 (02:20 +0800)]
platform/x86: lenovo-wmi-helpers: Convert returned buffer into u32
The Windows WMI-ACPI driver converts all ACPI objects into a common
buffer format, so returning a buffer with four bytes will look like an
integer for WMI consumers under Windows.
Therefore, some devices may simply implement the corresponding ACPI
methods to always return a buffer. While lwmi_dev_evaluate_int() expects
an integer (u32), convert returned >=4B buffer into u32 to support these
devices.
During the rework of the fan behavior control code in commit d8e8362b09d3 ("platform/x86: acer-wmi: Fix setting of fan behavior"),
acer_toggle_turbo() was changed to use WMID_gaming_set_fan_behavior()
instead of WMID_gaming_set_u64() when switching the fans to turbo
mode. The new function however does not check if the necessary
capability (ACER_CAP_TURBO_FAN) is actually enabled on a given
machine, causing the driver to potentially access unsupported
features.
Fix this by manually checking if ACER_CAP_TURBO_FAN is enabled
on a given machine before changing the fan mode.
Cc: stable@vger.kernel.org Fixes: d8e8362b09d3 ("platform/x86: acer-wmi: Fix setting of fan behavior") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260108164716.14376-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: hp-bioscfg: Fix kernel panic in GET_INSTANCE_ID macro
The GET_INSTANCE_ID macro that caused a kernel panic when accessing sysfs
attributes:
1. Off-by-one error: The loop condition used '<=' instead of '<',
causing access beyond array bounds. Since array indices are 0-based
and go from 0 to instances_count-1, the loop should use '<'.
2. Missing NULL check: The code dereferenced attr_name_kobj->name
without checking if attr_name_kobj was NULL, causing a null pointer
dereference in min_length_show() and other attribute show functions.
The panic occurred when fwupd tried to read BIOS configuration attributes:
Oops: general protection fault [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:min_length_show+0xcf/0x1d0 [hp_bioscfg]
Add a NULL check for attr_name_kobj before dereferencing and corrects
the loop boundary to match the pattern used elsewhere in the driver.
Cc: stable@vger.kernel.org Fixes: 5f94f181ca25 ("platform/x86: hp-bioscfg: bioscfg-h") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20260115203725.828434-3-mario.limonciello@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Armin Wolf [Fri, 16 Jan 2026 20:41:16 +0000 (21:41 +0100)]
platform/wmi: Update driver development guide
New WMI drivers should use the new buffer-based WMI API instead of
the deprecated ACPI-based API. Update the driver development guide
to recommend the buffer-based API to driver developers and explain
the purpose of struct wmi_buffer.
Also update the ACPI interface documentation to describe the
conversion rules for converting ACPI objects into WMI buffers.
Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260116204116.4030-10-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Armin Wolf [Fri, 16 Jan 2026 20:41:11 +0000 (21:41 +0100)]
platform/wmi: Add kunit test for the string conversion code
The string conversion frunctions provided by the WMI driver core
have no dependencies on the remaining WMI API, making them suitable
for unit tests.
Implement such a unit test using kunit. Those unit tests verify that
converting between WMI strings and UTF8 strings works as expected.
They also verify that edge cases are handled correctly.
Armin Wolf [Fri, 16 Jan 2026 20:41:10 +0000 (21:41 +0100)]
platform/wmi: Add helper functions for WMI string conversions
WMI strings are encoded using UTF16-LE characters, forcing WMI drivers
to manually convert them to/from standard UTF8 strings. Add a two
helper functions for those tasks.
Armin Wolf [Fri, 16 Jan 2026 20:41:09 +0000 (21:41 +0100)]
platform/wmi: Add kunit test for the marshalling code
The marshalling code used by the WMI driver core is implemented as
a separate component, suitable for unit tests.
Implmented such a unit test using KUnit. Those unit tests verify that
ACPI objects are correctly converted into WMI buffers and that WMI
strings are correctly converted into ACPI strings. They also verify
that invalid ACPI data (like nested packages) is rejected.
Armin Wolf [Fri, 16 Jan 2026 20:41:08 +0000 (21:41 +0100)]
platform/wmi: Introduce marshalling support
The Windows WMI-ACPI driver likely uses wmilib [1] to interact with
the WMI service in userspace. Said library uses plain byte buffers
for exchanging data, so the WMI-ACPI driver has to convert between
those byte buffers and ACPI objects returned by the ACPI firmware.
The format of the byte buffer is publicly documented [2], and after
some reverse eingineering of the WMI-ACPI driver using a set of custom
ACPI tables, the following conversion rules have been discovered:
- ACPI integers are always converted into a uint32
- ACPI strings are converted into special WMI strings
- ACPI buffers are copied as-is
- ACPI packages are unpacked
Extend the ACPI-WMI driver to also perform this kind of marshalling
for WMI data blocks, methods and events. Doing so gives us a number
of benefits:
- WMI drivers are not restricted to a fixed set of supported ACPI data
types anymore, see dell-wmi-aio (integer vs buffer) and
hp-wmi-sensors (string vs buffer)
- correct marshalling of WMI strings when data blocks are marked
as requiring ACPI strings instead of ACPI buffers
- development of WMI drivers without having to understand ACPI
This eventually should result in better compatibility with some
ACPI firmware implementations and in simpler WMI drivers. There are
however some differences between the original Windows driver and
the ACPI-WMI driver when it comes to ACPI object conversions:
- the Windows driver copies internal _ACPI_METHOD_ARGUMENT_V1 data
structures into the output buffer when encountering nested ACPI
packages. This is very likely an error inside the driver itself, so
we do not support nested ACPI packages.
- when converting WMI strings (UTF-16LE) into ACPI strings (ASCII),
the Windows driver replaces non-ascii characters (ä -> a, & -> ?)
instead of returning an error. This behavior is not documented
anywhere and might lead to severe errors in some cases (like
setting BIOS passwords over WMI), so we simply return an error.
As the current bus-based WMI API is based on ACPI buffers, a new
API is necessary. The legacy GUID-based WMI API is not extended to
support marshalling, as WMI drivers using said API are expected to
move to the bus-based WMI API in the future.
This version includes the following changes:
- Allow read only commands for non root users when permitted
- Fix file descriptor leak in isolate_cpus()
- Replace hardcoded libnl3 include path
tools/power/x86/intel-speed-select: Fix file descriptor leak in isolate_cpus()
The file descriptor opened in isolate_cpus() when (!level) is true was
not being closed before returning, causing a file descriptor leak in
both the error path and the success path.
When write() fails at line 950, the function returns at line 953 without
closing the file descriptor. Similarly, on success, the function returns
at line 956 without closing the file descriptor.
Add close(fd) calls before both return statements to fix the resource
leak. This follows the same pattern used elsewhere in the same function
where file descriptors are properly closed before returning (see lines
1005 and 1027).
Khem Raj [Mon, 29 Dec 2025 20:45:06 +0000 (12:45 -0800)]
tools/power/x86/intel-speed-select: Use pkg-config for libnl-3.0 detection
Replace hardcoded libnl3 include path with pkg-config detection to
improve portability across different distributions and build environments.
The previous implementation used a fixed path constructed from the
compiler's sysroot, which could fail on systems with non-standard
library installations. Now the build system:
- Attempts to detect libnl-3.0 include paths using pkg-config
- Falls back to /usr/include/libnl3 if pkg-config is unavailable
- Maintains backward compatibility with existing build configurations
This ensures the tool builds correctly on a wider range of systems
while preserving existing behavior when pkg-config is not present.
platform/x86: hp-bioscfg: Fix kobject warnings for empty attribute names
The hp-bioscfg driver attempts to register kobjects with empty names when
the HP BIOS returns attributes with empty name strings. This causes
multiple kernel warnings:
kobject: (00000000135fb5e6): attempted to be registered with empty name!
WARNING: CPU: 14 PID: 3336 at lib/kobject.c:219 kobject_add_internal+0x2eb/0x310
Add validation in hp_init_bios_buffer_attribute() to check if the
attribute name is empty after parsing it from the WMI buffer. If empty,
log a debug message and skip registration of that attribute, allowing the
module to continue processing other valid attributes.
Cc: stable@vger.kernel.org Fixes: a34fc329b189 ("platform/x86: hp-bioscfg: bioscfg") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20260115203725.828434-2-mario.limonciello@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Denis Benato [Fri, 2 Jan 2026 23:43:43 +0000 (00:43 +0100)]
platform/x86: asus-wmi: fix sending OOBE at probe
Disabling OOBE is an important step to be able to fully control the
hardware in TUF laptops that requires this command, but the command
has been incorrectly tied to deprecated attributes: restore sending
the OOBE exit command.
platform/x86: asus-armoury: Add power limits for Asus G513QY
Add the DMI entry and power limits for the Asus ROG Strix G15
Advantage Edition (G513QY). This laptop requires manual fan curves
and specific APU/Platform PPT limits.
Krishna Chomal [Tue, 13 Jan 2026 18:26:03 +0000 (23:56 +0530)]
platform/x86: hp-wmi: fix platform profile values for Omen 16-wf1xxx
HP Omen 16-wf1xxx (board ID 8C78) currently sends the incorrect
Victus-specific thermal profile values via WMI, leading to a logical
inconsistency when switching between platform profiles.
The driver currently uses Victus S values:
0x00 => Balanced / Low-Power
0x01 => Performance
However, Omen Gaming Hub logs / EC register inspection on Windows shows
that this board is intended to use:
0x30 => Balanced / Low-Power
0x31 => Performance
This patch corrects the thermal profile command values to match the
values observed from Omen Gaming Hub logs. The performance benchmarks
and peak power draw (from both CPU and GPU) show no observable change
with this correction (suggesting that the firmware is currently tolerant
of the incorrect values). However sending the correct values prevents
potential regressions after future firmware updates.
Refactor victus_s_thermal_profile_boards from a list of strings to a
dmi_system_id table and move the lookup to module init. The new struct
thermal_profile_params is used to store board-specific WMI parameters,
allowing the driver to cache these values in a static pointer. This
avoids repeated DMI string comparisons and allows marking of DMI table as
__initconst.
Testing on HP Omen 16-wf1xxx (board 8C78) confirmed WMI codes 0x30/0x31
are now sent, resolving the logical inconsistency and ensuring the value
visible in EC registers match the Windows state for this profile.
Fixes: fb146a38cb11 ("platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support") Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com> Link: https://patch.msgid.link/20260113182604.115211-2-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Krishna Chomal [Tue, 13 Jan 2026 12:37:38 +0000 (18:07 +0530)]
platform/x86: hp-wmi: implement fan keep-alive
The firmware on some HP laptops automatically reverts the fan speed
control to "Auto" mode after a 120 second timeout window.
To ensure that the user-selected fan profile (Max/Manual) persists,
implement a keep-alive mechanism that periodically refreshes the fan
mode trigger before the timeout occurs.
- Introduce a delayed workqueue to trigger the fan mode refresh every 90
seconds, ensuring the system maintains the correct fan mode setting.
- Integrate the refresh mechanism into hp_wmi_apply_fan_settings() to
start, update or cancel the keep-alive process based on the current
fan mode.
This ensures that the driver stays in sync with the hardware.
Krishna Chomal [Tue, 13 Jan 2026 12:37:37 +0000 (18:07 +0530)]
platform/x86: hp-wmi: add manual fan control for Victus S models
Add manual fan speed control and PWM reporting for HP Victus S-series
laptops.
While HPWMI_FAN_SPEED_SET_QUERY was previously added to reset max fan
mode, it is actually capable of individual fan control. This patch
implements hp_wmi_fan_speed_set() to allow manual control and hides
PWM inputs for non-Victus devices as the query is Victus specific.
The existing hp_wmi_fan_speed_max_get() query is unreliable on Victus S
firmware, often incorrectly reporting "Auto" mode even when "Max" is
active. To resolve this synchronization issue, move state tracking to
a per-device private context and apply "Auto" mode during driver
initialization to ensure a consistent starting point.
Refactor hp_wmi_apply_fan_settings() to use an intermediate ret
variable. This prepares the switch block for keep-alive logic being
added in a later patch, avoiding the need for duplicated mode check.
Krishna Chomal [Tue, 13 Jan 2026 12:37:36 +0000 (18:07 +0530)]
platform/x86: hp-wmi: order include headers
The include headers in hp-wmi driver are currently not in any specific
order. As the driver continues to grow, keep the header block organized
by sorting them alphabetically.
Nitin Joshi [Tue, 6 Jan 2026 17:45:18 +0000 (02:45 +0900)]
platform/x86: thinkpad_acpi: Add support to detect hardware damage detection capability.
Thinkpads are adding the ability to detect and report hardware damage
status. Add new sysfs interface to identify whether hardware damage
is detected or not.
Initial support is available for the USB-C replaceable connector.
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Nitin Joshi <nitjoshi@gmail.com> Link: https://patch.msgid.link/20260106174519.6402-1-nitjoshi@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Xi Pardee [Thu, 8 Jan 2026 22:31:41 +0000 (14:31 -0800)]
platform/x86/intel/pmc: Enable substate residencies for multiple PMCs
Enable substate residencies support for multiple PMCs. Previously
substate residencies were shown only for the primary PMC. This
change enables substate residencies for all available PMCs.
The output of substate_residencies with this patch will be similar
to this:
pmc0 Substate Residency
S0i2.0 0
S0i2.1 0
S0i2.2 0
pmc1 Substate Residency
S0i2.0 0
S0i2.1 0
S0i2.2 0
pmc2 Substate Residency
S0i2.0 0
Xi Pardee [Thu, 8 Jan 2026 22:31:40 +0000 (14:31 -0800)]
platform/x86/intel/pmc: Move LPM mode attributes to PMC
Move LPM modes attributes from the pmc_dev to the pmc structure. LPM
modes are PMC-specific and should be stored within the pmc structure.
After the change, LPM mode information will be retrieved and stored per
PMC. The substate_requirements attribute in debugfs will display the
requirements for each enabled LPM substate.
Xi Pardee [Thu, 8 Jan 2026 22:31:39 +0000 (14:31 -0800)]
platform/x86/intel/pmc: Change LPM mode fields to u8
Change the datatypes of num_lpm_modes and lpm_en_modes[] from int
to u8. The u8 type is more appropriate and improves the readability
and maintainability of the code.
platform/x86: ISST: Check for admin capability for write commands
In some SST deployments, administrators want to allow reading SST
capabilities for non-root users. This can be achieved by changing file
permissions for "/dev/isst_interface", but they still want to prevent
any changes to the SST configuration by non-root users.
This capability was available before for non-TPMI SST. Extend the same
capability for TPMI SST by adding a check for CAP_SYS_ADMIN for all
write commands.
platform/x86: ISST: Store and restore all domains data
The suspend/resume callbacks currently only store and restore the
configuration for power domain 0. However, other power domains may also
have modified configurations that need to be preserved across suspend/
resume cycles.
Extend the store/restore functionality to handle all power domains.
platform/x86/intel/uncore-freq: Replace sprintf() with sysfs_emit()
Replace sprintf() with sysfs_emit() in sysfs show functions. The
sysfs_emit() function is the preferred way to format sysfs output as
it ensures proper buffer bounds checking and correct return values.
platform/x86/intel/uncore-freq: Replace sprintf() with scnprintf()
Replace unbounded sprintf() calls with scnprintf() to prevent potential
buffer overflows when formatting device names. While the current format
strings cannot overflow the buffer, using scnprintf() follows kernel
best practices for string formatting.
Benjamin Philip [Thu, 1 Jan 2026 14:16:57 +0000 (19:46 +0530)]
platform/x86: yogabook: Clean up code style
This commit cleans up the following checks flagged by checkpatch in
yogabook.c:
- CHECK: Prefer kernel type 'u8' over 'uint8_t'
- CHECK: Comparison to NULL could be written "!data"
- CHECK: line length of ... exceeds 100 columns
Signed-off-by: Benjamin Philip <benjamin.philip495@gmail.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Link: https://patch.msgid.link/20260101141657.54258-1-benjamin.philip495@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Thorsten Blum [Mon, 5 Jan 2026 14:50:46 +0000 (15:50 +0100)]
platform/surface: Replace deprecated strcpy() in surface_button_add()
strcpy() has been deprecated [1] because it performs no bounds checking
on the destination buffer, which can lead to buffer overflows. Replace
it with the safer strscpy(). No functional changes.
Haiyue Wang [Tue, 30 Dec 2025 13:30:50 +0000 (21:30 +0800)]
docs: fix PPR for AMD EPYC broken link
As 'AMD Documentation Hub' [1] announced: "All technical documentation,
including for AMD EPYC™ processors ..., and more is now hosted on the
AMD Technical Information Portal (TIP) [2]".
Alok Tiwari [Wed, 24 Dec 2025 09:51:09 +0000 (01:51 -0800)]
platform/x86/intel/pmt/discovery: use valid device pointer in dev_err_probe
The PMT feature probe creates a child device with device_create().
If device creation fail, the code pass priv->dev (which is an ERR_PTR)
to dev_err_probe(), which is not a valid device pointer.
This patch change the dev_err_probe() call to use the parent auxiliary
device (&auxdev->dev) and update the error message to reference the
parent device name. It ensure correct error reporting and avoid
passing an invalid device pointer.
Junrui Luo [Fri, 26 Dec 2025 11:42:05 +0000 (19:42 +0800)]
platform/x86: hp-bioscfg: Fix out-of-bounds array access in ACPI package parsing
The hp_populate_*_elements_from_package() functions in the hp-bioscfg
driver contain out-of-bounds array access vulnerabilities.
These functions parse ACPI packages into internal data structures using
a for loop with index variable 'elem' that iterates through
enum_obj/integer_obj/order_obj/password_obj/string_obj arrays.
When processing multi-element fields like PREREQUISITES and
ENUM_POSSIBLE_VALUES, these functions read multiple consecutive array
elements using expressions like 'enum_obj[elem + reqs]' and
'enum_obj[elem + pos_values]' within nested loops.
The bug is that the bounds check only validated elem, but did not consider
the additional offset when accessing elem + reqs or elem + pos_values.
The fix changes the bounds check to validate the actual accessed index.
Reported-by: Yuhao Jiang <danisjiang@gmail.com> Reported-by: Junrui Luo <moonafterrain@outlook.com> Fixes: e6c7b3e15559 ("platform/x86: hp-bioscfg: string-attributes") Signed-off-by: Junrui Luo <moonafterrain@outlook.com> Link: https://patch.msgid.link/SYBPR01MB788173D7DD4EA2CB6383683DAFB0A@SYBPR01MB7881.ausprd01.prod.outlook.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Tomáš Hnyk [Fri, 26 Dec 2025 20:34:54 +0000 (21:34 +0100)]
platform/x86: ideapad-laptop: Reassign KEY_CUT to KEY_SELECTIVE_SCREENSHOT
As per Lenovo documentation, Fn+Print-Screen should "Open the Snipping
tool" which corresponds to KEY_SELECTIVE_SCREENSHOT (keycode 0x27a). It
is currently assigned to KEY_CUT because keycodes under 248 were
preferred due to X11 limitations.
Reassign Fn+Print-Screen from KEY_CUT to KEY_SELECTIVE_SCREENSHOT.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220566 Signed-off-by: Tomáš Hnyk <tomashnyk@gmail.com> Link: https://patch.msgid.link/20251226203454.405520-1-tomashnyk@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
A user reported that reading the charge threshold on his device
results in very strange values (like 78497792) being returned.
The reason for this seems to be the fact that the driver casts
the int pointer to an u8 pointer, leaving the last 3 bytes of
the destination uninitialized. Fix this by using a temporary
variable instead.
platform/x86/intel/pmt: Fix kobject memory leak on init failure
When kobject_init_and_add() fails in pmt_features_discovery(), the
function returns without calling kobject_put(). This violates the
kobject API contract where kobject_put() must be called even on
initialization failure to properly release allocated resources.
projects / thirdparty / linux.git / log
