HID: amd_sfh: don't log error when device discovery fails with -EOPNOTSUPP
When sensor discovery fails on systems without AMD SFH sensors, the
code already emits a warning via dev_warn() in amd_sfh_hid_client_init().
The subsequent dev_err() in sfh_init_work() for the same -EOPNOTSUPP
return value is redundant and causes unnecessary alarm.
Suppress the dev_err() for -EOPNOTSUPP to avoid confusing users who
have no AMD SFH sensors.
Fixes: 2105e8e00da4 ("HID: amd_sfh: Improve boot time when SFH is available") Reported-by: Casey Croy <ccroy@bugzilla.kernel.org> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221099 Signed-off-by: Maximilian Pezzullo <maximilianpezzullo@gmail.com> Acked-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
Osama Abdelkader [Wed, 11 Mar 2026 23:18:32 +0000 (00:18 +0100)]
RISC-V: KVM: fix PMU snapshot_set_shmem on 32-bit hosts
When saddr_high != 0 on RV32, the goto out was unconditional, causing
valid 64-bit addresses to be rejected. Only goto out when the address
is invalid (64-bit host with saddr_high != 0).
Yeoreum Yun [Sat, 14 Mar 2026 17:51:32 +0000 (17:51 +0000)]
KVM: arm64: Use CAST instruction for swapping guest descriptor
Use the CAST instruction to swap the guest descriptor when FEAT_LSUI
is enabled, avoiding the need to clear the PAN bit.
FEAT_LSUI is introduced in Armv9.6, where FEAT_PAN is mandatory. However,
this assumption may not always hold:
- Some CPUs may advertise FEAT_LSUI but lack FEAT_PAN.
- Virtualization or ID register overrides may expose invalid feature
combinations.
Therefore, instead of disabling FEAT_LSUI when FEAT_PAN is absent, wrap
LSUI instructions with uaccess_ttbr0_enable()/disable() when
ARM64_SW_TTBR0_PAN is enabled.
Yeoreum Yun [Sat, 14 Mar 2026 17:51:30 +0000 (17:51 +0000)]
arm64: futex: Support futex with FEAT_LSUI
Current futex atomic operations are implemented using LL/SC instructions
while temporarily clearing PSTATE.PAN and setting PSTATE.TCO (if
KASAN_HW_TAGS is enabled). With Armv9.6, FEAT_LSUI provides atomic
instructions for user memory access in the kernel without the need for
PSTATE bits toggling.
Use the FEAT_LSUI instructions to implement the futex atomic operations.
Note that some futex operations do not have a matching LSUI instruction,
(eor or word-sized cmpxchg). For such cases, use cas{al}t to implement
the operation.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
[catalin.marinas@arm.com: add comment on -EAGAIN in __lsui_futex_cmpxchg()] Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Identified resume-probe race condition in kernel v7.0 with the commit 38fa29b01a6a ("i2c: designware: Combine the init functions"),but this
issue existed from the beginning though not detected.
The amdisp i2c device requires ISP to be in power-on state for probe
to succeed. To meet this requirement, this device is added to genpd
to control ISP power using runtime PM. The pm_runtime_get_sync() called
before i2c_dw_probe() triggers PM resume, which powers on ISP and also
invokes the amdisp i2c runtime resume before the probe completes resulting
in this race condition and a NULL dereferencing issue in v7.0
Fix this race condition by using the genpd APIs directly during probe:
- Call dev_pm_genpd_resume() to Power ON ISP before probe
- Call dev_pm_genpd_suspend() to Power OFF ISP after probe
- Set the device to suspended state with pm_runtime_set_suspended()
- Enable runtime PM only after the device is fully initialized
Fixes: d6263c468a761 ("i2c: amd-isp: Add ISP i2c-designware driver") Co-developed-by: Bin Du <bin.du@amd.com> Signed-off-by: Bin Du <bin.du@amd.com> Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com> Cc: <stable@vger.kernel.org> # v6.16+ Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260320201302.3490570-1-pratap.nirujogi@amd.com
i2c: imx: ensure no clock is generated after last read
When reading from the I2DR register, right after releasing the bus by
clearing MSTA and MTX, the I2C controller might still generate an
additional clock cycle which can cause devices to misbehave. Ensure to
only read from I2DR after the bus is not busy anymore. Because this
requires polling, the read of the last byte is moved outside of the
interrupt handler.
An example for such a failing transfer is this:
i2ctransfer -y -a 0 w1@0x00 0x02 r1
Error: Sending messages failed: Connection timed out
It does not happen with every device because not all devices react to
the additional clock cycle.
Fixes: 5f5c2d4579ca ("i2c: imx: prevent rescheduling in non dma mode") Cc: stable@vger.kernel.org # v6.13+ Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260218150940.131354-3-eichest@gmail.com
i2c: imx: fix i2c issue when reading multiple messages
When reading multiple messages, meaning a repeated start is required,
polling the bus busy bit must be avoided. This must only be done for
the last message. Otherwise, the driver will timeout.
Here an example of such a sequence that fails with an error:
i2ctransfer -y -a 0 w1@0x00 0x02 r1 w1@0x00 0x02 r1
Error: Sending messages failed: Connection timed out
Fixes: 5f5c2d4579ca ("i2c: imx: prevent rescheduling in non dma mode") Cc: stable@vger.kernel.org # v6.13+ Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260218150940.131354-2-eichest@gmail.com
Even Xu [Wed, 18 Mar 2026 03:25:47 +0000 (11:25 +0800)]
HID: intel-thc-hid: Intel-quickspi: Improve power management for touch devices
Enhance power management with two key improvements:
1. Hibernate support: Send POWER_OFF command when entering hibernate
mode.
2. Conditional sleep commands: Only send POWER_SLEEP/POWER_ON commands
during system suspend/resume when the touch device is not configured
as a wake source, preserving Wake-on-Touch (WoT) functionality. This
ensures proper power states while maintaining expected wake behavior.
Tommaso Merciai [Thu, 12 Mar 2026 14:50:38 +0000 (15:50 +0100)]
reset: rzv2h-usb2phy: Keep PHY clock enabled for entire device lifetime
The driver was disabling the USB2 PHY clock immediately after register
initialization in probe() and after each reset operation. This left the
PHY unclocked even though it must remain active for USB functionality.
The behavior appeared to work only when another driver
(e.g., USB controller) had already enabled the clock, making operation
unreliable and hardware-dependent. In configurations where this driver
is the sole clock user, USB functionality would fail.
Fix this by:
- Enabling the clock once in probe() via pm_runtime_resume_and_get()
- Removing all pm_runtime_put() calls from assert/deassert/status
- Registering a devm cleanup action to release the clock at removal
- Removed rzv2h_usbphy_assert_helper() and its call in
rzv2h_usb2phy_reset_probe()
This ensures the PHY clock remains enabled for the entire device lifetime,
preventing instability and aligning with hardware requirements.
Cc: stable@vger.kernel.org Fixes: e3911d7f865b ("reset: Add USB2PHY port reset driver for Renesas RZ/V2H(P)") Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Pavan Chebbi [Sat, 14 Mar 2026 15:16:02 +0000 (08:16 -0700)]
fwctl/bnxt_en: Refactor aux bus functions to be more generic
Up until now there was only one auxiliary device that bnxt
created and that was for RoCE driver. bnxt fwctl is also
going to use an aux bus device that bnxt should create.
This requires some nomenclature changes and refactoring of
the existing bnxt aux dev functions.
Convert 'aux_priv' and 'edev' members of struct bnxt into
arrays where each element contains supported auxbus device's
data. Move struct bnxt_aux_priv from bnxt.h to ulp.h because
that is where it belongs. Make aux bus init/uninit/add/del
functions more generic which will loop through all the aux
device types. Make bnxt_ulp_start/stop functions (the only
other common functions applicable to any aux device) loop
through the aux devices to update their config and states.
Make callers of bnxt_ulp_start() call it only when there
are no errors.
Also, as an improvement in code, bnxt_register_dev() can skip
unnecessary dereferencing of edev from bp, instead use the
edev pointer from the function parameter.
Future patches will reuse these functions to add an aux bus
device for fwctl.
net: qrtr: fix endian handling of confirm_rx field
Convert confirm_rx to little endian when enqueueing and convert it back on
receive. This fixes control flow on big endian hosts, little endian is
unaffected.
On transmit, store confirm_rx as __le32 using cpu_to_le32(). On receive,
apply le32_to_cpu() before using the value. !! ensures the value is 0 or 1
in native endianness, so the conversion isn’t strictly required here, but
it is kept for consistency and clarity.
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
David Carlier [Wed, 25 Mar 2026 12:51:30 +0000 (12:51 +0000)]
net: ti: icssg-prueth: fix missing data copy and wrong recycle in ZC RX dispatch
emac_dispatch_skb_zc() allocates a new skb via napi_alloc_skb() but
never copies the packet data from the XDP buffer into it. The skb is
passed up the stack containing uninitialized heap memory instead of
the actual received packet, leaking kernel heap contents to userspace.
Copy the received packet data from the XDP buffer into the skb using
skb_copy_to_linear_data().
Additionally, remove the skb_mark_for_recycle() call since the skb is
backed by the NAPI page frag allocator, not page_pool. Marking a
non-page_pool skb for recycle causes the free path to return pages to
a page_pool that does not own them, corrupting page_pool state.
The non-ZC path (emac_rx_packet) does not have these issues because it
uses napi_build_skb() to wrap the existing page_pool page directly,
requiring no copy, and correctly marks for recycle since the page comes
from page_pool_dev_alloc_pages().
Fixes: 7a64bb388df3 ("net: ti: icssg-prueth: Add AF_XDP zero copy for RX") Signed-off-by: David Carlier <devnexen@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
When driver signals carrier up via netif_carrier_on() its internal
link_up state isn't updated immediately. This leads to inconsistent
speed/duplex in /proc/net/bonding/bondX where the speed and duplex
is shown as unknown while ethtool shows correct values. Fix this by
using netif_carrier_ok() for link checking in get_ksettings function.
Fixes: 84421b99cedc ("tg3: Update link_up flag for phylib devices") Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Pengpeng Hou [Wed, 25 Mar 2026 07:41:52 +0000 (15:41 +0800)]
net/ipv6: ioam6: prevent schema length wraparound in trace fill
ioam6_fill_trace_data() stores the schema contribution to the trace
length in a u8. With bit 22 enabled and the largest schema payload,
sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the
remaining-space check. __ioam6_fill_trace_data() then positions the
write cursor without reserving the schema area but still copies the
4-byte schema header and the full schema payload, overrunning the trace
buffer.
Keep sclen in an unsigned int so the remaining-space check and the write
cursor calculation both see the full schema length.
Fixes: 8c6f6fa67726 ("ipv6: ioam: IOAM Generic Netlink API") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Reviewed-by: Justin Iurman <justin.iurman@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Merge tag 'juno-updates-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/dt
Armv8 Juno/FVP/Vexpress updates for v7.1
1. The primary addition is initial support for Zena CSS that includes:
a new binding compatibility, a shared `zena-css.dtsi` description, and
an FVP device tree.
2. Extension of Corstone-1000 FVP platform support with binding updates
to add the new `arm,corstone1000-a320-fvp` platform, and the
`arm,corstone1000-ethos-u85` NPU integration.
Overall, this combines new platform enablement with some DTS layout
cleanup for Arm reference FVP based systems.
* tag 'juno-updates-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
arm64: dts: arm/corstone1000: Add corstone-1000-a320
arm64: dts: arm/corstone1000: Move FVP peripherals to separate .dtsi
arm64: dts: arm/corstone1000: Move cpu nodes
dt-bindings: npu: arm,ethos: Add "arm,corstone1000-ethos-u85"
dt-bindings: arm,corstone1000: Add "arm,corstone1000-a320-fvp"
arm64: dts: zena: Move SRAM into SoC and memory node out of SoC
arm64: dts: zena: Add support for Zena CSS
dt-bindings: arm: Add Zena CSS compatibility
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Merge tag 'v7.0-rockchip-dtsfixes1-v2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes
Revert to fix a regression that breaks Wifi support for a large part
of Pinebook Pro users (multiple Wifi chipsets).
* tag 'v7.0-rockchip-dtsfixes1-v2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
Revert "arm64: dts: rockchip: Further describe the WiFi for the Pinebook Pro"
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Merge tag 'imx-fixes-7.0' of https://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into arm/fixes
i.MX fixes for 7.0:
- Revert the NAND property move that broke compatibility across multiple
imx6/imx7 device trees
- Fix imx8mq-librem5 power management by bumping BUCK1 suspend voltage to
0.85V and reverting problematic DVS voltage changes
- Correct eMMC pad configuration for imx93-tqma9352 and imx91-tqma9131
- Change usdhc tuning step for eMMC and SD on imx93-9x9-qsb
- Correct gpu_ahb clock frequency for imx8mq
* tag 'imx-fixes-7.0' of https://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux:
arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85V
Revert "arm64: dts: imx8mq-librem5: Set the DVS voltages lower"
Revert "ARM: dts: imx: move nand related property under nand@0"
arm64: dts: imx93-tqma9352: improve eMMC pad configuration
arm64: dts: imx91-tqma9131: improve eMMC pad configuration
arm64: dts: imx93-9x9-qsb: change usdhc tuning step for eMMC and SD
arm64: dts: imx8mq: Set the correct gpu_ahb clock frequency
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Suggested-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/all/8403c8b7a832b5274743816eb77abfa4@garyguo.net/ Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://patch.msgid.link/20260326020406.1438210-1-alistair.francis@wdc.com
[ Dropped `projection.rs` since it is in another tree and already marked
as `inline(always)` and reworded accordingly. Changed Link tag to
Gary's original message and added Suggested-by. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
ovl: make fsync after metadata copy-up opt-in mount option
Commit 7d6899fb69d25 ("ovl: fsync after metadata copy-up") was done to
fix durability of overlayfs copy up on an upper filesystem which does
not enforce ordering on storing of metadata changes (e.g. ubifs).
In an earlier revision of the regressing commit by Lei Lv, the metadata
fsync behavior was opt-in via a new "fsync=strict" mount option.
We were hoping that the opt-in mount option could be avoided, so the
change was only made to depend on metacopy=off, in the hope of not
hurting performance of metadata heavy workloads, which are more likely
to be using metacopy=on.
This hope was proven wrong by a performance regression report from Google
COS workload after upgrade to kernel 6.12.
This is an adaptation of Lei's original "fsync=strict" mount option
to the existing upstream code.
The new mount option is mutually exclusive with the "volatile" mount
option, so the latter is now an alias to the "fsync=volatile" mount
option.
Reported-by: Chenglong Tang <chenglongtang@google.com> Closes: https://lore.kernel.org/linux-unionfs/CAOdxtTadAFH01Vui1FvWfcmQ8jH1O45owTzUcpYbNvBxnLeM7Q@mail.gmail.com/ Link: https://lore.kernel.org/linux-unionfs/CAOQ4uxgKC1SgjMWre=fUb00v8rxtd6sQi-S+dxR8oDzAuiGu8g@mail.gmail.com/ Fixes: 7d6899fb69d25 ("ovl: fsync after metadata copy-up")
Depends: 50e638beb67e0 ("ovl: Use str_on_off() helper in ovl_show_options()") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Fei Lv <feilv@asrmicro.com> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Merge tag 'mtk-dts64-for-v7.1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mediatek/linux into soc/dt
MediaTek ARM64 DeviceTree updates
This adds fixes and improvements for already supported devices.
In particular:
- The gpio-ranges pin could was fixed in MT6795, MT7981B, and
MT7986A SoCs, as the very last GPIO was unusable; Even though
anyway unused, this fixes the hardware description.
- Model string fixes for Bananapi BPI-R4 Pro 4E/8X: now the
correct model is shown.
- The MT6359 PMIC gets disambiguation for two default regulator
names, mainly fixing issues seen on U-Boot, but also making
the regulators visually distinguishable in a summary...!
- Aliases for eMMC/SD controllers added in MT8365 EVK board,
MT8395 Radxa NIO-12L and Genio 1200 for consistency
- Fixes to the MediaTek AUDSYS devicetree binding
....and honorable mention goes to:
- MT8195 Cherry Chromebooks get their WiFi on PCI Express and
Bluetooth on USB described with the proper power supplies now
tied to the correct devices (USB VBUS and PCIE3v3): this is
now described almost perfectly, or at least links the right
resources in the right places.
This is also done as a preparation for when the M.2 E-Key
connector binding will be upstreamed.
- MT8195 Cherry Dojo gets its M.2 M-Key slot correctly described
with the new pcie-m2-m-connector binding.
* tag 'mtk-dts64-for-v7.1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mediatek/linux:
arm64: dts: mediatek: mt7986a: Fix gpio-ranges pin count
arm64: dts: mediatek: mt7981b: Fix gpio-ranges pin count
arm64: dts: mediatek: mt6795: Fix gpio-ranges pin count
dt-bindings: arm: mediatek: audsys: fix formatting issues
arm64: dts: mediatek: mt8195-cherry-dojo: Describe M.2 M-key NVMe slot
arm64: dts: mediatek: mt8195-cherry: add WiFi PCIe and BT USB power supplies
arm64: dts: mediatek: mt7988a-bpi-r4pro: fix model string
arm64: dts: mt8167: Reorder nodes according to mmio address
arm64: dts: mediatek: mt6359: give regulators unique names
arm64: dts: mediatek: mt8365: Describe infracfg-nao as a pure syscon
arm64: dts: mediatek: mt8365-evk: add mmc aliases
arm64: dts: mediatek: mt8395-radxa-nio-12l: add mmc aliases
arm64: dts: mediatek: mt8395-genio-common: add mmc aliases
arm64: dts: mediatek: mt8195-cherry: Disable xhci1 completely
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Merge tag 'thead-dt-for-v7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux into soc/dt
T-HEAD Devicetrees for 7.1
Update the T-Head TH1520 RISC-V SoC device tree to support the
Verisilicon DC8200 display controller (called DPU in manual) and the
Synopsys DesignWare HDMI TX controller. In addition, enable HDMI output
for the LicheePi 4a board.
* tag 'thead-dt-for-v7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux:
riscv: dts: thead: lichee-pi-4a: enable HDMI
riscv: dts: thead: add DPU and HDMI device tree nodes
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Gary Guo [Thu, 12 Mar 2026 17:46:59 +0000 (17:46 +0000)]
rust: list: hide macros from top-level kernel doc
Due to Rust macro scoping rules, all macros defined in a crate using
`#[macro_export]` end up in the top-level. For the list macros, we
re-export them inside the list module, and expect users to use
`kernel::list::macro_name!()`.
Use `#[doc(hidden)]` on the macro definition, and use `#[doc(inline)]` on
the re-export to make the macro appear to be defined at module-level inside
documentation.
The other exported types are already automatically `#[doc(inline)]` because
they are defined in a non-public module, so there is no need to split the
macro re-exports out.
It should have been there since the beginning, and while it is not a big
deal since the file has not changed at all since it was added in commit 80db40bac8f4 ("rust: add `.rustfmt.toml`") back in 2022, this will be
especially useful to catch unintended unstable features if upstream
`rustfmt` started to allow them in stable toolchains [1][2].
platform/x86/intel-uncore-freq: Handle autonomous UFS status bit
When the AUTONOMOUS_UFS_DISABLED bit is set in the header, the ELC
(Efficiency Latency Control) feature is non-functional. Hence, return
error for read or write to ELC attributes.
Fixes: bb516dc79c4a ("platform/x86/intel-uncore-freq: Add support for efficiency latency control") Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260325192909.3417322-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Ville Syrjälä [Mon, 23 Mar 2026 10:16:09 +0000 (12:16 +0200)]
drm/i915/uncore: Do GT FIFO checks in early sanitize and forcewake get
We're mixing up the GT FIFO debug checks (overflows and such)
with RMbus unclaimed register checks. The two are quite different
things as RMbus is only relevant for display registers, and the
GT FIFO only relevant for GT registers.
Split the GT FIFO debugs out from the unclaimed register logic
and just do the checks during forcewake_get() and early init.
That is still sufficient to detect if any errors have happened.
Any errors would anyway be caused by overflowing the FIFO
rather than accessing specific registers, so trying to figure
out exactly when the error happened isn't particularly useful.
To fix such issues we'd rather have to do something to slow down
the rate at which registers are accessed (eg. increase
GT_FIFO_NUM_RESERVED_ENTRIES or something).
The live_forcewake_domains selftest doesn't really test anything
particularly sensible. It only runs on platforms that have RMbus
unclaimer error detection, but that only catches display registers
which the test doesn't even access.
I suppose if we really wanted to we might try to make the test
exercise the GT FIFO instead by writing GT registers as fast
as possible, and then checking GTFIFODBG to see if the FIFO has
overflowed. But dunno if there's much point in that. I think a
GT FIFO overflow might even be fatal to the machine.
So in its current for the test doesn't really make sense,
and it's in the way of moving all the RMbus noclaim stuff
to the display driver side. So let's just get rid of it.
Dmitry Torokhov [Thu, 26 Mar 2026 06:25:37 +0000 (23:25 -0700)]
HID: core: factor out hid_parse_collections()
In preparation to making use of __free(...) cleanup facilities to
clean up temporary buffers, factor out code parsing collections into
a separate function to make the code simpler.
Ville Syrjälä [Thu, 26 Mar 2026 11:18:13 +0000 (13:18 +0200)]
drm/i915/dsi: Fill BLLPs with blanking packets if requested
TGL/ADL DSI can be configured to fill all BLLPs with blanking
packets. Currently we enable that always, but the VBT actually
tells us whether this is desired or not. Hook that up.
Based on feature revision, number of buckets can be less than the
TRL_MAX_BUCKETS. In that case core counts in the remaining buckets
can be set to some invalid values.
Hence reset core count to 0 for all buckets before assigning correct
values.
Fixes: 885d1c2a30b7 ("platform/x86: ISST: Support SST-TF revision 2") Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260325192638.3417281-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
driver core: auxiliary bus: Drop auxiliary_dev_pm_ops
Since the PM core automatically falls back to using the driver PM
callbacks directly if no bus type callbacks are present, it is not
necessary to define a struct dev_pm_ops for a bus type that will only
invoke driver PM callbacks from its PM callbacks.
Accordingly, auxiliary_dev_pm_ops is redundant, so drop it.
Ville Syrjälä [Thu, 26 Mar 2026 11:18:12 +0000 (13:18 +0200)]
drm/i915/dsi: Make 'clock_stop' boolean
The DSI 'clock_stop' parameter is a boolean, so use a real
'bool' for it. And pimp the debug print while at it.
Note that we also remove the incorrect negation of the value
in the debug print. That has been there since the code was
introduced in commit 2ab8b458c6a1 ("drm/i915: Add support for
Generic MIPI panel driver"). An earlier version of the patch
https://lore.kernel.org/intel-gfx/1397454507-10273-5-git-send-email-shobhit.kumar@intel.com/
got it right, but looks like it got fumbled while dealing
with other review comments.
Ville Syrjälä [Thu, 26 Mar 2026 11:18:10 +0000 (13:18 +0200)]
drm/i915/dsi: Don't do DSC horizontal timing adjustments in command mode
Stop adjusting the horizontal timing values based on the
compression ratio in command mode. Bspec seems to be telling
us to do this only in video mode, and this is also how the
Windows driver does things.
This should also fix a div-by-zero on some machines because
the adjusted htotal ends up being so small that we end up with
line_time_us==0 when trying to determine the vtotal value in
command mode.
Note that this doesn't actually make the display on the
Huawei Matebook E work, but at least the kernel no longer
explodes when the driver loads.
Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12045 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260326111814.9800-2-ville.syrjala@linux.intel.com Fixes: 53693f02d80e ("drm/i915/dsi: account for DSC in horizontal timings") Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Arnd Bergmann [Tue, 24 Mar 2026 19:20:28 +0000 (20:20 +0100)]
HID: hid-lenovo-go: fix LEDS dependencies
The newly added hid-lenovo-go and hid-lenovo-go-s drivers attempt to
'select LEDS_CLASS', which has a dependency on NEW_LEDS, causing a build
failure when NEW_LEDS itself it disabled:
WARNING: unmet direct dependencies detected for LEDS_CLASS
Depends on [n]: NEW_LEDS [=n]
Selected by [m]:
- HID_LENOVO_GO [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m]
- HID_LENOVO_GO_S [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m]
Device drivers generally should not select other subsystems like this, as
that tends to cause dependency problems including loops in the dependency
graph.
Change these two and the older hid-lenovo driver to behave the same way as all
other HID drivers and use 'depends on LEDS_CLASS' or 'depends on LEDS_CLASS_MULTICOLOR'
instead, which itself has NEW_LEDS and LEDS_CLASS as dependencies.
Fixes: a23f3497bf20 ("HID: hid-lenovo-go-s: Add Lenovo Legion Go S Series HID Driver") Fixes: d69ccfcbc955 ("HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Jiri Kosina <jkosina@suse.com>
leo vriska [Wed, 4 Mar 2026 18:36:59 +0000 (13:36 -0500)]
HID: quirks: add HID_QUIRK_ALWAYS_POLL for 8BitDo Pro 3
According to a mailing list report [1], this controller's predecessor
has the same issue. However, it uses the xpad driver instead of HID, so
this quirk wouldn't apply.
Benoît Sevens [Mon, 23 Mar 2026 16:11:07 +0000 (16:11 +0000)]
HID: roccat: fix use-after-free in roccat_report_event
roccat_report_event() iterates over the device->readers list without
holding the readers_lock. This allows a concurrent roccat_release() to
remove and free a reader while it's still being accessed, leading to a
use-after-free.
Protect the readers list traversal with the readers_lock mutex.
Tomi Valkeinen [Wed, 11 Mar 2026 09:14:44 +0000 (11:14 +0200)]
drm/tidss: Fix missing drm_bridge_add() call
tidss encoder-bridge is not added with drm_bridge_add() call, which
leads to:
[drm] Missing drm_bridge_add() before attach
Add the missing call, using devm_drm_bridge_add() variant to get the
drm_bridge_remove() handled automatically.
The commit marked with the Fixes tag (from v6.6) is the commit that
added the encoder bridge without drm_bridge_add(). However, this fix is
not directly applicable there as devm_drm_bridge_alloc() was not used to
alloc the bridge, so using devm version for drm_bridge_add() wouldn't be
safe. Instead, drm_bridge_add() and drm_bridge_remove() would be needed
there, but that would require new plumbing code as we don't have a
separate cleanup function in the tidss_encoder.c, not in the tidss_kms.c
from which the encoder is created.
Also, there has been no reported bugs caused by the missing
drm_bridge_add(). The drm_bridge_add() initializes the bridge's
hpd_mutex, but HPD is not used for the encoder bridge. drm_bridge_add()
also adds the bridge to the global bridge_list, which is only used in
of_drm_find_bridge(), and again that is not used for the encoder bridge.
Thus, while the original commit is not right, there should be no bugs
caused by it, and for the time being I'm not sending a patch for the
stable kernels for the original commit.
This fix applies on top of commit 66cdf05f8548 ("drm/tidss: encoder:
convert to devm_drm_bridge_alloc()"), which changes the tidss_encoder.c
to use the devm variant (added in v6.17). The warning print was added in
v6.19, so applying this fix to v6.17+ gets rid of the warning for all
kernel versions.
Tomi Valkeinen [Wed, 11 Mar 2026 09:14:43 +0000 (11:14 +0200)]
drm/tidss: Drop extra drm_mode_config_reset() call
We are calling drm_mode_config_reset() twice at probe time. There's no
reason for this and the second call can be removed, reducing work at
probe time slightly.
Fuad Tabba [Fri, 6 Mar 2026 14:02:20 +0000 (14:02 +0000)]
KVM: arm64: Extract VMA size resolution in user_mem_abort()
As part of an effort to refactor user_mem_abort() into smaller, more
focused helper functions, extract the logic responsible for determining
the VMA shift and page size into a new static helper,
kvm_s2_resolve_vma_size().
Georgi Djakov [Fri, 27 Mar 2026 09:50:52 +0000 (11:50 +0200)]
Merge branch 'icc-msm8974' into icc-next
Commit d6edc31f3a68 ("clk: qcom: smd-rpm: Separate out interconnect bus
clocks") moved control over several RPM resources from the clk-smd-rpm
driver to the icc-rpm.c interconnect helpers. Most of the platforms were
fixed before that commit or shortly after. However the MSM8974 was left
as a foster child in broken state. Fix the loose ends and reenable
interconnects on that platform.
* icc-msm8974
dt-bindings: interconnect: qcom,msm8974: drop bus clocks
dt-bindings: interconnect: qcom,msm8974: use qcom,rpm-common
interconnect: qcom: drop unused is_on flag
interconnect: qcom: icc-rpm: allow overwriting get_bw callback
interconnect: qcom: define OCMEM bus resource
interconnect: qcom: let platforms declare their bugginess
interconnect: qcom: msm8974: switch to the main icc-rpm driver
interconnect: qcom: msm8974: expand DEFINE_QNODE macros
Jie Gan [Fri, 27 Mar 2026 06:24:14 +0000 (14:24 +0800)]
coresight: cti: fix the check condition in inout_sel_store
Correct the upper bound from CTIINOUTEN_MAX to config->nr_trig_max,
since nr_trig_max varies across CTI devices. An out-of-bounds issue
occurs when a value greater than config->nr_trig_max is provided,
leading to unexpected errors.
Revert "ALSA: hda/intel: Add MSI X870E Tomahawk to denylist"
commit 30b3211aa2416 ("ALSA: hda/intel: Add MSI X870E Tomahawk
to denylist") was added to silence a warning, but this effectively
reintroduced commit df42ee7e22f03 ("ALSA: hda: Add ASRock
X670E Taichi to denylist") which was already reported to cause
problems and reverted in commit ee8f1613596ad ("Revert "ALSA: hda:
Add ASRock X670E Taichi to denylist"")
Revert it yet again.
Cc: stable@vger.kernel.org Reported-by: Juhyun Song <juju6985@outlook.kr> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221274 Cc: Stuart Hayhurst <stuart.a.hayhurst@gmail.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20260326190542.524515-1-mario.limonciello@amd.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
Wenkai Lin [Sat, 21 Mar 2026 07:00:38 +0000 (15:00 +0800)]
crypto: hisilicon/sec2 - prevent req used-after-free for sec
During packet transmission, if the system is under heavy load,
the hardware might complete processing the packet and free the
request memory (req) before the transmission function finishes.
If the software subsequently accesses this req, a use-after-free
error will occur. The qp_ctx memory exists throughout the packet
sending process, so replace the req with the qp_ctx.
Fixes: f0ae287c5045 ("crypto: hisilicon/sec2 - implement full backlog mode for sec") Signed-off-by: Wenkai Lin <linwenkai6@hisilicon.com> Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: inside-secure/eip93 - make it selectable for ECONET
Econet SoCs feature an integrated EIP93 in revision 3.0p1. It is identical
to the one used by the Airoha AN7581 and the MediaTek MT7621. Ahmed reports
that the EN7528 passes testmgr's self-tests. This driver should also work
on other little endian Econet SoCs.
CC: Ahmed Naseef <naseefkm@gmail.com> Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Reviewed-by: Antoine Tenart <atenart@kernel.org> Tested-by: Ahmed Naseef <naseefkm@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
T Pratham [Fri, 20 Mar 2026 10:50:52 +0000 (16:20 +0530)]
crypto: ti - Add support for AES-CCM in DTHEv2 driver
AES-CCM is an AEAD algorithm supporting both encryption and
authentication of data. This patch introduces support for AES-CCM AEAD
algorithm in the DTHEv2 driver.
Signed-off-by: T Pratham <t-pratham@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
T Pratham [Fri, 20 Mar 2026 10:50:51 +0000 (16:20 +0530)]
crypto: ti - Add support for AES-GCM in DTHEv2 driver
AES-GCM is an AEAD algorithm supporting both encryption and
authentication of data. This patch introduces support for AES-GCM as the
first AEAD algorithm supported by the DTHEv2 driver.
Signed-off-by: T Pratham <t-pratham@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: testmgr - Add test vectors for authenc(hmac(md5),rfc3686(ctr(aes)))
Test vectors were generated starting from existing RFC3686(CTR(AES)) test
vectors and adding HMAC(MD5) computed with software implementation.
Then, the results were double-checked on Mediatek MT7986 (safexcel).
Platform pass self-tests.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: qat - add anti-rollback support for GEN6 devices
Anti-Rollback (ARB) is a QAT GEN6 hardware feature that prevents loading
firmware with a Security Version Number (SVN) lower than an authorized
minimum. This protects against downgrade attacks by ensuring that only
firmware at or above a committed SVN can run on the acceleration device.
During firmware loading, the driver checks the SVN validation status via
a hardware CSR. If the check reports a failure, firmware authentication
is aborted. If it reports a retry status, the driver reissues the
authentication command up to a maximum number of retries.
Extend the firmware admin interface with two new messages,
ICP_QAT_FW_SVN_READ and ICP_QAT_FW_SVN_COMMIT, to query and commit the
SVN, respectively. Integrate the SVN check into the firmware
authentication path in qat_uclo.c so the driver can react to
anti-rollback status during device bring-up.
Expose SVN information to userspace via a new sysfs attribute group,
qat_svn, under the PCI device directory. The group provides read-only
attributes for the active, enforced minimum, and permanent minimum SVN
values, as well as a write-only commit attribute that allows a system
administrator to commit the currently active SVN as the new authorized
minimum.
This is based on earlier work by Ciunas Bennett.
Signed-off-by: Suman Kumar Chakraborty <suman.kumar.chakraborty@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Thorsten Blum [Thu, 19 Mar 2026 09:29:33 +0000 (10:29 +0100)]
crypto: caam - guard HMAC key hex dumps in hash_digest_key
Use print_hex_dump_devel() for dumping sensitive HMAC key bytes in
hash_digest_key() to avoid leaking secrets at runtime when
CONFIG_DYNAMIC_DEBUG is enabled.
Fixes: 045e36780f11 ("crypto: caam - ahash hmac support") Fixes: 3f16f6c9d632 ("crypto: caam/qi2 - add support for ahash algorithms") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Thorsten Blum [Thu, 19 Mar 2026 09:29:32 +0000 (10:29 +0100)]
printk: add print_hex_dump_devel()
Add print_hex_dump_devel() as the hex dump equivalent of pr_devel(),
which emits output only when DEBUG is enabled, but keeps call sites
compiled otherwise.
Suggested-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: John Ogness <john.ogness@linutronix.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: nx - Fix packed layout in struct nx842_crypto_header
struct nx842_crypto_header is declared with the __packed attribute,
however the fields grouped with struct_group_tagged() were not packed.
This caused the grouped header portion of the structure to lose the
packed layout guarantees of the containing structure.
Fix this by replacing struct_group_tagged() with __struct_group(...,
..., __packed, ...) so the grouped fields are packed, and the original
layout is preserved, restoring the intended packed layout of the
structure.
Thorsten Blum [Tue, 17 Mar 2026 20:18:06 +0000 (21:18 +0100)]
crypto: nx - annotate struct nx842_crypto_header with __counted_by
Add the __counted_by() compiler attribute to the flexible array member
'group' to improve access bounds-checking via CONFIG_UBSAN_BOUNDS and
CONFIG_FORTIFY_SOURCE.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Thorsten Blum [Tue, 17 Mar 2026 08:04:52 +0000 (09:04 +0100)]
crypto: s5p-sss - use unregister_{ahashes,skciphers} in probe/remove
Replace multiple for loops with calls to crypto_unregister_ahashes() and
crypto_unregister_skciphers().
If crypto_register_skcipher() fails in s5p_aes_probe(), log the error
directly instead of checking 'i < ARRAY_SIZE(algs)' later. Also drop
now-unused local index variables. No functional changes.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Lianqin Hu [Wed, 25 Mar 2026 06:26:48 +0000 (06:26 +0000)]
ALSA: usb-audio: Add iface reset and delay quirk for AB17X USB Audio
Setting up the interface when suspended/resumeing fail on this card.
Adding a reset and delay quirk will eliminate this problem.
usb 1-1: new full-speed USB device number 2 using xhci-hcd
usb 1-1: New USB device found, idVendor=001f, idProduct=0b23
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: AB17X USB Audio
usb 1-1: Manufacturer: Generic
usb 1-1: SerialNumber: 20241228172028
Yeoreum Yun [Sat, 14 Mar 2026 17:51:29 +0000 (17:51 +0000)]
arm64: futex: Refactor futex atomic operation
Refactor the futex atomic operations using ll/sc instructions in
preparation for FEAT_LSUI support. In addition, use named operands for
the inline asm.
ALSA: hda/realtek: add HP Laptop 15-fd0xxx mute LED quirk
HP Laptop 15-fd0xxx with ALC236 codec does not handle the toggling of
the mute LED.
This patch adds a quirk entry for subsystem ID 0x8dd7 using
ALC236_FIXUP_HP_MUTE_LED_COEFBIT2 fixup, enabling correct mute LED
behavior.
César Montoya [Sat, 21 Mar 2026 15:36:03 +0000 (10:36 -0500)]
ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-eg0xxx
The HP Pavilion 15-eg0xxx with subsystem ID 0x103c87cb uses a Realtek
ALC287 codec with a mute LED wired to GPIO pin 4 (mask 0x10). The
existing ALC287_FIXUP_HP_GPIO_LED fixup already handles this correctly,
but the subsystem ID was missing from the quirk table.
Kailang Yang [Thu, 19 Mar 2026 07:49:46 +0000 (15:49 +0800)]
ALSA: hda/realtek - Fixed Speaker Mute LED for HP EliteBoard G1a platform
On the HP EliteBoard G1a platform (models without a headphone jack).
the speaker mute LED failed to function. The Sysfs ctl-led info showed
empty values because the standard LED registration couldn't correctly
bind to the master switch.
Adding this patch will fix and enable the speaker mute LED feature.
Shawn Lin [Fri, 27 Mar 2026 04:11:23 +0000 (12:11 +0800)]
mmc: core: Switch to use pm_ptr() for mmc_host_class_dev_pm_ops
Currently, the mmc_host_class_dev_pm_ops and its callback
functions are wrapped in #ifdef CONFIG_PM_SLEEP to handle the
conditional compilation when PM support is disabled.
Replace this #ifdef usage with the standard pm_ptr() helpers. This
allows the compiler to automatically optimize away the unused code
paths when CONFIG_PM_SLEEP is not selected, resulting in cleaner and
more maintainable code.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Shawn Lin [Fri, 27 Mar 2026 04:07:29 +0000 (12:07 +0800)]
mmc: core: Remove legacy 'enable-sdio-wakeup' DT property support
The 'enable-sdio-wakeup' device tree property was marked as legacy and
superseded by the standard 'wakeup-source' property in commit 71a0151c5c82
("Documentation: devicetree: fix reference to legacy wakeup properties")
back in 2015.
Since it has been a decade and the migration to the standard property
has long been completed, remove this obsolete legacy support.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Takashi Iwai [Fri, 27 Mar 2026 09:16:52 +0000 (10:16 +0100)]
Merge tag 'asoc-fix-v7.0-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.0
This is two week's worth of fixes and quirks so it's a bit larger than
you might expect, there's nothing too exciting individually and nothing
in core code.
Guangshuo Li [Thu, 26 Mar 2026 17:14:12 +0000 (01:14 +0800)]
auxdisplay: line-display: fix NULL dereference in linedisp_release
linedisp_release() currently retrieves the enclosing struct linedisp via
to_linedisp(). That lookup depends on the attachment list, but the
attachment may already have been removed before put_device() invokes the
release callback. This can happen in linedisp_unregister(), and can also
be reached from some linedisp_register() error paths.
In that case, to_linedisp() returns NULL and linedisp_release()
dereferences it while freeing the display resources.
The struct device released here is the embedded linedisp->dev used by
linedisp_register(), so retrieve the enclosing object directly with
container_of() instead.
Fixes: 66c93809487e ("auxdisplay: linedisp: encapsulate container_of usage within to_linedisp") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Sherry Yang [Thu, 26 Mar 2026 16:17:19 +0000 (09:17 -0700)]
iommupt/amdv1: mark amdv1pt_install_leaf_entry as __always_inline
After enabling CONFIG_GCOV_KERNEL and CONFIG_GCOV_PROFILE_ALL, following
build failure is observed under GCC 14.2.1:
In function 'amdv1pt_install_leaf_entry',
inlined from '__do_map_single_page' at drivers/iommu/generic_pt/fmt/../iommu_pt.h:650:3,
inlined from '__map_single_page0' at drivers/iommu/generic_pt/fmt/../iommu_pt.h:661:1,
inlined from 'pt_descend' at drivers/iommu/generic_pt/fmt/../pt_iter.h:391:9,
inlined from '__do_map_single_page' at drivers/iommu/generic_pt/fmt/../iommu_pt.h:657:10,
inlined from '__map_single_page1.constprop' at drivers/iommu/generic_pt/fmt/../iommu_pt.h:661:1:
././include/linux/compiler_types.h:706:45: error: call to '__compiletime_assert_71' declared with attribute error: FIELD_PREP: value too large for the field
706 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
|
......
drivers/iommu/generic_pt/fmt/amdv1.h:220:26: note: in expansion of macro 'FIELD_PREP'
220 | FIELD_PREP(AMDV1PT_FMT_OA,
| ^~~~~~~~~~
In the path '__do_map_single_page()', level 0 always invokes
'pt_install_leaf_entry(&pts, map->oa, PAGE_SHIFT, …)'. At runtime that
lands in the 'if (oasz_lg2 == isz_lg2)' arm of 'amdv1pt_install_leaf_entry()';
the contiguous-only 'else' block is unreachable for 4 KiB pages.
With CONFIG_GCOV_KERNEL + CONFIG_GCOV_PROFILE_ALL, the extra
instrumentation changes GCC's inlining so that the "dead" 'else' branch
still gets instantiated. The compiler constant-folds the contiguous OA
expression, runs the 'FIELD_PREP()' compile-time check, and produces:
FIELD_PREP: value too large for the field
gcov-enabled builds therefore fail even though the code path never executes.
Fix this by marking amdv1pt_install_leaf_entry as __always_inline.
Fixes: dcd6a011a8d5 ("iommupt: Add map_pages op") Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sherry Yang <sherry.yang@oracle.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Guanghui Feng [Thu, 19 Mar 2026 07:37:54 +0000 (15:37 +0800)]
iommu/amd: Fix illegal cap/mmio access in IOMMU debugfs
In the current AMD IOMMU debugfs, when multiple processes simultaneously
access the IOMMU mmio/cap registers using the IOMMU debugfs, illegal
access issues can occur in the following execution flow:
1. CPU1: Sets a valid access address using iommu_mmio/capability_write,
and verifies the access address's validity in iommu_mmio/capability_show
2. CPU2: Sets an invalid address using iommu_mmio/capability_write
3. CPU1: accesses the IOMMU mmio/cap registers based on the invalid
address, resulting in an illegal access.
This patch modifies the execution process to first verify the address's
validity and then access it based on the same address, ensuring
correctness and robustness.
Guanghui Feng [Thu, 19 Mar 2026 07:37:53 +0000 (15:37 +0800)]
iommu/amd: Fix illegal device-id access in IOMMU debugfs
In the current AMD IOMMU debugFS, when multiple processes use the IOMMU
debugFS process simultaneously, illegal access issues can occur in the
following execution flow:
1. CPU1: Sets a valid sbdf via devid_write, then checks the sbdf's
validity in execution flows such as devid_show, iommu_devtbl_show,
and iommu_irqtbl_show.
2. CPU2: Sets an invalid sbdf via devid_write, at which point the sbdf
value is -1.
3. CPU1: accesses the IOMMU device table, IRQ table, based on the
invalid SBDF value of -1, resulting in illegal access.
This is especially problematic in monitoring scripts, where multiple
scripts may access debugFS simultaneously, and some scripts may
unexpectedly set invalid values, which triggers illegal access in
debugfs.
This patch modifies the execution flow of devid_show,
iommu_devtbl_show, and iommu_irqtbl_show to ensure that these
processes determine the validity and access based on the
same device-id, thus guaranteeing correctness and robustness.
Jason Gunthorpe [Mon, 2 Mar 2026 22:22:53 +0000 (18:22 -0400)]
iommupt: Fix short gather if the unmap goes into a large mapping
unmap has the odd behavior that it can unmap more than requested if the
ending point lands within the middle of a large or contiguous IOPTE.
In this case the gather should flush everything unmapped which can be
larger than what was requested to be unmapped. The gather was only
flushing the range requested to be unmapped, not extending to the extra
range, resulting in a short invalidation if the caller hits this special
condition.
This was found by the new invalidation/gather test I am adding in
preparation for ARMv8. Claude deduced the root cause.
As far as I remember nothing relies on unmapping a large entry, so this is
likely not a triggerable bug.
Jason Gunthorpe [Mon, 2 Mar 2026 22:22:52 +0000 (18:22 -0400)]
iommu: Do not call drivers for empty gathers
An empty gather is coded with start=U64_MAX, end=0 and several drivers go
on to convert that to a size with:
end - start + 1
Which gives 2 for an empty gather. This then causes Weird Stuff to
happen (for example an UBSAN splat in VT-d) that is hopefully harmless,
but maybe not.
Prevent drivers from being called right in iommu_iotlb_sync().
Auditing shows that AMD, Intel, Mediatek and RSIC-V drivers all do things
on these empty gathers.
Further, there are several callers that can trigger empty gathers,
especially in unusual conditions. For example iommu_map_nosync() will call
a 0 size unmap on some error paths. Also in VFIO, iommupt and other
places.
Cc: stable@vger.kernel.org Reported-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Closes: https://lore.kernel.org/r/11145826.aFP6jjVeTY@jkrzyszt-mobl2.ger.corp.intel.com Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Ammar Mustafa [Fri, 27 Feb 2026 19:08:33 +0000 (14:08 -0500)]
Docs: iio: ad7191 Correct clock configuration
Correct the ad7191 documentation to match the datasheet:
- Fix inverted CLKSEL pin logic: device uses external clock when pin is
inactive, and internal CMOS/crystal when high.
- Correct CMOS-compatible clock pin from MCLK2 to MCLK1.
Signed-off-by: Ammar Mustafa <ammarmustafa34@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Kees Cook [Mon, 23 Mar 2026 17:17:14 +0000 (10:17 -0700)]
um: Replace strncpy() with strnlen()+memcpy_and_pad() in strncpy_chunk_from_user()
Replace the deprecated[1] strncpy() with strnlen() on the source
followed by memcpy_and_pad().
This function is a chunk callback for UML's strncpy_from_user()
implementation, called by buffer_op() to process userspace memory one
page at a time. The source is a kernel-mapped userspace address that
is not guaranteed to be NUL-terminated; "len" bounds how many bytes
to read from it.
By measuring the source string length first with strnlen(), we avoid
reading past the NUL terminator in the source. memcpy_and_pad() then
copies the string content and zero-fills the remainder of the chunk,
preserving the original strncpy() behavior exactly: copy up to the
first NUL, then pad with zeros to the full length.
strtomem_pad() would be the idiomatic helper for this strnlen() +
memcpy_and_pad() pattern, but it requires a compile-time-determinable
destination size (via ARRAY_SIZE()). Here the destination is a char *
into a caller-provided buffer and the chunk length is a runtime value,
so the explicit two-step is necessary.
No behavioral change: the same bytes are written to the destination
(string content followed by zero padding), the pointer advances by
the same amount, and the NUL-found return condition is unchanged.
projects / thirdparty / linux.git / log
