| 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/mst/vhost.git
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
|
|
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
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
|
|
|
|
Move the firmware attributes class helper from drivers/platform/x86 to
drivers/firmware and expose its class declaration through a public Linux
header.
The helper is not x86-specific. Keeping it in drivers/firmware lets
coreboot firmware drivers use the standard firmware-attributes ABI without
living under platform/x86.
Replace the affected drivers' relative helper includes directly with the
new public header.
Suggested-by: Derek J. Clark <derekjohn.clark@gmail.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com>
Tested-by: Oliver Lin <oliver@liuxiaozhen.dev>
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/5682c2228fa4a784d3953664b56a06e0dd9ccdef.1788284852.git.sean@starlabs.systems
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Instantiate both CS35L41 amplifiers of the CLSA0102 node found on the
Lenovo Yoga Slim 7 Carbon 14ACN6 (82L0), the same way as for CLSA0100
and CLSA0101.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215632
Assisted-by: Claude Opus 5
Signed-off-by: Ilya Pavlukhin <i.pavluhin@ya.ru>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260920092808.17234-3-i.pavluhin@ya.ru
|
|
|
|
A callback indicates that the parent driver is responsible for accessing
the data area. Creating a PMT memory remap is redundant.
If a read_telem callback has been provided, do not create a remap.
Enforce API usage where necessary.
Clean up open coded resource usage.
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Link: https://patch.msgid.link/20260923181115.2514193-27-michael.j.ruhl@intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Some HW does not have direct MMIO access to PMT control and data
features.
Augment the current callback infrastructure (data access) to allow
a registered driver to customize read/write access to the control
paths for PMT usage.
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Link: https://patch.msgid.link/20260923181115.2514193-26-michael.j.ruhl@intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Upcoming changes will include possible failures from HW accesses.
Refactor pmt_crashlog_rc() with a return value.
Update all necessary usage to use the return code.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Link: https://patch.msgid.link/20260923181115.2514193-25-michael.j.ruhl@intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Upcoming changes will include possible failures from HW accesses.
Refactor pmt_crashlog_rwm() with a return value.
Update all necessary usage to use the return code.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Link: https://patch.msgid.link/20260923181115.2514193-24-michael.j.ruhl@intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The update that moved struct pci_dev usage to struct device is
incomplete. Only telemetry endpoints are covered.
Other PMT features (crashlog) are now blocked from using the callback
mechanism.
Change struct intel_pmt_entry pci_dev member to device.
Update callback usage to use the intel_pmt_entry rather than the
telemetry endpoint.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Fixes: 353042d54d82 ("platform/x86/intel/vsec: Switch exported helpers from pci_dev to device")
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Link: https://patch.msgid.link/20260923181115.2514193-23-michael.j.ruhl@intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
With the introduction of the .read_telem() callback, control
for access to a devices data area must be done by the callback
owner.
This means that an area cannot be mmap-ed with the default PMT
handler.
If the .read_telem() callback is present, do not support mmap.
Fixes: 045a513040cc ("platform/x86/intel/pmt: Use PMT callbacks")
Cc: stable@vger.kernel.org
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Link: https://patch.msgid.link/20260910135954.1586360-2-michael.j.ruhl@intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Replace acpi_get_first_physical_node() that is slated for removal
with acpi_bus_get_primary_device() that takes a reference to the
device it is about to return.
This addresses a potential use-after-free that may occur if the
device returned by acpi_get_first_physical_node() is removed right
after dropping its ACPI companion's physical_node_lock in that
function.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Link: https://patch.msgid.link/3912360.MHq7AAxBmi@rafael.j.wysocki
|
|
Replace acpi_get_first_physical_node() that is slated for removal
with acpi_bus_get_primary_device() that takes a reference to the
device it is about to return.
This addresses a potential use-after-free that may occur if the
device returned by acpi_get_first_physical_node() is removed right
after dropping its ACPI companion's physical_node_lock in that
function.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Link: https://patch.msgid.link/2720286.Lt9SDvczpP@rafael.j.wysocki
|
|
Replace acpi_get_first_physical_node() that is slated for removal
with acpi_bus_get_primary_device() that takes a reference to the
device it is about to return.
This addresses a potential use-after-free that may occur if the
device returned by acpi_get_first_physical_node() is removed right
after dropping its ACPI companion's physical_node_lock in that
function.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Link: https://patch.msgid.link/1973238.CQOukoFCf9@rafael.j.wysocki
|
|
support for Surface Pro 11
The EC on the Surface Pro 11 exposes the performance profile and fan
interfaces. Enable their associated drivers.
Signed-off-by: Dale Whinham <daleyo@gmail.com>
Link: https://patch.msgid.link/20260918-surface-pro-11-aggregator-registry-fixes-v2-3-c4ed9335814a@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Pro 11
Replace ssam_node_kip_tablet_switch with ssam_node_pos_tablet_switch, as
Surface Pro 11 reports tablet-mode via the POS ('posture') subsystem and
not the KIP subsystem.
The KIP-based driver would remain stuck in a 'folded-back' state after
suspend/resume, whereas the POS-based device reports its state correctly
even after suspend/resume.
This fixes the type cover keyboard/mouse being ignored by desktop
environments after resume from sleep due to the erroneous 'folded-back'
state.
Fixes: c4a069095395 ("platform/surface: aggregator_registry: Add Surface Pro 11 (QCOM)")
Signed-off-by: Dale Whinham <daleyo@gmail.com>
Link: https://patch.msgid.link/20260918-surface-pro-11-aggregator-registry-fixes-v2-2-c4ed9335814a@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Remove ssam_node_hid_sam_sensors as this device is not present on
Surface Pro 11. This fixes a probe failure in dmesg:
surface_hid 01:15:01:06:00: unexpected descriptor length: got 0, expected 9
surface_hid 01:15:01:06:00: probe with driver surface_hid failed with error -71
Fixes: c4a069095395 ("platform/surface: aggregator_registry: Add Surface Pro 11 (QCOM)")
Signed-off-by: Dale Whinham <daleyo@gmail.com>
Link: https://patch.msgid.link/20260918-surface-pro-11-aggregator-registry-fixes-v2-1-c4ed9335814a@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 Transcend 14-fb1xxx (DMI board name "8E41") is recognized
as an Omen board by omen_thermal_profile_boards[] (so platform_profile
switching works via the generic path), but it has no entry in
hp_wmi_feature_boards[]. As a result active_board_params stays NULL
for this board, is_victus_s_board is never set, and none of the
board-specific paths that depend on a real ModelCapabilities entry
(EC thermal-profile readback, the Victus-S GPU CTGP/PPAB WMI calls,
the AC/battery power-source re-apply handler) ever run for it.
Confirmed by direct EC readback (CONFIG_ACPI_EC_DEBUGFS, reading
/sys/kernel/debug/ec/ec0/io) while cycling /sys/firmware/acpi/
platform_profile through performance/balanced/cool:
profile offset 0x95
performance 0x31
balanced 0x30
cool 0x50
These values are an exact match for hp_thermal_profile_omen_v1's
HP_OMEN_V1_THERMAL_PROFILE_PERFORMANCE (0x31), _DEFAULT (0x30) and
_COOL (0x50), read back at exactly HP_OMEN_EC_THERMAL_PROFILE_OFFSET
(0x95) -- the ec_tp_offset already used by omen_v1_legacy_board_params,
and identical to sibling boards already in the table (8902, 8A44,
8A4D, 8D26, 8E35). Two other candidate offsets from the same struct
(0x59, 0x62) were also probed and did not change with the profile;
0x63 changed by +/-1 opportunistically across reads and looks like
the unrelated timer byte, not a profile encoding.
System tested on:
DMI board_name: 8E41
DMI product_name: OMEN Transcend Gaming Laptop 14-fb1xxx
BIOS version: F.05
Kernel: 7.1.9-arch1-2
Signed-off-by: BurningHoryd <sjunhyuk1@gmail.com>
Link: https://patch.msgid.link/20260917011909.75399-1-sjunhyuk1@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Nothing reads asus->driver->screenpad_brightness anymore: the last
reader went away when the screenpad update path stopped relying on a
driver-side copy of the brightness, leaving only the write in
asus_screenpad_init(). ASUS_SCREENPAD_BRIGHT_DEFAULT became unused in
the same rework.
Drop the field from struct asus_wmi_driver, the write and the unused
define. Nothing in the current code depends on remembering the last
brightness while the panel is off; should a model turn up that needs
it (the original screenpad implementation did, and older DUO models
may behave differently from the hardware tested so far), the field can
be reintroduced then.
Assisted-by: zcode:glm-5.3-flash
Signed-off-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260916143838.170950-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>
|
|
The screenpad backlight sets BL_CORE_SUSPENDRESUME, so the backlight
core calls update_status() on suspend, resume and fb blanking with
BL_CORE_SUSPENDED or BL_CORE_FBBLANK set in bd->props.state while
bd->props.power keeps its value: the switch on bd->props.power alone
ignored those flags, repowering the panel at suspend entry instead of
turning it off, and ignoring fb blank requests.
Replace the switch with backlight_is_blank(), which accounts for both
bd->props.power and bd->props.state: the panel is powered off whenever
the backlight is blank and powered on with backlight_get_brightness()
otherwise. Writing a power state other than BACKLIGHT_POWER_ON or
BACKLIGHT_POWER_OFF to bl_power now blanks the panel following the
core convention instead of warning and failing with -EINVAL.
The visible change is that the panel now actually powers off on
suspend and fb blank, and is restored on unblank and resume.
Suggested-by: Hugo Baigue <hugobaigue2004@gmail.com>
Closes: https://lore.kernel.org/all/CAO84+xJ9aW3pj3x8e9b5biWtnNd4EyH7A4Uy7aqBR4qZMDcVvg@mail.gmail.com/
Assisted-by: zcode:glm-5.3-flash
Signed-off-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260916143838.170950-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>
|
|
On some models, e.g. the UX5400EA, the screenpad power state cannot be
read back: DSTS(ASUS_WMI_DEVID_SCREENPAD_POWER) never sets
ASUS_WMI_DSTS_STATUS_BIT, so asus_wmi_get_devstate_simple() reports the
panel as powered off regardless of its real state.
The DSDT shows DSTS 0x00050031 (POWER) and DSTS 0x00050032 (LIGHT)
both read the same two-byte EC register, each returning a different
byte: byte 0 is a raw EC status byte, which is 0xa0 when the panel is
powered and 0x00 when it is off, and byte 1 is the brightness. Read
the power state from the low byte instead of
ASUS_WMI_DSTS_STATUS_BIT: firmware reporting the power through the
status bit is covered too, since ASUS_WMI_DSTS_STATUS_BIT lies inside
ASUS_WMI_DSTS_BRIGHTNESS_MASK.
Reuse read_screenpad_backlight_power() in asus_screenpad_init() in
place of the raw devstate read. This makes the brightness read
reachable on models like the UX5400EA, so mask the SCREENPAD_LIGHT
value with ASUS_WMI_DSTS_BRIGHTNESS_MASK before storing it: the
unmasked devstate (0x0001ffa0 when the panel is on) would otherwise be
exposed to userspace as an out-of-range brightness (max_brightness is
255) which systemd-backlight then persists.
While at it, pass asus_wmi_get_devstate() the u32 it expects.
Fixes: 130d29c5627c ("platform/x86: asus-wmi: adjust screenpad power/brightness handling")
Reported-by: Hugo Baigue <hugobaigue2004@gmail.com>
Closes: https://lore.kernel.org/all/CAO84+x+P2_xyHP89+nGVSMV6bL+dy0P9=vyEEfZGnFhv0hBNWw@mail.gmail.com/
Suggested-by: Hugo Baigue <hugobaigue2004@gmail.com>
Tested-by: Hugo Baigue <hugobaigue2004@gmail.com>
Cc: stable@vger.kernel.org
Assisted-by: zcode:glm-5.3-flash
Signed-off-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260916143838.170950-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>
|
|
The bd->props.power is checked in parts of the driver correctly
comparing with BACKLIGHT_POWER_ON, while in others with a raw usage
of bd->props.power and !bd->props.power, moreover in certain checks
the logic has been inverted due to BACKLIGHT_POWER_ON being defined
as 0: fix both the wrong usage and the inconsistencies by using
proper comparisons.
Fixes: 130d29c5627c ("platform/x86: asus-wmi: adjust screenpad power/brightness handling")
Closes: https://lore.kernel.org/all/178362762638.911488.8564892548331679884@eldamar.lan/
Closes: https://lore.kernel.org/all/ea9c63d1-4776-49d5-9dc4-6c09498f99c9@linux.dev/
Tested-by: Hugo Baigue <hugobaigue2004@gmail.com>
Tested-by: Ponali <ponali2k@gmail.com>
Cc: stable@vger.kernel.org
Assisted-by: zcode:glm-5.3-flash
Signed-off-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260916143838.170950-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>
|
|
On certain 2025 Lenovo laptops, such as the Yoga Pro 7 14ASP10 and Legion
Pro 7 16AFR10H, the F11 key includes a symbol showing a laptop, a tablet
and a smartphone. According to the user manual, the key starts the Lenovo
Smart Connect app, which connects the laptop to phones and tablets.
These laptops send WMI hotkey event 0x48 (scancode 0x148) when the key
is pressed, which is currently reported as KEY_UNKNOWN. Map it to
KEY_LINK_PHONE as the closest match, as thinkpad_acpi does for the
Microsoft Phone Link and Intel Unison keys, see
commit 7ba618e893a4 ("platform/x86: thinkpad_acpi: Add support for new
phone link hotkey") and commit b511bbfe4242 ("platform/x86: thinkpad_acpi:
handle HKEY 0x1402 event").
Signed-off-by: Marco Giunta <marco_giunta@outlook.it>
Link: https://patch.msgid.link/SN6PR19MB2303EBD5288E51BA50D904EFFCB92@SN6PR19MB2303.namprd19.prod.outlook.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Build testing with -Wpadded shows a structure that is incompatible
between 32-bit and 64-bit x86 userspace:
./usr/include/linux/amd-pmf.h:202:1: error: padding struct size to alignment boundary with 4 bytes [-Werror=padded]
Use the 64-bit padded on all architectures here to avoid both
the warning and allow compat ioctl handling.
Fixes: 98432eec3180 ("platform/x86/amd/pmf: Add util layer and userspace character device interface")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20260915202535.3689880-1-arnd@kernel.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Add support for WMI device 0x0004001c and register it as the
platform::mute LED using the audio-mute trigger.
The device ID is present in the PM3406CKA DSDT and is also used
by GHelper for controlling the same LED.
Tested on ASUS ExpertBook PM3406CKA.
Signed-off-by: Patryk Dańków <patryk.dankow@protonmail.com>
Reviewed-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260915174110.67871-2-patryk.dankow@protonmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The L440 (BIOS J4ET93WW) reports its fan as stopped: /proc/acpi/ibm/fan
shows "status: disabled" and "speed: 0", and hwmon fan1_input is 0 under
any load. EC registers 0x2F and 0x84/0x85 always read 0 on this model.
The EC uses the 0x93/0x95 layout handled by TPACPI_FAN_NS. 0x93 reads 4
(FAN_NS_CTRL_STATUS) and 0x95 goes from 255 at idle to about 111 at full
speed. The DSDT has no fan methods.
Add the J4 BIOS family to fan_quirk_table. The fan then reads about
1900 RPM at idle and 2900 RPM under load. The L540 shares the J4 BIOS
and the same EC firmware, so it is covered by the same entry.
Tested on a ThinkPad L440 20ASS20200 with BIOS J4ET93WW and EC J4HT30WW.
Link: https://github.com/lm-sensors/lm-sensors/issues/510
Signed-off-by: Daniel Salmun <salmundani@gmail.com>
Link: https://patch.msgid.link/20260915021154.23252-1-salmundani@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The metrics table doesn't increment for all cases that can cause an
intermediate wakeup if the cycle is very fast. This can make the intent
from commit 9f5595d5f03fd ("platform/x86/amd: pmc: Require at least 2.5
seconds between HW sleep cycles") not work properly.
That commit originally was measured to work properly, but it was
accidental due to a logic error. The logic error was fixed in
commit 4dbd11796f3a8 ("platform/x86/amd: pmc: Clear metrics table at
start of cycle") but this now masked the table doesn't always update.
Since that code was introduced, Daniel Gibson added a number of changes
to the logic which includes a state variable introduced in
commit 037f0b03c663a ("platform/x86/amd/pmc: Don't log during
intermediate wakeups").
Utilize that state variable to instead decide if a single sequence has
started.
Cc: Daniel Gibson <daniel@gibson.sh>
Cc: stable@vger.kernel.org # 7.1.y: 037f0b03c663a platform/x86/amd/pmc: Don't log during intermediate wakeups
Cc: stable@vger.kernel.org # 6.18.y: 037f0b03c663a platform/x86/amd/pmc: Don't log during intermediate wakeups
Fixes: 4dbd11796f3a8 ("platform/x86/amd: pmc: Clear metrics table at start of cycle")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Tested-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
Link: https://patch.msgid.link/20260914141734.2703545-1-mario.limonciello@amd.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
On the HP Laptop 15-fd1xxx (motherboard ID 8DE1), hp-wmi currently falls
back to the legacy HPWMI_FAN_SPEED_GET_QUERY (0x11) command because the
board is not listed in hp_wmi_feature_boards[].
In HP BIOS DSDT table (e.g. BIOS F.26), method GM11 (query 0x11) is a
dummy stub that returns 4 bytes of 0x00 with return code 0 (success),
causing the driver to report 0 RPM via hwmon even while the fan is
actively spinning.
However, the DSDT implements method GM2D (query 0x2D / Victus S fan
interface), which reads the active fan tachometer directly from the
Embedded Controller (EC0) registers RPM1/RPM2 and reports accurate fan
speed.
Add board ID "8DE1" to hp_wmi_feature_boards[] mapped to
victus_s_board_params so hp-wmi uses the working query 0x2D interface.
Signed-off-by: Walid Elonok <walidelonk@gmail.com>
Link: https://patch.msgid.link/20260913054645.58692-1-walidelonk@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Add power limit data for the ASUS ROG Zephyrus Duo GX651AR.
The GX651AR uses the following limits:
- CPU PL1: 30-75 W
- CPU PL2: 38-80 W
- NVIDIA Dynamic Boost: 5-25 W
- NVIDIA TGP: 80-115 W
- NVIDIA temperature target: 75-87 C
The same CPU limits and temperature target are available on DC power.
Signed-off-by: Cymirk <Cymirk@icloud.com>
Signed-off-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260910205032.153165-1-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>
|
|
Remove the local str_supported() function and use the common
str_supported_unsupported() helper.
Debug messages now use "unsupported" instead of "not supported".
Signed-off-by: Thorsten Blum <blum@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20260907084319.351688-6-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 HP Laptop 14-fq1xxx (board 887C, BIOS F.38) takes about 10.2
seconds in noirq device resume from s2idle. Its firmware uses the NVMe
SMI path already handled by amd_pmc_skip_nvme_smi_handler().
Add the system to fwbug_list with the combined Cezanne quirk so the
existing spurious 8042 workaround remains enabled. This reduced noirq
device resume from 10195/10242 ms to 27 ms in testing.
Signed-off-by: Murat Bayraktar <bob65536@proton.me>
Link: https://patch.msgid.link/20260906-hp-887c-s2idle-quirk-v1-1-e470e36fb01d@proton.me
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Thanks for the information, I've currently added 8C58 to hp_wmi_feature_boards[]
and removed it from omen_thermal_profile_boards[] as suggested. Manual PWM fan control
is confirmed to be working but the GPU is still missing that additional +15w from 'Smart Performance Gain'.
That will require further investigation.
Add the HP Omen Transcend 14 board name 8C58 to the hp_wmi feature
board table using the existing omen_v1_legacy_board_params.
Remove 8C58 from the omen thermal profile board list so that the
board uses the appropriate feature-board handling.
Link: https://patch.msgid.link/20260906130114.139261-1-shaunvarghese43@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The driver evaluates the PALC0001 _DSM with revision 1 only. Extend it
to also support firmware implementing revision 0, as found on Slate PTL
CS 14, Yukon PTL CSLW 14 and Yukon PTL 360 14.
The supported revision is detected once during probe. Revision 1 is
checked first so that existing systems keep their current behaviour, and
the accepted revision is then used for evaluating the reset _DSM.
Signed-off-by: Jack Wu <jackbb_wu@compal.com>
Link: https://patch.msgid.link/20260904-dw5826e-acpi-reset-add-revision-v1-1-1be7153c3453@compal.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The static slider APTS state index is supplied by the BIOS as an 8-bit
value, but apts_config_store contains only APTS_MAX_STATES entries. An
invalid firmware value can therefore cause amd_pmf_update_slider_v2() to
read beyond the end of the array.
Validate the selected index before applying the slider values and return
an error when it is out of range.
Fixes: 8362e862fb87 ("platform/x86/amd/pmf: Update sps power thermals according to the platform-profiles")
Cc: stable@vger.kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260903182927.3556274-1-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>
|
|
The HP Omen 16-am0xxx (board ID: 8D3F) has the same WMI interface as
other Victus S boards, but requires quirks for correctly switching
thermal profile.
Add the DMI board name to hp_wmi_feature_boards[] table and
map it to omen_v1_legacy_board_params.
Testing on board 8D3F confirmed that platform profile is registered
successfully and fan RPMs are readable and controllable.
Tested-by: Jan Ziobro <ziobrojan79@gmail.com>
Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com>
Link: https://patch.msgid.link/20260829071843.62902-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>
|
|
Add the Alienware Area-51 (2025 desktop, model AAT2250) to the AWCC DMI
table. G-Mode is not applicable to this desktop, so generic_quirks is
used. The full product name is matched to avoid colliding with the
"Alienware Area-51m" and "Alienware 16/18 Area-51" laptop entries.
Tested on hardware with BIOS 1.6.0: loading with
force_platform_profile=1 force_hwmon=1 exposes a working platform
profile (quiet/balanced/balanced-performance/custom) and a fully
functional hwmon interface (6 fans - CPU, 3 top, 2 front - with fan
boost control and temperature sensors).
Signed-off-by: Rickey Bartlett <subtexel@gmail.com>
Reviewed-by: Kurt Borja <kuurtb@gmail.com>
Link: https://patch.msgid.link/20260828145756.341733-1-subtexel@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 Slim 16t-an000 (board ID: 8D40) uses the existing OMEN v1
WMI interface but does not use the standard EC thermal profile
parameters.
Furthermore, it is the closest sibling of board 8D41 and 8D42, which
are already included in the table with omen_v1_no_ec_board_params.
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 8D40, including
platform profile and fan control support.
(Tested-by tag not included due to invalid email address, see the
github link below.)
Link: https://github.com/CachyOS/kernel-patches/issues/157
Signed-off-by: Suryansh Singh <technosfan14@gmail.com>
Link: https://patch.msgid.link/20260827152226.35186-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>
|
|
The AMDI0112 ID is used to bind the PMF driver to some platforms.
It doesn't have any Linux side code changes relative to the most
similar AMDI0105.
Cc: stable@vger.kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260826163611.2268377-1-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>
|
|
quirk tables
The Lenovo ThinkPad X9-14 Gen 1 uses a non-standard Embedded Controller
firmware (ECFW) whose thermal and fan registers are not located at the
classic addresses. On this model the thermal registers sit at 0xA8-0xAF /
0xB8-0xBF and the fan registers use the non-standard offsets, instead of
the legacy 0x78-0x7F / 0xC0-0xC7 (thermal) and 0x2f / 0x84 (fan).
Because the model is not covered by the existing quirk tables, the driver
probes the legacy thermal addresses during init, reads back 0x00 from
every register, concludes the EC is "misbehaving" and disables all
thermal sensor access:
thinkpad_acpi: ThinkPad ACPI EC access misbehaving, disabling thermal
sensors access
Fan access is affected the same way, leaving fan1/fan2 reporting 0 RPM.
The infrastructure for these non-standard ECFW models is already in place
(commit 301c1904d638 ("platform/x86: thinkpad_acpi: Fix to correct wrong
temp reporting on some ThinkPads")); the X9-14 Gen 1 simply was not added
to the model lists yet. Add its BIOS model code N4D to both the thermal
and fan quirk tables so that:
- thermal_read_mode_check() selects TPACPI_THERMAL_TPEC_12 and reads
the 0xA8/0xB8 registers, and
- fan_init() selects the non-standard fan register addresses.
Reported-by: thisisamirv <thisisamirv@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221228
Signed-off-by: Huang Wei <huangwei@kylinos.cn>
Link: https://patch.msgid.link/20260918161539.2676619-1-huangwei@kylinos.cn
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
On the T14s, the EC already steps the keyboard backlight when you press
Fn+Space: off, then low, then high.
We report that change with t14s_kbd_bl_update() (brightness_hw_changed).
We then also send KEY_KBDILLUMTOGGLE.
The extra key is the problem. Desktops treat it as "please toggle the
light." GNOME calls Keyboard.Toggle() and changes the LED itself. That
fights the EC's three steps. The on-screen bar also stays empty,
because Toggle() always returns 0%.
thinkpad_acpi on x86 already skips the key when the firmware changed
the light. It only uses brightness_hw_changed. Do the same here: keep
the LED update, do not send KEY_KBDILLUMTOGGLE.
Tested on a Lenovo ThinkPad T14s Gen 6 (21N1, Snapdragon X Elite) with
GNOME. After this change the OSD bar tracks off / 50% / 100%.
Signed-off-by: David Stephenson <git@davidstephenson.net>
Reviewed-by: Sebastian Reichel <sre@kernel.org>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Link: https://patch.msgid.link/20260825193556.133277-1-git@davidstephenson.net
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
fan_curve_get_factory_default()
When firmware does not support the fan curve WMI method,
asus_wmi_evaluate_method_buf() returns -ENODEV. Callers treat this
as non-fatal, but the pr_warn() here still fires, producing
spurious boot noise on unsupported hardware. Downgrade the message
to pr_debug().
Link: https://patch.msgid.link/20260825-fan-curve-v3-1-617f8e661e9c@proton.me
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-ah0xxx (board ID: 8D42) uses the existing
OMEN v1 WMI interface but does not use the standard EC thermal
profile parameters.
Furthermore, it is the closest sibling of board 8D41, which is
already included in the table with omen_v1_no_ec_board_params.
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 8D42,
including platform profile and fan control support.
Link: https://github.com/yunusemreyl/OmenCtl/issues/93
Signed-off-by: Suryansh Singh <technosfan14@gmail.com>
Link: https://patch.msgid.link/20260823080946.103082-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>
|
|
The HP OMEN 17-ck1000nw (board ID: 8A18) supports the existing
OMEN thermal profile handling.
Add the DMI board name to omen_thermal_profile_boards[] so that
the existing thermal profile support is enabled for this board.
This enables the existing fan control and platform profile
handling for 8A18.
The board has been reported as working with this configuration
in OmenCtl.
Link: https://github.com/yunusemreyl/OmenCtl/commit/ea60e1c52859f0f299e092ae0478cdc7de82122f
Signed-off-by: Suryansh Singh <technosfan14@gmail.com>
Link: https://patch.msgid.link/20260823072407.74512-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>
|
|
Honor MagicBook laptops emit WMI event code 0x288 when pressing the
camera e-shutter / privacy toggle key (Fn+F8 on Honor).
Add the missing 0x288 keycode to huawei_wmi_keymap[] in correct numerical
order and map it to KEY_CAMERA_ACCESS_TOGGLE.
Tested on Honor MagicBook X14 Plus (FMI-76, AMD Ryzen 8845HS).
Signed-off-by: Ruzal Daminov <daminovruzal7@gmail.com>
Link: https://patch.msgid.link/20260819083836.1410-1-daminovruzal7@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
