| 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 HP EliteBook x360 1030 G2 is a 2-in-1 convertible with volume up and
volume down buttons on the side of the chassis. These buttons are reported
through the intel-hid 5 button array, but the array is not enabled by
default on this model, so pressing them produces no input events at all.
Loading the driver with enable_5_button_array=1 makes both buttons work as
KEY_VOLUMEUP and KEY_VOLUMEDOWN. Add the model to button_array_table so the
array is enabled automatically.
Signed-off-by: Mattias Andersson <86.mattias@gmail.com>
Link: https://patch.msgid.link/20261005192915.25392-1-86.mattias@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Use bool for the local is_thinkpad variable because it only stores a
boolean value.
Signed-off-by: Thorsten Blum <blum@kernel.org>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Link: https://patch.msgid.link/20261005163130.20375-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>
|
|
Commit d6479c25ecef ("platform/x86: thinkpad_acpi: Use
input_device_enabled()") changed hotkey_poll_setup() to acquire
tpacpi_inputdev->mutex and call input_device_enabled(tpacpi_inputdev).
However, the input core already holds dev->mutex when invoking a
device's open() and close() callbacks. Because hotkey_inputdev_open()
and hotkey_inputdev_close() call into hotkey_poll_setup(), attempting to
acquire tpacpi_inputdev->mutex again results in an immediate
self-deadlock.
Additionally, locking tpacpi_inputdev->mutex inside hotkey_poll_setup()
while holding hotkey_mutex introduces an ABBA lock ordering inversion
with hotkey_inputdev_open() and hotkey_inputdev_close(), which acquire
hotkey_mutex while holding tpacpi_inputdev->mutex. Finally,
input_inhibit_device() calls dev->close() before setting dev->inhibited,
so input_device_enabled() still returns true inside
hotkey_inputdev_close().
Track whether the input device is active in a driver-local boolean
protected by hotkey_mutex instead of locking tpacpi_inputdev->mutex and
querying input_device_enabled().
Fixes: d6479c25ecef ("platform/x86: thinkpad_acpi: Use input_device_enabled()")
Reported-by: Ali Ahmet Memiş <aliamemis@disroot.org>
Closes: https://lore.kernel.org/all/20260930075829.53484-1-aliamemis@disroot.org/
Reported-by: Qiling Zhu <kmatzkaczor244@gmail.com>
Closes: https://lore.kernel.org/all/asDVVtAXt8YVbZ3C@ThinkPad/
Reported-by: Oleksii Kryvenko <diver.ua@gmail.com>
Closes: https://lore.kernel.org/all/20261010002413.30007-1-krivenko@itstep.org/
Tested-by: Ali Ahmet Memiş <aliamemis@disroot.org>
Assisted-by: LLM
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20261010031827.3306077-1-dmitry.torokhov@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
intel_vsec_walk_header() used to return a bool that was true when devices
were found. It was converted to return 0 on success and a negative errno
on failure, but the boolean test in intel_vsec_get_features() was left
unchanged, so its meaning is now inverted.
A successful walk returns 0 and leaves found set to false, while a failed
walk returns an error that evaluates to true. When no other capabilities
are present, intel_vsec_pci_init() then returns -ENODEV even though the
auxiliary devices were created, and the driver core tears them back down.
This affects platforms that have no DVSEC or VSEC capabilities and
describe their features through device_data instead, which today means
DG1. Test the return value for success explicitly.
Fixes: a6ce8bf3c993 ("platform/x86/intel/vsec: Return real error codes from registration path")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Link: https://patch.msgid.link/20261001220351.1592138-3-david.e.box@linux.intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The ASUS ROG Flow Z13 (GZ302EA/GZ302EAC) wakes up from suspend-to-idle
without any user input. With PM debug messages enabled, each unexpected
wakeup shows the EC raising IRQ1 at the same time as the ACPI SCI:
PM: Triggering wakeup from IRQ 9
PM: Triggering wakeup from IRQ 1
ACPI: EC: Query(0xa3) started
ACPI: PM: Wakeup after ACPI Notify sync
EC query 0xa3 only notifies the battery of a status change, which
happens when it transitions between Charging and Full while on AC.
The ACPI core correctly treats that as a non-wakeup event and cancels
the SCI wakeup, but the IRQ1 wakeup remains pending and resumes the
system. i8042 debugging confirms that the keyboard controller has no
data at that point ("Interrupt 1, without any data").
The detachable keyboard on this device is a USB device, so disabling
the i8042 wakeup source does not result in any functional loss. With
serio0 wakeup disabled, the same battery event is processed during
suspend-to-idle and the system stays asleep.
Add the spurious_8042 quirk for it. The GZ302EAC reports sys_vendor
"ASUS" while the GZ302EA reports "ASUSTeK COMPUTER INC.", so match on
"ASUS" and on the "GZ302EA" board name to cover both models.
Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260929181655.26105-1-matthew.schwartz@linux.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The PM notifier iterates over every uncore frequency instance to restore
user-configured MSR_UNCORE_RATIO_LIMIT values after resume. Entries that
have never been configured legitimately have stored_uncore_data set to
zero.
The refactoring that split common and enumeration code changed the
iteration from active control CPUs to all allocated instances. It also
changed the skip for an invalid or unconfigured entry from continue to
return, causing that entry to terminate the entire restore operation.
On a multi-package or multi-die system, configuring only a later instance
therefore leaves its limit unrestored after suspend, hibernation, or
restore if an earlier entry is invalid or unconfigured.
Use continue to skip only the current entry and restore all remaining
configured instances.
Fixes: dbce412a7733 ("platform/x86/intel-uncore-freq: Split common and enumeration part")
Cc: stable@vger.kernel.org
Tested-by: Yijia Wang <wangyijia.yeah@bytedance.com>
Signed-off-by: Guixiong Wei <weiguixiong@bytedance.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://patch.msgid.link/20260929163133.14326-2-weiguixiong@bytedance.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Add the PCI root complex device ID (0x1b20) for AMD Family 1Ah model DCh
to the PMC driver. This new model shares the same PMC configuration as
the existing Family 1Ah model 80h, so reuse amd_1ah_m80_cpu_info for the
device data.
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260929155317.1710272-1-Shyam-sundar.S-k@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
reuse
The driver stores its state in a single file-scope static struct
amd_pmc_dev, which is reused on every bind. Its regbase, smu_virt_addr,
stb_virt_addr and fch_virt_addr members are MMIO mappings created with
devm_ioremap().
On unbind the driver core unmaps these mappings, but it does not clear
the pointers in the static struct. Since the struct is not freed, the
members keep pointing at the now-unmapped addresses.
On the next bind, the probe path re-maps a region only when its pointer
is still NULL, so the stale pointer is reused and the following
memcpy_fromio()/ioread32() touches freed MMIO, causing use-after-unmap
crash. Clear these pointers in amd_pmc_remove() so the next probe re-maps
them instead of reusing stale ones.
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Fixes: 156ec4731cb22b ("platform/x86: amd-pmc: Add AMD platform support for S2Idle")
Link: https://patch.msgid.link/20260929155609.1712638-1-Shyam-sundar.S-k@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The Thinkpad L14 Gen3 with DMI product name 21C5 is affected by the same
s2idle resume stall as the already listed 21C6 variant: resuming from
s2idle blocks for several seconds before the kernel resumes.
DMI_MATCH() performs substring matching, so a "21C5" entry also covers
SKUs such as 21C5S05800. Add the 21C5 model to the existing
quirk_s2idle_bug table.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222070
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221273
Signed-off-by: Bruno BOI <bruno.boi@bobtopus.eu>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Link: https://patch.msgid.link/20260928160607.679319-1-bruno.boi@bobtopus.eu
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Commit dee82409a883 ("platform/x86: msi-wmi: Reformat
msi_wmi_notify()") turned the condition for reporting a hotkey into
an early return, but only negated the brightness key comparisons,
not the backlight check. As a result, when the driver registers its
own backlight device, all WMI hotkeys are now dropped, instead of all
of them being reported as before.
Restore the original behavior: only drop the brightness keys, and
only when brightness is handled by the ACPI video driver.
This was found by code inspection. It is not tested on hardware that
uses the vendor backlight; on an MSI Katana 15 B13VFK (no vendor
backlight) hotkey handling is unchanged.
Fixes: dee82409a883 ("platform/x86: msi-wmi: Reformat msi_wmi_notify()")
Signed-off-by: Patryk Pilichowski <pat.pilichowski@gmail.com>
Link: https://patch.msgid.link/20260925213333.198058-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>
|
|
amd_hfi_init() manually registers a platform device with
platform_device_register_simple() before registering the driver. This
device has no ACPI companion, so when amd_hfi_probe() runs for it the
acpi_match_device() check fails and probe returns -ENODEV.
The driver already advertises an ACPI match table, so the ACPI subsystem
enumerates the real AMDI0104 device and binds it to the driver. The
manually created device therefore serves no purpose: it never binds and
lingers as an unbound platform device, wasting memory and cluttering the
device tree.
Drop the manual platform_device_register_simple() and the device that
tracked it, and rely solely on ACPI enumeration. The CPU feature gating
in amd_hfi_init() is retained so the driver is only registered on
supported hardware.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://patch.msgid.link/20260921170411.1149960-4-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>
|
|
amd_hfi_fill_metadata() parses CPU core ranking data out of the
firmware-provided PCC shared memory but trusts two values it should not:
- n_bitmaps is used to bound the outer loop that reads the APIC ID
bitmaps from table_data[], but it is never validated against the size
of the shared memory region (pcct_ext->length). A firmware-supplied
count larger than the region reads past the end of table_data.
- When resolving the base of the ranking data for a processor, the
pointer is shifted by an extra "i * nr_class" term, where i is the
current bitmap index. The per-processor offset is already applied
through apic_index, which uses the running count of active processors
(apic_start). The extra shift compounds for every logical processor
beyond the first bitmap (APIC ID >= 32), reading out of bounds.
Both result in out-of-bounds reads that can corrupt the ranking metrics,
oops, or otherwise destabilise the system.
Reject an n_bitmaps value that would not fit within the shared memory
region, and drop the bogus "i * nr_class" term so the ranking data is
addressed only through its correct per-processor offset.
Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: d4e95ea7a78e ("platform/x86: hfi: Parse CPU core ranking data from shared memory")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260921170411.1149960-3-mario.limonciello@amd.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
amd_hfi_probe() registers CPU hotplug callbacks with
cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, ...) and schedules the static
sched_amd_hfi_itmt_work work item, but amd_hfi_remove() tears down
neither. The dynamically assigned hotplug state returned by
cpuhp_setup_state() is discarded, so cpuhp_remove_state() can never be
called, and the pending work is never cancelled.
After the module is unloaded and its memory is freed, any subsequent CPU
hotplug event or execution of the scheduled work dereferences the stale
callback and work function pointers, resulting in a use-after-free and
kernel panic.
Store the hotplug state returned by cpuhp_setup_state() and, on removal,
call cpuhp_remove_state() to unregister the callbacks and
cancel_work_sync() to flush the scheduled work before the module memory
goes away.
Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: bb20421c05fc ("platform/x86: hfi: Add online and offline callback support")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260921170411.1149960-2-mario.limonciello@amd.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
A user has reported that the LAPKC71E variant of the Intel NUC x15
also works with the uniwill-laptop driver. The difference between the
LAPKC71E and the LAPKC71F seems to be the dedicated NVidia GPU module.
Add support for this device as well. It is suspected that the LAPKC71F
also supports the new UNIWILL_FEATURE_NVIDIA_CTGP_CONTROL feature, but
this would need to be verified on real hardware.
Link: https://github.com/Wer-Wolf/uniwill-laptop/issues/17
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20261007144101.323289-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 LED subsystem specifies that LEDs capable of producing arbitrary
colors (like RGB) should label themselfs as "rgb" instead of
"multicolor".
Use the "rgb" label instead of the "multicolor" label to fix
detection by userspace applications.
Reported-by: Werner Sembach <wse@tuxedocomputers.com>
Closes: https://github.com/Wer-Wolf/uniwill-laptop/issues/18
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20261007144101.323289-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>
|
|
Intel NUC 9 Extreme (Queens County) devices have a separate bit
inside the EC_ADDR_LIGHTBAR_AC_CTRL register for enabling the
breathing animation in s2idle mode.
Add support for this additional setting.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20261007144101.323289-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>
|
|
It turns out that some models require the lightbar to be activated
in order to display the rainbow animation, so users have to access
both the "rainbow_animation" sysfs attribute and the LED sysfs
interface when enabling the rainbow animation. This can cause short
glitches when the lightbar was previously disabled.
Fix this by replacing the sysfs attribute with a custom LED trigger
called "uniwill-rainbow". Selecting this trigger will atomically
activate the lightbar and enable the rainbow animation mode. This
can potentially break userspace applications using the old sysfs
attribute, but so far no such application is known to exist (yet).
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20261007144101.323289-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 LED sysfs ABI now allows us to specify the maximum values for the
global brightness and the color intensity values independently. At the
same time the maximum brightness value reported for the lightbar (like
200) does not match the real value supported by the hardware (1),
potentially confusing users.
Report the correct maximum brightness value and only use the intensity
values for controlling the lightbar color.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20261007144101.323289-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>
|
|
The PCSpecialist Recoil 16 AMD / TUXEDO Stellaris 16 Gen7 chassis has an
"Sc" key next to F12, meant to rotate the lay-flat screen by 180 degrees.
It reports WMI event 0xD0, which is currently reported as KEY_UNKNOWN.
Map it to KEY_ROTATE_DISPLAY.
Signed-off-by: Mohamed Jouini <amad3v@gmail.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20261008135624.3520849-3-amad3v@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The PCSpecialist Recoil 16 AMD is a rebadged TUXEDO Stellaris 16 Gen7 AMD
but reports sys_vendor "PCSpecialist" and board name "X6FR57TY", so the
existing entry does not match it. Use the Stellaris 16 Gen7 AMD feature
set.
Signed-off-by: Mohamed Jouini <amad3v@gmail.com>
Link: https://patch.msgid.link/20261008135624.3520849-2-amad3v@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
On HP systems with a large number of BIOS attribute instances, the
kzalloc_objs() allocation in hp_alloc_ordered_list_data() and
hp_alloc_string_data() can fail when physical memory is fragmented,
leaving the driver unable to register those attributes.
The same failure mode was already fixed for enumeration_data in
hp_alloc_enumeration_data() by commit 916727cfdb72 ("platform/x86:
hp-bioscfg: Support allocations of larger data"), reported on HP
Z2 Tower G9 and Z4 G5 Workstation systems:
https://bugs.debian.org/1127612
order-list-attributes.c and string-attributes.c use the identical
allocation pattern and are still affected. Apply the same fix: fall back
to kvzalloc_objs()/kvfree() instead of kzalloc_objs()/kfree(), and
return -EINVAL early when the instance count is zero.
Link: https://bugs.debian.org/1127612
Signed-off-by: Artem Maksimov <okuroshioffc@gmail.com>
Link: https://patch.msgid.link/20260925194454.6850-1-okuroshioffc@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
register_platform_devices() registers the battery, LED, and watchdog
platform devices in sequence. If LED registration fails, the battery
device remains registered. If watchdog registration fails, the LED and
battery devices remain registered.
These failure paths leave successful platform_device_register_data()
calls without the matching platform_device_unregister() calls.
Add an unwind ladder to unregister previously registered platform
devices in reverse order before returning the registration error.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fixes: dd123e62bded ("platform/x86: simatic-ipc: add main driver for Siemens devices")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Link: https://patch.msgid.link/20260924115617.1578309-1-lgs201920130244@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
On certain 2025 Lenovo laptops, such as the Yoga Pro 7 14ASP10 and Legion
Pro 7 16AFR10H, a switch on the side disables the camera. This is handled
by the firmware, which also sends event 0x0d (camera disabled) or 0x0c
(camera enabled) through the WMI event GUID handled with
ideapad_wmi_context_fn_keys. These events are currently reported as
KEY_UNKNOWN.
Other Lenovo laptops expose a similar camera switch through a separate WMI
GUID, which lenovo-wmi-camera reports as SW_CAMERA_LENS_COVER since
commit d98bf6a6ed61 ("platform/x86: lenovo-wmi-camera: Use
SW_CAMERA_LENS_COVER instead of KEY_CAMERA_ACESS"). That driver does not
bind on these laptops, so map the WMI events to SW_CAMERA_LENS_COVER as
well via sparse keymap KE_SW.
Unfortunately, there is no programmatic way to determine the current
state on the mentioned devices until the next relevant WMI key event.
Therefore, no switch event is emitted on probe or resume, intentionally
leaving the default (0, i.e., no covered) or the last state unchanged,
and let the first relevant WMI key event to correct it. This should
fulfill the requirement of using the switch events to show an OSD.
AFAIK, no userspace software queries its state via EVIOCGBIT(EV_SW).
The above behavior is basically the same as lenovo-wmi-camera, except
that SW_CAMERA_LENS_COVER is always exposed even on devices with no
camera switch. It's because, again, there is no programmatic way to
determine the switch's existence on the mentioned devices. Doing so
should be harmless as long as no switch event is emitted and eliminates
the need to dynamically register an additional input device at run time
like lenovo-wmi-camera does. Even if a userspace program does query the
switch's state via EVIOCGBIT(EV_SW), the returned state will always be 0
(not covered), which is the correct state on unsupported devices.
Co-developed-by: Marco Giunta <marco_giunta@outlook.it>
Signed-off-by: Marco Giunta <marco_giunta@outlook.it>
Tested-by: Marco Giunta <marco_giunta@outlook.it>
Signed-off-by: Rong Zhang <i@rong.moe>
Reviewed-by: Huang Wei <huangwei@kylinos.cn>
Link: https://patch.msgid.link/20260924-ideapad-laptop-camera-sw-v3-1-922ea6a9fff4@rong.moe
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
telemetry_def_get_trace_verbosity() returns success without initializing
the output verbosity value.
The default telemetry operations are installed when the core driver is
initialized and again by telemetry_clear_pltdata() when the platform
driver is removed. The telemetry debugfs files can remain available after
the platform driver removal.
A subsequent read of pss_trace_verbosity or ioss_trace_verbosity calls
telemetry_get_trace_verbosity(), which may use the default callback and
return success without setting verbosity. The uninitialized value is then
passed to seq_printf().
Validate the output pointer and initialize the default verbosity to zero
so callers never use an uninitialized value after a successful call.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 378f956e3f93 ("platform/x86: Add Intel Telemetry Core Driver")
Signed-off-by: Aleksandrova Alyona <aga@itb.spb.ru>
Link: https://patch.msgid.link/20260917110812.2831-1-aga@itb.spb.ru
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
There are several simple and dumb wrappers of
ap{mf,ts}_if_call_store_buffer() defined as global symbols, which are
heavily used by multiple layers and become symbols against linkage. This
bloats the size of the module.
Since is_apmf_func_supported() has been converted, convert the mentioned
wrappers into static inline functions to get rid of the overhead of
function outlining and linkage, and shrink the module
(!CONFIG_AMD_PMF_DEBUG && CONFIG_AMD_PMF_UTIL_SUPPORT) size by 515 Bytes
(GCC 16 -O2):
text data bss total filename (before)
26261 31264 2768 60293 amd-pmf.ko
text data bss total filename (after)
26046 30964 2768 59778 amd-pmf.ko
Signed-off-by: Rong Zhang <i@rong.moe>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260901-amd-pmf-fix-outlining-v1-5-b54ff94d3d45@rong.moe
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The Smart PC TA interfaces have a simple and dumb helper function
defined as a global symbol, which is used by other layers and becomes a
symbol against linkage. This bloats the size of the module.
Convert it into a static inline function to get rid of the overhead of
function outlining and linkage, and shrink the module
(!CONFIG_AMD_PMF_DEBUG && CONFIG_AMD_PMF_UTIL_SUPPORT) size by 208 Bytes
(GCC 16 -O2):
text data bss total filename (before)
26341 31392 2768 60501 amd-pmf.ko
text data bss total filename (after)
26261 31264 2768 60293 amd-pmf.ko
Signed-off-by: Rong Zhang <i@rong.moe>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260901-amd-pmf-fix-outlining-v1-4-b54ff94d3d45@rong.moe
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The SPS Layer has a simple and dumb helper function defined as a global
symbol, which is heavily used by other layers and becomes a symbol
against linkage. This bloats the size of the module.
Convert it into a static inline function to get rid of the overhead of
function outlining and linkage, and shrink the module
(!CONFIG_AMD_PMF_DEBUG && CONFIG_AMD_PMF_UTIL_SUPPORT) size by 252 Bytes
(GCC 16 -O2):
text data bss total filename (before)
26533 31452 2768 60753 amd-pmf.ko
text data bss total filename (after)
26341 31392 2768 60501 amd-pmf.ko
There are also two duplicated prototypes, so remove one of them as well.
Signed-off-by: Rong Zhang <i@rong.moe>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260901-amd-pmf-fix-outlining-v1-3-b54ff94d3d45@rong.moe
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The Core Layer has simple and dumb helper functions defined as global
symbols, which are heavily used by other layers and become symbols
against linkage. This bloats the size of the module.
Convert them into static inline functions to get rid of the overhead of
function outlining and linkage, and shrink the module
(!CONFIG_AMD_PMF_DEBUG && CONFIG_AMD_PMF_UTIL_SUPPORT) size by 432 Bytes
(GCC 16 -O2):
text data bss total filename (before)
26781 31636 2768 61185 amd-pmf.ko
text data bss total filename (after)
26533 31452 2768 60753 amd-pmf.ko
Signed-off-by: Rong Zhang <i@rong.moe>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260901-amd-pmf-fix-outlining-v1-2-b54ff94d3d45@rong.moe
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
A !CONFIG_AMD_PMF_DEBUG build compiles amd_pmf_dump_ta_inputs() as a
stub. However, the stub is implemented as a global function and becomes
a symbol against linkage. This bloats the size of the module.
As a best practice, convert the stub into a static inline function to
get rid of the overhead of function outlining and linkage, and shrink
the module (!CONFIG_AMD_PMF_DEBUG && CONFIG_AMD_PMF_UTIL_SUPPORT) size
by 65 Bytes (GCC 16 -O2):
text data bss total filename (before)
26810 31672 2768 61250 amd-pmf.ko
text data bss total filename (after)
26781 31636 2768 61185 amd-pmf.ko
Signed-off-by: Rong Zhang <i@rong.moe>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260901-amd-pmf-fix-outlining-v1-1-b54ff94d3d45@rong.moe
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
|
|
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>
|
