summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-10-20arm64: dts: socfpga: agilex5: Add SMMU nodesKhairul Anuar Romli
Agilex5 includes an ARM SMMU v3 (System Memory Management Unit) to provide address translation and memory protection for DMA-capable devices such as PCIe, USB, and other peripherals. This commit adds the SMMU node to the Agilex5 device tree with compatible string "arm,smmu-v3", along with its register space and interrupts. The SMMU is required to: - Enable DMA address translation for devices that cannot directly access the full physical memory space. - Provide isolation and memory protection by restricting device access to specific regions of memory, improving system security. - Support virtualization use cases by enabling safe and isolated device passthrough to guest VMs. - Align with ARM platform architecture requirements for IOMMU support. By describing the SMMU in the device tree, the Linux IOMMU framework can probe and initialize it during boot. Devices in the system can then bind to the SMMU via the `iommus` property, enabling memory translation and protection features as expected. The following devices are updated to reference the SMMU: - NAND controller - DMA controller - SPI controller This change is a necessary step toward full enablement high-speed peripherals on Agilex5. Signed-off-by: Adrian Ng Ho Yin <adrianhoyin.ng@altera.com> Signed-off-by: Khairul Anuar Romli <khairul.anuar.romli@altera.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-10-20dt-bindings: dma: snps,dw-axi-dmac: Add iommu propertyKhairul Anuar Romli
Agilex5 integrates an ARM SMMU v3 (System Memory Management Unit) with dedicated Translation Buffer Units (TBUs) assigned to various peripherals, including the Synopsys DesignWare AXI DMA controller. Each TBU handles address translation for its associated device by mapping stream IDs to memory access permissions and virtual-to-physical address mappings via the SMMU core. The DesignWare AXI DMAC instances on Agilex5 are connected to their respective TBUs. These TBUs forward DMA transactions from the controller through the SMMU, enabling IOMMU-based features such as: - Address translation for DMA operations - Isolation and protection of memory regions accessed by the DMA controller - Support for secure and virtualized environments through enforced access control To support this configuration, the `iommus` property must be added to the binding schema for `snps,dw-axi-dmac`. This allows the device tree to associate each DMA controller with the correct SMMU stream ID, enabling the Linux IOMMU framework to configure translation contexts at runtime. This change documents the IOMMU support for the DMA controller on Agilex5 and allows proper integration with the SMMUv3 hardware. Signed-off-by: Adrian Ng Ho Yin <adrianhoyin.ng@altera.com> Signed-off-by: Khairul Anuar Romli <khairul.anuar.romli@altera.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-10-20can: netlink: can_changelink(): allow disabling of automatic restartMarc Kleine-Budde
Since the commit c1f3f9797c1f ("can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode"), the automatic restart delay can only be set for devices that implement the restart handler struct can_priv::do_set_mode. As it makes no sense to configure a automatic restart for devices that doesn't support it. However, since systemd commit 13ce5d4632e3 ("network/can: properly handle CAN.RestartSec=0") [1], systemd-networkd correctly handles a restart delay of "0" (i.e. the restart is disabled). Which means that a disabled restart is always configured in the kernel. On systems with both changes active this causes that CAN interfaces that don't implement a restart handler cannot be brought up by systemd-networkd. Solve this problem by allowing a delay of "0" to be configured, even if the device does not implement a restart handler. [1] https://github.com/systemd/systemd/commit/13ce5d4632e395521e6205c954493c7fc1c4c6e0 Cc: stable@vger.kernel.org Cc: Andrei Lalaev <andrey.lalaev@gmail.com> Reported-by: Marc Kleine-Budde <mkl@pengutronix.de> Closes: https://lore.kernel.org/all/20251020-certain-arrogant-vole-of-sunshine-141841-mkl@pengutronix.de Fixes: c1f3f9797c1f ("can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode") Link: https://patch.msgid.link/20251020-netlink-fix-restart-v1-1-3f53c7f8520b@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-20dt-bindings: mtd: cdns,hp-nfc: Add iommu propertyKhairul Anuar Romli
Agilex5 integrates an ARM SMMU (System Memory Management Unit) with Translation Buffer Units (TBUs) assigned to various peripherals, including the NAND controller. The Cadence HP NAND controller ("cdns,hp-nfc") on Agilex5 is behind a TBU connected to the system's SMMUv3. To support this, the controller requires an `iommus` property in the device tree to properly configure address translation through the IOMMU framework. Adding the `iommus` property to the binding schema allows the OS to associate the NAND controller with its corresponding SMMU stream ID. This enables: - DMA address translation between the controller and system memory - Memory protection for NAND operations - Proper functioning of the IOMMU framework in secure or virtualized environments This change documents the IOMMU integration for the NAND controller on platforms like Agilex5 where such hardware is present. Signed-off-by: Adrian Ng Ho Yin <adrianhoyin.ng@altera.com> Signed-off-by: Khairul Anuar Romli <khairul.anuar.romli@altera.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-10-20Merge patch series "can: drivers: drop skb in xmit if device is in listen ↵Marc Kleine-Budde
only mode" Marc Kleine-Budde <mkl@pengutronix.de> says: I notived that 3 drivers (bxcan, esd and rockchip) use the function can_dropped_invalid_skb(), that doesn't check if the device is in listen only mode. This series converts these driver to use the new can_dev_dropped_skb() function. Link: https://patch.msgid.link/20251017-fix-skb-drop-check-v1-0-556665793fa4@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-20can: rockchip-canfd: rkcanfd_start_xmit(): use can_dev_dropped_skb() instead ↵Marc Kleine-Budde
of can_dropped_invalid_skb() In addition to can_dropped_invalid_skb(), the helper function can_dev_dropped_skb() checks whether the device is in listen-only mode and discards the skb accordingly. Replace can_dropped_invalid_skb() by can_dev_dropped_skb() to also drop skbs in for listen-only mode. Reported-by: Marc Kleine-Budde <mkl@pengutronix.de> Closes: https://lore.kernel.org/all/20251017-bizarre-enchanted-quokka-f3c704-mkl@pengutronix.de/ Fixes: ff60bfbaf67f ("can: rockchip_canfd: add driver for Rockchip CAN-FD controller") Link: https://patch.msgid.link/20251017-fix-skb-drop-check-v1-3-556665793fa4@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-20can: esd: acc_start_xmit(): use can_dev_dropped_skb() instead of ↵Marc Kleine-Budde
can_dropped_invalid_skb() In addition to can_dropped_invalid_skb(), the helper function can_dev_dropped_skb() checks whether the device is in listen-only mode and discards the skb accordingly. Replace can_dropped_invalid_skb() by can_dev_dropped_skb() to also drop skbs in for listen-only mode. Reported-by: Marc Kleine-Budde <mkl@pengutronix.de> Closes: https://lore.kernel.org/all/20251017-bizarre-enchanted-quokka-f3c704-mkl@pengutronix.de/ Fixes: 9721866f07e1 ("can: esd: add support for esd GmbH PCIe/402 CAN interface family") Link: https://patch.msgid.link/20251017-fix-skb-drop-check-v1-2-556665793fa4@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-20can: bxcan: bxcan_start_xmit(): use can_dev_dropped_skb() instead of ↵Marc Kleine-Budde
can_dropped_invalid_skb() In addition to can_dropped_invalid_skb(), the helper function can_dev_dropped_skb() checks whether the device is in listen-only mode and discards the skb accordingly. Replace can_dropped_invalid_skb() by can_dev_dropped_skb() to also drop skbs in for listen-only mode. Reported-by: Marc Kleine-Budde <mkl@pengutronix.de> Closes: https://lore.kernel.org/all/20251017-bizarre-enchanted-quokka-f3c704-mkl@pengutronix.de/ Fixes: f00647d8127b ("can: bxcan: add support for ST bxCAN controller") Link: https://patch.msgid.link/20251017-fix-skb-drop-check-v1-1-556665793fa4@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-20remoteproc: mtk_scp: Construct FW path if firmware-name not presentAngeloGioacchino Del Regno
After a reply on the mailing lists [1] it emerged that the DT property "firmware-name" should not be relied on because of possible issues with firmware versions. For MediaTek SCP, there has never been any firmware version vs driver version desync issue but, regardless, the firmwares are always using the same name and they're always located in a path with a specific pattern. Instead of unconditionally always relying on the firmware-name devicetree property to get a path to the SCP FW file, drivers should construct a name based on what firmware it knows and what hardware it is running on. In order to do that, add a `scp_get_default_fw_path()` function that constructs the path and filename based on two of the infos that the driver can get: 1. The compatible string with the highest priority (so, the first one at index 0); and 2. The type of SCP HW - single-core or multi-core. This means that the default firmware path is generated as: - Single core SCP: mediatek/(soc_model)/scp.img for example: mediatek/mt8183/scp.img; - Multi core SCP: mediatek/(soc_model)/scp_c(core_number).img for example: mediatek/mt8188/scp_c0.img for Core 0, and mediatek/mt8188/scp_c1.img for Core 1. Note that the generated firmware path is being used only if the "firmware-name" devicetree property is not present in the SCP node or in the SCP Core node(s). [1 - Reply regarding firmware-name property] Link: https://lore.kernel.org/all/7e8718b0-df78-44a6-a102-89529d6abcce@app.fastmail.com/ Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20251015084103.10737-1-angelogioacchino.delregno@collabora.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-10-20spi: intel-pci: Add support for Intel Wildcat Lake SPI serial flashMika Westerberg
Add Intel Wildcat Lake SPI serial flash PCI ID to the list of supported devices. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://patch.msgid.link/20251020145415.3377022-4-mika.westerberg@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-20spi: intel-pci: Add support for Arrow Lake-H SPI serial flashMika Westerberg
Add Intel Arrow Lake-H PCI ID to the driver list of supported devices. This is the same controller found in previous generations. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://patch.msgid.link/20251020145415.3377022-3-mika.westerberg@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-20spi: intel: Add support for 128M component densityMika Westerberg
With the recent hardware the flash component density can be increased to 128M. Update the driver to support this. While there log a warning if we encounter an unsupported value in this field. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://patch.msgid.link/20251020145415.3377022-2-mika.westerberg@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-20USB: serial: option: add UNISOC UIS7720Renjun Wang
Add support for UNISOC (Spreadtrum) UIS7720 (A7720) module. T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1782 ProdID=4064 Rev=04.04 S: Manufacturer=Unisoc-phone S: Product=Unisoc-phone S: SerialNumber=0123456789ABCDEF C: #Ifs= 9 Cfg#= 1 Atr=c0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms 0&1: RNDIS, 2: LOG, 3: DIAG, 4&5: AT Ports, 6&7: AT2 Ports, 8: ADB Signed-off-by: Renjun Wang <renjunw0@foxmail.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2025-10-20MAINTAINERS: Panfrost: Add Steven Price and Adrian LarumbeAdrián Larumbe
Recast Steven Price as Panfrost driver maintainer. Also add Adrian Larumbe in the same role. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-13-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Rename panfrost_job functions to reflect real roleAdrián Larumbe
panfrost_job_* prefixed functions in panfrost_job.c deal with both panfrost_job objects and also the more general JM (Job Manager) side of the device itself. This is confusing. Reprefix functions that program the JM to panfrosot_jm_* instead. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-12-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Remove unused device propertyAdrián Larumbe
The as_in_use_mask device state variable is no longer in use. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-11-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Add forward declaration and types headerAdrián Larumbe
This is to make LLVM syntactic analysers happy. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-10-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Make re-enabling job interrupts at device reset optionalAdrián Larumbe
Rather than remasking interrupts after a device reset in the main reset path, allow selecting whether to do this with an additional bool parameter. To this end, split reenabling job interrupts into two functions, one that clears the interrupts and another one which unmasks them conditionally. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-9-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Don't rework job IRQ enable mask in the enable pathAdrián Larumbe
Up until now, panfrost_job_enable_interrupts() would always recalculate the same job IRQ enablement mask, which is effectively a constant. Replace it with a compile-time constant value, and also in another couple places where an equivalent expression was being used. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-8-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Handle page mapping failureAdrián Larumbe
When mapping the pages of a BO, either a heap type at page fault time or else a non-heap BO at object creation time, if the ARM page table mapping function fails, we unmap what had been mapped so far and bail out. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-7-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Check sgt to know whether pages are already mappedAdrián Larumbe
In the MMU's page fault ISR for a heap object, determine whether the faulting address belongs to a 2MiB block that was already mapped by checking its corresponding sgt in the Panfrost BO. This is done in preparation for a future commit in which the MMU mapping helper might fail, but the page array is left populated, so this cannot be used as a check for an early bail-out. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-6-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Handle error when allocating AS numberAdrián Larumbe
If we reach the beginning of the LRU AS list, then return an error. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-5-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Handle job HW submit errorsAdrián Larumbe
Avoid waiting for the DRM scheduler job timedout handler, and instead, let the DRM scheduler core signal the error fence immediately when HW job submission fails. That means we must also decrement the runtime-PM refcnt for the device, because the job will never be enqueued or inflight. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-4-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Handle inexistent GPU during probeAdrián Larumbe
Just in case we're dealing with a yet not recognised device. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-3-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Replace DRM driver allocation method with newer oneAdrián Larumbe
Drop the deprecated DRM driver allocation method in favour of devm_drm_dev_alloc(). Overall just make it the same as in Panthor. Also discard now superfluous generic and platform device pointers inside the main panfrost device structure. Some ancient checkpatch issues unearthed as a result of these changes were also fixed, like lines too long or double assignment in one line. Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-2-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20arm64: dts: rockchip: add DTs for 100ASK DShanPi A1Hsun Lai
Add device tree for 100ASK DShanPi A1 with Rockchip RK3576 SoC (4x Cortex-A72, 4x Cortex-A53, Mali-G52 MC3 GPU, 6 TOPS NPU). Enables basic booting and connectivity. Link: https://wiki.dshanpi.org/en/docs/DshanPi-A1/intro/ The device contains the following hardware that is tested/working: - 32 or 64GB eMMC - SDMMC card slot - M.2 WiFi slot - 4 or 8GB of RAM - 2x 1Gbps Ethernet - 2x USB 3.2 Gen 1 Type-A ports - USB 3.0 port - HDMI port Signed-off-by: Hsun Lai <i@chainsx.cn> Link: https://patch.msgid.link/77BB123A1F1E3D11+20251014021623.286121-3-i@chainsx.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-10-20dt-bindings: arm: rockchip: Add 100ASK DShanPi A1Hsun Lai
This documents 100ASK DShanPi A1 which is a SBC based on RK3576 SoC. Link: https://wiki.dshanpi.org/en/docs/DshanPi-A1/intro/ Signed-off-by: Hsun Lai <i@chainsx.cn> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/0601AB836AE5F348+20251014021623.286121-2-i@chainsx.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-10-20arm64: dts: rockchip: add LinkEase EasePi R1Liangbin Lian
LinkEase EasePi R1 [1] is a high-performance mini router. Specification: - Rockchip RK3568 - 2GB/4GB LPDDR4 RAM - 16GB on-board eMMC - 1x M.2 key for 2280 NVMe (PCIe 3.0) - 1x USB 3.0 Type-A - 1x USB 2.0 Type-C (for USB flashing) - 2x 1000 Base-T (native, RTL8211F) - 2x 2500 Base-T (PCIe, RTL8125B) - 1x HDMI 2.0 Output - 12v DC Jack - 1x Power key connected to PMIC - 2x LEDs (one static power supplied, one GPIO controlled) [1] https://doc.linkease.com/zh/guide/easepi-r1/hardware.html Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Liangbin Lian <jjm2473@gmail.com> Link: https://patch.msgid.link/20251014051226.64255-4-jjm2473@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-10-20dt-bindings: arm: rockchip: Add LinkEase EasePi R1Liangbin Lian
LinkEase EasePi R1 is a high-performance mini router based on RK3568. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Liangbin Lian <jjm2473@gmail.com> Link: https://patch.msgid.link/20251014051226.64255-3-jjm2473@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-10-20dt-bindings: vendor-prefixes: Document LinkEaseLiangbin Lian
LinkEase is a company focusing on the research and development of network equipment and related software and hardware from Shenzhen. Add vendor prefix for it. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Liangbin Lian <jjm2473@gmail.com> Link: https://patch.msgid.link/20251014051226.64255-2-jjm2473@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-10-20accel/qaic: Fix mismatched types in min()Zack McKevitt
Use min_t() instead of min() to resolve compiler warnings for mismatched types. Signed-off-by: Zack McKevitt <zmckevit@qti.qualcomm.com> Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com> Reviewed-by: Carl Vanderlip <carl.vanderlip@oss.qualcomm.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Reviewed-by: Maciej Falkowski <maciej.falkowski@linux.intel.com> Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251015153715.184143-1-youssef.abdulrahman@oss.qualcomm.com
2025-10-20accel/qaic: Use check_add_overflow in sahara for 64b typesZack McKevitt
Use check_add_overflow instead of size_add in sahara when 64b types are being added to ensure compatibility with 32b systems. The size_add function parameters are of size_t, so 64b data types may be truncated when cast to size_t on 32b systems. When using check_add_overflow, no type casts are made, making it a more portable option. Signed-off-by: Zack McKevitt <zmckevit@qti.qualcomm.com> Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Reviewed-by: Carl Vanderlip <carl.vanderlip@oss.qualcomm.com> Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251015165408.213645-1-youssef.abdulrahman@oss.qualcomm.com
2025-10-20ASoC: codecs: va-macro: Clean up on error path in probe()Dan Carpenter
Do some clean up before returning the error code. Fixes: 281c97376cfc ("ASoC: codecs: va-macro: Rework version checking") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/aPMyw_ryay9LA5SW@stanley.mountain Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-20drm/rockchip: Use temporary variablesDaniel Stone
Brevity is good. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251015110042.41273-6-daniels@collabora.com
2025-10-20drm/rockchip: Rename variables for clarityDaniel Stone
actual_w and actual_h were the clipped source width, so rename them to fit the use. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251015110042.41273-5-daniels@collabora.com
2025-10-20drm/rockchip: Return error code for errorsDaniel Stone
Instead of silently disabling small planes, refuse to create them at all. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251015110042.41273-4-daniels@collabora.com
2025-10-20drm/rockchip: Declare framebuffer width/height boundsDaniel Stone
The VOP2 has limitations on its input and output sizes. The clipped display region must be at least 4px in each dimension for both framebuffer source and plane destination, and the clipped source region must be no greater than a per-version limit. It is never valid for VOP2 to have a framebuffer which is less than four pixels in either dimension, so declare that as our min width/height, enforced by AddFB failing if the user tries. It can theoretically be valid to have a single large framebuffer of which only certain clipped regions are shown, but this is a very uncommon case. Declaring to userspace that the framebuffer's maximum width and height is the maximum source clip helps it make better decisions as to which mode to use, instead of trying unsupported sizes and having to fall back. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251015110042.41273-3-daniels@collabora.com
2025-10-20drm/rockchip: Demote normal drm_err to debugDaniel Stone
A plane check failing is a normal and expected condition, as userspace isn't aware of the specific constraints and will try any and every combination until one succeeds. Push this down to a debug message, so users can see it if they want to, but make sure we don't spam the log during normal operation. Fixes: 604be85547ce4 ("drm/rockchip: Add VOP2 driver") Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251015110042.41273-2-daniels@collabora.com
2025-10-20dm-verity: use 2-way interleaved SHA-256 hashing when supportedEric Biggers
When the crypto library provides an optimized implementation of sha256_finup_2x(), use it to interleave the hashing of pairs of data blocks. On some CPUs this nearly doubles hashing performance. The increase in overall throughput of cold-cache dm-verity reads that I'm seeing on arm64 and x86_64 is roughly 35% (though this metric is hard to measure as it jumps around a lot). For now this is done only on data blocks, not Merkle tree blocks. We could use sha256_finup_2x() on Merkle tree blocks too, but that is less important as there aren't as many Merkle tree blocks as data blocks, and that would require some additional code restructuring. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-10-20dm-verity: reduce scope of real and wanted digestsEric Biggers
In preparation for supporting interleaved hashing where dm-verity will need to keep track of the real and wanted digests for multiple data blocks simultaneously, stop using the want_digest and real_digest fields of struct dm_verity_io from so many different places. Specifically: - Make various functions take want_digest as a parameter rather than having it be implicitly passed via the struct dm_verity_io. - Add a new tmp_digest field, and use this instead of real_digest when computing a digest solely for the purpose of immediately checking it. The result is that real_digest and want_digest are used only by verity_verify_io(). Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-10-20dm-verity: use SHA-256 library for SHA-256Eric Biggers
When the hash algorithm is SHA-256 and the verity version is not 0, use the SHA-256 library instead of crypto_shash. This is a prerequisite for making dm-verity interleave the computation of SHA-256 hashes for increased performance. That optimization is available in the SHA-256 library but not in crypto_shash. Even without interleaved hashing, switching to the library also slightly improves performance by itself because it avoids the overhead of crypto_shash, including indirect calls and other API overhead. (Benchmark on x86_64, AMD Zen 5: hashing 4K blocks gets 2.1% faster.) SHA-256 is by far the most common hash algorithm used with dm-verity. It makes sense to optimize for the common case and fall back to the generic crypto layer for uncommon cases, as suggested by Linus: https://lore.kernel.org/r/CAHk-=wgp-fOSsZsYrbyzqCAfEvrt5jQs1jL-97Wc4seMNTUyng@mail.gmail.com Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-10-20dm-verity: remove log message with shash driver nameEric Biggers
I added this log message in commit bbf6a566920e ("dm verity: log the hash algorithm implementation"), to help people debug issues where they forgot to enable the architecture-optimized SHA-256 code in their kconfig or accidentally enabled a slow hardware offload driver (such as QCE) that overrode the faster CPU-accelerated code. However: - The crypto layer now always enables the architecture-optimized SHA-1, SHA-256, and SHA-512 code. Moreover, for simplicity the driver name is now fixed at "sha1-lib", "sha256-lib", etc. - dm-verity now uses crypto_shash instead of crypto_ahash, preventing the mistake of accidentally using a slow driver such as QCE. Therefore, this log message generally no longer provides useful information. Remove it. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-10-20KVM: guest_memfd: Define a CLASS to get+put guest_memfd file from a memslotSean Christopherson
Add a CLASS to handle getting and putting a guest_memfd file given a memslot to reduce the amount of related boilerplate, and more importantly to minimize the chances of forgetting to put the file (thankfully the bug that prompted this didn't escape initial testing). Define a CLASS instead of using __free(fput) as _free() comes with subtle caveats related to FILO ordering (objects are freed in the order in which they are declared), and the recommended solution/workaround (declare file pointers exactly when they are initialized) is visually jarring relative to KVM's (and the kernel's) overall strict adherence to not mixing declarations and code. E.g. the use in kvm_gmem_populate() would be: slot = gfn_to_memslot(kvm, start_gfn); if (!kvm_slot_has_gmem(slot)) return -EINVAL; struct file *file __free(fput) = kvm_gmem_get_file(slot; if (!file) return -EFAULT; filemap_invalidate_lock(file->f_mapping); Note, using CLASS() still declares variables in the middle of code, but the syntactic sugar obfuscates the declaration, i.e. hides the anomaly to a large extent. No functional change intended. Link: https://lore.kernel.org/r/20251007222356.348349-1-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-10-20KVM: guest_memfd: Add gmem_inode.flags field instead of using i_privateSean Christopherson
Track a guest_memfd instance's flags in gmem_inode instead of burying them in i_private. Burning an extra 8 bytes per inode is well worth the added clarity provided by explicit tracking. Reviewed-by: Shivank Garg <shivankg@amd.com> Tested-by: Shivank Garg <shivankg@amd.com> Link: https://lore.kernel.org/r/20251016172853.52451-13-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-10-20KVM: selftests: Add guest_memfd tests for mmap and NUMA policy supportShivank Garg
Add tests for NUMA memory policy binding and NUMA aware allocation in guest_memfd. This extends the existing selftests by adding proper validation for: - KVM GMEM set_policy and get_policy() vm_ops functionality using mbind() and get_mempolicy() - NUMA policy application before and after memory allocation Run the NUMA mbind() test with and without INIT_SHARED, as KVM should allow doing mbind(), madvise(), etc. on guest-private memory, e.g. so that userspace can set NUMA policy for CoCo VMs. Run the NUMA allocation test only for INIT_SHARED, i.e. if the host can't fault-in memory (via direct access, madvise(), etc.) as move_pages() returns -ENOENT if the page hasn't been faulted in (walks the host page tables to find the associated folio) [sean: don't skip entire test when running on non-NUMA system, test mbind() with private memory, provide more info in assert messages] Signed-off-by: Shivank Garg <shivankg@amd.com> Tested-by: Ashish Kalra <ashish.kalra@amd.com> Link: https://lore.kernel.org/r/20251016172853.52451-12-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-10-20KVM: selftests: Add helpers to probe for NUMA support, and multi-node systemsShivank Garg
Add NUMA helpers to probe for support/availability and to check if the test is running on a multi-node system. The APIs will be used to verify guest_memfd NUMA support. Signed-off-by: Shivank Garg <shivankg@amd.com> [sean: land helpers in numaif.h, add comments, tweak names] Link: https://lore.kernel.org/r/20251016172853.52451-11-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-10-20KVM: selftests: Use proper uAPI headers to pick up mempolicy.h definitionsSean Christopherson
Drop the KVM's re-definitions of MPOL_xxx flags in numaif.h as they are defined by the already-included, kernel-provided mempolicy.h. The only reason the duplicate definitions don't cause compiler warnings is because they are identical, but only on x86-64! The syscall numbers in particular are subtly x86_64-specific, i.e. will cause problems if/when numaif.h is used outsize of x86. Opportunistically clean up the file comment as the license information is covered by the SPDX header, the path is superfluous, and as above the comment about the contents is flat out wrong. Fixes: 346b59f220a2 ("KVM: selftests: Add missing header file needed by xAPIC IPI tests") Reviewed-by: Shivank Garg <shivankg@amd.com> Tested-by: Shivank Garg <shivankg@amd.com> Link: https://lore.kernel.org/r/20251016172853.52451-10-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-10-20KVM: selftests: Add additional equivalents to libnuma APIs in KVM's numaif.hSean Christopherson
Add APIs for all syscalls defined in the kernel's mm/mempolicy.c to match those that would be provided by linking to libnuma. Opportunistically use the recently inroduced KVM_SYSCALL_DEFINE() builders to take care of the boilerplate, and to fix a flaw where the two existing wrappers would generate multiple symbols if numaif.h were to be included multiple times. Reviewed-by: Ackerley Tng <ackerleytng@google.com> Tested-by: Ackerley Tng <ackerleytng@google.com> Reviewed-by: Shivank Garg <shivankg@amd.com> Tested-by: Shivank Garg <shivankg@amd.com> Link: https://lore.kernel.org/r/20251016172853.52451-9-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-10-20KVM: selftests: Report stacktraces SIGBUS, SIGSEGV, SIGILL, and SIGFPE by ↵Sean Christopherson
default Register handlers for signals for all selftests that are likely happen due to test (or kernel) bugs, and explicitly fail tests on unexpected signals so that users get a stack trace, i.e. don't have to go spelunking to do basic triage. Register the handlers as early as possible, to catch as many unexpected signals as possible, and also so that the common code doesn't clobber a handler that's installed by test (or arch) code. Tested-by: Ackerley Tng <ackerleytng@google.com> Reviewed-by: Ackerley Tng <ackerleytng@google.com> Reviewed-by: Shivank Garg <shivankg@amd.com> Tested-by: Shivank Garg <shivankg@amd.com> Link: https://lore.kernel.org/r/20251016172853.52451-8-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-10-20KVM: selftests: Define wrappers for common syscalls to assert successSean Christopherson
Add kvm_<sycall> wrappers for munmap(), close(), fallocate(), and ftruncate() to cut down on boilerplate code when a sycall is expected to succeed, and to make it easier for developers to remember to assert success. Implement and use a macro framework similar to the kernel's SYSCALL_DEFINE infrastructure to further cut down on boilerplate code, and to drastically reduce the probability of typos as the kernel's syscall definitions can be copy+paste almost verbatim. Provide macros to build the raw <sycall>() wrappers as well, e.g. to replace hand-coded wrappers (NUMA) or pure open-coded calls. Reviewed-by: Ackerley Tng <ackerleytng@google.com> Tested-by: Ackerley Tng <ackerleytng@google.com> Reviewed-by: Shivank Garg <shivankg@amd.com> Tested-by: Shivank Garg <shivankg@amd.com> Link: https://lore.kernel.org/r/20251016172853.52451-7-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
generated by cgit v1.3 (git 2.53.0) at 2026-11-11 21:04:56 +0000