| Age | Commit message (Collapse) | Author |
|---|
|
# Conflicts:
# drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
# net/ceph/osd_client.c
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
# Conflicts:
# sound/hda/codecs/side-codecs/cs35l41_hda.c
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
|
|
|
|
The 2023 ROG Flow X13 (GV302X*) is a 360-degree convertible like the
GV301, but the existing "GV301" DMI entry does not match it, so the
driver does not register SW_TABLET_MODE and the desktop does not switch
to tablet mode when the screen is folded back.
With asus_nb_wmi.tablet_mode_sw=3 (lid-flip-rog) the "Asus WMI hotkeys"
input device reports SW_TABLET_MODE on every fold and unfold, so apply
quirk_asus_tablet_mode to GV302X* too. Apart from the tablet switch this
quirk is the same as quirk_asus_unknown, which these models get today.
DMI product name of the tested machine: "ROG Flow X13 GV302XV_GV302XV".
Tested on GV302XV.
Signed-off-by: Nikolay Plastinin <plaztininikolai@gmail.com>
Link: https://patch.msgid.link/20260924-gv302-tablet-v1-1-a45dd3a383f1@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Fix various spelling mistakes in comments found by codespell.
Assisted-by: Claude:claude-opus-5-5 codespell
Signed-off-by: Zain Aboobacker <zainaboobacker33@gmail.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Link: https://patch.msgid.link/20260926162528.25365-1-zainaboobacker33@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 17-ck1xxx (board 8A17) isn't in omen_thermal_profile_boards,
so hp-wmi uses the generic thermal profile query. The firmware only
stores that value and never acts on it, so the EC stays in its default
mode and the CPU is held at 45 W whatever profile is selected.
The board uses the OMEN interface (mode byte at EC 0x95, thermal policy
v1) and also needs the timed profile quirk: without it, the EC drops
back to the default mode about two minutes after each profile change.
Add 8A17 to omen_thermal_profile_boards and
omen_timed_thermal_profile_boards.
With this, all three profiles work and sustained package power under
load goes from 45 W to 56-79 W.
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Ciro Pedrini <ciro.pedrini@gmail.com>
Link: https://patch.msgid.link/20260925205226.883724-1-ciro.pedrini@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 Victus 15-fb3xxx (board ID: 8DD0) uses the existing
OMEN v1 WMI interface (despite being a Victus model) but does not use
the standard EC thermal profile parameters.
Add the DMI board name to hp_wmi_feature_boards[] and map it to
omen_v1_no_ec_board_params.
This enables the existing board-specific handling for 8DD0,
including platform profile and fan control support.
Link: https://github.com/yunusemreyl/omen-space/issues/206
Signed-off-by: Suryansh Singh <technosfan14@gmail.com>
Link: https://patch.msgid.link/20260927095701.185772-1-technosfan14@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
NULL-terminate the attribute group list and let sysfs_create_groups()
create it so that sysfs_remove_groups() can be used to rollback in case
of errors and on module removal.
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260925144229.3693-5-denis.benato@linux.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
series
Newer ASUS ProArt laptops (e.g. H7606 series) implement dGPU power
control on WMI DEVID 0x00090120 instead of the usual 0x00090020.
The default DEVID returns 0xFFFFFFE2 on these models, so the
dgpu_disable firmware attribute is never created and the dGPU cannot
be re-enabled from Linux at all.
Add a fallback probe for device ID 0x00090120 following the same
approach as the gpu_mux_dev_id probe.
Details for 0x00090120 (confirmed on H7606W using direct WMNB calls
and inspecting the DSDT DEVS handler):
- Reading DSTS returns 0x00010001 when the dGPU is off (CUMA=1),
or 0x00010000 when it's on.
- Writing DEVS: 0 enables the dGPU (calls PG00._ON() + Notifies
PEGP, Device Check), and 1 disables or ejects it.
This behavior matches the dgpu_disable attribute (1 = disabled).
Signed-off-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260925144229.3693-4-denis.benato@linux.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
mini_led_mode, gpu_mux_mode and dgpu_disable are created by ad-hoc
conditional blocks in asus_fw_attr_add() which must be manually tracked
by the error and exit paths; those paths also re-probe WMI to know which
groups were actually created.
Give every attribute group its own .is_visible() callback: all groups
are created unconditionally through the common loop and sysfs hides the
unsupported ones entirely. The plain group macros now gate their
visibility on the WMI presence of their device, the
ASUS_ATTR_GROUP_BOOL() and ASUS_ATTR_GROUP_ENUM() macros declare groups
backed by a device ID resolved at probe time, and the power tunable
macros are additionally gated on the platform limits defining a max
value, replacing the special-casing in asus_fw_attr_add() and with it
is_power_tunable_attr().
The dgpu_disable attribute now goes through the same resolved device ID
scheme as mini_led_mode and gpu_mux_mode, storing the device ID to use
in asus_armoury.dgpu_disable_dev_id instead of always operating on
ASUS_WMI_DEVID_DGPU.
No functional change is intended.
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260925144229.3693-3-denis.benato@linux.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
declarations
Pure code move in preparation for making the power tunable attribute
groups gate their visibility on the platform limits: the visibility
callbacks expanded by the group macros at the attribute declaration
sites will call has_valid_limit(), which therefore needs to be declared
before them.
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260925144229.3693-2-denis.benato@linux.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
tpmi_get_power_domain_mask()
tpmi_init() returns early on CPU models that are not in tpmi_cpu_ids,
before tpmi_power_domain_mask is allocated. When the driver is built
in, the exported tpmi_get_power_domain_mask() remains callable after
the failed init. It returns NULL then only because it indexes the NULL
array at offset 0 for the zeroed per-CPU data. If cpuhp_setup_state()
fails, the error path frees the array but leaves the pointer set, so
the helper would return a pointer into freed memory.
Nothing in the tree calls tpmi_get_power_domain_mask() today, so this
is hardening rather than a fix for a reachable bug. Return NULL when
the array was not allocated, and clear the pointer wherever it is
freed, as the previous patch does for domain_die_map.
Assisted-by: LLM
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://patch.msgid.link/20260924193625.1830526-3-kristen.c.accardi@intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
tpmi_init() returns early with -ENODEV on CPU models that are not in
tpmi_cpu_ids, before domain_die_map is allocated. When the driver is
built in, tpmi_get_linux_die_id() remains callable after the failed
init and dereferences the NULL domain_die_map.
This is reachable from user space: uncore-frequency-tpmi calls
tpmi_get_linux_die_id() from the show function of the world-readable
die_id sysfs attribute. The attribute is created on multi-die packages
for clusters with the core agent type, so reading it on such a CPU
that is missing from tpmi_cpu_ids oopses.
Likewise, if cpuhp_setup_state() fails, the error path frees
domain_die_map but leaves the pointer set, so a later call would read
freed memory.
Return -ENODEV when the map was not allocated, and clear the pointer
wherever it is freed.
tpmi_get_linux_cpu_number(), tpmi_get_punit_core_number() and
tpmi_get_power_domain_id() read only the static per-CPU data and hash
table, so they are safe after a failed init. tpmi_get_power_domain_mask()
has the same problem as this helper but no callers, so it is handled
separately.
Fixes: e37be5d85c60 ("platform/x86/intel: power-domains: Add interface to get Linux die ID")
Assisted-by: LLM
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://patch.msgid.link/20260924193625.1830526-2-kristen.c.accardi@intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Add the EC firmware string '1585EMS1.115' to ALLOWED_FW_10. This
enables battery charge thresholds on the MSI Katana 15 B13VFK
(MS-1585).
The out-of-tree msi-ec driver groups this firmware with 1582EMS1.107
and 1583EMS1.109, which are already in ALLOWED_FW_10. An independent
report for the same model and firmware confirms the same charge
control encoding.
Tested on MSI Katana 15 B13VFK with EC firmware 1585EMS1.115:
writing charge_control_end_threshold updates EC register 0xd7 as
expected (80 -> 0xd0, 100 -> 0xe4). With AC connected and the
battery at 87%, the battery was charging with the threshold at 100;
writing 80 stopped charging ("Not charging"). Charging resumes 10%
below the end threshold, which matches charge_control_start_threshold.
Keyboard backlight (0xd3) and cooler boost (0x98) also match this
configuration.
Link: https://github.com/BeardOverflow/msi-ec/issues/185
Signed-off-by: Patryk Pilichowski <pat.pilichowski@gmail.com>
Link: https://patch.msgid.link/20260925125628.69826-1-pat.pilichowski@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Use __free(kfree) for local pointer allocations in
dispatch_proc_write(), tpacpi_evaluate_bcl(), and auxmac_init().
This ensures automatic memory cleanup when exiting function scope and
removes explicit kfree() calls on exit paths.
Assisted-by: LLM
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Tested-by: Ali Ahmet Memiş <aliamemis@disroot.org>
Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20260929-thinkpad-acpi-cleanup-v2-2-88e176953a4b@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Convert conditional mutex_lock_killable() and mutex_lock_interruptible()
calls to ACQUIRE() and ACQUIRE_ERR() from linux/cleanup.h.
This eliminates explicit mutex_unlock() calls on return paths and
simplifies error handling across hotkey, brightness, volume, fan, and
dytc functions.
Assisted-by: LLM
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Tested-by: Ali Ahmet Memiş <aliamemis@disroot.org>
Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20260929-thinkpad-acpi-cleanup-v2-1-88e176953a4b@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Removed redundant .probe and .remove callbacks from
wmi_driver struct, as they were print-only and unnecessary
Signed-off-by: Arav Verma <svav2021@gmail.com>
Link: https://patch.msgid.link/20260923000002.1799245-2-svav2021@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Modernize firmware_update_request_show by replacing legacy
sprintf() call with sysfs_emit. When altering string,
corrected format specified from %d to %u to match u32 type of
target variable.
Signed-off-by: Arav Verma <svav2021@gmail.com>
Link: https://patch.msgid.link/20260923000002.1799245-1-svav2021@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
There exist two types of events recognized by this driver:
single hotkey events (0x0000) and sequences of hotkey events (0x000F).
Until now both literals are used without a named define, making it
harder to understand their meaning.
Fix this by using named defines for both event types.
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260922193809.4801-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>
|
|
The platform_profile_support variable is assigned during platform
profile setup but is never read anywhere in the driver. Remove it.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Vargas <justinyvar@gmail.com>
Link: https://patch.msgid.link/20260921022001.6020-1-justinyvar@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The platform_profile_support member of struct asus_wmi is assigned
during platform profile setup but is never read anywhere in the driver.
Remove it.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Vargas <justinyvar@gmail.com>
Link: https://patch.msgid.link/20260921021720.5976-3-justinyvar@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The platform_profile_support variable is assigned during platform
profile setup but is never read anywhere in the driver. Remove it.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Vargas <justinyvar@gmail.com>
Link: https://patch.msgid.link/20260921021720.5976-2-justinyvar@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The OneXPlayer 3 is a new Intel device by OneXPlayer. It uses the same
registers as the G1 Intel edition. So, add a quirk for it. Battery
bypass, capacity limits, fan curves, fan tachometer, and turbo button
override were confirmed to work.
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com>
Link: https://patch.msgid.link/20260920190438.3444923-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>
|
|
The OneXPlayer Apex uses E5/E6 for battery bypass / charge limit, making
it the first device to deviate. This was verified by a user on Windows
with BIOS version 2.17 and later by running this kernel patch.
Drop X1_ from the MASK variables as they are common in all devices,
introduce a board enum for Apex, and make it use the new E5/E6 registers
for charge limit / bypass. Apply the same quirks as oxp_fly, since APEX
uses the same registers otherwise.
Fixes: 3385ea97c14d ("platform/x86: oxpec: Add support for OneXPlayer APEX")
Cc: stable@vger.kernel.org
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com>
Link: https://patch.msgid.link/20260920190438.3444923-1-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 AYANEO 2S uses the same EC fan interface as the AYANEO 2 and
additionally supports charge limiting. Add an exact match ahead of the
broader AYANEO 2 match so the charge-control quirk is selected.
Reported-by: Tiago Silva <tiago.paulo@live.com>
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
Link: https://patch.msgid.link/20260920185759.3426627-1-lkml@antheas.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
While the current code works correctly, replace unbounded sprintf()
calls with the safer scnprintf() in new_password_store() to follow secure
coding best practices.
Signed-off-by: Thorsten Blum <blum@kernel.org>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Link: https://patch.msgid.link/20260920103035.281573-2-blum@kernel.org
[ij: snprintf() -> scnprintf()]
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Replace sprintf() with sysfs_emit() in pending_reboot_show().
sysfs_emit() is preferred for formatting sysfs output because it
provides safer bounds checking.
Signed-off-by: Thorsten Blum <blum@kernel.org>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Link: https://patch.msgid.link/20260920103518.281843-2-blum@kernel.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The Acer Nitro ANV15-51 uses the Predator V4 WMI interface for thermal
profile handling, hardware monitoring and fan control, but has no quirk
entry, so none of these features are available.
Add a quirk entry for this model.
Note that this machine does not support the turbo thermal profile:
writing PLATFORM_PROFILE_PERFORMANCE is rejected by the firmware with
-EIO. The four remaining profiles work as expected.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Vargas <justinyvar@gmail.com>
Tested-by: Justin Vargas <justinyvar@gmail.com>
Link: https://patch.msgid.link/20260920053918.1888-1-justinyvar@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Convert open-coded if/else with set_bit/clear_bit to the assign_bit and
change_bit APIs.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Link: https://patch.msgid.link/20260919130829.3041568-1-peng.fan@oss.nxp.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The Nova Lake PCD-S S0ix_LPM telemetry layout changed. The PCD-S telemetry
GUID was changed to reflect the layout change, per the client GUID
revision rule.
nvl_pcds_d3_status_1_map[] was correctly updated, but two companion
constants were never updated to match:
1. NVL_PCDS_NUM_S0IX_BLOCKER (core.h) is 71 instead of the actual
number of blk == 1 entries across nvl_pcds_blk_maps.
2. PCDS_LPM_REQ_GUID (nvl.c) is still 0x01091102. It was never
bumped to 0x01091103 to reflect the S0ix_LPM telemetry metadata
layout change.
Both constants describe the same S0ix_LPM/blocker telemetry region
for PCD-S, so fix them together in one change.
Fixes: 41354f4c8a79 ("platform/x86/intel/pmc: Add Nova Lake support to intel_pmc_core driver")
Signed-off-by: Xi Pardee <xi.pardee@linux.intel.com>
Link: https://patch.msgid.link/20260919051830.565240-1-xi.pardee@linux.intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Add a power limits quirk entry for the ASUS G614FM laptop.
The limits are extracted from the device's ThrottleGear XML
configuration.
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
Link: https://patch.msgid.link/4d561b599712eeb483c2d1f7c042827c6f8c8719.1789794282.git.scardracs@disroot.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
This platform does no longer populate this register.
Fixes: 2726b5758f80a ("platform/x86: amd-pmc: Use correct IP block table for AMD 1Ah M80H SoC")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260918170302.352054-3-mario.limonciello@amd.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
If the scratch register isn't defined for a platform, the debugfs file
will always fail. Only create it when declared.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260918170302.352054-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>
|
|
rfkill ops
With all WMI method evaluations serialized globally by asus_wmi_eval_lock
in asus_wmi_evaluate_method_locked(), the per-device wmi_lock in struct
asus_wmi is completely redundant.
Remove wmi_lock from struct asus_wmi, its initialization in
asus_wmi_rfkill_init(), and its manual locking in asus_rfkill_hotplug().
Consequently, asus_rfkill_wlan_set() becomes a simple pass-through to
asus_rfkill_set(), rendering asus_rfkill_wlan_ops identical to
asus_rfkill_ops. Drop asus_rfkill_wlan_set() and asus_rfkill_wlan_ops,
allocating WLAN rfkill devices with &asus_rfkill_ops directly.
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
Reviewed-by: Denis Benato <denis.benato@linux.dev>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/035f8cc544ebedc31f29bf1918ee54c623147717.1789722252.git.scardracs@disroot.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Concurrent evaluations of ASUS WMI management methods (from ACPI notify,
HID, userspace daemons, and debugfs) enter the BIOS ACPI/SMM interface
simultaneously, triggering re-entrant SMIs or EC mailbox buffer corruption.
Fix this at the root by introducing a centralized evaluation helper
(asus_wmi_evaluate_method_locked()) protected by a global mutex
(asus_wmi_eval_lock) using guard(mutex). Route all evaluations of
ASUS_WMI_MGMT_GUID (method3, method5, method_buf, and show_call) through
this helper.
A static mutex is required because asus_wmi_evaluate_method() is an
exported symbol used by external modules (such as hid-asus and
asus-armoury) that lack access to struct asus_wmi drvdata, and the
underlying ASUS ACPI/EC management method is a single physical platform
resource.
The mutex is non-recursive: nested ACPI/WMI notify handlers must not call
back into evaluate on the same task (defer via workqueue, as
asus_rfkill_notify already does).
The sysfs-versus-notify race predates the later export of
asus_wmi_evaluate_method(), so Fixes points at the original shared
evaluate helper rather than that export.
Link: https://github.com/OpenGamingCollective/asusctl/issues/328
Fixes: d33da3b68669 ("asus-wmi: factorise wmi_evaluate_method call")
Cc: stable@vger.kernel.org
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
Reviewed-by: Denis Benato <denis.benato@linux.dev>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/b6a1981777e63f0c28bd719d8203ebbda57d6957.1789722252.git.scardracs@disroot.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Add the firmware string '16U8EMS2.100' to the ALLOWED_FW_1 array.
This enables Embedded Controller support, including battery charge
thresholds, for the MSI GL65 Leopard 9SCXK (MS-16U8) laptop.
The EC memory layout of this firmware matches the existing config:
the CPU and GPU temperatures at 0x68 and 0x80 agree with coretemp and
the NVIDIA driver, the fan mode at 0xf4 reads 0x0d (auto), and the
charge control register is at 0xef.
Tested on MSI GL65 Leopard 9SCXK with EC firmware 16U8EMS2.100 and
BIOS E16U8IMS.504: with AC connected and the battery at 18%, writing 10
to charge_control_end_threshold stops charging ("Not charging", 0 A),
and writing 100 resumes it.
Assisted-by: LLM
Signed-off-by: Daasaradhi Mannava <daasaradhimannava@gmail.com>
Link: https://patch.msgid.link/20260916174830.11620-1-daasaradhimannava@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The charge thresholds are computed by subtracting a fixed offset from
the raw EC value. When no charge limit has been set, the EC can hold a
value below range_min (0x80 on an MSI GL65 Leopard 9SCXK), and reading
the sysfs attributes returns nonsense:
charge_control_start_threshold: -10
charge_control_end_threshold: 0
Both attributes are documented to be within 0 - 100, and an end
threshold of 0 wrongly suggests that charging is disabled.
The store path already rejects values outside range_min..range_max.
Apply the same range to the show path and report the maximum threshold
for any value outside of it.
Tested on an MSI GL65 Leopard 9SCXK (EC firmware 16U8EMS2.100) with
the EC holding 0x80: the attributes now read 90 and 100.
Fixes: 392cacf2aa10 ("platform/x86: Add new msi-ec driver")
Assisted-by: LLM
Signed-off-by: Daasaradhi Mannava <daasaradhimannava@gmail.com>
Link: https://patch.msgid.link/20260916174812.11496-1-daasaradhimannava@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The procfs entry /proc/acpi/ibm/beep is only created if beep_init()
succeeds, which requires beep_handle to be non-NULL. Remove the
unreachable code branch from beep_read().
Signed-off-by: Thorsten Blum <blum@kernel.org>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Link: https://patch.msgid.link/20260907090103.352995-3-blum@kernel.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
amd_pmf_get_battery_prop()
power_supply_get_by_name() takes a reference that is only dropped on
the error path. On success it leaks, five times per policy evaluation.
Unregistering the battery later trips the use_cnt WARN_ON in
power_supply_unregister() and never frees it.
While here, return -ENODEV instead of an uninitialised 'value' when
no battery matches, and stop at the first supply found rather than
letting the last one in the table win.
Found by reading the code. Fix and changelog drafted with Claude Code
(Fable 5.1) and reviewed by hand. Compile-tested only (allmodconfig,
W=1, sparse); not run on Smart PC hardware.
Fixes: f4627dfd0e19 ("platform/x86/amd/pmf: Add support to get inputs from other subsystems")
Cc: stable@vger.kernel.org
Assisted-by: LLM sparse
Signed-off-by: Jack Boykin <jtboykin.jb@gmail.com>
Link: https://patch.msgid.link/20260902210217.69483-1-jtboykin.jb@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Custom fan curves reach firmware unchecked, so a curve whose temperature
or PWM decreases from one point to the next is accepted. The firmware
does not respect such a curve: a first point of 100% followed by 50%
leaves every point running at 100%. The kernel keeps reporting the
points that were written, so sysfs stops describing what the fans are
actually doing.
Check the curve when enabling and reject it if it is invalid. Validation
is done on enable rather than on write because fan curves are written
one point at a time and are inconsistent mid-write.
Fixes: 0f0ac158d28f ("platform/x86: asus-wmi: Add support for custom fan curves")
Reported-by: Nir Yehoshua <nir@ciphersecuritylabs.com>
Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev>
Link: https://patch.msgid.link/20260831-fan-curve-validation-v2-1-7274ca16c8fe@ghoul.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The return value of toshiba_haps_protection_level() is ignored because
ret is immediately overwritten by the toshiba_haps_reset_protection()
call.
And ret is only used by the check, which has no effect because both
branches return the same value. So remove the check and ret, and
return the value directly.
No functional change.
Found by the Coccinelle script from
scripts/coccinelle/misc/cond_return_no_effect.cocci.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Link: https://patch.msgid.link/20260731150010.1025556-1-ekffu200098@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
hp_wmi_perform_query()
hp_wmi_perform_query() evaluates an ACPI WMI method and expects a
struct bios_return header in the returned buffer. However, it only
checks that the ACPI object type is ACPI_TYPE_BUFFER without verifying
that obj->buffer.length is at least sizeof(*bios_return) (8 bytes).
If the firmware or ACPI method returns a buffer shorter than 8 bytes:
1. bios_return->return_code at offset 4 reads out of bounds from the
allocated ACPI buffer slab.
2. If return_code evaluates to 0 and outsize is non-zero,
(int)(obj->buffer.length - sizeof(*bios_return)) evaluates to a
negative integer (e.g. -8 for a 0-length buffer). actual_outsize is
set to this negative value and passed to memcpy(buffer, ...,
actual_outsize), where the signed negative value is cast to
size_t (e.g. 0xfffffffffffffff8), attempting to copy ~18 Exabytes
and triggering an immediate kernel crash. Additionally,
memset(buffer + actual_outsize, ...) performs an out-of-bounds
write before buffer.
Fix this by ensuring obj->buffer.length is at least sizeof(*bios_return)
before accessing the return code, and compute actual_outsize safely
using min_t(u32, ...), which is sound specifically because the guard
above already rules out obj->buffer.length being smaller than
sizeof(*bios_return) by the time that subtraction runs.
Fixes: c3021ea1beee ("hp-wmi: allow setting input and output buffer sizes separately")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://patch.msgid.link/20260826103012.240453-1-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
hp_populate_string_elements_from_package(),
hp_populate_integer_elements_from_package(),
hp_populate_enumeration_elements_from_package(),
hp_populate_ordered_list_elements_from_package(), and
hp_populate_password_elements_from_package() each parse the same
PATH..SECURITY_LEVEL range into their own struct common_data
sub-object, copy-pasted five times. Factor it into
hp_get_common_data_from_package(), called from all five, mirroring
hp_get_common_data_from_buffer()'s existing split for the buffer
side.
The five PREREQUISITES loops weren't identical: on a bad
prerequisite string, string/integer/ordered_list continue,
enumeration returns -EINVAL, password breaks. The shared helper
continues, matching the majority and
hp_get_common_data_from_buffer()'s own handling of the equivalent
failure. This changes enumeration (no longer aborts the package)
and password (no longer leaves later prerequisites unfilled).
The expected_*_types[eloc] != obj[elem].type check above this
switch has the same split -- enumeration warns and continues, the
rest pr_err() and return -EIO -- left alone here; consolidating it
needs each type's expected_*_types[] table passed into a shared
checker, not just struct common_data.
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://patch.msgid.link/20260905214801.76265-1-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
audit_log_entries_show() checks "count * LOG_ENTRY_SIZE > PAGE_SIZE"
prior to entering the loop. Because "count" is already bounded to fit
within PAGE_SIZE, the inner loop check "(LOG_ENTRY_SIZE * i) > PAGE_SIZE"
can never be reached and is dead code.
Remove the redundant inner bounds check and eliminate the unnecessary
"else" block after "break" to clean up the loop control flow.
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://patch.msgid.link/20260919061108.87240-1-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
hp_calculate_security_buffer() special-cases an empty authentication
string and returns a fixed 4 bytes (sizeof(u16) * 2). But
hp_populate_security_buffer() does not special-case that same input:
for any authentication string that does not start with BEAM_PREFIX,
including the empty string, it always builds "UTF_PREFIX +
authentication" and converts the result to UTF-16, writing a 2-byte
length header plus 2 bytes per character of "<utf-16/>" (9 characters),
20 bytes total, regardless of how long "authentication" itself is.
The caller, hp_set_attribute(), sizes its kmalloc() buffer using
hp_calculate_security_buffer()'s return value, so for an empty
authentication token it allocates 4 bytes for the security area but
hp_populate_security_buffer() then writes 20 bytes into it, causing a
16-byte heap buffer overflow.
The authentication token used here is the current admin/setup
password, which is an empty string by default until one is
configured. Any write to a writable BIOS attribute while no admin
password has been set reaches this path.
Fix by removing the special-case early return for an empty string in
hp_calculate_security_buffer(). The generic calculation that follows
already accounts for the UTF_PREFIX correctly, which naturally yields
the same 20 bytes that hp_populate_security_buffer() writes for an empty
string, avoiding duplicate logic for special cases.
Fixes: b2715aa2e135 ("platform/x86: hp-bioscfg: spmobj-attributes")
Reported-by: Josh Snyder <josh@code406.com>
Closes: https://lore.kernel.org/platform-driver-x86/20260402-hp-bioscfg-overflow-v1-1-6985f8c9e67c@code406.com/
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://patch.msgid.link/20260919060037.84602-1-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Enable EC controlled keyboard backlight across the board for TUXEDO
devices.
This has split up the device descriptors even more, so the "featureset"
naming scheme was dropped in favor of a "generalized board_name" naming
scheme.
Also Stellaris and Polaris Gen3 are now identified by product_sku to split
them up.
Also some TUXEDO devices with lightbar still had the support missing. This
patch completes the list in this point.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260822003012.851574-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>
|
|
The devices with 3 brightness level keyboards send
UNIWILL_OSD_KB_LED_LEVEL0, UNIWILL_OSD_KB_LED_LEVEL2, and
UNIWILL_OSD_KB_LED_LEVEL4 and not UNIWILL_OSD_KB_LED_LEVEL0,
UNIWILL_OSD_KB_LED_LEVEL1, and UNIWILL_OSD_KB_LED_LEVEL2.
This patch maps the events correctly to brightness levels 0, 1, and 2.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260822003012.851574-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>
|
