The HP OMEN Transcend 16 (board ID: 8BB3) uses the existing
OMEN v1 WMI interface 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 8BB3,
including platform profile and fan control support.
Tested on:
HP OMEN Transcend 16-u0xxx
DMI Board Name: 8BB3
Platform profile registration, fan RPM reporting, and PWM fan
control have been verified on this board.
Link: 5d7a893432
Signed-off-by: Suryansh Singh <technosfan14@gmail.com>
Link: https://patch.msgid.link/20260817145206.148600-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 16-wf0xxx (board ID: 8BAA) has the same WMI interface
as other OMEN boards and is compatible with the existing
omen_v1_board_params.
Add the DMI board name to hp_wmi_feature_boards[] table
and map it to omen_v1_board_params.
Without this entry, platform profile switching is unavailable,
preventing fan RPM reporting and controlling.
Tested on:
HP OMEN 16-wf0xxx
DMI Board Name: 8BAA
It has been confirmed that the platform profile is registered
successfully, and the fan RPMs are readable and controllable.
Link: https://www.reddit.com/r/HPOmen/comments/1siukdu/guide_native_fan_control_on_hp_omen_16wfx0xxx/
Signed-off-by: Suryansh Singh <technosfan14@gmail.com>
Link: https://patch.msgid.link/20260817121233.44636-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>
Up until now, the MT8173 elm/hana device tree has set the dedicated
regulator supplying the trackpad as always-on, simply because the Elan
driver was missing proper delays. As a result the delay for the
Synaptics trackpad was also omitted, as it was not strictly required
under such a model and delayed the availability of the trackpad to the
user.
The Elan driver recently gained proper delays after power-up, with
adaptive skipping of the delay if the regulator was originally
on. The I2C HID driver and I2C OF component prober library gained
similar adaptive delay skipping. The device tree will be fixed to have
the regulator not be always on, and proper post-power-on delay time
added to the I2C HID device.
Also add the post-power-on delay to the ChromeOS OF component prober,
so that if the regulator is off at the time of probing, the prober knows
to wait for the hardware to initialize.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20260811122011.3539250-8-wenst@chromium.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Merge updates related to the ACPI video bus driver for 7.3-rc1:
- Introduce helper function acpi_dev_is_video_device() and use it in
the core ACPI device enumeration code, in the ACPI video bus driver,
in the ACPI support code for I2C, in the PCI VGA driver, and in the
x86 platform thinkpad_acpi driver (Andy Shevchenko)
- Add a quirk to use the native backlight on Acer Nitro AN515-46 to the
ACPI video bus driver (Marcos Paulo Medeiros)
- Release PCI device reference after lookup in video_detect_portege_r100()
in the ACPI video bus driver (Yuho Choi)
* acpi-video:
ACPI: video: Release PCI device reference after lookup
ACPI: video: force native backlight on Acer Nitro AN515-46
platform/x86: thinkpad_acpi: Convert to use acpi_dev_is_video_device() helper
PCI/VGA: Convert to use acpi_dev_is_video_device() helper
i2c: acpi: Convert to use acpi_dev_is_video_device() helper
ACPI: video: Convert to use acpi_dev_is_video_device() helper
ACPI: scan: Convert to use acpi_dev_is_video_device() helper
ACPI: utils: Introduce acpi_dev_is_video_device() helper
-----BEGIN PGP SIGNATURE-----
iQFSBAABCgA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmp49yoeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiG1WIH/1SD1rNIb4Prf0C7
Rk9Hz0IZ3uYNe1Xi+Ozv3zQUuLB6d7ewl9e4zyHHYT4eeIKvBZv9jtIF3QH4ty5X
JB9Gy62WICtqIEkzzt2bkcV1byFmKz2+BLv04fgcyTXEGOEByCDiZ3/N3kSJOqvg
YxsGOmKkQSTavFLSe96Gj2pgchJqZ6j3qucDO6GrPOo8depP2kfzxfaJbXix0HEZ
ln08X9hgZDxy4I98PmSaaJsK2R/i6T6jQdA3i8DnSbbyNhLn+3FK6gkP08ZEpaor
82WwJf+MVCLHXLYDy0aYOUDHpkNkkJWOj45A2Hv9JkOupGcUpyPGr82l4yh/MrxC
+kM28xs=
=rIbd
-----END PGP SIGNATURE-----
Merge tag 'v7.2-rc7' into driver-core-next
We need the driver-core fixes in here as well to build on top of.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
qcom_ec_read() accepts short positive transfers, while both callers
unconditionally consume every field in their fixed-size response. A short
transfer can therefore make them use trailing stack bytes that were not
returned by the device.
The first response byte contains the number of payload bytes, excluding
the byte count itself. A complete response of resp_len bytes must
therefore report resp_len - 1 payload bytes. The existing check only
rejects counts that do not fit in the response buffer and still accepts
an incomplete payload.
Require both the SMBus transfer length and the EC-provided payload count
to match the expected response size.
Fixes: 5c44f48e91 ("platform: arm64: Add driver for EC found on Qualcomm reference devices")
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Link: https://patch.msgid.link/20260728111924.4106898-1-lilinmao@kylinos.cn
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The Samsung Galaxy Book6 Pro (NP944XJG-KG4IT) exposes its SCAI ACPI
device with HID SAMB430, which is not in the driver's device ID table,
so the driver never binds and none of its features are available.
Add SAMB430 to galaxybook_device_ids[].
Tested on an NP944XJG-KG4IT by forcing the bind via driver_override,
which is equivalent to an ID table match. All driver features probe
successfully: keyboard backlight LED, battery charge control end
threshold, platform profile (low-power/quiet/balanced/performance),
firmware attributes (power_on_lid_open, usb_charging), and the camera
lens cover input switch.
One optional feature probe fails harmlessly on this model:
"failed to execute CSFI; device responded with failure code 0xff".
This does not affect any of the features listed above.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Riccardo Squarcialupi <rikysquarcia@gmail.com>
Link: https://patch.msgid.link/20260731125431.199902-1-rikysquarcia@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The Lenovo Yoga Book 9 14IAH10 ships with a detachable Bluetooth keyboard
that magnetically attaches to the bottom (secondary) screen in one of two
positions. The Embedded Controller tracks the attachment state in a 2-bit
field called BKBD and signals changes via WMI event GUID
806BD2A2-177B-481D-BFB5-3BA0BB4A2285 (notify ID 0xEB on the WM10 ACPI
device, _UID "GMZN").
The device contains embedded BMOF data (WQDD, 20705 bytes) documenting
both WMI interfaces used by this driver:
LENOVO_BTKBD_EVENT (event GUID): WmiDataId(1) uint32 Status.
The ACPI _WED(0xEB) method returns EC.BKBD directly as an integer,
so the notify callback receives BKBD without a separate query.
LENOVO_FEATURE_STATUS_DATA (block GUID, WQAF method): returns an
8-byte buffer {uint32 IDs=0x00060000, uint32 Status=BKBD}.
Used for the initial state read on probe and after resume.
BKBD encoding:
0 = keyboard detached
1 = keyboard docked on top half of bottom screen
2 = keyboard docked on bottom half of bottom screen
3 = reserved (not observed in practice)
This driver registers two WMI drivers sharing a module-level
BLOCKING_NOTIFIER_HEAD:
- The event driver (LENOVO_BTKBD_EVENT) uses .notify_new() to receive
a pre-parsed wmi_buffer and fires the notifier chain with the BKBD
value extracted from the buffer.
- The block driver (LENOVO_FEATURE_STATUS_DATA) owns the input_dev in
its per-device private struct. At probe time it registers a
notifier_block on the chain and reads the initial BKBD state via
wmidev_query_block(). The WMI buffer is parsed as
struct lenovo_feature_status { __le32 id; __le32 status; }, and the
ID field is verified before the status is used.
- SW_TABLET_MODE=1 is reported when the keyboard is detached;
SW_TABLET_MODE=0 when docked in either position (keyboard present).
- The raw BKBD value is exposed via read-only sysfs attribute
"keyboard_position".
- BKBD state is re-read via wmidev_query_block() on resume from
suspend or hibernation.
Tested on: Lenovo Yoga Book 9 14IAH10 (model 83KJ), kernel 7.0.
Acked-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Dave Carey <carvsdriver@gmail.com>
Link: https://patch.msgid.link/20260728225545.1333610-3-carvsdriver@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The Yoga Book 9 14IAH10 (DMI product name "83KJ") has a dedicated
yb9-kbdock WMI driver that registers an input device reporting
SW_TABLET_MODE to track the detachable Bluetooth keyboard.
lenovo-ymc also loads on this machine and creates an input node with the
SW_TABLET_MODE capability bit set. For input switches, the presence of
the capability bit has semantic meaning: userspace (e.g. GNOME) reads
the switch state at startup from every node advertising the capability
and does not expect more than one such node.
Add a DMI match for the Yoga Book 9 14IAH10 to probe() so that
lenovo-ymc returns -ENODEV on this hardware, leaving yb9-kbdock as the
sole SW_TABLET_MODE source. The ymc_ec_trigger EC write, the only
other action taken in response to a YMC event, is guarded by a separate
DMI table that excludes this machine; no other functionality is affected.
Signed-off-by: Dave Carey <carvsdriver@gmail.com>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Link: https://patch.msgid.link/20260728225545.1333610-2-carvsdriver@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The LIGHTBAR_CMD_SET_PROGRAM command uses an 8-bit size field for its
payload length, but the protocol-negotiated `max_request` may exceed
the maximum value an 8-bit integer can represent.
When this occurs, large payloads (e.g., >255 bytes) integer wrap the
8-bit size variable when assigning `param->set_program_ex.size`, causing
truncation and parse failures downstream in the EC firmware stack.
Clamp `max_size` to the maximum value the structural size field can
support.
Fixes: 9600b8bdbf ("platform/chrome: lightbar: Add support for large sequence")
Signed-off-by: Alexis Savery <asavery@google.com>
Link: https://lore.kernel.org/r/20260730204240.2227178-1-asavery@google.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Each int3472_gpio_map entry currently maps exactly one ACPI HID to a
GPIO quirk. As more sensors needing the same quirk are identified, this
means adding a full duplicate table entry per HID, differing only in
the HID string, which does not scale.
Change int3472_gpio_map::hid to a NULL-terminated hids array so a
single entry can match any number of ACPI HIDs, letting new HIDs be
added to the relevant array instead of duplicating quirk entries.
Cc: linux-media@vger.kernel.org
Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Tarang Raval <tarang.raval@siliconsignals.io>
Tested-by: Kate Hsuan <hpa@redhat.com>
Reviewed-by: Kate Hsuan <hpa@redhat.com>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Register the AWINIC AW88399 ACPI hardware ID "AWDZ8399" with the
serial-multi-instantiate driver and add it to the ACPI scan ignore
list so that the two I2C amplifier instances on Lenovo Legion laptops
are enumerated as separate I2C client devices rather than a single
ACPI platform device.
The SMI node creates two instances named "aw88399-hda" with
IRQ_RESOURCE_AUTO, matching the pattern used by CS35L41.
Tested-by: Nadim Kobeissi <nadim@symbolic.software>
Tested-by: Xia Yun'an <imitoy@imitoy.top>
Tested-by: Munzir Taha <munzirtaha@gmail.com>
Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Co-developed-by: Yakov Till <yakov.till@gmail.com>
Signed-off-by: Yakov Till <yakov.till@gmail.com>
Signed-off-by: Marco Giunta <marco_giunta@outlook.it>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/DS7PR19MB7724431AE60B3D2280E73492FCCA2@DS7PR19MB7724.namprd19.prod.outlook.com
cros_ec_debugfs_probe() registers notifier_panic with the EC panic
notifier chain. The remove path tears down debugfs and the console log,
but leaves the notifier registered. A later panic notification can call
back into the removed instance and queue work that accesses released
data.
Unregister the panic notifier before tearing down the debugfs and
console log state.
This issue was found by a static analysis tool.
Fixes: d90fa2c64d ("platform/chrome: cros_ec: Poll EC log on EC panic")
Signed-off-by: Hongyan Xu <getshell@seu.edu.cn>
Link: https://lore.kernel.org/r/f3ab74ef8034be63bb45a325f3d54656d658817f.1785320940.git.getshell@seu.edu.cn
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Fixes
- dell-dw5826e: Fix ACPI _DSM function index and bitmask usage
The following is an automated shortlog grouped by driver:
dell-dw5826e:
- fix ACPI _DSM function index and bitmask usage
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQSCSUwRdwTNL2MhaBlZrE9hU+XOMQUCamkQMwAKCRBZrE9hU+XO
MbdBAQC7mgdOnvJZdFpDHlGCelbc4W8PnI1thRspZGNSA7tmaAEA8F9Z2Jpey1UM
03HO9ioF5t8Zn9tmymkvPBwyvSVGyQk=
=qQaU
-----END PGP SIGNATURE-----
Merge tag 'platform-drivers-x86-v7.2-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
Pull x86 platform driver fix from Ilpo Järvinen:
- Fix ACPI _DSM function index and bitmask usage for Dell DW5826e
* tag 'platform-drivers-x86-v7.2-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
platform/x86: dell-dw5826e: fix ACPI _DSM function index and bitmask usage
The ACPI driver currently prepares the per-socket metric table only
on HSMP_PROTO_VER6. With protocol version 7 in use on Family 1Ah
Model 50h-5Fh, userspace cannot reach the larger ~13 KB table:
hsmp_get_tbl_dram_base() is skipped, sock->metric_tbl_addr stays
NULL, and the ioctl added earlier in this series has nothing to read.
Widen the proto_ver gate in init_acpi() from '== HSMP_PROTO_VER6'
to '>= HSMP_PROTO_VER6' so the DRAM region is mapped and
sock->metric_tbl_size is populated on protocol version 7 (and any
future compatible version), making the ioctl path functional.
hsmp_metric_tbl_acpi_read() now returns -EOPNOTSUPP whenever the
running protocol version is not VER6, because the sysfs binary
attribute cannot carry a table larger than PAGE_SIZE. Version 7
userspace gets a clear, actionable error and a documented pointer to
HSMP_IOCTL_GET_TELEMETRY_DATA; version 6 userspace sees no change.
The non-ACPI plat.c path is intentionally left untouched: it covers
Family 1Ah Model 0h-Fh hardware fixed at protocol version 6, where
the existing metrics_bin remains the supported interface.
Co-developed-by: Muthusamy Ramalingam <muthusamy.ramalingam@amd.com>
Signed-off-by: Muthusamy Ramalingam <muthusamy.ramalingam@amd.com>
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260727141542.3370108-6-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The metric table needs to be delivered to userspace as a single
atomic snapshot, but the current sysfs metrics_bin path is a file
read: userspace can read it in chunks and observe a torn snapshot
if an SMU refresh happens between read() calls. The same path is
also bounded by PAGE_SIZE, so the ~13 KB table used by HSMP protocol
version 7 on Family 1Ah Model 50h-5Fh cannot be returned at all,
regardless of how userspace reads it. Rather than extend sysfs to
lift both restrictions, expose the metric table through the
existing HSMP character device using a new ioctl that always copies
the table in one shot.
Add struct hsmp_telemetry_data and HSMP_IOCTL_GET_TELEMETRY_DATA
to the UAPI header. Under the surrounding #pragma pack(4), placing
the __u64 user pointer first gives a tight 16-byte layout that is
identical for 32- and 64-bit callers, and the trailing __u16
reserved field is rejected with -EINVAL if non-zero so future
kernels can repurpose it without breaking already-deployed
userspace. The command is encoded with _IOW because the kernel only
reads the request struct; the snapshot travels through the user
pointer it carries.
The requested size may be anything from one byte up to the size
firmware reported for that socket's table. A short request returns
the leading bytes of the snapshot, so userspace built against an
older table layout keeps working on firmware that grew the table,
mirroring the relaxed response_sz rule applied to HSMP messages
earlier in this series. A request larger than the firmware table is
rejected with -EINVAL rather than short-written, so a caller can
never mistake a partial copy for a full one.
Dispatch hsmp_ioctl() on the ioctl command: the existing message
handler is factored out as hsmp_ioctl_msg() for HSMP_IOCTL_CMD, and
HSMP_IOCTL_GET_TELEMETRY_DATA goes to a new
hsmp_ioctl_get_telemetry() helper.
/dev/hsmp is a singleton character device that outlives an
individual socket unbind, so an ioctl issued on an already-open fd
can run concurrently with socket teardown. hsmp_sock_rwsem is the
driver's contract for that: the data plane takes it for read, and
probe and remove take it for write to drain the data plane before
freeing the socket array, unmapping the metric tables and
destroying the per-socket mutexes. hsmp_ioctl_get_telemetry() takes
it for read across the socket lookup, the checks on that socket's
metric-table state and the table read itself, so none of that state
can be torn down underneath it. Without this the handler would
sleep in its kvmalloc() holding no lock at all, and could resume
with a freed socket, locking a destroyed mutex and reading from an
unmapped iomem region.
The lock is dropped before the copy_to_user(), because faulting in
the destination can block indefinitely on a userfaultfd-backed
buffer and would otherwise leave a socket unbind waiting for the
write lock.
Since hsmp_metric_tbl_read() reached the mailbox through
hsmp_send_message(), which takes hsmp_sock_rwsem itself, calling it
with the lock already held would recursively take the read side and
can deadlock against a queued writer. Split out
hsmp_metric_tbl_read_locked(), which asserts the lock and uses
hsmp_send_message_locked(), and leave hsmp_metric_tbl_read() as a
wrapper that takes the read lock for the sysfs callers. This also
brings the whole fill-and-copy under the rwsem for those callers,
where the memcpy_fromio() previously ran outside it, and makes the
lock order uniformly hsmp_sock_rwsem -> metric_read_lock ->
hsmp_sem.
The user-controlled socket index in HSMP_IOCTL_GET_TELEMETRY_DATA is
clamped with array_index_nospec() before indexing hsmp_pdev.sock[],
mitigating Spectre v1 (CVE-2017-5753). Include linux/nospec.h, which
the file relied on getting transitively.
Co-developed-by: Muthusamy Ramalingam <muthusamy.ramalingam@amd.com>
Signed-off-by: Muthusamy Ramalingam <muthusamy.ramalingam@amd.com>
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260727141542.3370108-5-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The driver hard-codes the metric-table region size to
sizeof(struct hsmp_metric_table). That is correct for HSMP protocol
version 6 but mis-sizes the ioremap of the SMU DRAM region on newer
platforms: Family 1Ah Model 50h-5Fh exposes a ~13 KB table under
protocol version 7, and the table is expected to keep growing on
future firmware. The same hard-coded value also forces
hsmp_metric_tbl_read() to reject any read that follows the actual
firmware layout.
Pick up the table size from firmware instead. SMU on Family 1Ah
Model 50h and later populates HSMP_GET_METRIC_TABLE_DRAM_ADDR's
args[2] with the DRAM region size in bytes; older firmware leaves it
0. Bump the descriptor's response_sz to 3 so the field is read, and
store the result in the new per-socket hsmp_socket.metric_tbl_size,
which is then used both for the ioremap() of the region and as the
expected size in hsmp_metric_tbl_read().
The size is stored per socket rather than per platform because
hsmp_get_tbl_dram_base() runs once per socket and each socket maps
its own region. A single platform-wide field would let the last
socket's size be used to copy out of an earlier socket's smaller
mapping.
Bump DRIVER_VERSION to 2.6.
Behaviour on existing protocol-version-6 hardware is unchanged.
Reading a third response word is safe there: for this command SMU
leaves args[2] as 0 rather than a stale value from an earlier
mailbox transaction, so the fallback always applies, yielding the
same value as the previous hard-coded one, and both the ioremap and
the size check produce the same result as before.
Co-developed-by: Muthusamy Ramalingam <muthusamy.ramalingam@amd.com>
Signed-off-by: Muthusamy Ramalingam <muthusamy.ramalingam@amd.com>
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260727141542.3370108-4-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
As HSMP protocol versions evolve, existing message IDs sometimes
gain additional response words on newer firmware. validate_message()
currently enforces a strict equality (response_sz == table value)
for HSMP_SET and HSMP_GET, so userspace compiled against an earlier
descriptor table is rejected with -EINVAL when it asks for fewer
response words than the in-kernel table now declares - even though
that caller has no interest in the additional words. Only
HSMP_SET_GET already used a relaxed upper-bound check.
Replace the per-type branching with a single upper-bound check for
all message types. Userspace can now request fewer response words
than hardware provides, while requests that exceed the descriptor
table (and therefore the hardware capability) are still rejected.
Co-developed-by: Muthusamy Ramalingam <muthusamy.ramalingam@amd.com>
Signed-off-by: Muthusamy Ramalingam <muthusamy.ramalingam@amd.com>
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260727141542.3370108-3-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
We now use PTR_ERR() and IS_ERR() in this module so pull in the header
that provides them.
Fixes: 1e0bd438b8 ("platform/surface: gpe: use platform_device_register_full()")
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://patch.msgid.link/20260727144308.61842-1-bartosz.golaszewski@oss.qualcomm.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The 1AH_M80H platform introduces a new firmware managed DRAM based
metrics table (amd_pmf_metrics_v3) covering the full platform telemetry
including power, voltages, frequencies, throttlers and activity monitors.
As a first consumer of this table, add NPU metrics retrieval. Unlike
earlier platforms that use a transfer table command, 1AH_M80H metrics
are accumulator based and require delta calculation between consecutive
samples.
Extend amd_pmf_npu_metrics with npu_temp, populated from the
npu_temp_acc accumulator field available on 1AH_M80H.
Key changes include:
- Add DRAM based metrics table support for the 1AH_M80H platform
- Introduce amd_pmf_get_tbl_dram_addr() to obtain the DRAM address
- Add amd_pmf_get_metrics_table_log_sample() to trigger metrics updates
- Add struct amd_pmf_metrics_v3 for the 1AH_M80H metrics format
- Implement accumulator based delta calculation for metrics
- Introduce amd_pmf_calculate_acc_npu_metrics() to get NPU metrics
- Introduce amd_pmf_supports_accumulator_metrics() to check the
accumulator based metrics support.
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com>
Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260723111534.1940925-8-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>
Refactor the NPU metrics retrieval code to use a switch-case structure
based on CPU ID, preparing the driver for supporting additional
platforms with different metrics table formats.
This change restructures amd_pmf_get_smu_metrics() to handle
platform-specific metrics retrieval paths. The existing logic for
1AH_M20H and 1AH_M60H platforms is preserved within the switch-case
block.
No functional changes.
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com>
Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260723111534.1940925-7-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>
Replace the open coded manual bit shifting used to split a 64-bit
physical address into its high and low 32-bit halves with the standard
kernel helpers upper_32_bits() and lower_32_bits().
No functional changes.
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com>
Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260723111534.1940925-6-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>
Add the missing trailing newline to the dev_err() message printed when
an invalid CPU id is encountered.
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260723111534.1940925-5-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>
Refactor metrics related code from core.c into a new metrics.c file
to improve code organization and maintainability. The metrics
functionality is evolving with new platform support, warranting a
separate file.
No functional changes.
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com>
Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260723111534.1940925-4-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>
Add PCI device ID (0x115b) and ACPI ID (AMDI0109) to enable PMF driver
support for the AMD 1AH_M80H (Family 1AH Model 80H).
The 1AH_M80H platform introduces an extended SMU mailbox interface that
uses three argument registers instead of the single register used by
earlier platforms. Define five new register offsets for the 1AH_M80H
mailbox: message, response and three argument registers. The extended
argument registers are required because 1AH_M80H exposes metrics through
a firmware managed DRAM region. The GET_METRICS_TABLE_DRAM_ADDR command
returns a 64-bit physical address split across arg_reg[0] (low 32-bit)
and arg_reg[1] (high 32-bit), with the metrics table size in arg_reg[2].
Define amd_pmf_smu_regs_v2 to capture this extended register layout and
register it in pmf_pci_ids[] via PCI_DEVICE_DATA(), keeping the existing
amd_pmf_smu_regs_v1 shared instance for all prior platforms unchanged.
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com>
Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260723111534.1940925-3-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>
Different AMD platforms use varying SMU register layouts for PMF-SMU
mailbox communication. The register offsets are currently hardcoded as
AMD_PMF_REGISTER_MESSAGE, AMD_PMF_REGISTER_RESPONSE and
AMD_PMF_REGISTER_ARGUMENT directly in amd_pmf_send_cmd() and
amd_pmf_dump_registers(), making it difficult to support platforms that
use a different mailbox register layout without scattering per-platform
conditionals across the send path.
Introduce struct amd_pmf_smu_regs to capture the SoC-specific SMU
mailbox register offsets (msg_reg, resp_reg, arg_reg) and add a
pointer to it in struct amd_pmf_dev. RMB, PS, 1AH_M20H and 1AH_M60H
all share the same legacy register layout and point to a single shared
amd_pmf_smu_regs_v1 instance, avoiding redundant struct definitions.
Convert the pmf_pci_ids[] table from PCI_DEVICE() to PCI_DEVICE_DATA(),
embedding the smu_regs pointer directly as driver_data. Introduce
amd_pmf_get_smu_mb_offset() which resolves the matching PCI entry via
pci_match_id() at probe time and assigns driver_data to dev->smu_regs.
Update all SMU register accesses in amd_pmf_send_cmd() and
amd_pmf_dump_registers() to go through dev->smu_regs. Remove the
hardcoded register offset references from the send path. New platform
support requires only a new smu_regs instance and a corresponding
PCI_DEVICE_DATA() entry.
No functional changes for existing platforms.
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com>
Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260723111534.1940925-2-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 HP OMEN 16-wd0xxx (board ID: 8BA9) 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_board_params.
Without this entry, platform profile switching is unavailable,
preventing fan RPM reporting and controlling.
Tested on:
HP OMEN 16-wd0012TX
DMI Board Name: 8BA9
It has been confirmed that the platform profile is registered
successfully, and the fan RPMs are readable and controllable.
Signed-off-by: Suryansh Singh <technosfan14@gmail.com>
Link: https://patch.msgid.link/20260724120255.49649-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>
There can only exist a single instance of the dell-smbios-wmi driver
at the same time because of naming conflicts with the character
device ("wmi/dell-smbios"). Having a global list for all instances
thus makes no sense.
Replace the global list with a single item used by the character
device. This simplifies the driver and allows us to mark it as
being multi-instance safe.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260720131921.368000-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>
The WMI SMBIOS backend needs to access the its driver state container
when performing SMBIOS calls. Pass the device associated with a given
backend to the callback function to allow the WMI backend to retrieve
said state container in a more straightforward manner.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260720131921.368000-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>
When unbinding the WMI driver while a userspace application has
an open file descriptor for the character device, a UAF occurs:
KASAN: slab-use-after-free in _copy_to_user from platform/x86/dell-smbios-wmi
The reason for this is that even after calling misc_deregister(),
userspace appications can still call read() and/or ioctl() on open
file descriptors associated with the already unregistered character
device. This causes a UAF by attempting to access the already freed
state container of the WMI driver.
Fix this by no longer storing the state container inside
filp->private_data. Instead retrieve the state container using
get_first_smbios_priv() and return -ENODEV if the state container
does not exist anymore.
Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
Closes: https://lore.kernel.org/platform-driver-x86/178144969601.60470.13396800403157907003@gmail.com/
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260720131921.368000-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>
STB (Spill to DRAM) is an optional debugging facility that is only enabled
through the enable_stb module parameter. On some platforms the SMU refuses
the S2D setup outright, and on long-running systems the large telemetry
region can fail to ioremap. In either case amd_stb_s2d_init() returns an
error and, because probe treated that as fatal, the entire PMC driver
failed to load - silently disabling s0i3 support even though STB is only a
debug aid.
Downgrade the failure to a warning and continue probing so that s0i3
support via the LPS0 handler no longer depends on an optional debug
feature.
Since probe no longer aborts on this path, the LPS0 and debugfs unwinding
added by the earlier fix in this series becomes unreachable and is removed.
Reported-by: Francis De Brabandere <francisdb@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221759
Tested-by: Francis De Brabandere <francisdb@gmail.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260721181756.143084-7-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_pmc_probe() registers the LPS0 s2idle handler with
acpi_register_lps0_dev() and creates the driver's debugfs directory before
calling amd_stb_s2d_init(), which is the last step in probe that can fail.
When amd_stb_s2d_init() fails (for example the S2D telemetry region cannot
be ioremapped on a long-running system, or the SMU rejects the S2D setup)
the error path only calls pci_dev_put() and returns. This leaves
amd_pmc_s2idle_dev_ops on the global lps0_s2idle_devops_head list and leaks
the debugfs directory, while the devm-managed resources backing the handler
are torn down.
Reloading the module then walks the corrupted list in
acpi_register_lps0_dev() and hits:
list_add corruption. next->prev should be prev, but was NULL.
kernel BUG at lib/list_debug.c:29!
acpi_register_lps0_dev+0x44/0x80
amd_pmc_probe+0x224/0x380 [amd_pmc]
platform_probe+0x67/0x90
Even without a reload, the stale registration means the next s2idle
transition calls into torn-down driver state.
Unwind the debugfs directory and the LPS0 registration on the
amd_stb_s2d_init() error path. acpi_unregister_lps0_dev() is safe to call
unconditionally here: it is guarded on the same conditions as
acpi_register_lps0_dev(), which is exactly what amd_pmc_remove() already
relies on.
Reported-by: Francis De Brabandere <francisdb@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221759
Tested-by: Francis De Brabandere <francisdb@gmail.com>
Fixes: 83ad6974dd ("platform/x86/amd/pmc: Move STB block into amd_pmc_s2d_init()")
Cc: stable@vger.kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260721181756.143084-6-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_stb_s2d_init() creates the v2 "stb_read" debugfs node before mapping
the telemetry buffer into dev->stb_virt_addr, leaving a window during probe
where a read faults on a NULL dev->stb_virt_addr in
amd_stb_debugfs_open_v2()/amd_stb_handle_efr().
This becomes trivial to hit once a failed STB init no longer aborts probe
(next patch), which leaves the node registered with a NULL buffer. Create
it only after dev->stb_virt_addr is mapped.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260721181756.143084-5-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_stb_s2d_init() discards the return value of several S2D SMU commands.
When the SMU refuses a command (e.g. "SMU cmd failed. err: 0xff") the
failure is only noticed indirectly - if at all - and reported as -EIO,
masking the real error.
More seriously, the S2D_PHYS_ADDR_LOW/HIGH return values are ignored, so
on failure phys_addr_low/hi are left uninitialised and the assembled
address is passed straight to devm_ioremap(). When the SMU leaves them at
zero this maps physical address 0 and trips the ioremap-on-RAM warning:
amd_pmc AMDI000B:00: SMU cmd failed. err: 0xff
ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff
WARNING: CPU: 13 PID: 4592 at arch/x86/mm/ioremap.c:...
Check the return value of each SMU command and propagate it, and reject a
zero physical address before calling devm_ioremap().
Reported-by: Francis De Brabandere <francisdb@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221759
Tested-by: Francis De Brabandere <francisdb@gmail.com>
Fixes: 3d7d407dfb ("platform/x86: amd-pmc: Add support for AMD Spill to DRAM STB feature")
Cc: stable@vger.kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260721181756.143084-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_stb_debugfs_open_v2() switches dev->msg_port to MSG_PORT_S2D to query
S2D telemetry but only restores it to MSG_PORT_PMC on one path. The early
return on the dump_custom_stb path (and the error/allocation returns) leave
the port stuck on MSG_PORT_S2D, so subsequent SMU communication - including
the s2idle prepare/restore handlers - is directed at the wrong mailbox.
Consolidate the exit path through a single label so the message port is
always restored, mirroring the fix in amd_stb_s2d_init().
Reported-by: sashiko.dev
Link: https://sashiko.dev/#/patchset/20260717162023.956346-1-mario.limonciello%40amd.com
Fixes: 2851f4f8ed ("platform/x86/amd/pmc: Define enum for S2D/PMC msg_port and add helper function")
Cc: stable@vger.kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260721181756.143084-3-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>
dev->msg_port is switched to MSG_PORT_S2D before issuing the S2D SMU
commands but is only restored to MSG_PORT_PMC on the success path. The
early "return -EIO" and "return -ENOMEM" leave the port stuck on
MSG_PORT_S2D, so all subsequent SMU communication - including the s2idle
prepare/restore handlers - is directed at the wrong mailbox.
Consolidate the exit path through a single label so the message port is
always restored.
Fixes: 3d7d407dfb ("platform/x86: amd-pmc: Add support for AMD Spill to DRAM STB feature")
Cc: stable@vger.kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260721181756.143084-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>
-----BEGIN PGP SIGNATURE-----
iQJKBAABCAA0FiEEzOlt8mkP+tbeiYy5AoYrw/LiJnoFAmpjKJIWHGNoZW5odWFj
YWlAa2VybmVsLm9yZwAKCRAChivD8uImeulhD/9Oe/6FLvyuK4KYi+0DyacU4FZ4
NQjgFa3g2CBY+qiS6qSjzygbClFLZjkhbXsOaQekQjiYWNCKwTCJGg0m/y+qNS+S
F1UWxuZxVor1ty4y6KSldCHtdI5ROSXf2Iq3UNw2JX2W8LK0r/asLvFpkIHGcDdJ
kqMnD4aktxgs+RYZVs9rQrS0cR8mQom6KVu39/4KB/6QulEMEaH857txobexlaTo
7Jo/I3fcsxbcWxo+I6yZSdSkIBRI5H6eywbHgF0ug7cOmpQL70IGIx0S42XK7RUy
A/A7BrPN1JMFTloDSHTX6b05lCh4UEhLBbFgX3ztVCNXt0j5v7/y5dqISwn4qlDP
LkPEx/LQ1GsHQu9pqDN3gpD/G/RK+DvpA4p6+GpDrrQ7PQFMIKuzcil7LeZZ0C7H
VNbt7QP+HgPHezNroOMp16/PeEBLp2tkO1bqjCf/gRc47OPqLQtOiPJOK0B9yFzw
x4J8SRwxjqrg/TYYfP5lOhqafF0cp7ZE7LSlCMwylnZ6EYHaeEJh14ii5u36XJuj
ohu83vsobIRa9fJ7StQ8Hf6nJSGSoWpkn6WIAxiL/+Ksz4gzfe+5TNEoBg1cGqjX
XBS/qVj0ju06QVrg4H8X9gKEt7LQN+nIXBCg/OXSD75pdM/wlO08PANygU4FXUbE
/Q3RTJykzBT4P1TETg==
=BlSV
-----END PGP SIGNATURE-----
Merge tag 'loongarch-fixes-7.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson
Pull LoongArch fixes from Huacai Chen:
- fix build warnings and errors
- move jump_label_init() before parse_early_param()
- retrieve CPU package ID from PPTT when available
- fix some bugs kgdb, BPF JIT and laptop platform driver bugs
* tag 'loongarch-fixes-7.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson:
platform/loongarch: laptop: Explicitly reset bl_powered state when suspend
platform/loongarch: laptop: Stop setting acpi_device_class()
LoongArch: BPF: Fix memory leak in bpf_jit_free()
LoongArch: BPF: Zero-extend signed ALU32 div/mod results
LoongArch: Fix oops during single-step debugging
LoongArch: Fix address space mismatch in kexec command line lookup
LoongArch: Retrieve CPU package ID from PPTT when available
LoongArch: Move jump_label_init() before parse_early_param()
LoongArch: Fix build errors due to wrong instructions for 32BIT
LoongArch: Increase TASK_STRUCT_OFFSET up to 2040 for 32BIT
PALC_DSM_FN_TRIGGER_PLDR was defined as BIT(1) (value 2).
acpi_evaluate_dsm() expects a 0-based function index integer (0, 1,
2, ...), whereas acpi_check_dsm() expects a bitmask of supported
function indices (BIT(1), BIT(2), ...).
Because PALC_DSM_FN_TRIGGER_PLDR was defined as BIT(1),
acpi_evaluate_dsm() was evaluating Function Index 2 instead of Function
Index 1, while acpi_check_dsm() was checking for Function Index 1
support.
Fix this by setting PALC_DSM_FN_TRIGGER_PLDR to 1 (the function index)
and passing BIT(PALC_DSM_FN_TRIGGER_PLDR) to acpi_check_dsm().
Fixes: 1ab843135a ("platform/x86: dell-dw5826e: Add reset driver for DW5826e")
Signed-off-by: Surendra Singh Chouhan <kr494167@gmail.com>
Link: https://patch.msgid.link/20260724125533.74751-1-kr494167@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Before this change the HSMP data plane runs without any coordination with
driver teardown: open /dev/hsmp fds and hwmon sysfs reads call
hsmp_send_message() while probe and remove bring sockets up and down.
misc_deregister() does not drain already-open fds, so an in-flight message
can race a concurrent unbind and touch a freed socket array or an unmapped
mailbox.
Add the read side of hsmp_sock_rwsem to the data plane. Split the message
send into hsmp_send_message_locked(), which does the bounds check and MMIO
access and asserts the rwsem is held, and hsmp_send_message(), which wraps
it in guard(rwsem_read). Probe and remove hold the rwsem for write, so they
drain in-flight messages and keep new ones out while they tear a socket
down.
The probe-time senders run under the probe write lock and so must not take
the rwsem again: route hsmp_test(), hsmp_cache_proto_ver() and
hsmp_get_tbl_dram_base() through hsmp_send_message_locked() to avoid
recursive locking. A single rwsem therefore covers both the data plane and
the probe/remove handshake, with no separate probe lock:
- acpi.c already holds it for write across probe for the socket-array and
misc-registration handshake, so the mailbox handshake now nests under
that same lock.
- plat.c takes it for write around init_platform_device(). It is not held
across devm_add_action_or_reset() so the release action, which also
takes it for write, cannot deadlock if that registration fails.
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260723094656.3806028-7-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The ACPI driver binds one platform device per socket but shares a single
socket array and a single /dev/hsmp misc device across them. Replace the
is_probed flag with state that tracks this shared ownership:
- miscdevice.this_device tells whether /dev/hsmp is registered, so the
misc device is registered on the first socket and torn down last. A
preceding change clears mdev.this_device on deregister so this gate
stays reliable across a re-probe.
- a kref tracks the sockets that share the array. The first probe
initializes it, each further probe takes a reference and every remove
(or probe failure) drops one; the last put runs the release callback.
All get/put happen under hsmp_sock_rwsem held for write, so the counting
is already serialized and kref's atomic is not strictly needed, but kref
gives the clearer get/put interface and a release callback. The shared
socket array is allocated with kcalloc() on the first probe and freed by
the release callback once the last reference is dropped.
hsmp_acpi_sock_release() is the single teardown helper, run from
kref_put(): it deregisters /dev/hsmp if registered, unmaps any
metric-table DRAM, destroys the per-socket mutexes and frees the array.
The remove path and the probe-failure path both reach it through the last
put, so the teardown lives in one place.
Both paths also clear this socket's dev, so a message issued after a
non-final unbind (or to a socket that failed to probe on a multi-socket
system, whose array stays alive and whose remove() is never called) cannot
reach the mailbox that devres is about to unmap.
Two lifetime fixes fall out of the array persisting across a non-final
unbind:
- hsmp_get_tbl_dram_base() iounmap()s any stale metric_tbl_addr before
remapping, so a rebind does not leak one mapping per cycle. It runs
during (re)probe before the metric sysfs attribute is exposed, so no
reader can be using the old mapping.
- The ACPI path registers /dev/hsmp unparented by passing NULL to
hsmp_misc_register(). Its per-socket devices can be unbound individually
and out of order and the misc device outlives all but the last of them,
so parenting it to one socket's device would leave a dangling parent.
hsmp_misc_register() now takes the parent from its caller, so the
platform driver keeps parenting /dev/hsmp to its single device.
hsmp_sock_rwsem is held for write across probe and remove, so the release
and probe-failure cleanup run with it already held; an upcoming change adds
its read side so the same lock also drains the data plane.
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260723094656.3806028-6-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
misc_deregister() destroys the device but leaves miscdevice.this_device
pointing at the freed struct device. Clear it so any later check of
this_device, and a subsequent re-register, does not observe a stale
pointer. An upcoming change uses this_device to track whether /dev/hsmp is
registered across the shared ACPI sockets and relies on it being NULL after
deregister.
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260723094656.3806028-5-muralidhara.mk@amd.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
HSMP_GET_METRIC_TABLE makes the firmware refill a shared per-socket metric
DRAM region, which hsmp_metric_tbl_read() then copies out with
memcpy_fromio(). Two concurrent readers of the metrics_bin sysfs attribute
on the same socket can race: one can trigger a fresh fill while the other
is mid-copy and return a torn snapshot. (The hwmon path does not touch
this region; it only issues power messages via hsmp_send_message().)
Embed a struct mutex metric_read_lock in each hsmp_socket and hold it
across the fill-and-copy in hsmp_metric_tbl_read(). Add
hsmp_init_metric_read_locks() and hsmp_destroy_metric_read_locks(), which
take only struct hsmp_plat_device and iterate pdev->sock[] over
pdev->num_sockets so the caller cannot pass a count that disagrees with the
array.
Wire them into both front-ends' probe and teardown paths so the mutex is
always initialized before metrics_bin is exposed: the platform driver and
the ACPI driver both drive hsmp_metric_tbl_read() through the same 0444
metrics_bin attribute. Doing this in one patch avoids a bisection point
where an ACPI read would lock an uninitialized mutex.
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260723094656.3806028-4-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The metric-table DRAM region is mapped with devm_ioremap(), which ties the
mapping to the socket device's devres scope. An upcoming change lets the
ACPI front-end share the socket array across sockets and run its own
coordinated teardown, so the mapping can no longer be pinned to a single
per-socket devres scope.
Map it with plain ioremap() instead and add hsmp_unmap_metric_tbls(), which
drops every socket's metric_tbl_addr mapping. The platform driver registers
that helper with devm_add_action_or_reset() so the mappings are released on
both remove and probe failure, while the socket array itself stays
devm-managed.
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260723094656.3806028-3-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Add hsmp_sock_rwsem and export it, then hold it for write across ACPI
probe, remove and init_acpi() so concurrent per-socket platform probes
cannot race the is_probed handshake or the one-time socket-array
allocation. Use lockdep_assert_held_write() in init_acpi() to catch
incorrect locking under lockdep.
An rw_semaphore is used rather than a plain mutex because an upcoming
change adds a read side so data-plane messages run concurrently with each
other while probe/remove hold it for write to drain in-flight messages.
Introducing it as an rwsem now keeps the lock type stable across that
change.
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260723094656.3806028-2-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
There are two drivers in the ideapad-laptop module: a wmi_driver and a
platform_driver. The former is registered before the latter, but the
unregistration order is the same as the init one instead of the reverse.
Fix the driver unregistration order by reversing it.
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20260723-ideapad-rev-exit-v2-1-9c31159022de@rong.moe
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Sashiko reports a possible information leak that can occur as follows:
1. In parse_package(), memory allocated for data->device_mode_info is not
zerozed initially as it is allocated with devm_kmalloc_array().
2. In the for loop after the allocation, a malformed ACPI package
provided by firmware can cause some fields in data->device_mode_info
to remain uninitialized.
3. Later in update_sar_data(), the uninitialized fields gets copied to
the fields of context->sar_data, which can be exposed to userspace
through sysfs attribute read (intc_data_show()).
Fix the leak by switching to use devm_kcalloc() for allocation.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260710052806.100107-1-nihaal%40cse.iitm.ac.in
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Link: https://patch.msgid.link/20260723-platx86-v4-2-93b4a178b595@cse.iitm.ac.in
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The memory allocated for device_mode_info in parse_package() called by
sar_get_data() is not freed in some of the error paths in sar_probe().
Fix that by converting to use device managed allocations.
Fixes: dcfbd31ef4 ("platform/x86: BIOS SAR driver for Intel M.2 Modem")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Link: https://patch.msgid.link/20260723-platx86-v4-1-93b4a178b595@cse.iitm.ac.in
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Add support for querying and switching the graphics MUX mode on HP
systems via WMI. This introduces the 'gpu_mux_mode' sysfs attribute
under the hp-wmi platform device, allowing userspace tools to check
and safely switch between available graphics modes (e.g., UMA, Hybrid,
Discrete).
The hardware capabilities mask is primarily read using the modern
128-byte System Design Data query. However, to ensure backward
compatibility with older models, a fallback mechanism is implemented.
By mirroring the behavior of the Windows Omen Gaming Hub software, if
the modern query fails but the MUX WMI endpoint (0x52) responds
successfully to a read request, the driver defaults to a standard
Hybrid + Discrete support mask (0x06).
Signed-off-by: Kürşat Abaylı <hello@kursatabayli.dev>
Link: https://patch.msgid.link/20260723172734.18361-1-hello@kursatabayli.dev
[ij: add kstrtox.h]
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
On EAECIS NL60R with EC firmware version 1.11, resuming from S3 has a
very high chance (>90%) of causing the EC to lose the previous backlight
power state. When this happens, the laptop resumes normally from S3, but
the backlight remains off (when shining on the screen with a flash light,
we can see the screen contents are updating normally).
Since there is no generic way to query the EC's backlight state on
Loongson laptop platforms, assume the worst-case scenario and restart
the backlight power inside the kernel each time the system resumes.
Cc: stable@vger.kernel.org
Fixes: 53c762b47f ("platform/loongarch: laptop: Add backlight power control support")
Tested-by: Yao Zi <me@ziyao.cc>
Tested-by: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Zixing Liu <liushuyu@aosc.io>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
The driver populates acpi_device_class() which is never read afterward,
so make it stop doing that and drop the symbol defined specifically for
this purpose.
No intentional functional impact.
This change will facilitate the removal of "device_class" from "struct
acpi_device_pnp" in the future.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Extract the EC feature-reading logic from cros_ec_check_features() into
cros_ec_read_features() helper function.
Currently, cros_ec_check_features() swallows command transfer errors. By
isolating the transaction logic into an explicit helper that returns the
actual transfer error code, subsequent callers (such as the cros_ec_dev
driver during device probing) can catch a read error.
Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org>
Acked-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/20260608211518.2214740-2-akuchynski@chromium.org
Signed-off-by: Lee Jones <lee@kernel.org>
Fixes
- asus-wmi: Revert retaining battery charge threshold on boot due to
userspace regression. Userspace assumed (errorneously) a
non-zero return code from sysfs read implies feature is not
supported but the correct way would be to check file
visibility instead. This results in the kernel change
breaking the functionality completely. Thus, we are taking
timeout on the kernel side to allow userspace to sort their
problem first.
- intel/vsec: Free ACPI discovery data allocation on error paths
The following is an automated shortlog grouped by driver:
asus-wmi:
- temporarily revert to setting a charge limit
intel/vsec:
- free ACPI discovery data on early errors
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQSCSUwRdwTNL2MhaBlZrE9hU+XOMQUCamC2OgAKCRBZrE9hU+XO
MayPAQD6WZEq/0gBk0qmXQs/LsgGbhmmt0lWjN2i4KeQ/CqUlQEA/TAII2u3amM0
m0xOxdu139D4b7VJp8QjCanIYhFusg0=
=ePnn
-----END PGP SIGNATURE-----
Merge tag 'platform-drivers-x86-v7.2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
Pull x86 platform driver fixes from Ilpo Järvinen:
- asus-wmi: Revert retaining battery charge threshold on boot due to
userspace regression.
Userspace assumed (errorneously) a non-zero return code from sysfs
read implies feature is not supported but the correct way would be to
check file visibility instead. This results in the kernel change
breaking the functionality completely. Thus, we are taking timeout on
the kernel side to allow userspace to sort their problem first.
- intel/vsec: Free ACPI discovery data allocation on error paths
* tag 'platform-drivers-x86-v7.2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
platform/x86: asus-wmi: temporarily revert to setting a charge limit
platform/x86/intel/vsec: free ACPI discovery data on early errors
Merge the introduction of acpi_dev_is_video_device() along with some
following driver updates related to it (from Andy Shevchenko).
* acpi-video:
platform/x86: thinkpad_acpi: Convert to use acpi_dev_is_video_device() helper
PCI/VGA: Convert to use acpi_dev_is_video_device() helper
i2c: acpi: Convert to use acpi_dev_is_video_device() helper
ACPI: video: Convert to use acpi_dev_is_video_device() helper
ACPI: scan: Convert to use acpi_dev_is_video_device() helper
ACPI: utils: Introduce acpi_dev_is_video_device() helper
WMI_gaming_execute_u32_u64() returns success when firmware supplies
no output object, leaving the caller output untouched. Gaming getters
then inspect an uninitialized result value.
When the caller requests an output value, return -ENOMSG if firmware
supplies no object. Preserve a NULL output pointer as the supported way
for callers to ignore the result.
Fixes: 2d76708c22 ("platform/x86: acer-wmi: use WMI calls for platform profile handling")
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
Link: https://patch.msgid.link/20260701164208.8998-1-alhouseenyousef@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
pmc_core_pmt_get_lpm_req() returns the last telemetry read status. When
firmware exposes no enabled low-power modes, the loop does not run
and the function returns an uninitialized stack value.
Initialize the status to success so an empty mode set is handled
deterministically.
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
Reviewed-by: David E. Box <david.e.box@linux.intel.com>
Link: https://patch.msgid.link/20260630105101.54016-1-alhouseenyousef@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Add 2 of the new feature defines, UNIWILL_FEATURE_AC_AUTO_BOOT and
UNIWILL_FEATURE_USB_POWERSHARE, to TUXEDO devices where applicable.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Link: https://patch.msgid.link/20260708211950.568799-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>
The ThinkPad T14 Gen 2 AMD was sold under two machine types, 20XK and
20XL, but only 20XK has been in the s2idle quirk list since the quirk
was introduced in commit 455cd867b8 ("platform/x86: thinkpad_acpi:
Add a s2idle resume quirk for a number of laptops").
On 20XL machines the firmware SMI handler therefore still runs on the
NVMe D3->D0 transition when exiting suspend-to-idle. With IOMMU
translation enabled (the default), this intermittently stalls resume
for ~10.25 seconds: seven devices across three root ports (nvme, both
xhci_hcd functions, xhci-pci-renesas, snd_hda_intel x2, snd_rn_pci_acp3x)
block in pci_pm_resume_noirq and are released simultaneously, consistent
with all cores being held in SMM.
Add the missing 20XL machine type, mirroring the existing 20XK entry.
This is the same class of omission fixed by commit 9a469c6dfa
("platform/x86: thinkpad_acpi: Add missing T14s Gen1 type to s2idle
quirk list").
Verified on a ThinkPad T14 Gen 2a (type 20XLS41C00, BIOS R1MET62W 1.32,
kernel 6.12.95): with this entry the quirk message appears at probe and
a 14-hour suspend resumes in ~1s with no noirq stalls, where previously
even short suspends could hit the ~10s delay. A further two-day soak
(short naps and two ~14-hour suspends) showed every resume clean.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221755
Signed-off-by: Yap Weei Choong <ywc8891@gmail.com>
Tested-by: Yap Weei Choong <ywc8891@gmail.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260717060744.1252065-2-ywc8891@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Replace open coded variant of acpi_dev_is_video_device() helper.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://patch.msgid.link/20260714185915.865396-7-andriy.shevchenko@linux.intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The dedicated "ProArt" key on the ASUS ProArt PX13 (HN7306) emits ASUS
WMI event code 0x8b. This code is absent from the asus-nb-wmi sparse
keymap, so pressing the key only produces a "Unknown key code 0x8b"
message and does nothing in userspace.
On this model the key is exposed solely through the WMI interface and has
no HID scancode, so it can only be handled inside asus-nb-wmi. Map 0x8b
to KEY_PROG3 so the key emits a bindable event, consistent with the
existing KEY_PROG3 mapping used for the ASUS programmable/Armoury key.
Signed-off-by: Nizar Al-Kabbani <nizar.m.kabbani@gmail.com>
Reviewed-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260719090843.66777-1-nizar.m.kabbani@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Having a ad-hoc device whitelist inside uniwill_kbd_led_init()
to work around unreliable KBD_WHITE_ONLY values conflicts with
the idea of the device descriptor infrastructure.
Remove the ad-hoc device whitelist and use the device descriptor
infrastructure instead.
Suggested-by: Werner Sembach <wse@tuxedocomputers.com>
Reviewed-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260720132611.374073-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 function uniwill_kbd_led_init() is quite large and doing multiple
things at once:
- general hardware initialisation
- single color keyboard backlight registration
- RGB keyboard backlight registration
Move the last two things into separate functions to increase the
maintainability of uniwill_kbd_led_init().
Suggested-by: Werner Sembach <wse@tuxedocomputers.com>
Reviewed-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260720132611.374073-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>
On systems where the USCS ACPI method is absent, acpi_evalf() returns
AE_NOT_FOUND which maps to -EIO. This caused tpacpi_usbc_security_init()
to propagate the error and thinkpad_acpi failed to probe entirely on
unsupported platforms.
Fix this by checking for USCS method presence with acpi_has_method() before
attempting to call it, returning -ENODEV immediately if absent.
This follows the same pattern used by other subdrivers in thinkpad_acpi.c.
Fixes: 67e8d1e9cacd ("platform/x86: thinkpad_acpi: Add USB-C Security (USCS) support")
Reported-by: Oliver Lin <oliver@liuxiaozhen.dev>
Closes: https://lore.kernel.org/platform-driver-x86/239c8162-e1e6-4b49-8292-35547c5a525c@liuxiaozhen.dev/
Tested-by: Oliver Lin <oliver@liuxiaozhen.dev>
Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
Link: https://patch.msgid.link/20260715010205.514132-1-vishnuocv@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Creating a software node for a given set of properties and adding it to
a platform device can be achieved with a single call to
platform_device_register_full(). There's nothing in this driver that
suggests using the more fine-grained interfaces was intentional so
switch to using the high-level helper.
Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260716-swnode-remove-on-dev-unreg-v8-2-5c2b8cc38c28@oss.qualcomm.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Commit 833740a233 ("platform/chrome: sensorhub: Bound the EC-reported
sensor number") evaluated the `sensor_num` against the bounds limit even
for timestamp events. A timestamp event typically has a `sensor_num` of
0xff [1], causing the driver to flag it as invalid and skip to the next
event.
As a result, we'd see a flooding of "Invalid sensor number 255 from EC"
warning logs and these timestamp events were being dropped.
Move the bounds-check into cros_ec_sensor_ring_process_event() and
evaluate it only after standalone timestamp events have already been
processed and returned early.
[1] https://crrev.com/219ca6ef82ba266da788b673ee4ad50bd3ea1285/common/motion_sense_fifo.c#427
Fixes: 833740a233 ("platform/chrome: sensorhub: Bound the EC-reported sensor number")
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20260715024454.4127571-1-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
intel_vsec_add_dev() may attach an ACPI discovery table copy to the
intel_vsec_device before passing ownership to intel_vsec_add_aux(). The
normal auxiliary-device release path frees that copy, but the earliest
intel_vsec_add_aux() failures free only the outer structure directly.
Route those direct frees through a common helper so acpi_disc is
released consistently on the parent, xarray, and ID allocation failure
paths.
Fixes: 22fa2ebc11 ("platform/x86/intel/vsec: Plumb ACPI PMT discovery tables through vsec")
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
Reviewed-by: David E. Box <david.e.box@linux.intel.com>
Link: https://patch.msgid.link/CAMuQ4bUtJtYNTguKoiXngROJw0QQQcrvW3=3_B0-hpMQOFqvCQ@mail.gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Fixes
- amd/pmc:
- Use correct IP block table for AMD 1Ah M80H SoC
- Avoid logging "(null)" for missing DMI values
- asus-armoury: update power limits for G614PR
- bitland-mifs-wmi: Fix NULL pointer dereference during suspend/resume
The following is an automated shortlog grouped by driver:
amd/pmc:
- Avoid logging "(null)" for DMI values
amd-pmc:
- Use correct IP block table for AMD 1Ah M80H SoC
asus-armoury:
- update power limits for G614PR
bitland-mifs-wmi:
- Fix NULL pointer dereference during suspend/resume
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQSCSUwRdwTNL2MhaBlZrE9hU+XOMQUCalDWfQAKCRBZrE9hU+XO
MRg6AQClzm56cAKihLDveRd1iQxSK1SC5SR1ZlAsrUiH1iIClQEAr/e8V0Ax8On+
O7nhuR6Jh4nWuLijj+BuCfhg3D88yg0=
=CBFq
-----END PGP SIGNATURE-----
Merge tag 'platform-drivers-x86-v7.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
Pull x86 platform driver fixes from Ilpo Järvinen:
- amd/pmc:
- Use correct IP block table for AMD 1Ah M80H SoC
- Avoid logging "(null)" for missing DMI values
- asus-armoury: update power limits for G614PR
- bitland-mifs-wmi: Fix NULL pointer dereference during suspend/resume
* tag 'platform-drivers-x86-v7.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
platform/x86: amd-pmc: Use correct IP block table for AMD 1Ah M80H SoC
platform/x86: asus-armoury: update power limits for G614PR
platform/x86: bitland-mifs-wmi: Fix NULL pointer dereference during suspend/resume
platform/x86/amd/pmc: Avoid logging "(null)" for DMI values
Ahead of reworking the reference counting logic for platform devices,
encapsulate the assignment of the firmware node for dynamically allocated
platform devices with the provided helper.
Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260706-pdev-fwnode-ref-v3-16-1ff028e33779@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since every platform driver can be forced to match a device that doesn't
match its list of device IDs because of device_match_driver_override(),
platform drivers that rely on the existence of a device's ACPI companion
object should verify its presence.
san_probe() dereferences the result of ACPI_COMPANION() when installing
the GSBUS address space handler, so force-binding the driver to a device
without an ACPI companion leads to a NULL pointer dereference. The
dereference was introduced when the probe function was switched from
ACPI_HANDLE() to ACPI_COMPANION().
Check the ACPI companion against NULL and return -ENODEV when it is
missing, like commit e4865a56d0 ("ACPI: driver: Check ACPI_COMPANION()
against NULL during probe") does for the core ACPI platform drivers.
Fixes: a9e10e5873 ("ACPI: scan: Extend acpi_walk_dep_device_list()")
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
Link: https://patch.msgid.link/20260706012512.524359-2-lilinmao@kylinos.cn
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
mlxbf_pmc_probe() passes the result of ACPI_COMPANION() to
acpi_device_hid(), which dereferences it, so force-binding the driver to
a device without an ACPI companion leads to a NULL pointer dereference.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
mlxbf-pmc driver and return -ENODEV when the companion is missing.
Fixes: 1a218d312e ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver")
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
Link: https://patch.msgid.link/20260706012056.524096-1-lilinmao@kylinos.cn
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
During driver initialization in asus_wmi_add(), various subsystems are
registered sequentially. However, the error path labels are out of order
relative to the registration sequence.
Specifically:
1. If asus_wmi_custom_fan_curve_init() fails, the driver jumps to
fail_custom_fan_curve. Because this label is placed below fail_sysfs,
it bypasses the cleanup calls for the input device and sysfs groups,
which were successfully registered before, leaking those resources.
2. If asus_screenpad_init() fails, the driver jumps to fail_screenpad.
Because fail_screenpad is placed below fail_backlight, it bypasses the
cleanup calls for backlight and rfkill, leaking those resources.
Fix these resource leaks by reordering the error path labels in
asus_wmi_add() to match the exact reverse order of the resource
allocations.
Fixes: 0f0ac158d2 ("platform/x86: asus-wmi: Add support for custom fan curves")
Fixes: 2c97d3e55b ("platform/x86: asus-wmi: add support for ASUS screenpad")
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
Link: https://patch.msgid.link/20260617155104.10111-1-scardracs@disroot.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Implement the ioctl handler for the util layer character device. This
support adds the actual functionality to populate PMF metrics from the
TA shared memory buffer and return them to userspace.
The implementation includes:
- amd_pmf_populate_data() to extract metrics from TA shared memory
- amd_pmf_set_ioctl() to handle userspace ioctl requests
- Size negotiation for forward/backward compatibility
- Feature-based population of struct fields
- Export amd_pmf_get_ta_custom_bios_inputs()
Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com>
Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260609081044.2416731-6-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>
These debug helper functions convert enumerated values to appropriate
message and can be useful for userspace tools and other kernel components
that need to interpret AMD PMF state values.
By making them inline functions in the UAPI header, they become available
to both kernel and userspace without code duplication. Also, prefix the
function names with amd_pmf_.
Also, include a case to cover unused enum entries.
Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com>
Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260609081044.2416731-5-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>
Relocate commonly used enums from multiple source files into a shared
header file to simplify code structure, improve readability, and
enhance maintainability. Also, remove the initialization of the first
enum member, since it is not needed.
Add the AMD_PMF_ prefix to the laptop_placement and platform_type enums
since these names are overly generic for inclusion in a UAPI header
Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com>
Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260609081044.2416731-4-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>
Add a bios_output[] to amd_pmf_dev struct and store the latest values for
BIOS output policies when applying PMF policies. This enables the AMD PMF
util layer to expose these BIOS outputs alongside selected thermal and
power metrics to user space via /dev/amdpmf_interface and a new IOCTL,
supporting real-time monitoring tools such as SystemDeck.
Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com>
Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260609081044.2416731-3-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>
Add a util layer to AMD PMF that exposes a minimal userspace interface
via a character device for metrics monitoring and feature discovery.
This creates /dev/amdpmf_interface with basic ioctl support to retrieve
PMF metrics such as:
* Power source and power slider position
* Platform type, lid state, and user presence
* Skin temperature and ambient light
* BIOS input parameters (1-10)
* Graphics workload metrics
* CPU C-state residency (average and maximum)
* Socket power consumption
* Auto Mode: Automatic power profile switching based on system activity
* Static Power Slider: User-selectable power profiles
* Policy Builder (Smart PC): Action based policy management
* Dynamic Power Slider AC: Adaptive power profiles when on AC power
* Dynamic Power Slider DC: Adaptive power profiles when on battery
The interface enables smoother integration with userspace tools such as
AMD SystemDeck [1], which is widely used for monitoring and controlling
power and thermal behavior on AMD platforms. These tools help designers
keep major components within thermal limits to ensure proper operation
and enhance overall system stability and reliability.
The feature is gated behind the CONFIG_AMD_PMF_UTIL_SUPPORT Kconfig
option, allowing it to be disabled if not needed. The implementation
uses existing PMF infrastructure to populate data from the TA (Trusted
Application) shared memory buffer.
Link: https://docs.amd.com/v/u/en-US/68773_0.50 [1]
Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com>
Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20260609081044.2416731-2-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>
Every platform driver can be forced to match a device that does not match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device ACPI companion
object need to verify its presence.
asus_wireless_probe() returns success when acpi_match_acpi_device()
finds no match, leaving behind an input device that never reports
anything because the notify handler is not installed. Worse, when the
driver is force-bound to a device without an ACPI companion, probe
still succeeds and stores a NULL companion pointer, which
asus_wireless_remove() later passes to acpi_dev_remove_notify_handler(),
leading to a NULL pointer dereference on unbind.
Return -ENODEV when the device does not match the ID table. This also
covers the missing-companion case, because acpi_match_acpi_device()
rejects a NULL device. Perform the check before allocating any driver
state, instead of after the input device has already been registered.
Fixes: f7e648027d ("platform/x86: asus-wireless: Convert ACPI driver to a platform one")
Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
Link: https://patch.msgid.link/20260710094355.186143-1-lilinmao@kylinos.cn
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The Halo Box features an RGB LED light bar that can be controlled
through WMI methods to display any color combination.
The driver exposes the LED through the LED multicolor subsystem,
allowing userspace to control RGB values via sysfs:
/sys/class/leds/amd_halo:multicolor:status/multi_intensity
/sys/class/leds/amd_halo:multicolor:status/brightness
Hardware interface:
- Three separate RGB channels (Red, Green, Blue)
- All 3 channels are configured at once with a single WMI method call
- Value range: 0-100 (matching hardware range directly)
Co-developed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Yo-Jung Leo Lin (AMD) <Leo.Lin@amd.com>
Link: https://patch.msgid.link/20260709-halo-leds-v2-plus-v8-1-b34c64277193@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
hp_populate_enumeration_elements_from_package() returns -EIO and aborts
enumeration of the entire attribute when any single element has an
unexpected ACPI type. This is observed on HP EliteBook 840 G2 when the
BIOS returns malformed ACPI data following a failed WMI query:
ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Index (0x000000032)
is beyond end of object (length 0x32)
ACPI Error: Aborting method \_SB.WMID.WQBE due to previous error
Error expected type 2 for elem 13, but got type 1 instead
hp_bioscfg: Returned error 0x3,
"Invalid command value/Feature not supported"
Aborting immediately discards the attribute entirely.
Warn about the unexpected element type, free the temporary string, skip
the offending element, and continue parsing the remaining package
instead of failing the whole attribute.
Fixes: a34fc329b1 ("platform/x86: hp-bioscfg: bioscfg")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260709165900.30615-5-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_init_bios_package_attribute() hard-fails when a WMI ACPI package
contains fewer elements than the type-specific expected count (e.g. 11
elements instead of 13 for INTEGER or ENUMERATION attributes). This
causes the entire hp_bioscfg driver to skip attribute enumeration on
older HP hardware whose BIOS returns shortened packages when optional
fields like prerequisites or possible values are absent.
Observed on HP EliteBook 840 G2 (BIOS M71 Ver. 01.31):
hp_bioscfg: ACPI-package does not have enough elements: 11 < 13
The element layout has two tiers:
- Elements 0-9 (SECURITY_LEVEL+1 = 10): common to all attribute types
- Elements 10-N: type-specific (bounds, values, encodings, ...)
The per-type populate functions (hp_populate_*_elements_from_package)
already handle sparse packages correctly via their own elem < count
loop guards and inner-loop bounds checks. The only unsafe case is when
we lack even the common elements needed to register the attribute.
Fix by introducing COMMON_ELEM_CNT to mark the hard minimum (10), and
splitting the check into two tiers:
- Fewer than COMMON_ELEM_CNT elements: hard fail, can't proceed.
- Fewer than expected type-specific elements: warn, but let the
populate function parse what is available.
Fixes: a34fc329b1 ("platform/x86: hp-bioscfg: bioscfg")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260709165900.30615-4-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_ordered_list_elements_from_package() differs from the other
per-type parsers: its main loop is bounded only by the fixed per-type
count and never checks elem against the number of elements actually
present in the package,
for (elem = 1, eloc = 1; eloc < ORD_ELEM_CNT; elem++, eloc++)
whereas the string, integer, enumeration and password parsers bound
their main loop with "elem < count" as well.
This is safe today because hp_init_bios_package_attribute() rejects any
package with fewer than ORD_ELEM_CNT elements before the parser runs.
An upcoming change, however, relaxes that check to accept shorter
packages.
Bound the loop by the validated element count as well, so it stops at
whichever comes first, the per-type count or the real package size,
for (elem = 1, eloc = 1; eloc < ORD_ELEM_CNT && elem < order_obj_count;
elem++, eloc++)
order_obj_count is the validated element count, now correctly forwarded
from the caller. No functional change for packages that enumerate
correctly today.
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://patch.msgid.link/20260709165900.30615-3-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The per-type package parsers are handed the wrong element count.
hp_init_bios_package_attribute() validates obj->package.count and then
calls one of the five hp_populate_*_package_data() wrappers (string,
integer, enumeration, ordered list, password). Each wrapper forwards a
count to its hp_populate_*_elements_from_package() parser, but instead
of forwarding the validated obj->package.count it derives the count
from elements[0]. elements[0] is the NAME field and is always an
ACPI_TYPE_STRING, so reading ->package.count from it in fact reads
->string.length through the union acpi_object. The parsers thus bound
themselves against the length of the name string rather than against
the real number of elements in the package.
This is safe today because hp_init_bios_package_attribute() refuses any
package that has fewer than the type's element count, so a parser only
ever runs on a full package and never reads past it regardless of the
bogus bound.
An upcoming change relaxes that check to accept shorter packages. Once
a parser can receive fewer elements than its per-type count, a bound
taken from the name length no longer reflects the array size, and the
"elem < count" loop conditions and "elem + n >= count" sub-loop guards
read past the end of elements[] - an out-of-bounds heap read.
Forward the validated obj->package.count to every *_package_data()
wrapper so the parsers bound themselves against the real package size.
This does not change behaviour for the packages that enumerate
correctly today and is a prerequisite for accepting shorter packages
safely.
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://patch.msgid.link/20260709165900.30615-2-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
ecl_ishtp_cl_probe() acquires a reference to an ACPI device via
acpi_find_eclite_device() but fails to release it in the error path
when acpi_opregion_init() fails. This results in a reference count
leak, preventing proper cleanup of the ACPI device.
Calling path: acpi_find_eclite_device() ->
acpi_dev_get_first_match_dev() -> acpi_dev_get_next_match_dev() ->
bus_find_device() -> get_device().
Found by code review.
Signed-off-by: Ma Ke <make_ruc2021@163.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: stable@vger.kernel.org
Fixes: 7b6bf51de9 ("platform/x86: Add Intel ishtp eclite driver")
Link: https://patch.msgid.link/20260624014910.1226446-1-make_ruc2021@163.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The driver sets acpi_device_name() to initialize an input class device
name initialization and print a message on probe success, but the input
class device name can be set directly to the "Surface Pro 3/4 Buttons"
string literal and used for printing the message.
Make the driver do so, stop setting acpi_device_name() in it and drop
the symbol specifically defined for this purpose.
No intentional functional impact.
This will facilitate the removal of device_name from struct
acpi_device_pnp in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Chen Yu <yu.c.chen@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/12927239.O9o76ZdvQC@rafael.j.wysocki
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Currently, manual fan control on supported HP models uses a single
PWM value for both CPU and GPU fans, linking their speeds via a hardcoded
gpu_delta offset. This prevents userspace tools from managing the thermal
profiles of the CPU and GPU independently.
Refactor the hwmon implementation to support independent dual-channel
PWM control:
- Split the single 'pwm' state into 'cpu_pwm' and 'gpu_pwm'.
- Expose a second PWM channel ('pwm2') to userspace via hwmon_channel_info.
- Remove the gpu_delta mechanism entirely.
The 'pwm1_enable' mode remains shared, as the underlying hardware does
not support per-fan modes. When switching to manual mode, both fans are
smoothly initialized to their current RPMs. Additionally, ensure that
the HP_FAN_SPEED_AUTOMATIC flag is isolated from rpm_to_pwm mathematical
interpolations during mode resets to prevent unintended fan states.
Tested on: HP Victus 16-s0xxx
Tested-by: Radhey Kalra <radheykalra901@gmail.com>
Signed-off-by: Kürşat Abaylı <hello@kursatabayli.dev>
Link: https://patch.msgid.link/20260707203740.55369-1-hello@kursatabayli.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Convert init_rog_tunables() to use the cleanup infrastructure to
automatically free ac_rog_tunables if dc_rog_tunables allocation fails.
By declaring local pointers with the __free(kfree) attribute, the
manual kfree() in the error path can be removed. Upon successful
initialization, the ownership is transferred to the global struct
using no_free_ptr().
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
Link: https://patch.msgid.link/20260707213741.6515-3-scardracs@disroot.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
In init_rog_tunables(), if dc_limits are defined and allocating
dc_rog_tunables fails, the already allocated ac_rog_tunables gets
freed but the pointer stored in
asus_armoury.rog_tunables[ASUS_ROG_TUNABLE_AC] is not cleared. Since
init_rog_tunables() returns void, the driver initialization continues,
which can lead to a Use-After-Free (UAF) when asus_fw_attr_add()
accesses the freed AC tunables pointer.
Additionally, if init_rog_tunables() succeeds but asus_fw_attr_add()
fails, the allocated tunables are not freed, resulting in a memory leak.
Fix these issues by making init_rog_tunables() return an error code and
propagating it in asus_fw_init(). Defer setting the global pointers in
asus_armoury.rog_tunables until both tunables have been successfully
allocated. If asus_fw_attr_add() fails, release the allocated resources
using a standard goto rollback block in asus_fw_init().
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
Link: https://patch.msgid.link/20260707213741.6515-2-scardracs@disroot.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
On the LG Gram 16T90SP, the ACPI firmware will only accept the values
0x80, 0xA2 and 0xA4 when setting the keyboard backlight. After a bit
of research using ACPI tables from older models it seems that bit 8
is supposed to be always written as 1.
Fix the keyboard backlight support on this model by always setting
bit 8 inside the argument passed to the WMAB ACPI control method.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260708195553.7762-6-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The WMAB ACPI control method can return two kinds of results:
1. A ACPI integer containing the result.
2. A ACPI buffer containing the result and an error code.
Devices implement one of those mechanisms, but not both. Extend
lg_wmab() to abstract away the differences between both mechanisms
to fix keyboard backlight support on newer devices.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260708195553.7762-5-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
LG devices support two interfaces for receiving events:
- the WMI-based interface currently being used by the driver
- a ACPI-based interface similar to the WMI-based interface
Older devices use the WMI-based interface by default and need
to be manually switched into ACPI mode. Newer devices however
only support the ACPI-based interface, preventing the current
driver from receiving events on them.
Fix this by always using the native ACPI-based interface for
receiving events.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260708195553.7762-3-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The event notification callback might access kbd_backlight even
when it was not successfully registered with the LED subsystem.
The same happens inside acpi_remove(), where the LED devices are
unregistered unconditionally.
Fix this by tracking the availability of the kbd_backlight LED
device and use devm_led_classdev_register() to let devres take
care of unregistering the LED devices during removal. For this
the parent device of the LED devices is changed to the native
platform device.
Fixes: ae26278829 ("platform/x86: lg-laptop: Use correct event for keyboard backlight FN-key")
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260708195553.7762-2-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Newer ThinkPad systems expose a USB-C Security (Restricted Mode) feature.
When active, USB-C data connections are disabled while power delivery is
preserved. This is useful for kiosk and physically-secured deployments.
Hardware interface:
The HKEY device exposes a read-only ACPI method USCS():
Return value bit layout:
Bit 16 : Capability flag (1 = feature present on this SKU)
Bit 0 : Current state (0 = security OFF, 1 = security ON)
The sysfs attribute is read-only.
The Fn+U followed by Fn+S hotkey chord is the only way to toggle the
hardware state.
Hotkey:
Fn+U followed by Fn+S generates HKEY event 0x131e.
sysfs interface:
/sys/devices/platform/thinkpad_acpi/usb_c_security (read-only)
"enabled\n" -- data connections are currently blocked
"disabled\n" -- data connections are currently allowed
The attribute is hidden on SKUs where the USCS capability bit (bit 16)
is not set, so there is no ABI impact on unsupported hardware.
Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
Link: https://patch.msgid.link/20260709021504.465792-1-vishnuocv@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Add power limits quirk entry for ASUS ROG FA608WV laptop.
The limits are extracted from the device's ThrottleGear XML configuration
file for the 'Ryzen' profile.
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
Link: https://patch.msgid.link/20260701164003.4271-1-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 TDP data for laptop models HN7306EA and HN7306EAC.
Signed-off-by: Flávio Barroso Neves <flaviobn@gmail.com>
Link: https://patch.msgid.link/20260705195126.17120-1-flaviobn@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
