summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-06-05arm64: dts: lx2160a-cex7: add usb hubJosua Mayer
LX2160A CEX-7 module provides a total of 4 USB ports to the carrier board, one from first usb controller, and 3 from a hub behind the second controller. Both controllers currently have their status set okay in the module's dtsi file. However devices should be disabled by default when incomplete. The first USB controller is only completed by a carrier board featuring a device or USB connector. The second controller hosts a USB hub and should therefore be active. Add description for the USB hub, and enable the first controller only in the carrier board description. Signed-off-by: Josua Mayer <josua@solid-run.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: lx2160a-clearfog-itx: move shared includes to dtsJosua Mayer
Originally includes were defined hierarchically: - CEX-7 Module includes SoC - Clearfog-CX & Honeycomb common parts include CEX-7 Module - Boards include common parts This makes it difficult to modify the includes on a per-board level, e.g. when adding a new board based on CEX-7 module but revision 2 SoC (which now has its own soc dtsi). Move includes of both SoC and CEX-7 module out of common parts and into each board dts. Signed-off-by: Josua Mayer <josua@solid-run.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: lx2160a-clearfog-itx: remove redundant dts version tagJosua Mayer
The dts version tag should only appear in the top level dts file. Since the cex-7 module and clearfog-itx are shared code intended for inclusion, drop their dts version tags. Signed-off-by: Josua Mayer <josua@solid-run.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05dt-bindings: arm: fsl: Add solidrun lx2160a twins boardJosua Mayer
The SolidRun LX2160A Twins board supports two configurations, one with with a single CEX-7 module, and one with two (dual). The single configuration is a specific assembly that maximises connectivity for single cpu by routing some second cpu resources to the first via zero-Ohm resistors. The dual configuration was not yet tested and is intentionally omitted. Initial review strongly suggests that the dual configuration will have different bindings, because from either cpu point of view the board appears different (e.g. different number of sfp, fewer i2c gpio). Add binding for the single variant only. Signed-off-by: Josua Mayer <josua@solid-run.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: lx2162a-clearfog: specify sfp ports led colour and functionJosua Mayer
The LX2162A Clearfog board has a green LED on each of four SFP ports. Describe in device-tree that their colour is green and function "lan". Signed-off-by: Josua Mayer <josua@solid-run.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: lx2162a-clearfog: cleanup superfluous status propertiesJosua Mayer
The SoC dtsi has always enabled serdes block 1, enabled dpmac and disabled pcie nodes. Drop the superfluous status properties on these nodes. Further drop crypto alias as SoM dtsi already set it. Signed-off-by: Josua Mayer <josua@solid-run.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: lx2162a-clearfog: use rev2 SoC dtsiJosua Mayer
LX2160A and LX2162A are different packages of the same silicon. While LX2160A had two revisions, LX2162A was released later based on LX2160A revision 2. Commit a8fe6c8dfc40 ("arm64: dts: fsl-lx2160a: add rev2 support") has added a new soc dtsi for revision 2. Update LX2162A Clearfog description to use revision 2 dtsi. Fixes: 5093b190f9ce ("arm64: dts: freescale: Add support for LX2162 SoM & Clearfog Board") # no-stable Signed-off-by: Josua Mayer <josua@solid-run.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: lx2160a-rev2: extend 32-bit and add 64-bit pci regionsJosua Mayer
LX2160 SoC PCIe controller supports 64-bit memory regions up to 16GB, 32-bit regions up to 3GB and 16-bit regions up to 64k. For each PCIe controller: - extend the existing 32-bit regions to 3GB size - add 64-bit region See [1] and [2] for boot messages showing ranges before and after. On LX2160A Silicon revision 1, the pcie driver fails to program atu for ranges larger than 4GB [3]. Therefore changes are limited to revision 2. Similar memory allocation with similar flags was tested with UEFI and ACPI on pcie3 and pcie5, on a variety of nxp vendor fork versions. Fixes allocation of large, and 64-bit BARs as requested by many PCI cards especially graphics processors or AI accelerators, e.g.: [ 2.941187] pci 0000:01:00.0: BAR 0: no space for [mem size 0x200000000 64bit pref] [ 2.948834] pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x200000000 64bit pref] [1] example of new allocations (pcie5): [ 1.182745] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges: [ 1.182760] layerscape-pcie 3800000.pcie: MEM 0xa400000000..0xa7ffffffff -> 0xa400000000 [ 1.182771] layerscape-pcie 3800000.pcie: MEM 0xa040000000..0xa0ffffffff -> 0x0040000000 [ 1.182778] layerscape-pcie 3800000.pcie: IO 0xa000010000..0xa00001ffff -> 0x0000000000 [ 1.183642] layerscape-pcie 3800000.pcie: iATU: unroll F, 256 ob, 24 ib, align 4K, limit 4G [ 1.385429] layerscape-pcie 3800000.pcie: PCIe Gen.3 x8 link up [ 1.385481] layerscape-pcie 3800000.pcie: PCI host bridge to bus 0001:00 [ 1.385484] pci_bus 0001:00: root bus resource [bus 00-ff] [ 1.385488] pci_bus 0001:00: root bus resource [mem 0xa400000000-0xa7ffffffff pref] [ 1.385491] pci_bus 0001:00: root bus resource [mem 0xa040000000-0xa0ffffffff] (bus address [0x40000000-0xffffffff]) [ 1.385494] pci_bus 0001:00: root bus resource [io 0x10000-0x1ffff] (bus address [0x0000-0xffff]) [ 1.385516] pci 0001:00:00.0: [1957:8d80] type 01 class 0x060400 PCIe Root Port [ 1.385538] pci 0001:00:00.0: PCI bridge to [bus 01-ff] [ 1.385544] pci 0001:00:00.0: bridge window [io 0x11000-0x11fff] [ 1.385548] pci 0001:00:00.0: bridge window [mem 0xa040000000-0xa0502fffff] [ 1.385605] pci 0001:00:00.0: supports D1 D2 [ 1.385607] pci 0001:00:00.0: PME# supported from D0 D1 D2 D3hot [ 1.386778] pci 0001:01:00.0: [1002:6995] type 00 class 0x030000 PCIe Legacy Endpoint [ 1.387336] pci 0001:01:00.0: BAR 0 [mem 0xa040000000-0xa04fffffff 64bit pref] [ 1.387368] pci 0001:01:00.0: BAR 2 [mem 0xa050000000-0xa0501fffff 64bit pref] [ 1.387385] pci 0001:01:00.0: BAR 4 [io 0x11000-0x110ff] [ 1.387402] pci 0001:01:00.0: BAR 5 [mem 0xa050200000-0xa05023ffff] [ 1.387418] pci 0001:01:00.0: ROM [mem 0xa050240000-0xa05025ffff pref] [ 1.387493] pci 0001:01:00.0: enabling Extended Tags [ 1.388960] pci 0001:01:00.0: supports D1 D2 [2] example of previous allocations (pcie5): [ 1.716744] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges: [ 1.724060] layerscape-pcie 3800000.pcie: MEM 0xa040000000..0xa07fffffff -> 0x0040000000 [ 1.733277] layerscape-pcie 3800000.pcie: iATU: unroll F, 256 ob, 24 ib, align 4K, limit 4G [ 1.836220] layerscape-pcie 3800000.pcie: PCIe Gen.3 x8 link up [ 1.842186] layerscape-pcie 3800000.pcie: PCI host bridge to bus 0001:00 [ 1.848883] pci_bus 0001:00: root bus resource [bus 00-ff] [ 1.854363] pci_bus 0001:00: root bus resource [mem 0xa040000000-0xa07fffffff] (bus address [0x40000000-0x7fffffff]) [ 1.864892] pci 0001:00:00.0: [1957:8d80] type 01 class 0x060400 PCIe Root Port [ 1.872216] pci 0001:00:00.0: PCI bridge to [bus 01-ff] [ 1.877438] pci 0001:00:00.0: bridge window [io 0x1000-0x1fff] [ 1.883526] pci 0001:00:00.0: bridge window [mem 0xa040000000-0xa0502fffff] [3] error programming atu beyond 4GB: [ 1.716762] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges: [ 1.724080] layerscape-pcie 3800000.pcie: MEM 0xa400000000..0xa7ffffffff -> 0xa400000000 [ 1.732615] layerscape-pcie 3800000.pcie: MEM 0xa040000000..0xa0ffffffff -> 0x0040000000 [ 1.741142] layerscape-pcie 3800000.pcie: IO 0xa010000000..0xa01000ffff -> 0x0000000000 [ 1.750379] layerscape-pcie 3800000.pcie: iATU: unroll F, 256 ob, 24 ib, align 4K, limit 4G [ 1.759089] layerscape-pcie 3800000.pcie: Failed to set MEM range [mem 0xa400000000-0xa7ffffffff flags 0x2200] [ 1.769089] layerscape-pcie 3800000.pcie: probe with driver layerscape-pcie failed with error -22 [4] pci bootloaderp atching related errors with IORESOURCE_MEM_64 flag: [ 0.967809] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges: [ 0.967830] layerscape-pcie 3800000.pcie: MEM 0xa400000000..0xa7ffffffff -> 0xa400000000 [ 0.967842] layerscape-pcie 3800000.pcie: MEM 0xa040000000..0xa0ffffffff -> 0x0040000000 [ 0.967849] layerscape-pcie 3800000.pcie: IO 0xa000010000..0xa00001ffff -> 0x0000000000 [ 1.169315] pci 0000:01:00.0: [8086:1572] type 00 class 0x020000 PCIe Endpoint [ 1.169733] pci 0000:01:00.0: BAR 0 [mem 0x00000000-0x00ffffff 64bit pref] [ 1.169771] pci 0000:01:00.0: BAR 3 [mem 0x00000000-0x00007fff 64bit pref] [ 1.169796] pci 0000:01:00.0: ROM [mem 0x00000000-0x0007ffff pref] [ 1.173389] OF: /soc/pcie@3800000: no msi-map translation for id 0x100 on (null) [ 1.173515] OF: /soc/pcie@3800000: no iommu-map translation for id 0x100 on (null) Signed-off-by: Josua Mayer <josua@solid-run.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: imx95: Correct PCIe outbound address space configurationRichard Zhu
Fix the PCIe outbound memory ranges for both pcie0 and pcie1 controllers on i.MX95. The memory window size was incorrectly set to 256MB during initial bring-up, but the hardware supports up to 4GB of outbound address space per controller. Additionally, the ECAM region cannot be mapped as I/O space. Use a memory-mapped region for I/O space instead, and relocate the 1MB I/O region to immediately follow the memory region at offset 0xf0000000 within each window. Update the outbound address space layout per controller as follows: - 3.5GB 64-bit prefetchable memory - 256MB 32-bit non-prefetchable memory - 1MB I/O Fixes: 3b1d5deb29ff ("arm64: dts: imx95: add pcie[0,1] and pcie-ep[0,1] support") Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: imx91-9x9-qsb: add reset gpios for ethernet PHYsJoy Zou
The PHYs of the EQOS interface is supported to be reset by I2C GPIO expander. So add the support to reset PHYs. Signed-off-by: Joy Zou <joy.zou@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: imx91-11x11-evk: add reset gpios for ethernet PHYsJoy Zou
Both the PHYs of the EQOS interface and the FEC interface are supported to be reset by I2C GPIO expander. So add the support to reset PHYs. Signed-off-by: Joy Zou <joy.zou@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: imx91-11x11-evk: add pinctrl for wdog3 resetJoy Zou
The wdog3 node enables fsl,ext-reset-output to assert an external reset signal upon watchdog timeout, but lacks pinctrl configuration for the physical pad. Without proper pinctrl settings, which could cause the watchdog timeout to fail to reset the board hardware. Add pinctrl configuration to ensure the pin is properly muxed and configured for external watchdog reset functionality. Signed-off-by: Joy Zou <joy.zou@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: imx91-9x9-qsb: add pinctrl for wdog3 resetJoy Zou
The wdog3 node enables fsl,ext-reset-output to assert an external reset signal upon watchdog timeout, but lacks pinctrl configuration for the physical pad. Without proper pinctrl settings, which could cause the watchdog timeout to fail to reset the board hardware. Add pinctrl configuration to ensure the pin is properly muxed and configured for external watchdog reset functionality. Signed-off-by: Joy Zou <joy.zou@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: imx91-9x9-qsb: remove unused property clock-frequency from mdio nodeJoy Zou
The clock-frequency property is not implemented. Remove it to clean up the device tree. Signed-off-by: Joy Zou <joy.zou@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: freescale: add bootph-all to watchdog nodes for i.MX platformsAlice Guo
Add the bootph-all property to ULP watchdog nodes across multiple i.MX SoC device trees, ensuring the watchdog is available during all boot phases. The affected watchdog nodes are: - imx8ulp: wdog3 - imx91/93: wdog3, wdog4, wdog5 - imx94: wdog3 - imx95: wdog3 - imx952: wdog3 Signed-off-by: Alice Guo <alice.guo@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: imx94: fix DDR PMU interrupt numberAlice Guo
The DDR Performance Monitor node was added with incorrect interrupt number 91, which actually belongs to the wdog4 watchdog. Fix it to the correct interrupt number 374. Fixes: e918e5f847b3 ("arm64: dts: imx94: add DDR Perf Monitor node") Signed-off-by: Alice Guo <alice.guo@nxp.com> Reviewed-by: Xu Yang <xu.yang_2@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: s32g: add SAR ADC support for s32g2 and s32g3Khristine Andreea Barbulescu
Add ADC0 and ADC1 for S32G2 and S32G3 SoCs. Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com> Reviewed-by: Enric Balletbo i Serra <eballetb@redhat.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: imx943-evk: Fix PCIe EP vpcie-supplySherry Sun
The vpcie-supply property should reference the regulator that controls the actual M.2 power supply, not the W_DISABLE1# signal. On imx943-evk: - reg_m2_wlan controls M.2 W_DISABLE1# signal - reg_m2_pwr controls the actual M.2 power supply Fix the vpcie-supply to use reg_m2_pwr for proper power control in PCIe endpoint mode. Fixes: 1962c596d51c ("arm64: dts: imx943-evk: Add pcie[0,1] and pcie-ep[0,1] support") Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: s32g: add PIT support for s32g2 and s32g3Khristine Andreea Barbulescu
Add PIT0 and PIT1 for S32G2 and S32G3 SoCs Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com> Reviewed-by: Enric Balletbo i Serra <eballetb@redhat.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: imx8mp-kontron: Reduce EERAM SPI clock frequencyFrieder Schrempf
There is an onboard level shifter for the SPI signals that causes additional propagation delay and renders the SPI transmission unreliable at 20 MHz. Reduce the clock frequency to a safe value. Fixes: 946ab10e3f40 ("arm64: dts: Add support for Kontron OSM-S i.MX8MP SoM and BL carrier board") Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: imx95: Add Root Port node and PERST propertySherry Sun
Since describing the PCIe PERST# property under Host Bridge node is now deprecated, it is recommended to add it to the Root Port node, so creating the Root Port node and add the reset-gpios property in Root Port. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: imx8dxl/qm/qxp: Add Root Port node and PERST propertySherry Sun
Since describing the PCIe PERST# property under Host Bridge node is now deprecated, it is recommended to add it to the Root Port node, so creating the Root Port node and add the reset-gpios property in Root Port. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: imx8mq: Add Root Port node and PERST propertySherry Sun
Since describing the PCIe PERST# property under Host Bridge node is now deprecated, it is recommended to add it to the Root Port node, so creating the Root Port node and add the reset-gpios property in Root Port. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: imx8mp: Add Root Port node and PERST propertySherry Sun
Since describing the PCIe PERST# property under Host Bridge node is now deprecated, it is recommended to add it to the Root Port node, so creating the Root Port node and add the reset-gpios property in Root Port. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: imx8mm: Add Root Port node and PERST propertySherry Sun
Since describing the PCIe PERST# property under Host Bridge node is now deprecated, it is recommended to add it to the Root Port node, so creating the Root Port node and add the reset-gpios property in Root Port. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05arm64: dts: imx8mp: Add DT overlays for DH i.MX8M Plus DHCOM SoM and boardsMarek Vasut
Add DT overlays to support DH i.MX8M Plus DHCOM SoM variants and carrier board expansion modules. The following DT overlays are implemented: - SoM: - DH 660-x00 SoM with 1xRMII PHY - DH 660-x00 SoM with 2xRMII PHY - PDK2: - DH 505-200 Display board in edge connector X12 via direct LVDS - DH 531-100 SPI/I2C board in header X21 - DH 531-200 SPI/I2C board in header X22 - DH 560-200 Display board in edge connector X12 - PDK3: - DH 505-200 Display board in edge connector X36 via direct LVDS - DH 531-100 SPI/I2C board in header X40 - DH 531-200 SPI/I2C board in header X41 - DH 560-300 Display board in edge connector X36 - EA muRata 2AE M.2 A/E-Key card in connector X20 - NXP SPF-29853-C1 MINISASTOCSI with OV5640 sensor in connector X31 - NXP SPF-29853-C1 MINISASTOCSI with OV5640 sensor in connector X29 - PicoITX: - DH 626-100 Display board in edge connector X2 Signed-off-by: Marek Vasut <marex@nabladev.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-05RDMA/irdma: Initialize iwmr->access during MR registrationJacob Moroni
Initialize iwmr->access during initial user mem registration so that it contains a valid value during a subsequent rereg_mr. Otherwise, a rereg_mr that doesn't set IB_MR_REREG_ACCESS (for example, one that only changes the PD) ends up clearing the access flags in HW since iwmr->access is zero-initialized, which is not intended. Fixes: 5ac388db27c4 ("RDMA/irdma: Add support to re-register a memory region") Link: https://patch.msgid.link/r/20260604154104.4035581-1-jmoroni@google.com Signed-off-by: Jacob Moroni <jmoroni@google.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05RDMA/irdma: Fix OOB read during CQ MR registrationJacob Moroni
Sashiko pointed out an unrelated bug during a previous patch: https://sashiko.dev/#/patchset/20260512183852.614045-1-jmoroni%40google.com This change fixes the bug by eliminating the cqmr->split field which was not being set properly and instead just checks the CQ resize feature flag directly. The cqmr->split field essentially tracks whether IRDMA_FEATURE_CQ_RESIZE is set, but it was not being set until CQ creation time, which is _after_ CQ memory registration (the only other place where it is referenced). As a result, it would always be false during MR registration and would therefore cause irdma_handle_q_mem to populate cqmr->shadow even for GEN_2 HW and beyond: cqmr->shadow = (dma_addr_t)arr[req->cq_pages]; The issue is that for GEN_2 and beyond, req->cq_pages may be exactly equal to iwmr->page_cnt and therefore equal to the size of arr, which would cause an OOB read by one. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Link: https://patch.msgid.link/r/20260602214423.1315105-2-jmoroni@google.com Signed-off-by: Jacob Moroni <jmoroni@google.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05RDMA/irdma: Remove redundant legacy_mode checksJacob Moroni
The driver has the following invariants: 1. legacy_mode is only allowed on GEN_1 hardware (enforced in irdma_alloc_ucontext). 2. GEN_1 hardware does not set IRDMA_FEATURE_CQ_RESIZE or IRDMA_FEATURE_RTS_AE. These feature flags are only set for GEN_2 and GEN_3 hardware. Therefore, legacy_mode is always false if IRDMA_FEATURE_CQ_RESIZE or IRDMA_FEATURE_RTS_AE is set, so remove the redundant checks. Link: https://patch.msgid.link/r/20260602214423.1315105-1-jmoroni@google.com Signed-off-by: Jacob Moroni <jmoroni@google.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05RDMA/siw: bound Read Response placement to the RREAD lengthMichael Bommarito
In drivers/infiniband/sw/siw/siw_qp_rx.c, siw_proc_rresp() places each inbound Read Response DDP segment at sge->laddr + wqe->processed and then accumulates wqe->processed, but it never checks the running total against the sink buffer length on continuation segments. siw_check_sge() resolves and validates the sink memory only on the first fragment (the if (!*mem) branch), and siw_rresp_check_ntoh() compares the cumulative length against wqe->bytes only on the final segment (the !frx->more_ddp_segs guard). A connected siw peer that answers an outstanding RREAD with Read Response segments that keep the DDP Last flag clear, carrying more total payload than the RREAD requested, drives wqe->processed past the validated sink buffer; the next siw_rx_data() call writes out of bounds at sge->laddr + wqe->processed. siw runs iWARP over ordinary routable TCP, so the peer is the remote end of an established RDMA connection and needs no local privilege. Bound every segment before placement, exactly as siw_proc_send() and siw_proc_write() already do for their tagged and untagged paths, and terminate the connection with a base-or-bounds DDP error when the Read Response would overrun the sink buffer. This is the second receive-path length fix for this file. A separate change rejects an MPA FPDU length that underflows the per-fragment remainder in the header decode; that guard does not cover this case, because here each individual segment length is self-consistent and only the accumulated placement offset overruns the buffer. Fixes: 8b6a361b8c48 ("rdma/siw: receive path") Link: https://patch.msgid.link/r/20260602194700.2273758-1-michael.bommarito@gmail.com Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05Merge tag 'kvmarm-fixes-7.1-5' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 7.1, take #5 - Correctly drop the ITS translation cache reference when it actually gets invalidated - Take the SRCU lock for SW page table walks - Restore POR_EL0 access to host EL0, avoiding POR_EL0 becoming inaccessible from EL0 after running a guest - Reassign nested_mmus array behind mmu_lock, ensuring that vcpu init and MMU notifiers are mutually exclusive - Correctly handle FEAT_XNX at stage-2
2026-06-05vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arcJunrui Luo
vfio_mig_get_next_state() walks vfio_from_fsm_table[] one step at a time, looping to skip optional states the device does not support until *next_fsm is supported. A blocked transition is encoded as VFIO_DEVICE_STATE_ERROR, which the trailing return reports as -EINVAL. The skip loop does not account for the ERROR sentinel. state_flags_table[ERROR] is ~0U and vfio_from_fsm_table[ERROR][*] is ERROR, so once *next_fsm becomes ERROR the loop condition stays true and *next_fsm never changes. The blocked arcs STOP_COPY -> PRE_COPY and STOP_COPY -> PRE_COPY_P2P map to ERROR yet pass the support check on a precopy-capable device, causing the loop to spin forever while holding the driver state mutex. This can result in a soft lockup, and a panic with softlockup_panic set. Terminate the skip loop on the ERROR sentinel so a blocked transition falls through to the existing return and reports -EINVAL. Fixes: 4db52602a607 ("vfio: Extend the device migration protocol with PRE_COPY") Reported-by: Yuhao Jiang <danisjiang@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo <moonafterrain@outlook.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/SYBPR01MB7881290BBDE79B61AE6A017FAF122@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-06-05vfio/nvgrace-gpu: Add Blackwell-Next GPU readiness check via CXL DVSECAnkit Agrawal
Add a CXL DVSEC-based readiness check for Blackwell-Next GPUs alongside the existing legacy BAR0 polling path. The CXL Device DVSEC offset is discovered at probe time. Probe, fault and read/write paths then branch on that to use either the legacy BAR0 polling or the CXL DVSEC polling. The CXL path polls Memory_Active, requiring MEM_INFO_VALID within 1s and MEM_ACTIVE within Memory_Active_Timeout (up to 256s) as per CXL spec r4.0 sec 8.1.3.8.2. Given the long worst-case wait, the CXL poll runs outside memory_lock with only a quick readiness check is done under the lock. The poll loops sleep with schedule_timeout_killable() and return -EINTR on a fatal signal. This avoids hung-task panics during the long uninterruptible wait. Extend this to the legacy based wait as well for improvement. In the fault handler the wait runs locklessly before memory_lock. If a reset races in, the in-lock recheck returns -EAGAIN and the wait is retried rather than returning a spurious VM_FAULT_SIGBUS. Add PCI_DVSEC_CXL_MEM_ACTIVE_TIMEOUT to pci_regs.h for the timeout field. Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Suggested-by: Alex Williamson <alex@shazbot.org> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20260602063015.3915-1-ankita@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-06-05RDMA/mlx5: Fix state and counter desync on loopback enable failureLi RongQing
In mlx5_ib_enable_lb(), dev->lb.enabled was unconditionally set to true even if mlx5_nic_vport_update_local_lb() failed. Fix this by only setting dev->lb.enabled on success. On failure, roll back the reference counters and return the error. Link: https://patch.msgid.link/r/20260601095818.2227-1-lirongqing@baidu.com Signed-off-by: Li RongQing <lirongqing@baidu.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05RDMA/mlx5: Fix error propagation in __mlx5_ib_addLi RongQing
__mlx5_ib_add() currently returns -ENOMEM on any stage initialization failure, losing the actual error code returned by the init function. This makes it impossible for callers to distinguish between different failure reasons (e.g. -EINVAL, -EIO, -EOPNOTSUPP) and leads to misleading error handling. Fix it by returning the actual error code stored in 'err'. Link: https://patch.msgid.link/r/20260601095654.2178-1-lirongqing@baidu.com Signed-off-by: Li RongQing <lirongqing@baidu.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05Merge tag 'nfs-for-7.1-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfsLinus Torvalds
Pull NFS client fix from Trond Myklebust: - Fix a use after free in nfs_write_completion * tag 'nfs-for-7.1-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: NFS: write_completion: dereference loop-local req, not hdr->req
2026-06-05ALSA: hda: fix Kconfig dependency of HD Audio PCIOliver Hartkopp
With commit 2d9223d2d64c ("ALSA: hda: Move controller drivers into sound/hda/controllers directory") the HD Audio drivers have been moved from linux/sound/pci/hda to linux/sound/hda. But the Kconfig dependency for SND_HDA_INTEL stayed on SND_PCI instead of depending on PCI directly. To make the "HD Audio PCI" configuration entry visible it is currently needed to enable "PCI sound devices" although no PCI device in the submenu needs to be selected. Make SND_HDA_INTEL directly depending on hardware/architecture like the other entries in this Kconfig. Fixes: 2d9223d2d64c ("ALSA: hda: Move controller drivers into sound/hda/controllers directory") Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://patch.msgid.link/20260529-hda-kconfig-v1-1-4a2c6a0efd56@hartkopp.net Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-06-05accel/amdxdna: Require carveout when PASID and force_iova are disabledLizhi Hou
When both PASID and force_iova are disabled, carveout memory should be used. Reject buffer allocations that cannot use carveout memory in this configuration and return an error. Fixes: 3cc5d7a59519 ("accel/amdxdna: Add carveout memory support for non-IOMMU systems") Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260604195459.2423279-1-lizhi.hou@amd.com
2026-06-05KVM: riscv: selftests: Split SBI FWFT into separate feature-specific sublistsYong-Xuan Wang
Divide the monolithic SBI FWFT (Firmware Features) register list into separate sublists, each testing a specific FWFT feature independently with proper dependency checking. Previously, all FWFT features were tested together in a single sublist. This caused issues because: 1. Not all FWFT features are available on all platforms 2. Some features depend on specific ISA extensions (e.g., pointer_masking requires Smnpm) 3. Tests would fail if any single feature was unavailable Add the feature-specific SBI FWFT sublists with the following improvements: - Add check_fwft_feature() helper to verify FWFT feature availability at runtime - Update filter_reg() to handle per-feature FWFT register filtering Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260601-kvm-get_reg_list-v2-v5-5-415d08a2813b@sifive.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-05KVM: riscv: selftests: Refactor ISA and SBI extension sublist macrosYong-Xuan Wang
Refactor the get-reg-list test to use unified sublist macros for ISA and SBI extensions, eliminating code duplication and improving maintainability. Previously, each extension had its own hand-coded sublist definition (e.g., SUBLIST_ZICBOM, SUBLIST_AIA, etc.) and the config structures repeated the same pattern. This made the code verbose and error-prone. Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260601-kvm-get_reg_list-v2-v5-4-415d08a2813b@sifive.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-05KVM: RISC-V: SBI FWFT: Fix stale feature exposure after runtime extension ↵Yong-Xuan Wang
changes Fix a bug where FWFT features could be incorrectly exposed to guests after userspace disables their dependent ISA extensions at runtime. The 'supported' field in kvm_sbi_fwft_config was set once during vCPU initialization based on the initial hardware/extension availability. However, when userspace subsequently disables ISA extensions via the KVM ONE_REG interface, the 'supported' field was not updated. This caused the following issues: 1. FWFT features would remain visible and accessible to guests even after their prerequisite ISA extensions were disabled 2. Guests could configure FWFT features that depend on disabled extensions, leading to undefined behavior 3. The static 'supported' flag and the dynamic supported() callback could disagree about feature availability The fix introduces a two-layer checking mechanism: 1. Add an optional init() callback to the kvm_sbi_fwft_feature structure for features that require hardware probing during initialization. This separates the one-time hardware detection logic from the runtime availability check. 2. Add runtime checks in all FWFT-related functions that call feature->supported(vcpu) if the callback exists. This ensures feature availability is re-evaluated based on the current ISA extension state. This approach maintains the cached 'supported' field for initialization- time decisions while ensuring runtime availability is always determined by the current vCPU configuration, not initialization-time snapshots. Fixes: 6b72fd170592 ("RISC-V: KVM: add support for FWFT SBI extension") Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260601-kvm-get_reg_list-v2-v5-3-415d08a2813b@sifive.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-05KVM: RISC-V: SBI FWFT: Add optional init() callback for hardware probingYong-Xuan Wang
Add an optional init() callback to separate one-time hardware probing from runtime availability checks. For pointer masking, this allows probing supported PMM lengths during initialization while checking ISA extension availability at runtime. Fix try_to_set_pmm() to restore the previous HENVCFG.PMM value after probing, preventing side effects from hardware detection. Add preemption protection to ensure CSR probe sequences complete atomically on the same CPU. Fixes: 6f576fc0aeb9 ("RISC-V: KVM: Add support for SBI_FWFT_POINTER_MASKING_PMLEN") Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260601-kvm-get_reg_list-v2-v5-2-415d08a2813b@sifive.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-05KVM: RISC-V: SBI FWFT: Mark vCPU CSRs dirty after setting feature valueYong-Xuan Wang
Mark the vCPU CSRs as dirty after successfully setting an FWFT feature value. FWFT features may modify CSRs (e.g., pointer masking modifies henvcfg.PMM), and failing to mark them dirty can lead to the guest observing stale CSR state after vCPU scheduling or migration. Fixes: 1323a5cfe52c ("KVM: riscv: Skip CSR restore if VCPU is reloaded on the same core") Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260601-kvm-get_reg_list-v2-v5-1-415d08a2813b@sifive.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-05IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()Jason Gunthorpe
Codex pointed out that cm_init_av_by_path() can call cm_set_av_port() which takes a reference on the cm device, but then can immediately return error if ib_init_ah_attr_from_path() fails. Since callers like ib_send_cm_req() put the av on the stack this leaks that cm device reference. Re-order cm_init_av_by_path() so it doesn't touch the av until it has done all its failable work, and then update the av in one shot so it is either left alone or fully init'd. Sashiko also pointed out that the cm_destroy_av() prior to cm_init_av_by_path() is harmful as it leaves the AV broken in the error case and thus the REJ won't send. Since cm_init_av_by_path() is now atomic it is safe to delete the cm_destroy_av(). On succees the av from cm_init_av_for_response() is cleaned up by cm_init_av_by_path(), on failure the 'goto rejected' guarentees the av is destroyed during ib_destroy_cm_id(). Fixes: 76039ac9095f ("IB/cm: Protect cm_dev, cm_ports and mad_agent with kref and lock") Link: https://patch.msgid.link/r/0-v1-38292501f539+14f-ib_cm_av_leak_jgg@nvidia.com Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05RDMA/bnxt_re: Update create_qp to use QP buffer umem attrsSriharsha Basavapatna
Use ib_umem_get_attr_or_va() helper to pin QP buffer umems. Pass attribute ids SQ_BUF_UMEM and RQ_BUF_UMEM for respective buffers. Link: https://patch.msgid.link/r/20260602145618.21643-1-sriharsha.basavapatna@broadcom.com Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com> Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05RDMA/hfi1: Open-code rvt_set_ibdev_name()Arnd Bergmann
clang warns about a function missing a printf attribute: include/rdma/rdma_vt.h:457:47: error: diagnostic behavior may be improved by adding the 'format(printf, 2, 3)' attribute to the declaration of 'rvt_set_ibdev_name' [-Werror,-Wmissing-format-attribute] 447 | static inline void rvt_set_ibdev_name(struct rvt_dev_info *rdi, | __attribute__((format(printf, 2, 3))) 448 | const char *fmt, const char *name, 449 | const int unit) The helper was originally added as an abstraction for the hfi1 and qib drivers needing the same thing, but now qib is gone, and hfi1 is the only remaining user of rdma_vt. Avoid the warning and allow the compiler to check the format string by open-coding the helper and directly assigning the device name. Fixes: 5084c8ff21f2 ("IB/{rdmavt, hfi1, qib}: Self determine driver name") Link: https://patch.msgid.link/r/20260602140453.3542427-1-arnd@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Kees Cook <kees@kernel.org> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05RDMA/umem: Make ib_umem_is_contiguous() safe on 32 bitJason Gunthorpe
Sashiko points out the roundup_pow_of_two() only uses unsigned long but dma_addr_t can be u64. Change this algorithm to be simpler, compute the page size, if any page size is found and it results in a single block then it is contiguous. Link: https://patch.msgid.link/r/3-v1-88303e9e509f+f7-ib_umem_types_jgg@nvidia.com Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05RDMA/umem: Be careful about boundary conditions in ib_umem_find_best_pgsz()Jason Gunthorpe
Several corner cases, especially important on 32 bits: - umem->iova is u64, the function argument should pass in u64 or iova will be truncated - Check that the length is not too large for the iova - Check that lengths > 4G don't overflow the GENMASK Link: https://patch.msgid.link/r/2-v1-88303e9e509f+f7-ib_umem_types_jgg@nvidia.com Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05Merge tag 'xfs-fixes-7.1-rc7' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds
Pull xfs fixes from Carlos Maiolino: "A collection of fixes mostly for the RT device, including a small refactor that has no functional change" * tag 'xfs-fixes-7.1-rc7' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: Remove mention of PageWriteback xfs: abort mount if xfs_fs_reserve_ag_blocks fails xfs: factor rtgroup geom write pointer reporting into a helper xfs: drop the RTG reference later in xfs_ioc_rtgroup_geometry xfs: fix rtgroup cleanup in CoW fork repair xfs: fix error returns in CoW fork repair xfs: fix overlapping extents returned for pNFS LAYOUTGET xfs: fix use of uninitialized imap in xfs_fs_map_blocks error path xfs: handle racing deletions in xfs_zone_gc_iter_irec
2026-06-05Merge tag 'erofs-for-7.1-rc7-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs Pull erofs fixes from Gao Xiang: - Fix a UAF of sbi->sync_decompress when compressed I/Os race with unmount - Fix a regression introduced this development cycle that incorrectly rejects multiple-algorithm images * tag 'erofs-for-7.1-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs: erofs: fix EFSCORRUPTED on multi-algorithm images in z_erofs_map_sanity_check() erofs: fix use-after-free on sbi->sync_decompress