Johannes Berg [Tue, 28 Apr 2026 08:36:49 +0000 (10:36 +0200)]
wifi: mac80211: move frame RX handling to type files
The interface frame queue processing code currently
differentiates many frame types and below those the
interface types, but then falls through to per-type
processing. Move this code to the per-type functions,
creating a new ap.c file that gets relevant code, and
this way reduce the number of non-static symbols.
This also helps with adding more cases for UHR later.
wifi: mac80211_hwsim: Add support for extended FTM ranging
Introduce support for continuous ranging and advanced timing
parameters in the FTM request, response, and capability paths.
This enables more flexible ranging scenarios with improved control
over measurement timing and session management.
Frank Li [Mon, 4 May 2026 23:54:39 +0000 (19:54 -0400)]
pinctrl: add generic board-level pinctrl driver using mux framework
Many boards use on-board mux chips (often controlled by GPIOs from an I2C
expander) to switch shared signals between peripherals.
Add a generic pinctrl driver built on top of the mux framework to
centralize mux handling and avoid probe ordering issues. Keep board-level
routing out of individual drivers and supports boot-time only mux
selection.
Ensure correct probe ordering, especially when the GPIO expander is probed
later.
Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
Frank Li [Mon, 4 May 2026 23:54:38 +0000 (19:54 -0400)]
pinctrl: add optional .release_mux() callback
Add an optional .release_mux() callback to struct pinmux_ops.
Some drivers acquire additional resources in .set_mux(), such as software
locks. These resources may need to be released when the mux function is no
longer active. Introducing a dedicated .release_mux() callback allows
drivers to clean up such resources.
The callback is optional and does not affect existing drivers.
Commit 2243a87d90b42 ("pinctrl: avoid duplicated calling
enable_pinmux_setting for a pin") removed the .disable() callback
to resolve two issues:
Adding .release_mux() does not reintroduce those problems. The callback is
intended only for releasing driver-side resources (e.g. locks) and must not
modify hardware registers.
Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
Frank Li [Mon, 4 May 2026 23:54:37 +0000 (19:54 -0400)]
pinctrl: extract pinctrl_generic_to_map() from pinctrl_generic_pins_function_dt_node_to_map()
Refactor pinctrl_generic_pins_function_dt_subnode_to_map() by separating DT
parsing logic from map creation. Introduce a new helper
pinctrl_generic_to_map() to handle mapping to kernel data structures, while
keeping DT property parsing in the subnode function.
Improve code structure and enables easier reuse for platforms using
different DT properties (e.g. pinmux) without modifying the
dt_node_to_map-style callback API. Avoid unnecessary coupling to
pinctrl_generic_pins_function_dt_node_to_map(), which provides
functionality not needed when the phandle target is unambiguous.
Maximize code reuse and provide a cleaner extension point for future
pinctrl drivers.
Suggested-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
Frank Li [Mon, 4 May 2026 23:54:36 +0000 (19:54 -0400)]
dt-bindings: pinctrl: Add generic pinctrl for board-level mux chips
Add a generic pinctrl binding for board-level pinmux chips that are
controlled through the multiplexer subsystem.
On some boards, especially development boards, external mux chips are used
to switch SoC signals between different peripherals (e.g. MMC and UART).
The mux select lines are often driven by a GPIO expander over I2C,
as illustrated below:
Traditionally, gpio-hog is used to configure the onboard mux at boot.
However, the GPIO expander may probe later than consumer devices such as
MMC. As a result, the MUX might not be configured when the peripheral
driver probes, leading to initialization failures or data transfer errors.
Introduce a generic pinctrl binding that models the board-level MUX as a
pin control provider and builds proper device links between the MUX, its
GPIO controller, and peripheral devices. This ensures correct probe
ordering and reliable mux configuration.
The implementation leverages the standard multiplexer subsystem, which
provides broad support for onboard mux controllers and avoids the need for
per-driver custom MUX handling.
Allow pinctrl-* pattern as node name because this pinctrl device have not
reg property.
Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
drm/panel: himax-hx83102: restore MODE_LPM after sending disable cmds
When preparing the panel, it seems that it always expects commands to be
transferred in LP mode. However, the disable function removes the
MIPI_DSI_MODE_LPM flag, and no other function re-adds it.
As the unprepare function contains no DSI commands, re-adding the flag
just after disabling the panel should be safe. Add the code re-adding
the flag after the two commands for disabling the panel are sent.
This fixes screen unblanking (after blanking once) on
mt8188-geralt-ciri-sku1 device.
Cc: stable@vger.kernel.org # 6.11+ Fixes: 0ef94554dc40 ("drm/panel: himax-hx83102: Break out as separate driver") Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260425165751.1716569-1-zhengxingda@iscas.ac.cn
Icenowy Zheng [Sun, 3 May 2026 09:17:08 +0000 (17:17 +0800)]
drm/panel: boe-tv101wum-nl6: restore MODE_LPM after sending disable cmds
When preparing the panel, it seems that it always expects commands to be
transferred in LP mode. However, the disable function removes the
MIPI_DSI_MODE_LPM flag, and no other function re-adds it.
As the unprepare function contains no DSI commands, re-adding the flag
just after disabling the panel should be safe. Add the code re-adding
the flag after the two commands for disabling the panel are sent.
This fixes error messages shown in kernel log when unblanking on
mt8183-kukui-kodama-sku32 device.
Cc: stable@vger.kernel.org Fixes: a869b9db7adf ("drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panel") Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260503091708.1079962-1-zhengxingda@iscas.ac.cn
Like a number of other panel drivers, this newly merged driver
needs DRM_DISPLAY_DSC_HELPER to be enabled:
arm-linux-gnueabi-ld: drivers/gpu/drm/panel/panel-himax-hx83121a.o: in function `himax_prepare':
panel-himax-hx83121a.c:(.text+0x1024): undefined reference to `drm_dsc_pps_payload_pack'
Fixes: a7c61963b727 ("drm/panel: Add Himax HX83121A panel driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: David Heidelberg <david@ixit.cz> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260413071043.3829868-1-arnd@kernel.org
Chen Ni [Fri, 27 Mar 2026 02:17:28 +0000 (10:17 +0800)]
drm/panel: himax-hx83121a: Fix incorrect error check for devm_drm_panel_alloc()
Check devm_drm_panel_alloc() return value for ERR_PTR instead of NULL.
devm_drm_panel_alloc() returns an ERR_PTR on failure, never NULL. Using
a NULL check skips the error path and may cause a NULL pointer
dereference.
Fixes: a7c61963b727 ("drm/panel: Add Himax HX83121A panel driver") Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Reviewed-by: Pengyu Luo <mitltlatltl@gmail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260327021728.647182-1-nichen@iscas.ac.cn
====================
first series for xpcs based rsfec configuration
The series:
- Fixes an addr validation error
- Adds MDIO defines associated with RS-FEC
- consolidates the handling of the boilerplat ID registers
into a routine to report id'ish registers and reduces the lines
of code across the entire set of c45 routines.
- adds PMA read/write routines
https://lore.kernel.org/all/20260428172810.175077-2-mike.marciniszyn@gmail.com/
has been removed from the series and submitted to net as
https://lore.kernel.org/all/20260429150049.1643-1-mike.marciniszyn@gmail.com/
pcs reads for DEVS1 and DEVS2 cleaned up 2/3
====================
Document the MDIO interface topology with an ASCII diagram
showing the MAC, PCS (MMD 3), FEC, Separated PMA (MMD 8), and PMD
(MMD 1) blocks and their interconnects. The diagram illustrates how
4 lanes connect the MAC through PCS, FEC, and PMA, then narrow to
2 lanes at the PMD.
The c45 read and write routines are enhanced to support
read and write of the separated PMA for the fbnic.
Co-developed-by: Alexander Duyck <alexanderduyck@fb.com> Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Signed-off-by: Mike Marciniszyn (Meta) <mike.marciniszyn@gmail.com> Link: https://patch.msgid.link/20260430150802.3521-4-mike.marciniszyn@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
net: eth: fbnic: Consolidate register reads for ids and devs
Consolidate the register reads for boiler plate registers
to reduce LOC and cleanup pcs reads for DEVS1 to
fetch overrides for reserved bits that the hardware does not
return.
The RK3588 MIPI CSI-2 receivers are compatible to the ones found in the
RK3568. Introduce a list of compatible variants and add the RK3588 variant
to it.
Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Michael Riesch <michael.riesch@collabora.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
media: intel/ipu6: Improve DWC PHY HSFREQRANGE band selection for overlapping ranges
The get_hsfreq_by_mbps() function searches the freqranges[] table
backward (from highest to lowest index). Because adjacent frequency
bands overlap, a data rate that falls in the overlap region always
lands on the higher-indexed band.
For data rates up to 1500 Mbps (index 42) every band uses
osc_freq_target 335. Starting at index 43 (1461-1640 Mbps) the
osc_freq_target drops to 208. A sensor running at 1498 Mbps sits in
the overlap between index 42 (1414-1588, osc 335) and index 43
(1461-1640, osc 208). The backward search picks index 43, programming
the lower osc_freq_target of 208 instead of the optimal 335.
This causes DDL lock instability and CSI-2 CRC errors on affected
configurations, such as the OmniVision OV08X40 sensor on Intel Arrow
Lake platforms (Dell Pro Max 16).
Rewrite get_hsfreq_by_mbps() to select the optimal band:
1. Among bands whose min/max range covers the data rate, prefer
the one with the higher osc_freq_target.
2. If osc_freq_target is equal, prefer the band whose default_mbps
is closest to the requested rate.
Since the frequency ranges are monotonically increasing, the loop
exits early once min exceeds the requested rate.
For 1498 Mbps this now correctly selects index 42 (osc_freq_target
335, range 1414-1588) instead of index 43 (osc_freq_target 208,
range 1461-1640).
Fixes: 1e7eeb301696 ("media: intel/ipu6: add the CSI2 DPHY implementation") Cc: stable@vger.kernel.org Signed-off-by: Marco Nenciarini <mnencia@kcore.it> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Lian Xiangyu [Mon, 23 Mar 2026 17:31:40 +0000 (01:31 +0800)]
staging: media: ipu7: remove 'U' suffix from hexadecimal literals
The ipu7 driver's TODO specifies that the 'U' suffix should be
removed from hexadecimal values in register definitions.
This patch cleans up the definitions in the header files within the
ipu7 directory to comply with the requirements and improve consistency.
The modification was verified by comparing the disassembly of the
built-in.a archive before and after the change. The MD5 hashes of the
disassembly output remained identical, confirming that this is a
purely cosmetic cleanup with no functional impact on the binary.
Signed-off-by: Lian Xiangyu <lin25001x@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Alexandru Hossu [Mon, 13 Apr 2026 15:12:44 +0000 (17:12 +0200)]
staging: media: ipu7: fix double-free and use-after-free in error paths
In both ipu7_isys_init() and ipu7_psys_init(), pdata is allocated and
then passed to ipu7_bus_initialize_device(), which stores it in
adev->pdata. The ipu7_bus_release() function frees adev->pdata when the
device's reference count drops to zero.
Two error paths incorrectly call kfree(pdata) after the device teardown
has already freed it:
1. When ipu7_mmu_init() fails: put_device() is called, which drops the
reference count to zero and triggers ipu7_bus_release() ->
kfree(pdata). The subsequent kfree(pdata) is a double-free.
2. When ipu7_bus_add_device() fails: it calls auxiliary_device_uninit()
internally, which calls put_device() -> ipu7_bus_release() ->
kfree(pdata). The subsequent kfree(pdata) is again a double-free.
Note that the kfree(pdata) when ipu7_bus_initialize_device() itself
fails is correct, because in that case auxiliary_device_init() failed
and the release function was never set up, so pdata must be freed
manually.
Additionally, the error code was not saved before calling put_device(),
causing ERR_CAST() to dereference the already-freed adev pointer when
constructing the return value. Fix this by saving the error from
dev_err_probe() before put_device() and returning ERR_PTR() instead.
Remove the redundant kfree(pdata) calls and fix the use-after-free in
the return values of the two affected error paths.
Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver") Cc: stable@vger.kernel.org Reviewed-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Sakari Ailus [Thu, 26 Mar 2026 13:15:23 +0000 (15:15 +0200)]
media: dw9719: Add back the I²C device id table
The I²C device id table is necessary as the device may be, besides through
system firmware, also instantiated in the IPU bridge so matching takes
place using the I²C device id table. Add back the table, with ids for all
supported devices.
Reported-by: Michael Anthony <manthony.nw@outlook.com> Closes: https://lore.kernel.org/linux-media/AMBP190MB2678E7DC048409068260DCE8ED4AA@AMBP190MB2678.EURP190.PROD.OUTLOOK.COM/ Fixes: 15faf0fa1472 ("media: i2c: dw9719: Remove unused i2c device id table") Cc: stable@vger.kernel.org # for v6.19 and later Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
drm/i915: remove HAS_PCH_NOP() dependency from clock gating
intel_pch_init_clock_gating() already handles unsupported PCH types,
including PCH_NOP, by doing nothing.
Drop the explicit HAS_PCH_NOP() check from the IVB clock gating
path and always call the display helper directly. This removes one
more direct dependency on display-side PCH macros from
intel_clock_gating.c.
drm/i915/display: move HSW and BDW clock gating init to display
Move the HSW and BDW display clock gating programming into the display
code. In this case we need two different helpers, because the common
code between these two is split in the middle.
drm/i915/display: move GLK clock gating init to display
Move the GLK-specific display clock gating programming into display
intel_display_clock_gating.c, to remove more dependencies from i915 to
display registers.
Now that all remaining Gen9-family callers moved into display, we can
move the shared Gen9 display clock gating helper into display and
remove the old local helper from intel_clock_gating.c.
Additionally, the SKL_DE_COMPRESSED_HASH_MODE programming was
protected by HAS_LLC(), but that's incidental, because in Gen9
platforms, only SKL and KBL, for which this workaround applies, have
LLC(). In order not to use HAS_LLC() in display code, we can simply
remove this check from the generic Gen9 function and move the
SKL_DE_COMPRESSED_HASH_MODE programming to the KBL and SKL specific
functions. And, intentionally or not, CFL and CML were also using
this workaround, because they also have LLC, even though the comments
were only mentioning SKL and KBL. In order not to change anything
functionally with this patch, the workaround was also added to
intel_display_cfl_init_clock_gating().
drm/i915/display: move CFL clock gating init to display
Move the CFL/CML-specific display clock gating programming into
display intel_display_clock_gating.c, to remove more dependencies from
i915 to display registers.
Move the KBL-specific display clock gating programming into a
display intel_display_clock_gating.c, to remove more dependencies from
i915 to display registers.
ASoC: wm_adsp_fw_find_test: Clear searched_fw_files in find-by-index test
In wm_adsp_fw_find_test_find_firmware_byindex() the content of
priv->searched_fw_files must be cleared before starting the next iteration.
The files searched for are appended to priv->searched_fw_files, so if it is
not cleared on each iteration it will still contain the searches from the
previous iteration.
Redirect wm_adsp_release_firmware_files() to a replacement function that
handles the dummy firmware created by the tests. Use the same cleanup
function to cleanup in the test exit() function. Also call it on each
loop in wm_adsp_fw_find_test_find_firmware_byindex() to free the created
strings before reusing priv->found_fw on the next loop.
wm_adsp_release_firmware_files() will pass the struct firmware* pointers
to release_firmware(). But the pointers created by the tests are dummies
and must not be passed to release_firmware().
The test never invokes wm_adsp_release_firmware_files() so it wasn't
redirected. But the error handling in wm_adsp_request_firmware_files()
calls wm_adsp_release_firmware_files(). The redirected function makes
this safe.
Using the same cleanup function to perform cleanup from the test exit()
handler and wm_adsp_fw_find_test_find_firmware_byindex() avoids the risk
of duplicate cleanup code that all needs updating if there is any change
to the cleanup requirements.
This problem was found by https://sashiko.dev.
Fixes: bf2d44d07de7 ("ASoC: wm_adsp: Add kunit test for firmware file search") Closes: https://sashiko.dev/#/patchset/20260326100853.1582886-1-rf%40opensource.cirrus.com Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260505105123.3539778-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: rockchip: Move MODULE_DEVICE_TABLE next to the table itself
By convention MODULE_DEVICE_TABLE() immediately follows the ID table it
exports, because this is easier to read and verify. It also makes more
sense since #ifdef for ACPI or OF could hide both of them.
Most of the privers already have this correctly placed, so adjust
the missing ones. No functional impact.
ASoC: tegra: Move MODULE_DEVICE_TABLE next to the table itself
By convention MODULE_DEVICE_TABLE() immediately follows the ID table it
exports, because this is easier to read and verify. It also makes more
sense since #ifdef for ACPI or OF could hide both of them.
Most of the privers already have this correctly placed, so adjust
the missing ones. No functional impact.
regulator: palmas: Move MODULE_DEVICE_TABLE next to the table itself
By convention MODULE_DEVICE_TABLE() immediately follows the ID table it
exports, because this is easier to read and verify. It also makes more
sense since #ifdef for ACPI or OF could hide both of them.
Most of the privers already have this correctly placed, so adjust
the missing ones. No functional impact.
arm64: dts: ti: k3-j722s: Add wakeup domain peripherals specific to J722S
Introduce the "k3-j722s-mcu.dtsi" file to contain wakeup domain peripherals
that are specific to J722S SoC and are not shared with AM62P.
Previously, those nodes were squatting the k3-j722s-main.dtsi file which
should contain only main domain peripherals.
arm64: dts: ti: k3-j722s: Add mcu domain peripherals specific to J722S
Introduce the "k3-j722s-mcu.dtsi" file to contain mcu domain peripherals
that are specific to J722S SoC and are not shared with AM62P.
Previously, those nodes were squatting the k3-j722s-main.dtsi file which
should contain only main domain peripherals.
thunderbolt: Don't create multiple DMA tunnels on firmware connection manager
Firmware connection manager supports only one DMA tunnel per XDomain
connection. Firmware prior Intel Titan Ridge failed the operation
directly but the same does not happen anymore on Titan Ridge and
forward. For this reason add an explicit check, and fail the operation
accordingly in the driver.
Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Mika Westerberg [Thu, 6 Nov 2025 15:59:52 +0000 (17:59 +0200)]
thunderbolt: Remove XDomain from the bus without holding tb->lock
Currently we call device_unregister() for services and the XDomain
itself with tb->lock held. This prevents the service drivers from
calling any functions that may take it. For this reason separate
removing the XDomain from the topology data structures (where we need
the lock) from unregistering the device from the bus (where remove
callbacks of the drivers are being called).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Mika Westerberg [Mon, 8 Sep 2025 10:37:36 +0000 (13:37 +0300)]
thunderbolt: Remove service debugfs entries during unregister
We add them as part of the register path so to keep it symmetric remove
them as part of the unregister path. This also removes them even if the
service itself is not yet released (but is unregistered), thus allowing
new register with the same service name to happen.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Mika Westerberg [Fri, 24 Apr 2026 10:04:26 +0000 (13:04 +0300)]
thunderbolt: dma_test: No need to store debugfs directory pointer
We don't actually need to store the debugfs directory pointer inside
struct dma_test. Instead we can use the debugfs_lookup_and_remove()
which also handles the case if the debugfs directory is already removed
by the core driver (for example when cable is disconnected).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Mika Westerberg [Wed, 19 Nov 2025 10:53:58 +0000 (12:53 +0200)]
thunderbolt: Wait for tb_domain_release() to complete when driver is removed
We should not call nhi_shutdown() before the domain structure and the
control channel rings are completely released. Otherwise we might
release resources like the nhi->msix_ida that are still referenced in
tb_domain_release(). For this reason wait for the tb_domain_release() to
be completed before continuing to nhi_shutdown() and eventually
releasing of the rest of the data structures.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Mika Westerberg [Wed, 19 Nov 2025 10:49:30 +0000 (12:49 +0200)]
thunderbolt: Set tb->root_switch to NULL when domain is stopped
Similarly what we do with the firmware connection manager. This makes
tb_xdp_handle_request() return error to the remote host. However, we
need to make sure we keep the uuid alive so that we can reply until the
whole domain is released.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Mika Westerberg [Wed, 19 Nov 2025 11:15:58 +0000 (13:15 +0200)]
thunderbolt: Release request if tb_cfg_request() fails in __tb_xdomain_response()
If tb_cfg_request() fails setting up the request (for example the
control channel is shut down already) it returns an error without
calling the callback. To avoid leaking that memory, call
tb_cfg_request_put() if tb_cfg_request() fails.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Mika Westerberg [Fri, 21 Nov 2025 06:47:23 +0000 (08:47 +0200)]
thunderbolt: Keep the domain reference while processing hotplug
We process hotplug events in a workqueue that may run after the domain
has been removed by tb_domain_remove(). For example if user unloads the
driver while at the same time plugging a device router we may have
scheduled tb_handle_hotplug() to run. Avoid possible UAF in this case by
taking the domain reference before scheduling the hotplug handler in
tb_queue_hotplug().
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Mika Westerberg [Fri, 11 Aug 2023 09:59:09 +0000 (12:59 +0300)]
thunderbolt: Make XDomain lane bonding comply with the USB4 v2 spec
The USB4 v2 Inter-Domain spec "unified" the lane bonding flow so that
when the other end (with higher UUID) is not yet set the target link
width accordingly it is expected to reply with ERROR_NOT_READY.
Implement this for Linux.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Mika Westerberg [Tue, 11 Nov 2025 15:52:01 +0000 (17:52 +0200)]
thunderbolt: Don't disable lane adapter if XDomain lane bonding isn't possible
This happens when firmware connection manager is being used. It will
deal with disabling the lane 1 adapter after the tunnel has been
established and re-enabling it afterwards. For this reason only do this
when we know that lane bonding is possible (e.g running software
connection manager).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Gil Fine [Sun, 2 Nov 2025 21:58:34 +0000 (23:58 +0200)]
thunderbolt: Avoid reserved fields in path config space for USB4 routers
According to USB4 spec, USB4 Connection Manager shall not change value
of any fields that are defined as "RsvdZ" or "VD". Specifically fields:
Path Credits Allocated, IFC, ISE fields in path config space shall not
be written by CM. To handle this, CM shall first read current path
config space from the hardware, change only the fields that can be
changed, and then write back the path config space.
Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
wifi: cfg80211: add LTF keyseed support for secure ranging
Currently there is no way to install an LTF key seed that can be
used in non-trigger-based (NTB) and trigger-based (TB) FTM ranging
to protect NDP frames. Without this, drivers cannot enable PHY-layer
security for peer measurement sessions, leaving ranging measurements
vulnerable to eavesdropping and manipulation.
Introduce NL80211_KEY_LTF_SEED attribute and the dedicated extended
feature flag NL80211_EXT_FEATURE_SET_KEY_LTF_SEED to allow drivers
to advertise and install LTF key seeds via nl80211. The key seed
must be configured beforehand to ensure the peer measurement session
is secure. The driver must advertise both NL80211_EXT_FEATURE_SECURE_LTF
and NL80211_EXT_FEATURE_SET_KEY_LTF_SEED for the key seed installation
to be permitted.
The LTF key seed is pairwise key material and must only be used with
pairwise key type. Reject attempts to use it with other key types.
wifi: cfg80211: allow suppressing FTM result reporting for PD requests
Proximity detection often does not require detailed ranging
measurements, yet userspace currently receives full FTM results for
every request, causing unnecessary data transfer, host wakeups, and
processing overhead.
Add an optional control to suppress ranging result reporting for
peer-to-peer PD requests. Introduce the
NL80211_PMSR_FTM_REQ_ATTR_PD_SUPPRESS_RESULTS flag; when set with a
PD request, the device may perform the measurements (e.g. when acting
as RSTA) but must not report the measurement results to userspace.
Validate that the flag is only accepted when request_type is set to
NL80211_PMSR_FTM_REQ_TYPE_PD, reject otherwise.
wifi: cfg80211: add PD-specific preamble and bandwidth capabilities
Devices may support different preamble and bandwidth configurations
for proximity detection (PD) ranging versus standard ranging. Add
separate pd_preambles and pd_bandwidths fields to
cfg80211_pmsr_capabilities to allow drivers to advertise PD-specific
capabilities.
Expose these over nl80211 using new attributes
NL80211_PMSR_FTM_CAPA_ATTR_PD_PREAMBLES and
NL80211_PMSR_FTM_CAPA_ATTR_PD_BANDWIDTHS, advertised only when
pd_support is set.
For PD requests, validate bandwidth and preamble against pd_bandwidths
and pd_preambles. For non-PD requests, validate against the existing
bandwidths and preambles fields.
wifi: cfg80211: add ingress/egress distance thresholds for FTM
Proximity detection applications need to receive measurement results
only when devices cross specific distance boundaries to avoid
unnecessary host wakeups and reduce power consumption.
Introduce configurable distance-based reporting thresholds that
drivers can use to implement selective result reporting. Add ingress
and egress distance parameters allowing applications to specify when
results should be reported as peers cross these boundaries.
wifi: cfg80211: add role-based peer limits to FTM capabilities
Peer measurement capabilities currently advertise a single maximum
peer count regardless of device role. Some devices support different
peer limits when operating as initiator versus responder.
Add max_peers fields inside the ftm.ista and ftm.rsta sub-structs of
cfg80211_pmsr_capabilities to allow drivers to advertise per-role peer
limits. These limits are generic and not restricted to any specific
ranging type.
Expose these over nl80211 using new NL80211_PMSR_ATTR_MAX_PEER_ISTA_ROLE
and NL80211_PMSR_ATTR_MAX_PEER_RSTA_ROLE attributes inside the
ISTA_CAPS and RSTA_CAPS nested attributes respectively.
When a role limit is advertised, validate the number of peers in the
request separately for each role using the existing rsta flag in the
FTM request, and reject the request if the limit is exceeded.
wifi: cfg80211: extend PMSR FTM response for proximity ranging
Applications need negotiated session parameters to interpret
proximity ranging results and perform post-processing. Currently,
the FTM response lacks LTF repetition counts, time constraints,
spatial stream configuration, and availability window parameters.
Extend the FTM response structure to report these negotiated
parameters, enabling applications to track session configuration
and use them in post-processing to increase ranging precision.
wifi: cfg80211: add NTB continuous ranging and FTM request type support
Enable NTB continuous ranging with configurable timing and measurement
parameters as per the Wi-Fi Alliance specification "Proximity Ranging
(PR) Implementation Consideration Draft 1.9 Rev 1, section 5.3". Add
new FTM request attributes for min/max time between measurements,
nominal time (mandatory for NTB), AW duration, and total measurement
count.
Add NL80211_PMSR_PEER_ATTR_REQ_TYPE attribute using the new
nl80211_peer_measurement_ftm_req_type enum to allow userspace to
specify the ranging request type per peer:
- NL80211_PMSR_FTM_REQ_TYPE_INFRA: STA-to-AP or AP-to-STA ranging
(default if attribute is absent)
- NL80211_PMSR_FTM_REQ_TYPE_PD: peer-to-peer ranging
Validate the request type against the device TYPE_CAPS capabilities
advertised via NL80211_PMSR_FTM_CAPA_ATTR_TYPE_CAPS. Reject PD
requests if the device does not advertise PD support.
Reject PD requests that set trigger-based ranging, as TB ranging is
not compatible with peer-to-peer proximity detection.
Add ftms_per_burst limit of 4 for PD NTB ranging requests.
wifi: cfg80211: add proximity detection capabilities to PMSR
Introduce Proximity Detection (PD) capabilities in Peer Measurement
Service (PMSR) as defined in the Wi-Fi Alliance specification
"Proximity Ranging (PR) Implementation Consideration Draft 1.9 Rev 1
section 3.3". This enables devices to advertise peer to peer ranging
support.
Restructure FTM capabilities in cfg80211_pmsr_capabilities to replace
the single support_rsta flag with nested ista and rsta sub-structs,
each carrying per-mode flags for Non-Trigger Based (NTB), Trigger Based
(TB), and EDCA based ranging. This allows drivers to advertise detailed
role and protocol support for both initiator and responder roles.
Add support to pass additional ISTA and RSTA role capabilities to
userspace using new nested ISTA_CAPS and RSTA_CAPS attributes. The
legacy RSTA_SUPPORT flag is retained for backward compatibility.
Add NL80211_PMSR_FTM_CAPA_ATTR_TYPE_CAPS nested attribute using the
nl80211_peer_measurement_ftm_type_capa enum with two sub-flags:
NL80211_PMSR_FTM_TYPE_CAPA_ATTR_INFRA_SUPPORT for STA-to-AP or
AP-to-STA ranging, and NL80211_PMSR_FTM_TYPE_CAPA_ATTR_PD_SUPPORT
for peer-to-peer ranging.
Add CONCURRENT_ISTA_RSTA_SUPPORT as a FTM capability flag indicating
the device can simultaneously act as initiator and responder in a
multi-peer measurement request.
Extend FTM capabilities with antenna configuration fields
(max_no_of_tx_antennas, max_no_of_rx_antennas) for the PR Element
during PASN negotiation, and ranging interval limits
(min_allowed_ranging_interval_edca, min_allowed_ranging_interval_ntb)
to advertise device timing constraints for EDCA and NTB-based ranging.
Update the FTM request validation path in pmsr.c to check RSTA
requests against the per-mode rsta capabilities (NTB, TB, EDCA),
rejecting requests for modes the device does not support.
Currently, the proximity detection (PD) interface type has no
start/stop commands defined, preventing user space from
controlling PD operations through the nl80211 interface.
Add NL80211_CMD_START_PD and NL80211_CMD_STOP_PD commands to
allow user space to start and stop a PD interface. Add the
corresponding start_pd and stop_pd operations to cfg80211_ops
and ieee80211_ops, along with nl80211 command handlers, rdev
wrappers, and tracing support. Validate that drivers advertising
PD interface support implement the required operations. Handle
PD interface teardown during device unregistration and when
the interface leaves the network.
wifi: cfg80211/mac80211: Add NL80211_IFTYPE_PD for PD PASN and PMSR operations
Add a new wdev-only interface type NL80211_IFTYPE_PD to support
Proximity Detection (PD) operations such as PASN and peer measurement
operations. This interface type operates without a netdev, similar to
P2P_DEVICE and NAN interfaces.
Implement support across cfg80211 and mac80211 layers with PD-specific
checks gated by the NL80211_EXT_FEATURE_SECURE_RTT feature flag,
management frame registration and transmission capabilities, and proper
channel context handling where PD interfaces are excluded from bandwidth
calculations. Update mac80211 to recognize the new interface type in the
relevant paths for this management-only interface.
PD discovery can be performed on any available interface, such as
NL80211_IFTYPE_STATION.
If PD/PMSR uses the MAC address of an existing interface type, such as
NL80211_IFTYPE_STATION, then pairing and measurement shall use that
same interface. If PD/PMSR uses a different MAC address, such as a
random MAC address, then pairing and measurement can be performed on a
new NL80211_IFTYPE_PD interface created with that random MAC address.
wifi: cfg80211: Add MAC address filter to remain_on_channel
Currently the remain_on_channel operation does not support
filtering incoming frames by destination MAC address. This
prevents use cases such as PASN authentication in the
responder side that need to receive frames addressed to a
specific MAC during the off-channel period.
Add an rx_addr parameter to the remain_on_channel operation
callback and propagate it through the call chain from nl80211
to driver implementations. Introduce the extended feature
NL80211_EXT_FEATURE_ROC_ADDR_FILTER as a capability gate so
that cfg80211 rejects the request if the driver does not
advertise support for address filtering. Extract the address
from the NL80211_ATTR_MAC attribute when provided in the
netlink message and update the tracing infrastructure to
include the address in remain_on_channel trace events. The
rx_addr parameter is optional and can be NULL, maintaining
backward compatibility with existing drivers.
wifi: cfg80211: restrict LMR feedback check to TB and non-TB ranging
The lmr_feedback field is only applicable to TB and non-TB ranging.
Currently, pmsr_parse_ftm() enforces lmr_feedback for all RSTA
requests, incorrectly rejecting valid EDCA-based RSTA requests.
Fix this by limiting the lmr_feedback requirement to TB and non-TB
ranging only.
Fixes: 853800c746d3 ("wifi: nl80211/cfg80211: support operating as RSTA in PMSR FTM request") Co-developed-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Signed-off-by: Peddolla Harshavardhan Reddy <peddolla.reddy@oss.qualcomm.com> Link: https://patch.msgid.link/20260420090856.2152905-2-peddolla.reddy@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
On AM62-LP-SK, the TPS65219 PMIC is the system power controller
responsible for handling system poweroff. Add the "system-power-controller"
property to the PMIC node to explicitly designate it as such.
Among all in-tree device trees using the TPS65219 PMIC (verified via
compatible string), AM62-LP-SK was the only one missing this property.
This patch corrects that omission.
This property will be used by the PMIC driver to conditionally register
the poweroff handler, ensuring only the designated power controller
registers for system poweroff operations.
Judith Mendez [Tue, 24 Mar 2026 14:02:47 +0000 (09:02 -0500)]
arm64: dts: ti: k3-am62a7-sk: Add bootph-all tag to vqmmc
Add bootph-all property to vqmmc voltage regulator node and its
corresponding pinmux node to make it available during all boot
phases. This allows to run tuning early in SPL stages of boot.
Randy Dunlap [Sun, 1 Mar 2026 01:12:28 +0000 (17:12 -0800)]
soc: ti: knav_dma: fix all kernel-doc warnings in knav_dma.h
Use correct struct member names and formats to avoid kernel-doc
warnings:
Warning: include/linux/soc/ti/knav_dma.h:83 struct member 'priority' not
described in 'knav_dma_tx_cfg'
Warning: include/linux/soc/ti/knav_dma.h:113 struct member 'err_mode' not
described in 'knav_dma_rx_cfg'
Warning: include/linux/soc/ti/knav_dma.h:113 struct member 'desc_type' not
described in 'knav_dma_rx_cfg'
Warning: include/linux/soc/ti/knav_dma.h:113 struct member 'fdq' not
described in 'knav_dma_rx_cfg'
Warning: include/linux/soc/ti/knav_dma.h:127 struct member 'direction' not
described in 'knav_dma_cfg'
Warning: include/linux/soc/ti/knav_dma.h:127 struct member 'u' not
described in 'knav_dma_cfg'
Judith Mendez [Mon, 9 Feb 2026 17:23:30 +0000 (11:23 -0600)]
soc: ti: k3-socinfo: Add support for AM62P variants via NVMEM
Add support for detecting AM62P silicon revisions.
On AM62P, silicon revision is discovered with GP_SW1 register instead
of JTAGID register. Use the NVMEM framework to read GP_SW1 from the
gpsw-efuse nvmem provider to determine SoC revision.
Judith Mendez [Mon, 9 Feb 2026 17:23:29 +0000 (11:23 -0600)]
dt-bindings: hwinfo: ti,k3-socinfo: Add nvmem-cells support
Add optional nvmem-cells and nvmem-cell-names properties to support
reading silicon revision information from alternate location using
NVMEM providers. This is used on AM62P to read GP_SW1 register for
accurate silicon revision detection.
Tomi Valkeinen [Thu, 23 Apr 2026 14:21:16 +0000 (17:21 +0300)]
drm/fourcc: Add DRM_FORMAT_T430
Add T430, a 3 plane 10 bits per component non-subsampled YCbCr format.
A new initial letter was chosen for this one, as the format doesn't
match the existing P, Q or S formats. T is the next one in the alphabet.
It was definitely not chosen because of the initial letter in the
author's name.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Vishal Sagar <vishal.sagar@amd.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20260423-xilinx-formats-v10-5-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Tomi Valkeinen [Thu, 23 Apr 2026 14:21:14 +0000 (17:21 +0300)]
drm/fourcc: Add DRM_FORMAT_Y8
Add greyscale Y8 format.
The 8-bit greyscale format has been discussed before, and the earlier
guidance was to use DRM_FORMAT_R8, as a single-channel 8-bit pixel.
However, adding DRM_FORMAT_Y8 makes sense, we can mark it as 'is_yuv' in
the drm_format_info, and this can help the drivers handle e.g.
full/limited range. This will distinguish two single-channel formats:
R8, which is a RGB format with the same value for all components, and
Y8, which is a Y-only YCbCr format, with Cb and Cr being neutral.
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Vishal Sagar <vishal.sagar@amd.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20260423-xilinx-formats-v10-3-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Tomi Valkeinen [Thu, 23 Apr 2026 14:21:12 +0000 (17:21 +0300)]
drm/fourcc: Add warning for bad bpp
drm_format_info_bpp() cannot be used for formats which do not have an
integer bits-per-pixel in a pixel block.
E.g. DRM_FORMAT_P030's plane 0 has three 10-bit pixels (Y components),
and two padding bits, in a 4 byte block. That is 10.666... bits per
pixel when considering the whole 4 byte block, which is what
drm_format_info_bpp() does. Thus a driver that supports such formats
cannot use drm_format_info_bpp(),
It is a driver bug if this happens, but so handle wrong calls by
printing a warning and returning 0.
Alice Ryhl [Mon, 27 Apr 2026 10:54:51 +0000 (10:54 +0000)]
drm/gpuvm: rust: add RUST_DRM_GPUVM option to Kconfig
Since Rust uses GPUVM via the kernel crate, which is built-in, the GPUVM
module must also be built-in to use GPUVM from Rust. Adjust the Kconfig
settings accordingly.
Alice Ryhl [Thu, 9 Apr 2026 15:26:10 +0000 (15:26 +0000)]
rust: gpuvm: add GpuVmCore::sm_map()
Finally also add the operation for creating new mappings. Mapping
operations need extra data in the context since they involve a vm_bo
coming from the outside.
Alice Ryhl [Thu, 9 Apr 2026 15:26:07 +0000 (15:26 +0000)]
rust: gpuvm: add GpuVm::obtain()
This provides a mechanism to create (or look up) VMBO instances, which
represent the mapping between GPUVM and GEM objects.
The GpuVmBoRegistered<T> type can be considered like ARef<GpuVm<T>>,
except that no way to increment the refcount is provided.
The GpuVmBoAlloc<T> type is more akin to a pre-allocated GpuVmBo<T>, so
it's not really a GpuVmBo<T> yet. Its destructor could call
drm_gpuvm_bo_destroy_not_in_lists(), but as the type is currently
private and never called anywhere, this perf optimization does not need
to happen now.
Pre-allocating and obtaining the gpuvm_bo object is exposed as a single
step. This could theoretically be a problem if one wanted to call
drm_gpuvm_bo_obtain_prealloc() during the fence signalling critical
path, but that's not a possibility because:
1. Adding the BO to the extobj list requires the resv lock, so it cannot
happen during the fence signalling critical path.
2. obtain() requires that the BO is not in the extobj list, so obtain()
must be called before adding the BO to the extobj list.
Thus, drm_gpuvm_bo_obtain_prealloc() cannot be called during the fence
signalling critical path. (For extobjs at least.)
rust: drm: add base GPUVM immediate mode abstraction
Add a GPUVM abstraction to be used by Rust GPU drivers.
GPUVM keeps track of a GPU's virtual address (VA) space and manages the
corresponding virtual mappings represented by "GPU VA" objects. It also
keeps track of the gem::Object<T> used to back the mappings through
GpuVmBo<T>.
This abstraction is only usable by drivers that wish to use GPUVM in
immediate mode. This allows us to build the locking scheme into the API
design. It means that the GEM mutex is used for the GEM gpuva list, and
that the resv lock is used for the extobj list. The evicted list is not
yet used in this version.
This abstraction provides a special handle called the UniqueRefGpuVm,
which is a wrapper around ARef<GpuVm> that provides access to the
interval tree. Generally, all changes to the address space requires
mutable access to this unique handle.
Signed-off-by: Asahi Lina <lina+kernel@asahilina.net> Co-developed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Co-developed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260409-gpuvm-rust-v6-1-b16e6ada7261@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
sched: Use trace_call__<tp>() to save a static branch
The wrapper functions __trace_set_current_state() and
__trace_set_need_resched() allow the tracepoints to be called from code
outside sched/core.c, those calls are already guarded by a
tracepoint_enabled(<tp>) so there is no need to repeat this check once
again inside the call using trace_<tp>().
Use the new trace_call__<tp>() API to directly call the tracepoint
without check. Those helper functions must be called after the
appropriate check.
Aniket Gattani [Sun, 3 May 2026 21:22:05 +0000 (21:22 +0000)]
selftests/membarrier: Add rseq stress test for CFS throttle interactions
Add a new stress test to exercise the interaction between targeted
expedited membarrier commands and CFS bandwidth throttling.
The test creates a deep cgroup hierarchy and aggressively hammers the
membarrier syscall to expose lock contention and latency issues. This
serves as a reliable reproducer for the `membarrier_ipi_mutex` cascade
lockup, ensuring future changes to membarrier locking do not regress
targeted command latency.
Closes: https://lore.kernel.org/r/202604151516.Vc7Ro4LP-lkp@intel.com/ Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Aniket Gattani <aniketgattani@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260503212205.3714217-4-aniketgattani@google.com
Aniket Gattani [Sun, 3 May 2026 21:22:03 +0000 (21:22 +0000)]
sched/membarrier: Use per-CPU mutexes for targeted commands
Currently, the membarrier system call uses a single global mutex
(`membarrier_ipi_mutex`) to serialize expedited commands. This causes
significant contention on large systems when multiple threads invoke
membarrier concurrently, even if they target different CPUs.
This contention becomes critical when combined with CFS bandwidth
throttling/unthrottling, during which interrupts can be disabled for
relatively long periods on target CPUs. If membarrier is waiting for a
response from such a CPU, it holds the global mutex, blocking all other
membarrier calls on the system. This cascade effect can lead to hard
lockups when thousands of threads stall waiting for the mutex.
Optimize `MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ` when a specific CPU is
targeted by introducing per-CPU mutexes. Broadcast commands and commands
without a specific CPU target continue to use the global mutex.
This prevents the cascade lockup scenario. As measured by the stress test
introduced in the subsequent patch, on an AMD Turin machine with 384 CPUs
(2 NUMA nodes with SMT=2), this optimization yields 200x more
throughput.
Randy Dunlap [Thu, 30 Apr 2026 23:39:27 +0000 (16:39 -0700)]
locking/barrier: Use correct parameter names
Use the correct parameter names in kernel-doc comments to avoid
warnings:
Warning: include/asm-generic/barrier.h:245 function parameter 'cond_expr'
not described in 'smp_cond_load_relaxed'
Warning: include/asm-generic/barrier.h:267 function parameter 'cond_expr'
not described in 'smp_cond_load_acquire'
Alice Ryhl [Thu, 16 Apr 2026 13:10:54 +0000 (13:10 +0000)]
drm/gpuvm: take refcount on DRM device
Currently GPUVM relies on the owner implicitly holding a refcount to the
drm device, and it does not implicitly take a refcount on the drm
device. This design is error-prone, so take a refcount on the device.
Both Auto Counter Reload (ACR) and Architectural PEBS use the PERF_CFG_C
MSRs to configure event behavior. Currently, the driver maintains two
independent variables acr_cfg_c and cfg_c_val to cache the values intended
for these MSRs.
Using separate variables to track a single hardware register state is
error-prone and can lead to configuration conflicts. Consolidate the
tracking into a single cfg_c_val variable to ensure a unified and
consistent view of the PERF_CFG_C MSR state.
Dapeng Mi [Thu, 30 Apr 2026 00:25:57 +0000 (08:25 +0800)]
perf/x86/intel: Enable auto counter reload for DMR
Panther cove µarch starts to support auto counter reload (ACR), but the
static_call intel_pmu_enable_acr_event() is not updated for the Panther
Cove µarch used by DMR. It leads to the auto counter reload is not
really enabled on DMR.
Update static_call intel_pmu_enable_acr_event() in intel_pmu_init_pnc().
Dapeng Mi [Thu, 30 Apr 2026 00:25:56 +0000 (08:25 +0800)]
perf/x86/intel: Disable PMI for self-reloaded ACR events
On platforms with Auto Counter Reload (ACR) support, such as NVL, a
"NMI received for unknown reason 30" warning is observed when running
multiple events in a group with ACR enabled:
$ perf record -e '{instructions/period=20000,acr_mask=0x2/u,\
cycles/period=40000,acr_mask=0x3/u}' ./test
The warning occurs because the Performance Monitoring Interrupt (PMI)
is enabled for the self-reloaded event (the cycles event in this case).
According to the Intel SDM, the overflow bit
(IA32_PERF_GLOBAL_STATUS.PMCn_OVF) is never set for self-reloaded events.
Since the bit is not set, the perf NMI handler cannot identify the source
of the interrupt, leading to the "unknown reason" message.
Furthermore, enabling PMI for self-reloaded events is unnecessary and
can lead to extraneous records that pollute the user's requested data.
Disable the interrupt bit for all events configured with ACR self-reload.
Fixes: ec980e4facef ("perf/x86/intel: Support auto counter reload") Reported-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260430002558.712334-4-dapeng1.mi@linux.intel.com
Dapeng Mi [Thu, 30 Apr 2026 00:25:55 +0000 (08:25 +0800)]
perf/x86/intel: Always reprogram ACR events to prevent stale masks
Members of an ACR group are logically linked via a bitmask of their
hardware counter indices. If some members of the group are assigned new
hardware counters during rescheduling, even events that keep their
original counter index must be updated with a new mask.
Without this, an event will continue to use a stale acr_mask that
references the old indices of its group peers. Ensure all ACR events are
reprogrammed during the scheduling path to maintain consistency across
the group.
projects / thirdparty / kernel / linux.git / log
