The driver sets acpi_device_name() to initialize an input class device
name initialization and print a message on probe success, but the input
class device name can be set directly to the "Surface Pro 3/4 Buttons"
string literal and used for printing the message.
Make the driver do so, stop setting acpi_device_name() in it and drop
the symbol specifically defined for this purpose.
No intentional functional impact.
This will facilitate the removal of device_name from struct
acpi_device_pnp in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Chen Yu <yu.c.chen@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/12927239.O9o76ZdvQC@rafael.j.wysocki
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Currently, manual fan control on supported HP models uses a single
PWM value for both CPU and GPU fans, linking their speeds via a hardcoded
gpu_delta offset. This prevents userspace tools from managing the thermal
profiles of the CPU and GPU independently.
Refactor the hwmon implementation to support independent dual-channel
PWM control:
- Split the single 'pwm' state into 'cpu_pwm' and 'gpu_pwm'.
- Expose a second PWM channel ('pwm2') to userspace via hwmon_channel_info.
- Remove the gpu_delta mechanism entirely.
The 'pwm1_enable' mode remains shared, as the underlying hardware does
not support per-fan modes. When switching to manual mode, both fans are
smoothly initialized to their current RPMs. Additionally, ensure that
the HP_FAN_SPEED_AUTOMATIC flag is isolated from rpm_to_pwm mathematical
interpolations during mode resets to prevent unintended fan states.
Tested on: HP Victus 16-s0xxx
Tested-by: Radhey Kalra <radheykalra901@gmail.com>
Signed-off-by: Kürşat Abaylı <hello@kursatabayli.dev>
Link: https://patch.msgid.link/20260707203740.55369-1-hello@kursatabayli.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Convert init_rog_tunables() to use the cleanup infrastructure to
automatically free ac_rog_tunables if dc_rog_tunables allocation fails.
By declaring local pointers with the __free(kfree) attribute, the
manual kfree() in the error path can be removed. Upon successful
initialization, the ownership is transferred to the global struct
using no_free_ptr().
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
Link: https://patch.msgid.link/20260707213741.6515-3-scardracs@disroot.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
In init_rog_tunables(), if dc_limits are defined and allocating
dc_rog_tunables fails, the already allocated ac_rog_tunables gets
freed but the pointer stored in
asus_armoury.rog_tunables[ASUS_ROG_TUNABLE_AC] is not cleared. Since
init_rog_tunables() returns void, the driver initialization continues,
which can lead to a Use-After-Free (UAF) when asus_fw_attr_add()
accesses the freed AC tunables pointer.
Additionally, if init_rog_tunables() succeeds but asus_fw_attr_add()
fails, the allocated tunables are not freed, resulting in a memory leak.
Fix these issues by making init_rog_tunables() return an error code and
propagating it in asus_fw_init(). Defer setting the global pointers in
asus_armoury.rog_tunables until both tunables have been successfully
allocated. If asus_fw_attr_add() fails, release the allocated resources
using a standard goto rollback block in asus_fw_init().
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
Link: https://patch.msgid.link/20260707213741.6515-2-scardracs@disroot.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
On the LG Gram 16T90SP, the ACPI firmware will only accept the values
0x80, 0xA2 and 0xA4 when setting the keyboard backlight. After a bit
of research using ACPI tables from older models it seems that bit 8
is supposed to be always written as 1.
Fix the keyboard backlight support on this model by always setting
bit 8 inside the argument passed to the WMAB ACPI control method.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260708195553.7762-6-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>
The WMAB ACPI control method can return two kinds of results:
1. A ACPI integer containing the result.
2. A ACPI buffer containing the result and an error code.
Devices implement one of those mechanisms, but not both. Extend
lg_wmab() to abstract away the differences between both mechanisms
to fix keyboard backlight support on newer devices.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260708195553.7762-5-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>
LG devices support two interfaces for receiving events:
- the WMI-based interface currently being used by the driver
- a ACPI-based interface similar to the WMI-based interface
Older devices use the WMI-based interface by default and need
to be manually switched into ACPI mode. Newer devices however
only support the ACPI-based interface, preventing the current
driver from receiving events on them.
Fix this by always using the native ACPI-based interface for
receiving events.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260708195553.7762-3-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>
The event notification callback might access kbd_backlight even
when it was not successfully registered with the LED subsystem.
The same happens inside acpi_remove(), where the LED devices are
unregistered unconditionally.
Fix this by tracking the availability of the kbd_backlight LED
device and use devm_led_classdev_register() to let devres take
care of unregistering the LED devices during removal. For this
the parent device of the LED devices is changed to the native
platform device.
Fixes: ae26278829 ("platform/x86: lg-laptop: Use correct event for keyboard backlight FN-key")
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260708195553.7762-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>
Newer ThinkPad systems expose a USB-C Security (Restricted Mode) feature.
When active, USB-C data connections are disabled while power delivery is
preserved. This is useful for kiosk and physically-secured deployments.
Hardware interface:
The HKEY device exposes a read-only ACPI method USCS():
Return value bit layout:
Bit 16 : Capability flag (1 = feature present on this SKU)
Bit 0 : Current state (0 = security OFF, 1 = security ON)
The sysfs attribute is read-only.
The Fn+U followed by Fn+S hotkey chord is the only way to toggle the
hardware state.
Hotkey:
Fn+U followed by Fn+S generates HKEY event 0x131e.
sysfs interface:
/sys/devices/platform/thinkpad_acpi/usb_c_security (read-only)
"enabled\n" -- data connections are currently blocked
"disabled\n" -- data connections are currently allowed
The attribute is hidden on SKUs where the USCS capability bit (bit 16)
is not set, so there is no ABI impact on unsupported hardware.
Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
Link: https://patch.msgid.link/20260709021504.465792-1-vishnuocv@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Add the AC and DC power limit definitions for the ASUS ROG Strix SCAR 16
2025 (G635LX), enabling the nv_tgp, nv_dynamic_boost and ppt_pl*_* tuning
attributes on this model. Without an entry in the power_limits table the
attributes are not exposed (has_valid_limit() returns false) and the
firmware power knobs cannot be controlled.
The G635LX ships an NVIDIA RTX 5090 Laptop GPU (150 W base TGP + 25 W
Dynamic Boost = 175 W max, per the ASUS specification) and an Intel Core
Ultra 9 275HX, matching the ROG Strix SCAR 18 (G835LW). The limits are
therefore taken from the G835LW sibling entry and the ASUS specification
rather than dumped from this board's firmware.
Testing on a G635LX confirmed the attributes populate with this entry and
that writing nv_dynamic_boost changes the measured GPU power draw
(~151 W at minimum, ~169 W at maximum during inference), i.e. the limits
reach firmware.
Signed-off-by: Avi Fenesh <aviarchi1994@gmail.com>
Link: https://patch.msgid.link/20260621130204.103566-1-aviarchi1994@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The HP OMEN MAX 16-ak0xxx (board ID: 8DD6) has the same WMI interface
as other Victus S boards, but requires quirks for correctly switching
thermal profile.
After testing we know that (similar to another HP Omen Max 16 device,
board ID 8D87), the embedded controller on this board does not expose
thermal profile which means we have to intentionally disable EC readback.
Add the DMI board name to victus_s_thermal_profile_boards[] table and
map it to omen_v1_no_ec_thermal_params.
Testing on board 8DD6 confirmed that platform profile is registered
successfully and fan RPMs are readable and controllable.
Tested-by: Yahia Ahmed <yahmedd043@gmail.com>
Cc: stable@vger.kernel.org # v6.18+
Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com>
Link: https://patch.msgid.link/20260623141314.33947-1-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>
Newer Huawei laptops (e.g. FLMH-XX / MateBook 14 2024) no longer support
the legacy WMI interface for Fn-lock control. Instead, they expose direct
ACPI methods \GFRS and \SFRS (Get/Set Fn key Reversal Status) which
communicate with the EC via registers 0x6B (read) and 0x6C (write).
Add huawei_acpi_fn_lock_get() and huawei_acpi_fn_lock_set() helpers that
use acpi_evaluate_object() to call these methods. Both
huawei_wmi_fn_lock_get() and huawei_wmi_fn_lock_set() now probe for
\GFRS/\SFRS via acpi_has_method() first and fall back to the legacy WMI
path if not present.
Tested on: HUAWEI FLMH-XX (MateBook 14 2024),
CachyOS (kernel 7.0.9-1-cachyos).
Signed-off-by: Shaposhnikov Daniil <2minesweeper2@gmail.com>
Link: https://patch.msgid.link/20260525130058.7408-2-2minesweeper2@gmail.com
[ij: removed a few blank lines and "legacy"s from comments]
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The driver sets acpi_device_class() which is never read afterward, so
make it stop doing that and drop the two symbols defined specifically
for this purpose.
Likewise, acpi_device_name() set by the driver is only used for input
class device name initialization and the "EBook Switch" string literal
may as well be used directly for that, so make the driver do so and
stop setting acpi_device_name(), which allows the symbol defined
specifically for this purpose to be dropped.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/2731795.Lt9SDvczpP@rafael.j.wysocki
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The driver sets acpi_device_class() which is never read afterward,
so make it stop doing that and drop the symbol defined specifically
for this purpose.
For consistency, also make it stop setting acpi_device_name() and add
a name field to the "fujitsu" structure for storing the name string
used during input class device initialization.
While at it, use scnprintf() instead of snprintf() for populating the
name and phys fields of the "fujitsu" structure.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/2378407.iZASKD2KPV@rafael.j.wysocki
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The driver sets acpi_device_name() that are only used for printing
messages and initializing input class device names. Since
ACPI_FUJITSU_BL_DEVICE_NAME and ACPI_FUJITSU_LAPTOP_DEVICE_NAME can
be used directly in all of those cases, make the driver do so and
stop setting acpi_device_name() in it.
Likewise, acpi_device_class() set by the driver are never read
afterward, so make the driver stop setting it and drop the symbol
defined specifically for this purpose.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Jonathan Woithe <jwoithe@just42.net>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/3441919.aeNJFYEL58@rafael.j.wysocki
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The driver sets acpi_device_name() which is never read afterward,
so make it stop doing that and drop the symbol defined specifically
for this purpose.
Likewise, acpi_device_class() set by the driver is only used for
generating ACPI netlink events, but the "hotkey" string literal may
as well be used directly for that, so make the driver do so and stop
setting acpi_device_class(), and drop the symbol defined specifically
for this purpose.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/2291726.irdbgypaU6@rafael.j.wysocki
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The driver sets acpi_device_name() which is never read afterward,
so make it stop doing that and drop the symbol defined specifically
for this purpose.
Likewise, acpi_device_class() set by the driver is only used for
generating ACPI netlink events, but the "hotkey" string literal may
as well be used directly for that, so make the driver do so and stop
setting acpi_device_class(), and drop the symbol defined specifically
for this purpose.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/5106055.GXAFRqVoOG@rafael.j.wysocki
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
hsmp_parse_acpi_table() published sock->dev before hsmp_read_acpi_crs()
had mapped virt_base_addr. sock->dev is the readiness gate for the
lock-free data plane, so on a multi-socket system - where socket 0
exposes /dev/hsmp before later sockets finish probing - an ioctl aimed
at a socket still in bring-up could pass the gate and dereference a NULL
virt_base_addr.
Publish sock->dev last with smp_store_release() once virt_base_addr, the
mailbox offsets and the semaphore are initialized, and read it with
smp_load_acquire() in hsmp_send_message() so a non-NULL dev guarantees
the rest of the socket state is visible.
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260629155634.1807598-5-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
hsmp_read_acpi_crs() and hsmp_read_acpi_dsd() read the ACPI handle and
emit error messages via sock->dev. Pass the struct device explicitly to
both helpers instead of reading it back from sock->dev.
This is a pure refactor with no functional change; it prepares for
publishing sock->dev as the data-plane readiness gate only after the
socket has been fully initialized, so the parsers must not depend on
sock->dev already being set.
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260629155634.1807598-4-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The .driver_data member of the the two struct ssam_device_id arrays were
initialized by list expressions. This isn't easily readable if you don't
work with the Surface System Aggregator core regularily. Using named
initializers is more explicit and thus easier to parse and also more
robust to changes of the struct definition. This robustness is relevant
for a planned change to struct ssam_device_id replacing .driver_data
by an anonymous union.
While touching these arrays, also drop the comma after the list
terminators.
This change doesn't introduce changes to the compiled ssam_device_id
arrays.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://patch.msgid.link/bc8eff03b2f36c82af5a75fc7114c277228921db.1781526433.git.u.kleine-koenig@baylibre.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The .driver_data member of the the two struct ssam_device_id arrays were
initialized by list expressions. This isn't easily readable if you don't
work with the Surface System Aggregator core regularily. Using named
initializers is more explicit and thus easier to parse and also more
robust to changes of the struct definition. This robustness is relevant
for a planned change to struct ssam_device_id replacing .driver_data
by an anonymous union.
This change doesn't introduce changes to the compiled ssam_device_id
arrays.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://patch.msgid.link/4421c8c959452d8a717ebc7cc905ad9c2912680c.1781522576.git.u.kleine-koenig@baylibre.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
set_attribute() populates the security area of the BIOS attribute request
buffer with the current admin password via populate_security_buffer(), then
dumps the whole request buffer with print_hex_dump_bytes(). This can expose
the plaintext admin password in the kernel log.
The same issue was fixed for the password attribute path by
commit d1a196e0a6 ("platform/x86: dell-wmi-sysman: Don't hex dump
plaintext password data"). Remove the remaining dump from the BIOS
attribute path.
Fixes: e8a60aa740 ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/20260614045353.143500-1-sammiee5311@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
MSI Claw devices produce WMI events through the MSI WMI hotkeys GUID for
some of their buttons. When pressed, these cause spam in the kernel. For
the majority of devices these events can be safely ignored as they are
duplicated by the AT Translated Set 2 Keyboard device exposed as an
evdev. For the MSI Claw A8 BZ2EM model's M-Center Menu button (left of
the screen) there is no associated keyboard event, so this event must be
exposed. Map this button to the same scancode produced by the AT
Keyboard device on other models. This does cause double F15 events on
the A1M, 7 AI+ A2VM, and 8 AI+ A2VM, but it appears to be harmless in my
testing.
Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260613021654.933618-3-derekjohn.clark@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The commit message of commit 5fbd827eb9 ("platform/x86: dell-wmi: Recognise or support new switches")
states that the ultra performance key contains additional data
after the type and code fields. The event data passed to
dell_wmi_process_key() is already parsed, so "buffer" already
starts after those two fields.
Use the correct index for accessing the first data field to avoid
a potential buffer overread.
Fixes: 5fbd827eb9 ("platform/x86: dell-wmi: Recognise or support new switches")
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260612173451.467629-4-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>
