| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Some Windows-on-Arm notebooks contain embedded Binary MOF data,
accessible using the WMI-ACPI interface. Move the associated driver
to the generic WMI code to make it possible to build it on arm64.
Also rework the Kconfig help text a bit.
Link: https://lists.linaro.org/archives/list/aarch64-laptops@lists.linaro.org/thread/U2IZENSIOOHZHGXVN7GM5HX5O3FD5KCF/
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260724025959.142826-4-W_Armin@gmx.de
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The WMI-ACPI driver now supports architectures other than x86.
Remove the CONFIG_X86 handling from video-detect and the associated
drivers to simplify the resulting code.
Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patch.msgid.link/20260724025959.142826-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 aarch64-laptops project found out that some Windows-on-Arm
notebooks contain WMI-ACPI mapping devices (PNP0C14) that work
exactly like on x86. Remove the dependency on CONFIG_X86 to
make it possible to build the ACPI-WMI driver on arm64.
Link: https://lists.linaro.org/archives/list/aarch64-laptops@lists.linaro.org/thread/U2IZENSIOOHZHGXVN7GM5HX5O3FD5KCF/
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260724025959.142826-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>
|
|
|
|
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>
|
|
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>
|
|
https://gitlab.freedesktop.org/drm/rust/kernel into drm-next
DRM Rust changes for v7.4-rc1
- Cross-subsystem:
- I/O (shared from driver-core tree via signed tag rust-io-7.4-rc1):
- Reimplement register!() as a procedural macro, require matching
base types for register access, and replace relative registers
with typed I/O projections. Convert Nova, Tyr and the PCI sample
- Add AsRepr/AsReprMut conversions for I/O on compatible wrapper
types and transmute helpers with deferred size checks
- DMA (shared from driver-core tree via signed tag rust-dma-7.4-rc1):
- Tie Coherent, CoherentBox and CoherentHandle to the device's bound
lifetime, and allow scoped debugfs files backed by non-'static
data
- Allow auxiliary registration-data closures to return covariant
sub-fields and add UserSliceWriter::write_truncated()
- Implement Send and Sync for MapleTree
- Add PCI resource_flags() and IORESOURCE_MEM_64, and convert PCI IRQ
flags to impl_flags!()
- Add I/O view cast() with compile-time size and alignment checks
- DRM:
- Add Rust dma_fence abstractions with separate producer (DriverFence)
and consumer (Fence) types, per-context sequencing, signal callbacks
and preallocation. Additional backend operations remain follow-up
work.
- Initialize DRM registrations and their data in place, removing a
separate allocation
- Drop the unused flags argument from drm::Registration::new()
- Nova:
- UAPI and Cross Module API:
- Add NovaCoreApi and a lifetime-bound handle for auxiliary child
drivers, carried in nova-drm registration data
- Expose a render node and extensible INFO ioctl reporting GPU
architecture, opaque chip ID, usable VRAM and VRAM BAR sizes,
full and short GPU names, and GID, with size discovery and
truncation to the userspace buffer size
- Move BAR-size queries into GPU info, removing GETPARAM and
changing the UAPI
- PRAMIN access:
- Add typed CPU access to VRAM through the movable 1 MiB BAR0
PRAMIN window, with per-architecture support from Turing through
Blackwell
- Add GpuMm centralized memory manager, VramAddress type, aperture
documentation and optional probe-time self-tests under
CONFIG_NOVA_CORE_SELFTESTS
- GPU virtual memory and BAR1:
- Add VRAM buddy allocation, TLB flushing, MMU v2/v3 page-table
types with trait-based generics (PteOps, PdeOps, DualPdeOps,
MmuConfig) and a generic walker
- Add maple-tree virtual address tracking and multi-page mapping,
separating allocation from mapping execution
- Add CPU access to mapped VRAM through BAR1 and memory-management
self-tests; handle 64-bit BAR0 when locating BAR1
- GPU interrupts and GSP events:
- Add GIN (GPU Interrupt and Notification) interrupt-tree support
with MSI-X, MSI fallback and per-architecture rearming
- Drain GSP events between commands via a threaded SWGEN0 handler
- Report OS errors, robust-channel notifications and unknown
messages without aborting command waits; hold the queue lock and
use one deadline per wait
- Disable GSP event interrupts on persistent falcon faults or
drain errors
- Add a delivery/rearm self-test, interrupt-tree KUnit coverage
and interrupt-controller documentation
- GSP messaging fixes:
- Queue setup RPCs before GSP-RM boot
- Correct DMA barriers in both queue directions
- Firmware and transport:
- Extract a reusable radix3 buffer mapper; zero-pad page-table
levels to whole pages to prevent booter reads of stale padding
- Correct GSP-FMC naming and boot-flow documentation
- Set MCTP header version 1 for FSP messages and retain the
command queue's BAR0 reference
- Resource handling:
- Replace unnecessary BarUser reference counting with in-place
ownership and borrowed access; consolidate probe initialization
- Declare an unlimited DMA maximum segment size
- Tyr:
- Use bitfield!() for firmware section flags and memory attributes
that do not describe registers
- Zero unsupported and newly added GPU-info fields, and limit the
doorbell array to 17 entries to fit the mapped register region
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: "Danilo Krummrich" <dakr@kernel.org>
Link: https://patch.msgid.link/DM371PN4TBJT.3LY1B0EYWSI4@kernel.org
|
|
ath12k_mac_vdev_delete() walks txmgmt_idr with idr_for_each(), and its
callback removes each entry belonging to the interface. Removing the
current entry can invalidate the radix-tree iterator retained by
idr_for_each().
Move the walk into a helper that uses idr_for_each_entry(). It performs a
fresh lookup for every iteration, so each matching entry can be removed
through the locked removal helper without retaining iterator state across
the removal.
Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20261003092104.520135-6-yaojiale02@163.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
