summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-06-11phy: lynx-28g: optimize read-modify-write operationVladimir Oltean
It is unnecessary to rewrite a register if the masked field already contains the desired value upon reading. The hardware behaviour does not depend upon register writes with identical values. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-13-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: add support for big endian register mapsVladimir Oltean
Some 10G Lynx SerDes blocks are big endian and require byte swapping because the CPUs are little endian armv8 (LS1046A). Parse the "big-endian" device tree property, and modify the base lynx_read() and lynx_write() accessors to test this property before issuing either the ioread32() or ioread32be() variants (as per Documentation/driver-api/device-io.rst). All other accessors - lynx_rmw(), lynx_lane_read(), lynx_lane_write(), lynx_lane_rmw(), lynx_pll_read() - need to go through these endian-aware helpers. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-12-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: common probe() and remove()Vladimir Oltean
Factor the device-agnostic logic from lynx_28g_probe() and lynx_28g_remove() into lynx_probe() and lynx_remove() inside phy-fsl-lynx-core.c. These will be shared with the 10G Lynx driver. Since the PLL configuration, lane configuration and CDR lock detection procedure are going to be different, introduce lynx_info function pointers so that this code remains in the 28G Lynx driver. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-11-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: make lynx_28g_pll_read_configuration() callable per PLLVladimir Oltean
In a future change, lynx_28g_pll_read_configuration() and lynx_28g_lane_read_configuration() will be made methods of struct lynx_info. There is no functional reason, but lynx_28g_lane_read_configuration() is called per lane and lynx_28g_pll_read_configuration() iterates over PLLs internally. So the API exported by the lynx_info structure would not be uniform. Change lynx_28g_pll_read_configuration() to also permit reading the PLL configuration individually, and move the for loop at the call site. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-10-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: move struct lynx_info definitions downwardsVladimir Oltean
We need to be able to reference more function pointers in upcoming patches. The struct lynx_info definitions are currently placed a bit up in lynx-28g.c in order to be able to do that without function prototype forward declarations, so move them downward to avoid that situation. No functional change intended. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-9-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: provide default lynx_lane_supports_mode() implementationVladimir Oltean
For the 28G Lynx, there are situations where a protocol is not supported on a lane despite there being a PCCR register and protocol converter available: - LX2160A SerDes 1: reference manual documents PCCD fields E25GC_CFG and E25GD_CFG and protocol converter registers E25GCCR1..E25GCCR3 / E25GDCR1..E25GDCR3, but nonetheless, Table 289. SerDes 1 protocol mapping shows no RCW[SRDS_PRTCL_S1] value for which lanes C and D support 25G - when using the "fsl,lynx-28g" fallback compatible string, we don't want to offer 25GbE because we don't know if the lane supports it, even though we know how to reach the PCCR and protocol converter registers for it. But for the upcoming 10G Lynx SerDes, the above situations don't exist. There, if we know how to reach the PCCR and protocol converter registers on a lane, we implicitly know that the protocol is supported there, so implementing priv->info->lane_supports_mode() would be redundant. Implement lynx_lane_supports_mode_default() which decides whether a lane mode is supported just based on priv->info->get_pccr() and priv->info->get_pcvt_offset(). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-8-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: generalize protocol converter accessorsVladimir Oltean
The protocol converters on the 10G Lynx are architecturally similar, but different in layout from the 28G Lynx ones. Move lynx_pccr_read(), lynx_pccr_write(), lynx_pcvt_read() and lynx_pcvt_write() from the 28G Lynx driver to the common module, and permit each SerDes driver to provide just its own bits in order to use this common API. Currently, that just means that the direct calls to lynx_28g_get_pcvt_offset() are modified to go through the lynx->info->get_pcvt_offset() indirect function call, and similarly, lynx_28g_get_pccr() through lynx->info->get_pccr(). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-7-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: common lynx_pll_get()Vladimir Oltean
The logic should be absolutely unchanged in the new 10G Lynx SerDes driver, so let's move this to phy-fsl-lynx-core.c and update the 28G Lynx driver to use the common variant. While at it, update the call site, lynx_28g_lane_remap_pll(), to use the new data structures, and refactor the NULL pll pointer check (the current form triggers a checkpatch CHECK). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-6-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: move data structures to coreVladimir Oltean
The goal is to avoid duplicating the core data structures when introducing the new lynx-10g driver. We move the following to phy-fsl-lynx-core: - struct lynx_28g_pll -> struct lynx_pll. This has some hardware-specific register fields which need to become hardware agnostic (the PLL register layout is different for Lynx 10G), So: - PLLnRSTCTL_DIS(pll->rstctl) becomes !pll->enabled - PLLnRSTCTL_LOCK(pll->rstctl) becomes pll->locked - FIELD_GET(PLLnCR1_FRATE_SEL, pll->cr1) becomes pll->frate_sel - FIELD_GET(PLLnCR0_REFCLK_SEL, pll->cr0) becomes pll->refclk_sel - struct lynx_28g_lane -> struct lynx_lane - struct lynx_28g_priv -> struct lynx_priv - field lane[LYNX_28G_NUM_LANE] has to be dynamically allocated. Not all Lynx 10G SerDes blocks have 8 lanes. - LYNX_28G_NUM_PLL -> LYNX_NUM_PLL. This is an architectural constant which is the same for Lynx 10G as well. To avoid major noise in the lynx-28g driver, we keep compatibility shims (for now) where the old lynx_28g names are preserved, but translate to the common data structures. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-5-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: move lane mode helpers to new core moduleVladimir Oltean
Do some preparation work for the introduction of the lynx-10g driver, which will share a common backbone with the 28G Lynx SerDes. This is just trivial stuff which can be moved without any surgery, and is easy to follow but otherwise pollutes more serious changes. The lane modes themselves are exported to a public header, because on the 10G Lynx, the hardware requires implementing a procedure called "RCW override". This requires coordination with drivers/soc/fsl/guts.c to tell it that a SerDes lane needs to be switched to a different protocol (enum lynx_lane_mode). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-4-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: reject probing on devices with unsupported OF nodesVladimir Oltean
It is possible to bind the lynx-28g driver to an arbitrary device with an OF node, using the driver_override mechanism that is available for the platform bus, and trigger a crash this way: $ echo 1ea0000.serdes > /sys/bus/platform/drivers/lynx-10g/unbind $ echo lynx-28g > /sys/bus/platform/devices/1ea0000.serdes/driver_override $ echo 1ea0000.serdes > /sys/bus/platform/drivers/lynx-28g/bind Internal error: Oops: 0000000096000004 [#1] SMP Hardware name: LS1028A RDB Board (DT) pc : lynx_probe+0x118/0x4fc lr : lynx_probe+0x110/0x4fc Call trace: lynx_probe+0x118/0x4fc (P) lynx_28g_probe+0x54/0x7c platform_probe+0x68/0xa4 really_probe+0x14c/0x2ec __driver_probe_device+0xc8/0x170 device_driver_attach+0x58/0xa8 bind_store+0xd8/0x118 drv_attr_store+0x24/0x38 The crash is caused by the fact that of_device_get_match_data() returns NULL (the bound device has a different compatible string) and this is not checked. There was a previous attempt to avoid this in commit c9d80e861034 ("phy: lynx-28g: require an OF node to probe"), but the mechanism was not fully understood and it only covered the case where the driver was bound to a device with no OF node. The issue was found during Sashiko review. Elevated privilege is required to override the driver for a device, so the real life impact of the issue should not be very high. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-3-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: lynx-28g: avoid returning NULL in of_xlate() functionVladimir Oltean
Sashiko points out that _of_phy_get() does not support a NULL returned output from phy_provider->of_xlate(), just a valid pointer or a pointer-encoded error. When lynx_28g_probe() -> for_each_available_child_of_node() skips over lanes which have OF nodes with status = "disabled", the priv->lane[idx].phy pointer will remain NULL. This NULL pointer may be propagated to lynx_28g_xlate() if the device tree contains a phandle to the disabled lane AND fw_devlink did not block probing for the consumer. In that case, the PHY core will crash when trying to dereference the NULL phy pointer. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260610151952.2141019-2-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11dt-bindings: PCI: mediatek: Add support for EcoNet EN7528Caleb James DeLisle
Introduce EcoNet EN7528 SoC compatible in MediaTek PCIe controller binding. EcoNet PCIe controller has the same configuration model as Mediatek v2 but is initialized more similarly to an MT7621 PCIe. Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20260521171951.1495781-3-cjd@cjdns.fr
2026-06-11PCI: mediatek: Use actual physical address instead of virt_to_phys()Manivannan Sadhasivam
The driver previously used virt_to_phys() on the ioremapped register base (port->base) to compute the MSI message address. Using virt_to_phys() on an IO mapped address is incorrect because it expects a kernel virtual address. To fix it, store the physical start of the I/O register region in mtk_pcie_port->phys_base and use it to build the MSI address. This replaces the incorrect virt_to_phys() usage and ensures MSI addresses are generated correctly. Fixes: 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and MT7622") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Caleb James DeLisle <cjd@cjdns.fr> Link: https://patch.msgid.link/20260521171951.1495781-2-cjd@cjdns.fr
2026-06-11phy: qcom: qmp-pcie: Add QMP PCIe PHY support for ElizaKrishna Chaitanya Chundru
Add QMP PCIe PHY support for the Eliza SoC. Introduce a new Gen3x1 PHY configuration with Eliza-specific initialization tables, and reuse the existing sm8550 Gen3x2 configuration for the Gen3x2 PHY instance. Also add the missing QPHY_PCIE_V6_PCS_PCIE_INT_AUX_CLK_CONFIG1 register definition to the PCIe V6 PCS header. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260608-eliza-v3-3-9bdeb7434b28@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11dt-bindings: phy: sc8280xp-qmp-pcie: Document Eliza PCIe phyKrishna Chaitanya Chundru
Add compatibles for the Eliza PCIe QMP PHY's, which supports Gen3x1 and Gen3x2 configurations. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Acked-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260608-eliza-v3-1-9bdeb7434b28@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11phy: nxp-ptn3222: Use named initializers for struct i2c_device_idUwe Kleine-König (The Capable Hub)
While being less compact, using named initializers allows to more easily see which members of the structs are assigned which value without having to lookup the declaration of the struct. And it's also more robust against changes to the struct definition. This patch doesn't modify the compiled arrays, only their representation in source form benefits. The former was confirmed with x86 and arm64 builds. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Link: https://patch.msgid.link/20260519151957.1593214-2-u.kleine-koenig@baylibre.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11dt-bindings: phy: sc8280xp-qmp-pcie: Disallow bifurcation register on PurwaKonrad Dybcio
Neither of the two Gen4x4 PHYs found on Purwa supports bifurcation. The PHY is however physically laid out as if it were to, since there are two separate ports (A/B). Split out a new if-then block to un-require the bifurcation register handle to squash this warning: purwa-iot-evk.dtb: phy@1bd4000 (qcom,x1p42100-qmp-gen4x4-pcie-phy): 'qcom,4ln-config-sel' is a required property Fixes: 2e1ffd4c1805 ("dt-bindings: phy: qcom,qmp-pcie: Add X1P42100 PCIe Gen4x4 PHY") Reported-by: Rob Herring <robh@kernel.org> Closes: https://lore.kernel.org/linux-arm-msm/176857775469.1631885.16133311938753588148.robh@kernel.org/ Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260610-topic-purwa_phy_shutup_warning-v2-1-951c1fbfe9b2@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11crypto: xilinx-trng - Replace crypto_drbg_ctr_df() with HMAC-SHA512Eric Biggers
This code is just trying to condition 48 bytes of random data. This can be done easily using HKDF-SHA512-Extract, saving 300 lines of code. This commit also fixes forward security (in this particular case) by clearing the entropy from memory after it's used. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-11crypto: xilinx-trng - Fix return value of xtrng_hwrng_trng_read()Eric Biggers
Implementations of hwrng::read are expected to return the number of bytes generated. Update xtrng_hwrng_trng_read() to match that. Fixes: 8979744aca80 ("crypto: xilinx - Add TRNG driver for Versal") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-11crypto: xilinx-trng - Remove crypto_rng interfaceEric Biggers
Implementing the crypto_rng interface has no purpose, as it isn't used in practice. It's being removed from other drivers too. Just remove it. This leaves hwrng, which is actually used. Tagging with 'Cc stable' due to the bugs that this removes: - xtrng_trng_generate() sometimes returned success even when it didn't fill in all the bytes. - It was possible for xtrng_trng_generate() and xtrng_hwrng_trng_read() to run concurrently and interfere with each other, as the locking code in xtrng_hwrng_trng_read() was broken. Fixes: 8979744aca80 ("crypto: xilinx - Add TRNG driver for Versal") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-11crypto: exynos-rng - Remove exynos-rng driverEric Biggers
This driver has no purpose. It doesn't feed into the Linux RNG, nor does it implement the hwrng interface. It is accessible only via the "rng" algorithm type of AF_ALG, which isn't used in practice. Everyone uses either the Linux RNG, or rarely /dev/hwrng. Moreover, this is a PRNG whose only source of entropy is the 160-bit seed the user passes in. So this can be used only by a user who already has a source of cryptographically secure random numbers, such as /dev/random. Which they can, and do, just use in the first place. Just remove this driver. There's no need to keep useless code around. Note that the other crypto_rng drivers in drivers/crypto/ are similarly unused and are being removed too. This commit just handles exynos-rng. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-11hwrng: hisi-trng - Move hisi-trng into drivers/char/hw_random/Eric Biggers
Since this file just implements a hwrng driver, move it into drivers/char/hw_random/. Rename the kconfig option accordingly as well. Note that this moves the file back to its original location. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-11crypto: hisi-trng - Remove crypto_rng interfaceEric Biggers
drivers/crypto/hisilicon/trng/trng.c exposes the same hardware through two completely separate interfaces, crypto_rng and hwrng. However, the implementation of this is buggy because it permits generation operations from these interfaces to run concurrently with each other, accessing the same registers. That is, hisi_trng_generate() synchronizes with itself but not with hisi_trng_read(). This results in potential repetition of output from the RNG, output of non-random values, etc. Fortunately, there's actually no point in hardware RNG drivers implementing the crypto_rng interface. It's not actually used by anything besides the "rng" algorithm type of AF_ALG, which in turn is not actually used in practice. Other crypto_rng hardware drivers are likewise being phased out, leaving just the hwrng support. Thus, remove it to simplify the code and avoid conflict (and confusion) with the hwrng interface which is the one that actually matters. Fixes: e4d9d10ef4be ("crypto: hisilicon/trng - add support for PRNG") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-11crypto: loongson - Remove broken and unused loongson-rngEric Biggers
The loongson-rng rng_alg has several vulnerabilities, including not providing forward security, and a use-after-free bug due to the use of wait_for_completion_interruptible(). Meanwhile, the rng_alg framework doesn't really have any purpose in the first place other than to access the software algorithms crypto/drbg.c and crypto/jitterentropy.c. Hardware-specific rng_algs have no in-kernel user, and unlike hwrng there's no feed into the actual Linux RNG. As such, there's really no point to this code. There are of course other rng_alg drivers that are similarly unused, but they're similarly in the process of being phased out, e.g. https://lore.kernel.org/r/20260529193648.18172-1-ebiggers@kernel.org and https://lore.kernel.org/r/20260529220430.34135-1-ebiggers@kernel.org Given that, there's no point in fixing forward these vulnerabilities, and it makes much more sense to simply roll back the addition of this driver. If this platform provides TRNG (not PRNG) functionality, it could make sense to add a hwrng driver, but it would be quite different. Link: https://lore.kernel.org/linux-crypto/20260525145939.GC2018@quark/ Fixes: 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-11crypto: crypto4xx - Remove insecure and unused rng_algEric Biggers
Remove crypto4xx_rng, as it is insecure and unused: - It has only a 64-bit security strength, which is highly inadequate. This can be seen by the fact that crypto4xx_hw_init() seeds it with only 64 bits of entropy, and the fact that the original commit mentions that it implements ANSI X9.17 Annex C. Another issue was that this driver didn't implement the crypto_rng API correctly, as crypto4xx_prng_generate() didn't return 0 on success. - No user of this code is known. It's usable only theoretically via the "rng" algorithm type of AF_ALG. But userspace actually just uses the actual Linux RNG (/dev/random etc) instead. And rng_algs don't contribute entropy to the actual Linux RNG either. (This may have been confused with hwrng, which does contribute entropy.) Fixes: d072bfa48853 ("crypto: crypto4xx - add prng crypto support") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> Acked-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-11crypto: qat - validate RSA CRT component lengthsGiovanni Cabiddu
The generic RSA key parser (rsa_helper.c) bounds each CRT component (p, q, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt() allocates half-size DMA buffers (key_sz / 2) and right-aligns each component with: memcpy(dst + half_key_sz - len, src, len) When a CRT component is larger than half_key_sz the subtraction underflows and memcpy writes past the DMA buffer, causing memory corruption. Add a len > half_key_sz check next to the existing !len check for each of the five CRT components so the driver falls back to the non-CRT path instead of writing out of bounds. Fixes: 879f77e9071f ("crypto: qat - Add RSA CRT mode") Cc: stable@vger.kernel.org Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by: Ahsan Atta <ahsan.atta@intel.com> Reviewed-by: Laurent M Coquerel <laurent.m.coquerel@intel.com> Tested-by: Laurent M Coquerel <laurent.m.coquerel@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-11dt-bindings: dma: snps,dw-axi-dmac: Add fallback compatible for CV1800BInochi Amaoto
The previous version of the binding change only add compatible string without adding the fallback compatible, this breaks backward compatibility. Add the needed fallback compatible to fix this. Fixes: be3e2a0419c6 ("dt-bindings: dma: snps,dw-axi-dmac: Add CV1800B compatible") Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20260511063818.463877-2-inochiama@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11MAINTAINERS: dmaengine/ti: Remove myself and add Vignesh as maintainerPeter Ujfalusi
As I cannot spend adequate time to fulfill my role as maintainer for the TI DMA drivers, it is for the better if I resign and hand over the role to Vignesh Raghavendra. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@gmail.com> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://patch.msgid.link/20260505164605.15878-1-peter.ujfalusi@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11dmaengine: qcom: Unify user-visible "Qualcomm" nameKrzysztof Kozlowski
Various names for Qualcomm as a company are used in user-visible config options: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified "Qualcomm" so it will be easier for users to identify the options when for example running menuconfig. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260423173602.92503-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11dt-bindings: dma: qcom,gpi: Document GPI DMA engine for Shikra SoCXueyao An
Document the GPI DMA engine on Shikra platform. It is fully compatible with the GPI DMA engine found on SM6350, thus using qcom,sm6350-gpi-dma as fallback compatible. Signed-off-by: Xueyao An <xueyao.an@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com> Link: https://patch.msgid.link/20260608-shikra-dt-m1-v4-1-2114300594a6@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11dmaengine: qcom: hidma: use sysfs_emit() in sysfs show callbacksHungyu Lin
Replace sprintf() and strlen() patterns in sysfs show callbacks with sysfs_emit(). sysfs_emit() is the preferred helper for formatting sysfs output and simplifies the implementation. Signed-off-by: Hungyu Lin <dennylin0707@gmail.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260607163119.78717-1-dennylin0707@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11dmaengine: dw-axi-dmac: fix PM for system sleep and channel allocTze Yee Ng
The driver only had runtime PM callbacks. If a channel stayed allocated across system suspend/resume, the runtime usage count could remain non-zero while hardware state (DMAC_CFG, clocks) was lost, and axi_dma_runtime_resume() would not run to restore it. Add system-sleep PM ops that use pm_runtime_force_suspend() and pm_runtime_force_resume() so suspend/resume reuses the existing axi_dma_suspend() and axi_dma_resume() paths. Replace pm_runtime_get() with pm_runtime_resume_and_get() in dma_chan_alloc_chan_resources() so clocks are enabled before a client can immediately submit a transfer and touch MMIO. Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com> Link: https://patch.msgid.link/18bf778a3a1cc2f377ef8eb0d1508d8ac6371896.1779688569.git.tze.yee.ng@altera.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11dmaengine: dw-axi-dmac: drop redundant DMAC enable in block startNiravkumar L Rabara
axi_chan_block_xfer_start() runs after the controller is already enabled, so calling axi_dma_enable() again is unnecessary. Remove the redundant enable call to keep the transfer start path clean and avoid repeated no-op programming. Signed-off-by: Niravkumar L Rabara <niravkumarlaxmidas.rabara@altera.com> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com> Link: https://patch.msgid.link/060733464e19298f670cd269d4849f2092644923.1779688569.git.tze.yee.ng@altera.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11dmaengine: altera-msgdma: Use memcpy_toio for descriptor FIFO writesAdrian Ng Ho Yin
The descriptor FIFO requires that all words of a descriptor are written in order, with the control word written last to flush it into the DMA engine. Using memcpy() with __force to __iomem is not the correct API and does not guarantee appropriate MMIO access on all architectures. Replace the descriptor body copy with memcpy_toio(), using offsetof(struct msgdma_extended_desc, control) to exclude the control word. This matches the previous sizeof(desc->hw_desc) - sizeof(u32) length only when control is the last struct member; add a static_assert to enforce that layout so a future field after control cannot silently break FIFO ordering. Keep writing the control word separately with write barriers, so it remains the final word pushed into the FIFO. Signed-off-by: Adrian Ng Ho Yin <adrianhoyin.ng@altera.com> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com> Link: https://patch.msgid.link/f6f3b4a2e2eb0eb1a51976de3f5d1ef5bab9bd76.1779697226.git.tze.yee.ng@altera.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-11dt-bindings: dma: fsl-edma: add dma-channel-mask property descriptionJoy Zou
Add documentation for the dma-channel-mask property in the fsl-edma binding. This property uses an inverted bit definition: bit value 0 indicates the channel is available, while bit value 1 indicates unavailable. That was already used widely for i.MX8, i.MX9. Correcting the definition will break backward compatibility. This reversal only impacts the eDMA dts node and driver, and doesn't impact DMA consumer. Therefore, keep the inverted definition. Also add a note at the top of the binding to highlight this inverted definition to prevent confusion. Signed-off-by: Joy Zou <joy.zou@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260211-b4-imx95-v2x-v4-1-10852754b267@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-10hwmon: (gpd-fan) Reject EC PWM value 0 as invalidPei Xiao
The EC firmware is expected to return values in [1, pwm_max]. A read of 0 is illegal and would cause underflow in the conversion formula. Explicitly check for 0 and return -EIO. Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Link: https://lore.kernel.org/r/1c2ffa0d832ae3a74f6d4ffa7cc7b7e6cced69e3.1781138459.git.xiaopei01@kylinos.cn Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-10drm/xe: fix refcount leak in xe_range_fence_insert()Wentao Liang
xe_range_fence_insert() acquires a reference on fence via dma_fence_get() and stores it in rfence->fence. It then calls dma_fence_add_callback() and handles two cases: when the callback is successfully registered (err == 0) the fence is transferred to the tree for later cleanup; when the fence is already signaled (err == -ENOENT) it manually drops the extra reference with dma_fence_put(fence). However, dma_fence_add_callback() can fail with other errors (e.g. -EINVAL) and in that case the code falls through to the free: label without releasing the acquired reference, leaking it. Fix the leak by adding an else branch that calls dma_fence_put() before jumping to free: for any error other than -ENOENT. Fixes: 845f64bdbfc9 ("drm/xe: Introduce a range-fence utility") Signed-off-by: Wentao Liang <vulab@iscas.ac.cn> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260610172705.3450560-1-matthew.brost@intel.com
2026-06-10Input: synaptics-rmi4 - unregister function handlers on physical driver ↵Haoxiang Li
registration failure If rmi_register_physical_driver() fails, the current error path unregisters only the RMI bus. The function handlers registered earlier remain registered with the driver core. Add a separate error path to unregister the function handlers before unregistering the bus in this failure case. Fixes: 2b6a321da9a2 ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices") Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260610064633.2837084-1-haoxiang_li2024@163.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-10selftests/bpf: Cover tail-call cgroup storage prog-array checksLin Ma
Add tail-call selftests for prog-array ownership when cgroup storage is in use. Verify that loading succeeds when callers and callees reuse the owner's cgroup storage map, and that loading fails for a different storage map and for the A(storage) -> B(no storage) -> C(storage) bridge case addressed in the previous commit. Also verify that a storage-less leaf program which cannot perform tail calls itself is still allowed to join a storage-owned prog array, while a storage-less tail-caller is rejected also at map update time. # LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t tailcalls [...] #475/25 tailcalls/tailcall_freplace:OK #475/26 tailcalls/tailcall_bpf2bpf_freplace:OK #475/27 tailcalls/tailcall_failure:OK #475/28 tailcalls/reject_tail_call_spin_lock:OK #475/29 tailcalls/reject_tail_call_rcu_lock:OK #475/30 tailcalls/reject_tail_call_preempt_lock:OK #475/31 tailcalls/reject_tail_call_ref:OK #475/32 tailcalls/tailcall_sleepable:OK #475/33 tailcalls/tailcall_cgrp_storage:OK #475/34 tailcalls/tailcall_cgrp_storage_diff_storage:OK #475/35 tailcalls/tailcall_cgrp_storage_no_storage:OK #475/36 tailcalls/tailcall_cgrp_storage_no_storage_leaf:OK #475/37 tailcalls/tailcall_cgrp_storage_no_storage_bridge:OK #475 tailcalls:OK Summary: 1/37 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Lin Ma <malin89@huawei.com> Signed-off-by: Rongzhen Cui <cuirongzhen@huawei.com> Signed-off-by: Jingguo Tan <tanjingguo@huawei.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20260610105539.705887-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-10bpf: Tighten cgroup storage cookie checks for prog arraysDaniel Borkmann
The fix in commit abad3d0bad72 ("bpf: Fix oob access in cgroup local storage") is still incomplete. The prog-array compatibility check treats a program with no cgroup storage as compatible with any stored storage cookie. This allows a storage-less program to bridge a tail call chain between an entry program and a storage-using callee even though cgroup local storage at runtime still follows the caller's context, that is, A -> B(no storage) -> C(storage) path. Requiring exact cookie equality would break the legitimate case of a storage-less leaf program being tail called from a storage-using one. Instead, only accept a zero storage cookie if the program cannot perform tail calls itself. This keeps A -> B(no storage) working while rejecting the A -> B(no storage) -> C(storage) bridge. Fixes: abad3d0bad72 ("bpf: Fix oob access in cgroup local storage") Reported-by: Lin Ma <malin89@huawei.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20260610105539.705887-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-10Input: ads7846 - don't use scratch for tx_buf when clearing registerKris Bahnsen
The workaround for XPT2046 clears the command register, giving the touchscreen controller a NOP. The change incorrectly re-uses the req->scratch variable which is used as rx_buf for xfer[5], so by the time xfer[6] occurs, the contents of req->scratch may not be 0. It was found that the touchscreen controller can end up in a completely unresponsive state due to it being given a command the driver does not expect. Instead, rely on the spi_transfer behavior of tx_buf being NULL to transmit all 0 bits and use the scratch variable for the rx_buf for both the 1 byte command to and 2 byte response from the controller. Also relocates the scratch member of struct ser_req to force it into a different cache line to prevent any potential issues of DMA stepping on unrelated data in other struct members due to sharing the same cache line. This change was tested on real TSC2046 and ADS7843 controllers, but not the XPT2046 the workaround was originally created for. Confirming that the original modification to clear the command register does not impact either real controller. Fixes: 781a07da9bb94 ("Input: ads7846 - add dummy command register clearing cycle") Cc: stable@vger.kernel.org Co-developed-by: Mark Featherston <mark@embeddedTS.com> Signed-off-by: Mark Featherston <mark@embeddedTS.com> Signed-off-by: Kris Bahnsen <kris@embeddedTS.com> Link: https://patch.msgid.link/20260507164943.760009-1-kris@embeddedTS.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-10perf symbols: Add bounds checks to read_build_id() note iteration in minimal ↵Arnaldo Carvalho de Melo
build symbol-minimal.c's read_build_id() iterates ELF notes with the same pattern as symbol-elf.c's elf_read_build_id(): pointer arithmetic driven by n_namesz and n_descsz from 32-bit note header fields, without validating that the name and desc fit within the note section data. A malformed ELF file with oversized note sizes causes out-of-bounds reads past the section data buffer. Add the same bounds check as the libelf path: validate namesz and descsz individually against remaining data before advancing the pointer, avoiding size_t overflow on 32-bit. Fixes: b691f64360ecec49 ("perf symbols: Implement poor man's ELF parser") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-06-10perf symbols: Add bounds checks to elf_read_build_id() note iterationArnaldo Carvalho de Melo
elf_read_build_id() iterates ELF notes using pointer arithmetic driven by n_namesz and n_descsz from the note headers. Neither the note header read nor the subsequent name/desc advances are checked against the section boundary. A malformed ELF file with oversized note sizes causes out-of-bounds reads past the section data buffer. Add two bounds checks: verify the note header fits within the remaining section data, and verify that namesz + descsz (after alignment) fits before advancing the pointer. Fixes: fd7a346ea292074e ("perf symbols: Filename__read_build_id should look at .notes section too") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-06-10perf bpf: Fix metadata leak in perf_env__add_bpf_info() on duplicate insertArnaldo Carvalho de Melo
When perf_env__insert_bpf_prog_info() returns false (duplicate program), the error path frees info_linear and info_node but not info_node->metadata. If bpf_metadata_create() had succeeded, the metadata allocation is permanently leaked. Fix by calling bpf_metadata_free() on info_node->metadata before freeing info_node. bpf_metadata_free() handles NULL, so this is safe even when bpf_metadata_create() returned NULL. Reported-by: sashiko-bot <sashiko-bot@kernel.org> Fixes: fdc3441f2d317b40 ("perf record: collect BPF metadata from new programs") Cc: Blake Jones <blakejones@google.com> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-06-10perf bpf: Fix map data leak in bpf_metadata_create() on alloc failureArnaldo Carvalho de Melo
bpf_metadata_create() calls bpf_metadata_read_map_data() which allocates map.btf and map.rodata. If the subsequent bpf_metadata_alloc() fails, the code does 'continue' which skips bpf_metadata_free_map_data(), permanently leaking both allocations. Fix by calling bpf_metadata_free_map_data() before continue. Reported-by: sashiko-bot <sashiko-bot@kernel.org> Fixes: ab38e84ba9a80581 ("perf record: collect BPF metadata from existing BPF programs") Cc: Blake Jones <blakejones@google.com> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-06-10perf bpf: Add NULL check for btf__type_by_id() in synthesize_bpf_prog_name()Arnaldo Carvalho de Melo
synthesize_bpf_prog_name() calls btf__type_by_id() and immediately dereferences the result via t->name_off without checking for NULL. btf__type_by_id() returns NULL when the type_id is invalid or out of range. When processing perf.data files, finfo->type_id comes from untrusted input, so an invalid ID causes a NULL pointer dereference. Fix by checking t for NULL before dereferencing. Reported-by: sashiko-bot <sashiko-bot@kernel.org> Fixes: fc462ac75b36daaa ("perf bpf: Extract logic to create program names from perf_event__synthesize_one_bpf_prog()") Cc: Song Liu <songliubraving@fb.com> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-06-10tools lib api: Fix mount_overload() snprintf truncation and toupper rangeArnaldo Carvalho de Melo
mount_overload() builds an environment variable name like "PERF_SYSFS_ENVIRONMENT" from fs->name. Two bugs: 1) snprintf() uses name_len as the buffer size instead of sizeof(upper_name). For fs->name = "sysfs" (len=5), the output is truncated to "PERF" (4 chars + null), so getenv() never finds the intended variable. 2) mem_toupper() only uppercases name_len bytes, converting just the "PERF" prefix rather than the full string including the filesystem name portion. Fix by using sizeof(upper_name) for snprintf and strlen(upper_name) for mem_toupper, so the full "PERF_SYSFS_ENVIRONMENT" string is correctly formatted and uppercased. Reported-by: sashiko-bot <sashiko-bot@kernel.org> Fixes: 73ca85ad364769ff ("tools lib api fs: Add FSTYPE__mount() method") Cc: Jiri Olsa <jolsa@kernel.org> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-06-10tools lib api: Fix filename__write_int() writing uninitialized stack dataArnaldo Carvalho de Melo
filename__write_int() formats an integer into a 64-byte buffer with sprintf() then passes sizeof(buf) (64) as the write length. This writes all 64 bytes including uninitialized stack data past the formatted string. Most sysfs files reject the oversized write, making the function always return -1. Fix by capturing the sprintf() return value and using it as the write length. Reported-by: sashiko-bot <sashiko-bot@kernel.org> Fixes: 3b00ea938653d136 ("tools lib api fs: Add sysfs__write_int function") Cc: Kan Liang <kan.liang@intel.com> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-06-10perf tools: Use snprintf() in dso__read_running_kernel_build_id()Arnaldo Carvalho de Melo
dso__read_running_kernel_build_id() uses sprintf() to format a sysfs path from machine->root_dir into a PATH_MAX buffer. If root_dir is close to PATH_MAX in length, appending "/sys/kernel/notes" (18 bytes) overflows the stack buffer. Switch to snprintf() with sizeof(path) to prevent the overflow. Reported-by: sashiko-bot <sashiko-bot@kernel.org> Fixes: cdd059d731eeb466 ("perf tools: Move dso_* related functions into dso object") Cc: Jiri Olsa <jolsa@kernel.org> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-10 07:15:03 +0000