summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2025-08-15soundwire: Correct some property namesCharles Keepax1-2/+2
[ Upstream commit ae6a0f5b8a5b0ca2e4bf1c0380267ad83aca8401 ] The DisCo properties should be mipi-sdw-paging-supported and mipi-sdw-bank-delay-supported, with an 'ed' on the end. Correct the property names used in sdw_slave_read_prop(). The internal flag bank_delay_support is currently unimplemented, so that being read wrong does not currently affect anything. The two existing users for this helper and the paging_support flag rt1320-sdw.c and rt721-sdca-sdw.c both manually set the flag in their slave properties, thus are not affected by this bug either. Fixes: 56d4fe31af77 ("soundwire: Add MIPI DisCo property helpers") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20250624125507.2866346-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15PCI: qcom: Wait PCIE_RESET_CONFIG_WAIT_MS after link-up IRQNiklas Cassel1-0/+1
[ Upstream commit 15b6b243cc2b1017cf89e2477aa0b4e1a306a82a ] Per PCIe r6.0, sec 6.6.1, software must generally wait a minimum of 100ms (PCIE_RESET_CONFIG_WAIT_MS) after Link training completes before sending a Configuration Request. Prior to 36971d6c5a9a ("PCI: qcom: Don't wait for link if we can detect Link Up"), qcom used dw_pcie_wait_for_link(), which waited between 0 and 90ms after the link came up before we enumerate the bus, and this was apparently enough for most devices. After 36971d6c5a9a, qcom_pcie_global_irq_thread() started enumeration immediately when handling the link-up IRQ, and devices (e.g., Laszlo Fiat's PLEXTOR PX-256M8PeGN NVMe SSD) may not be ready to handle config requests yet. Delay PCIE_RESET_CONFIG_WAIT_MS after the link-up IRQ before starting enumeration. Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver") Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> Link: https://patch.msgid.link/20250625102347.1205584-13-cassel@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15PCI: dw-rockchip: Wait PCIE_RESET_CONFIG_WAIT_MS after link-up IRQNiklas Cassel1-0/+1
[ Upstream commit c7eb9c5e1498882951b7583c56add0b77bfc162e ] Per PCIe r6.0, sec 6.6.1, software must generally wait a minimum of 100ms (PCIE_RESET_CONFIG_WAIT_MS) after Link training completes before sending a Configuration Request. Prior to ec9fd499b9c6 ("PCI: dw-rockchip: Don't wait for link since we can detect Link Up"), dw-rockchip used dw_pcie_wait_for_link(), which waited between 0 and 90ms after the link came up before we enumerate the bus, and this was apparently enough for most devices. After ec9fd499b9c6, rockchip_pcie_rc_sys_irq_thread() started enumeration immediately when handling the link-up IRQ, and devices (e.g., Laszlo Fiat's PLEXTOR PX-256M8PeGN NVMe SSD) may not be ready to handle config requests yet. Delay PCIE_RESET_CONFIG_WAIT_MS after the link-up IRQ before starting enumeration. Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver") Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> Cc: Laszlo Fiat <laszlo.fiat@proton.me> Link: https://patch.msgid.link/20250625102347.1205584-12-cassel@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15PCI: Rename PCIE_RESET_CONFIG_DEVICE_WAIT_MS to PCIE_RESET_CONFIG_WAIT_MSNiklas Cassel2-2/+2
[ Upstream commit 817f989700fddefa56e5e443e7d138018ca6709d ] Rename PCIE_RESET_CONFIG_DEVICE_WAIT_MS to PCIE_RESET_CONFIG_WAIT_MS. Suggested-by: Bjorn Helgaas <helgaas@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20250625102347.1205584-10-cassel@kernel.org Stable-dep-of: c7eb9c5e1498 ("PCI: dw-rockchip: Wait PCIE_RESET_CONFIG_WAIT_MS after link-up IRQ") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15PCI: Adjust the position of reading the Link Control 2 registerJiwei Sun1-2/+4
[ Upstream commit b85af48de3ece4e5bbdb2248a5360a409991cf67 ] In a89c82249c37 ("PCI: Work around PCIe link training failures"), if the speed limit is set to 2.5 GT/s and the retraining is successful, an attempt will be made to lift the speed limit. One condition for lifting the speed limit is to check whether the link speed field of the Link Control 2 register is PCI_EXP_LNKCTL2_TLS_2_5GT. However, since de9a6c8d5dbf ("PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed"), the `lnkctl2` local variable does not undergo any changes during the speed limit setting and retraining process. As a result, the code intended to lift the speed limit is not executed. To address this issue, adjust the position of the Link Control 2 register read operation in the code and place it before its use. Fixes: de9a6c8d5dbf ("PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed") Suggested-by: Maciej W. Rozycki <macro@orcam.me.uk> Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Jiwei Sun <sunjw10@lenovo.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20250123055155.22648-3-sjiwei@163.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15pinctrl: canaan: k230: Fix order of DT parse and pinctrl registerZe Huang1-2/+5
[ Upstream commit d94a32ac688f953dc9a9f12b5b4139ecad841bbb ] Move DT parse before pinctrl register. This ensures that device tree parsing is done before calling devm_pinctrl_register() to prevent using uninitialized pin resources. Fixes: 545887eab6f6 ("pinctrl: canaan: Add support for k230 SoC") Reported-by: Yao Zi <ziyao@disroot.org> Signed-off-by: Ze Huang <huangze@whut.edu.cn> Link: https://lore.kernel.org/20250624-k230-return-check-v1-2-6b4fc5ba0c41@whut.edu.cn Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15pinctrl: canaan: k230: add NULL check in DT parseZe Huang1-1/+5
[ Upstream commit 65bd0be486390fc12a84eafaad78758c5e5a55e6 ] Add a NULL check for the return value of of_get_property() when retrieving the "pinmux" property in the group parser. This avoids a potential NULL pointer dereference if the property is missing from the device tree node. Also fix a typo ("sintenel") in the device ID match table comment, correcting it to "sentinel". Fixes: 545887eab6f6 ("pinctrl: canaan: Add support for k230 SoC") Reported-by: Yao Zi <ziyao@disroot.org> Signed-off-by: Ze Huang <huangze@whut.edu.cn> Link: https://lore.kernel.org/20250624-k230-return-check-v1-1-6b4fc5ba0c41@whut.edu.cn Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15pinctrl: berlin: fix memory leak in berlin_pinctrl_build_state()Yuan Chen1-2/+6
[ Upstream commit 8f6f303551100291bf2c1e1ccc66b758fffb1168 ] In the original implementation, krealloc() failure handling incorrectly assigned the original memory pointer to NULL after kfree(), causing a memory leak when reallocation failed. Fixes: de845036f997 ("pinctrl: berlin: fix error return code of berlin_pinctrl_build_state()") Signed-off-by: Yuan Chen <chenyuan@kylinos.cn> Link: https://lore.kernel.org/20250620015343.21494-1-chenyuan_fl@163.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15pinctrl: sunxi: Fix memory leak on krealloc failureYuan Chen1-3/+8
[ Upstream commit e3507c56cbb208d4f160942748c527ef6a528ba1 ] In sunxi_pctrl_dt_node_to_map(), when krealloc() fails to resize the pinctrl_map array, the function returns -ENOMEM directly without freeing the previously allocated *map buffer. This results in a memory leak of the original kmalloc_array allocation. Fixes: e11dee2e98f8 ("pinctrl: sunxi: Deal with configless pins") Signed-off-by: Yuan Chen <chenyuan@kylinos.cn> Link: https://lore.kernel.org/20250620012708.16709-1-chenyuan_fl@163.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15PCI: endpoint: pci-epf-vntb: Return -ENOENT if pci_epc_get_next_free_bar() failsJerome Brunet1-1/+1
[ Upstream commit 7ea488cce73263231662e426639dd3e836537068 ] According the function documentation of epf_ntb_init_epc_bar(), the function should return an error code on error. However, it returns -1 when no BAR is available i.e., when pci_epc_get_next_free_bar() fails. Return -ENOENT instead. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> [mani: changed err code to -ENOENT] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250603-pci-vntb-bar-mapping-v2-1-fc685a22ad28@baylibre.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15crypto: qat - restore ASYM service support for GEN6 devicesSuman Kumar Chakraborty1-1/+9
[ Upstream commit 4e55a929ff4d973206879a997a47a188353b3cd6 ] Support for asymmetric crypto services was not included in the qat_6xxx by explicitly setting the asymmetric capabilities to 0 to allow for additional testing. Enable asymmetric crypto services on QAT GEN6 devices by setting the appropriate capability flags. Fixes: 17fd7514ae68 ("crypto: qat - add qat_6xxx driver") Signed-off-by: Suman Kumar Chakraborty <suman.kumar.chakraborty@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15power: supply: max1720x correct capacity computationThomas Antoine1-5/+6
[ Upstream commit 58ae036172b5f051a19a32eba94a3e5eb37bf47e ] From the datasheet of the MAX17201/17205, the LSB should be "5.0μVh/RSENSE". The current computation sets it at 0.5mAh=5.0μVh/10mOhm, which does not take into account the value of rsense (which is in 10µV steps) which can be different from 10mOhm. Change the computation to fit the specs. Fixes: 479b6d04964b ("power: supply: add support for MAX1720x standalone fuel gauge") Signed-off-by: Thomas Antoine <t.antoine@uclouvain.be> Link: https://lore.kernel.org/r/20250523-b4-gs101_max77759_fg-v4-1-b49904e35a34@uclouvain.be Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15power: supply: qcom_pmi8998_charger: fix wakeirqCasey Connolly1-1/+3
[ Upstream commit 6c5393771c50fac30f08dfb6d2f65f4f2cfeb8c7 ] Unloading and reloading the driver (e.g. when built as a module) currently leads to errors trying to enable wake IRQ since it's already enabled. Use devm to manage this for us so it correctly gets disabled when removing the driver. Additionally, call device_init_wakeup() so that charger attach/remove will trigger a wakeup by default. Fixes: 8648aeb5d7b7 ("power: supply: add Qualcomm PMI8998 SMB2 Charger driver") Signed-off-by: Casey Connolly <casey.connolly@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250619-smb2-smb5-support-v1-3-ac5dec51b6e1@linaro.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15power: supply: max14577: Handle NULL pdata when CONFIG_OF is not setCharles Han1-2/+2
[ Upstream commit 2937f5d2e24eefef8cb126244caec7fe3307f724 ] When the kernel is not configured CONFIG_OF, the max14577_charger_dt_init function returns NULL. Fix the max14577_charger_probe functionby returning -ENODATA instead of potentially passing a NULL pointer to PTR_ERR. This fixes the below smatch warning: max14577_charger_probe() warn: passing zero to 'PTR_ERR' Fixes: e30110e9c96f ("charger: max14577: Configure battery-dependent settings from DTS and sysfs") Signed-off-by: Charles Han <hanchunchao@inspur.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250519061601.8755-1-hanchunchao@inspur.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15power: reset: POWER_RESET_TORADEX_EC should depend on ARCH_MXCGeert Uytterhoeven1-0/+1
[ Upstream commit 22e4d29f081df8a10f1c062d3d952bb876eb9bdc ] The Toradex Embedded Controller is currently only present on Toradex SMARC iMX8MP and iMX95 SoMs. Hence add a dependency on ARCH_MXC, to prevent asking the user about this driver when configuring a kernel without NXP i.MX SoC family support. Fixes: 18672fe12367ed44 ("power: reset: add Toradex Embedded Controller") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/1ef0beb1e09bf914650f9f9885a33af06772540d.1746536287.git.geert+renesas@glider.be Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15power: supply: cpcap-charger: Fix null check for power_supply_get_by_nameCharles Han1-3/+2
[ Upstream commit d9fa3aae08f99493e67fb79413c0e95d30fca5e9 ] In the cpcap_usb_detect() function, the power_supply_get_by_name() function may return `NULL` instead of an error pointer. To prevent potential null pointer dereferences, Added a null check. Fixes: eab4e6d953c1 ("power: supply: cpcap-charger: get the battery inserted infomation from cpcap-battery") Signed-off-by: Charles Han <hanchunchao@inspur.com> Link: https://lore.kernel.org/r/20250519024741.5846-1-hanchunchao@inspur.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15clk: xilinx: vcu: unregister pll_post only if registered correctlyRohit Visavalia1-2/+2
[ Upstream commit 3b0abc443ac22f7d4f61ddbbbbc5dbb06c87139d ] If registration of pll_post is failed, it will be set to NULL or ERR, unregistering same will fail with following call trace: Unable to handle kernel NULL pointer dereference at virtual address 008 pc : clk_hw_unregister+0xc/0x20 lr : clk_hw_unregister_fixed_factor+0x18/0x30 sp : ffff800011923850 ... Call trace: clk_hw_unregister+0xc/0x20 clk_hw_unregister_fixed_factor+0x18/0x30 xvcu_unregister_clock_provider+0xcc/0xf4 [xlnx_vcu] xvcu_probe+0x2bc/0x53c [xlnx_vcu] Fixes: 4472e1849db7 ("soc: xilinx: vcu: make pll post divider explicit") Signed-off-by: Rohit Visavalia <rohit.visavalia@amd.com> Link: https://lore.kernel.org/r/20250210113614.4149050-2-rohit.visavalia@amd.com Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15media: v4l2-ctrls: Fix H264 SEPARATE_COLOUR_PLANE checkJames Cowgill1-4/+4
[ Upstream commit 803b9eabc649c778986449eb0596e5ffeb7a8aed ] The `separate_colour_plane_flag` element is only present in the SPS if `chroma_format_idc == 3`, so the corresponding flag should be disabled whenever that is not the case and not just on profiles where `chroma_format_idc` is not present. Fixes: b32e48503df0 ("media: controls: Validate H264 stateless controls") Signed-off-by: James Cowgill <james.cowgill@blaize.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15media: imx-jpeg: Account for data_offset when getting image addressMing Qian2-11/+37
[ Upstream commit 51ad3b570ea7b1916ff4db993f1aa22bb48fdac6 ] Applications may set data_offset when it refers to an output queue. So driver need to account for it when getting the start address of input image in the plane. Meanwhile the mxc-jpeg codec requires the address (plane address + data_offset) to be 16-aligned. Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder") Signed-off-by: Ming Qian <ming.qian@oss.nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15clk: davinci: Add NULL check in davinci_lpsc_clk_register()Henry Martin1-0/+5
[ Upstream commit 13de464f445d42738fe18c9a28bab056ba3a290a ] devm_kasprintf() returns NULL when memory allocation fails. Currently, davinci_lpsc_clk_register() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue and ensuring no resources are left allocated. Fixes: c6ed4d734bc7 ("clk: davinci: New driver for davinci PSC clocks") Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com> Link: https://lore.kernel.org/r/20250401131341.26800-1-bsdhenrymartin@gmail.com Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15mtd: fix possible integer overflow in erase_xfer()Ivan Stepchenko1-1/+1
[ Upstream commit 9358bdb9f9f54d94ceafc650deffefd737d19fdd ] The expression '1 << EraseUnitSize' is evaluated in int, which causes a negative result when shifting by 31 - the upper bound of the valid range [10, 31], enforced by scan_header(). This leads to incorrect extension when storing the result in 'erase->len' (uint64_t), producing a large unexpected value. Found by Linux Verification Center (linuxtesting.org) with Svace. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ivan Stepchenko <sid@itb.spb.ru> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15crypto: qat - fix state restore for banks with exceptionsSvyatoslav Pankratov1-7/+22
[ Upstream commit 254923ca8715f623704378266815b6d14eb26194 ] Change the logic in the restore function to properly handle bank exceptions. The check for exceptions in the saved state should be performed before conducting any other ringstat register checks. If a bank was saved with an exception, the ringstat will have the appropriate rp_halt/rp_exception bits set, causing the driver to exit the restore process with an error. Instead, the restore routine should first check the ringexpstat register, and if any exception was raised, it should stop further checks and return without any error. In other words, if a ring pair is in an exception state at the source, it should be restored the same way at the destination but without raising an error. Even though this approach might lead to losing the exception state during migration, the driver will log the exception from the saved state during the restore process. Signed-off-by: Svyatoslav Pankratov <svyatoslav.pankratov@intel.com> Fixes: bbfdde7d195f ("crypto: qat - add bank save and restore flows") Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15crypto: qat - allow enabling VFs in the absence of IOMMUAhsan Atta1-1/+0
[ Upstream commit 53669ff591d4deb2d80eed4c07593ad0c0b45899 ] The commit ca88a2bdd4dd ("crypto: qat - allow disabling SR-IOV VFs") introduced an unnecessary change that prevented enabling SR-IOV when IOMMU is disabled. In certain scenarios, it is desirable to enable SR-IOV even in the absence of IOMMU. Thus, restoring the previous functionality to allow VFs to be enumerated in the absence of IOMMU. Fixes: ca88a2bdd4dd ("crypto: qat - allow disabling SR-IOV VFs") Signed-off-by: Ahsan Atta <ahsan.atta@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by: Michal Witwicki <michal.witwicki@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15crypto: ccp - Fix dereferencing uninitialized error pointerAshish Kalra1-3/+5
[ Upstream commit 0fa766726c091ff0ec7d26874f6e4724d23ecb0e ] Fix below smatch warnings: drivers/crypto/ccp/sev-dev.c:1312 __sev_platform_init_locked() error: we previously assumed 'error' could be null Fixes: 9770b428b1a2 ("crypto: ccp - Move dev_info/err messages for SEV/SNP init and shutdown") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202505071746.eWOx5QgC-lkp@intel.com/ Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15crypto: marvell/cesa - Fix engine load inaccuracyHerbert Xu2-3/+6
[ Upstream commit 442134ab30e75b7229c4bfc1ac5641d245cffe27 ] If an error occurs during queueing the engine load will never be decremented. Fix this by moving the engine load adjustment into the cleanup function. Fixes: bf8f91e71192 ("crypto: marvell - Add load balancing between engines") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15crypto: qat - use unmanaged allocation for dc_dataSuman Kumar Chakraborty1-2/+2
[ Upstream commit 4cc871ad0173e8bc22f80e3609e34d546d30ef1a ] The dc_data structure holds data required for handling compression operations, such as overflow buffers. In this context, the use of managed memory allocation APIs (devm_kzalloc() and devm_kfree()) is not necessary, as these data structures are freed and re-allocated when a device is restarted in adf_dev_down() and adf_dev_up(). Additionally, managed APIs automatically handle memory cleanup when the device is detached, which can lead to conflicts with manual cleanup processes. Specifically, if a device driver invokes the adf_dev_down() function as part of the cleanup registered with devm_add_action_or_reset(), it may attempt to free memory that is also managed by the device's resource management system, potentially leading to a double-free. This might result in a warning similar to the following when unloading the device specific driver, for example qat_6xxx.ko: qat_free_dc_data+0x4f/0x60 [intel_qat] qat_compression_event_handler+0x3d/0x1d0 [intel_qat] adf_dev_shutdown+0x6d/0x1a0 [intel_qat] adf_dev_down+0x32/0x50 [intel_qat] devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c1/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x74/0xf0 pci_unregister_driver+0x2e/0xb0 Use unmanaged memory allocation APIs (kzalloc_node() and kfree()) for the dc_data structure. This ensures that memory is explicitly allocated and freed under the control of the driver code, preventing manual deallocation from interfering with automatic cleanup. Fixes: 1198ae56c9a5 ("crypto: qat - expose deflate through acomp api for QAT GEN2") Signed-off-by: Suman Kumar Chakraborty <suman.kumar.chakraborty@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15crypto: sun8i-ce - fix nents passed to dma_unmap_sg()Ovidiu Panait1-2/+2
[ Upstream commit b6cd3cfb5afe49952f8f6be947aeeca9ba0faebb ] In sun8i_ce_cipher_unprepare(), dma_unmap_sg() is incorrectly called with the number of entries returned by dma_map_sg(), rather than using the original number of entries passed when mapping the scatterlist. To fix this, stash the original number of entries passed to dma_map_sg() in the request context. Fixes: 0605fa0f7826 ("crypto: sun8i-ce - split into prepare/run/unprepare") Signed-off-by: Ovidiu Panait <ovidiu.panait.oss@gmail.com> Acked-by: Corentin LABBE <clabbe.montjoie@gmail.com> Tested-by: Corentin LABBE <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15clk: renesas: rzv2h: Fix missing CLK_SET_RATE_PARENT flag for ddiv clocksLad Prabhakar1-0/+1
[ Upstream commit 715676d8418062f54d746451294ccce9786c1734 ] Commit bc4d25fdfadf ("clk: renesas: rzv2h: Add support for dynamic switching divider clocks") missed setting the `CLK_SET_RATE_PARENT` flag when registering ddiv clocks. Without this flag, rate changes to the divider clock do not propagate to its parent, potentially resulting in incorrect clock configurations. Fix this by setting `CLK_SET_RATE_PARENT` in the clock init data. Fixes: bc4d25fdfadfa ("clk: renesas: rzv2h: Add support for dynamic switching divider clocks") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250609140341.235919-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15PCI: rockchip-host: Fix "Unexpected Completion" log messageHans Zhang1-1/+1
[ Upstream commit fcc5f586c4edbcc10de23fb9b8c0972a84e945cd ] Fix the debug message for the PCIE_CORE_INT_UCR interrupt to clearly indicate "Unexpected Completion" instead of a duplicate "malformed TLP" message. Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support") Signed-off-by: Hans Zhang <18255117159@163.com> [mani: added fixes tag] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Acked-by: Shawn Lin <shawn.lin@rock-chips.com> Link: https://patch.msgid.link/20250607160201.807043-2-18255117159@163.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15remoteproc: qcom: pas: Conclude the rename from adspBjorn Andersson2-319/+313
[ Upstream commit 2c0c883f895f16fd9d367ec2e64bccab907d8d87 ] The change that renamed the driver from "adsp" to "pas" didn't change any of the implementation. The result is an aesthetic eyesore, and confusing to many. Conclude the rename of the driver, by updating function, structures and variable names to match what the driver actually is. The "Hexagon v5" is also dropped from the name and Kconfig, as this isn't correct either. No functional change. Fixes: 9e004f97161d ("remoteproc: qcom: Rename Hexagon v5 PAS driver") Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Reviewed-by: Wasim Nazir <quic_wasimn@quicinc.com> Link: https://lore.kernel.org/r/20250605-pas-rename-v2-1-f1c89e49e691@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15pinctrl: cirrus: madera-core: Use devm_pinctrl_register_mappings()Thomas Richard1-11/+3
[ Upstream commit 90256033c11028a57437b145449c0dab196183b9 ] Use devm_pinctrl_register_mappings(), so the mappings are automatically unregistered by the core. If pinctrl_enable() failed during the probe, pinctrl_mappings were not freed. Now it is done by the core. Fixes: 218d72a77b0b ("pinctrl: madera: Add driver for Cirrus Logic Madera codecs") Signed-off-by: Thomas Richard <thomas.richard@bootlin.com> Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/20250609-pinctrl-madera-devm-pinctrl-register-mappings-v1-1-ba2c2822cf6c@bootlin.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int()Kees Cook1-4/+5
[ Upstream commit ee4cf798202d285dcbe85e4467a094c44f5ed8e6 ] When gmin_get_config_var() calls efi.get_variable() and the EFI variable is larger than the expected buffer size, two behaviors combine to create a stack buffer overflow: 1. gmin_get_config_var() does not return the proper error code when efi.get_variable() fails. It returns the stale 'ret' value from earlier operations instead of indicating the EFI failure. 2. When efi.get_variable() returns EFI_BUFFER_TOO_SMALL, it updates *out_len to the required buffer size but writes no data to the output buffer. However, due to bug #1, gmin_get_var_int() believes the call succeeded. The caller gmin_get_var_int() then performs: - Allocates val[CFG_VAR_NAME_MAX + 1] (65 bytes) on stack - Calls gmin_get_config_var(dev, is_gmin, var, val, &len) with len=64 - If EFI variable is >64 bytes, efi.get_variable() sets len=required_size - Due to bug #1, thinks call succeeded with len=required_size - Executes val[len] = 0, writing past end of 65-byte stack buffer This creates a stack buffer overflow when EFI variables are larger than 64 bytes. Since EFI variables can be controlled by firmware or system configuration, this could potentially be exploited for code execution. Fix the bug by returning proper error codes from gmin_get_config_var() based on EFI status instead of stale 'ret' value. The gmin_get_var_int() function is called during device initialization for camera sensor configuration on Intel Bay Trail and Cherry Trail platforms using the atomisp camera stack. Reported-by: zepta <z3ptaa@gmail.com> Closes: https://lore.kernel.org/all/CAPBS6KoQyM7FMdPwOuXteXsOe44X4H3F8Fw+y_qWq6E+OdmxQA@mail.gmail.com Fixes: 38d4f74bc148 ("media: atomisp_gmin_platform: stop abusing efivar API") Reviewed-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20250724080756.work.741-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15vrf: Drop existing dst reference in vrf_ip6_input_dstStanislav Fomichev1-0/+2
[ Upstream commit f388f807eca1de9e6e70f9ffb1a573c3811c4215 ] Commit ff3fbcdd4724 ("selftests: tc: Add generic erspan_opts matching support for tc-flower") started triggering the following kmemleak warning: unreferenced object 0xffff888015fb0e00 (size 512): comm "softirq", pid 0, jiffies 4294679065 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 40 d2 85 9e ff ff ff ff ........@....... 41 69 59 9d ff ff ff ff 00 00 00 00 00 00 00 00 AiY............. backtrace (crc 30b71e8b): __kmalloc_noprof+0x359/0x460 metadata_dst_alloc+0x28/0x490 erspan_rcv+0x4f1/0x1160 [ip_gre] gre_rcv+0x217/0x240 [ip_gre] gre_rcv+0x1b8/0x400 [gre] ip_protocol_deliver_rcu+0x31d/0x3a0 ip_local_deliver_finish+0x37d/0x620 ip_local_deliver+0x174/0x460 ip_rcv+0x52b/0x6b0 __netif_receive_skb_one_core+0x149/0x1a0 process_backlog+0x3c8/0x1390 __napi_poll.constprop.0+0xa1/0x390 net_rx_action+0x59b/0xe00 handle_softirqs+0x22b/0x630 do_softirq+0xb1/0xf0 __local_bh_enable_ip+0x115/0x150 vrf_ip6_input_dst unconditionally sets skb dst entry, add a call to skb_dst_drop to drop any existing entry. Cc: David Ahern <dsahern@kernel.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Fixes: 9ff74384600a ("net: vrf: Handle ipv6 multicast and link-local addresses") Signed-off-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20250725160043.350725-1-sdf@fomichev.me Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15igb: xsk: solve negative overflow of nb_pkts in zerocopy modeJason Xing1-2/+1
[ Upstream commit 3b7c13dfdcc26a78756cc17a23cdf4310c5a24a9 ] There is no break time in the while() loop, so every time at the end of igb_xmit_zc(), negative overflow of nb_pkts will occur, which renders the return value always false. But theoretically, the result should be set after calling xsk_tx_peek_release_desc_batch(). We can take i40e_xmit_zc() as a good example. Returning false means we're not done with transmission and we need one more poll, which is exactly what igb_xmit_zc() always did before this patch. After this patch, the return value depends on the nb_pkts value. Two cases might happen then: 1. if (nb_pkts < budget), it means we process all the possible data, so return true and no more necessary poll will be triggered because of this. 2. if (nb_pkts == budget), it means we might have more data, so return false to let another poll run again. Fixes: f8e284a02afc ("igb: Add AF_XDP zero-copy Tx support") Signed-off-by: Jason Xing <kernelxing@tencent.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20250723142327.85187-3-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15stmmac: xsk: fix negative overflow of budget in zerocopy modeJason Xing1-1/+1
[ Upstream commit 2764ab51d5f0e8c7d3b7043af426b1883e3bde1d ] A negative overflow can happen when the budget number of descs are consumed. as long as the budget is decreased to zero, it will again go into while (budget-- > 0) statement and get decreased by one, so the overflow issue can happen. It will lead to returning true whereas the expected value should be false. In this case where all the budget is used up, it means zc function should return false to let the poll run again because normally we might have more data to process. Without this patch, zc function would return true instead. Fixes: 132c32ee5bc0 ("net: stmmac: Add TX via XDP zero-copy socket") Signed-off-by: Jason Xing <kernelxing@tencent.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20250723142327.85187-2-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15net: dsa: microchip: Fix wrong rx drop MIB counter for KSZ8863Tristram Ha2-1/+6
[ Upstream commit 165a7f5db919ab68a45ae755cceb751e067273ef ] When KSZ8863 support was first added to KSZ driver the RX drop MIB counter was somehow defined as 0x105. The TX drop MIB counter starts at 0x100 for port 1, 0x101 for port 2, and 0x102 for port 3, so the RX drop MIB counter should start at 0x103 for port 1, 0x104 for port 2, and 0x105 for port 3. There are 5 ports for KSZ8895, so its RX drop MIB counter starts at 0x105. Fixes: 4b20a07e103f ("net: dsa: microchip: ksz8795: add support for ksz88xx chips") Signed-off-by: Tristram Ha <tristram.ha@microchip.com> Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://patch.msgid.link/20250723030403.56878-1-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15macsec: set IFF_UNICAST_FLT priv flagStanislav Fomichev1-1/+1
[ Upstream commit 0349659fd72f662c054ff20d432559bfaa228ce4 ] Cosmin reports the following locking issue: # BUG: sleeping function called from invalid context at kernel/locking/mutex.c:275 # dump_stack_lvl+0x4f/0x60 # __might_resched+0xeb/0x140 # mutex_lock+0x1a/0x40 # dev_set_promiscuity+0x26/0x90 # __dev_set_promiscuity+0x85/0x170 # __dev_set_rx_mode+0x69/0xa0 # dev_uc_add+0x6d/0x80 # vlan_dev_open+0x5f/0x120 [8021q] # __dev_open+0x10c/0x2a0 # __dev_change_flags+0x1a4/0x210 # netif_change_flags+0x22/0x60 # do_setlink.isra.0+0xdb0/0x10f0 # rtnl_newlink+0x797/0xb00 # rtnetlink_rcv_msg+0x1cb/0x3f0 # netlink_rcv_skb+0x53/0x100 # netlink_unicast+0x273/0x3b0 # netlink_sendmsg+0x1f2/0x430 Which is similar to recent syzkaller reports in [0] and [1] and triggers because macsec does not advertise IFF_UNICAST_FLT although it has proper ndo_set_rx_mode callback that takes care of pushing uc/mc addresses down to the real device. In general, dev_uc_add call path is problematic for stacking non-IFF_UNICAST_FLT because we might grab netdev instance lock under addr_list_lock spinlock, so this is not a systemic fix. 0: https://lore.kernel.org/netdev/686d55b4.050a0220.1ffab7.0014.GAE@google.com 1: https://lore.kernel.org/netdev/68712acf.a00a0220.26a83e.0051.GAE@google.com/ Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/netdev/2aff4342b0f5b1539c02ffd8df4c7e58dd9746e7.camel@nvidia.com Fixes: 7e4d784f5810 ("net: hold netdev instance lock during rtnetlink operations") Reported-by: Cosmin Ratiu <cratiu@nvidia.com> Tested-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20250723224715.1341121-1-sdf@fomichev.me Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15net/mlx5e: Fix potential deadlock by deferring RX timeout recoveryShahar Shitrit3-1/+33
[ Upstream commit e80d65561571db5024fbdd5ec3f5472cfc485d21 ] mlx5e_reporter_rx_timeout() is currently invoked synchronously in the driver's open error flow. This causes the thread holding priv->state_lock to attempt acquiring the devlink lock, which can result in a circular dependency with other devlink operations. For example: - Devlink health diagnose flow: - __devlink_nl_pre_doit() acquires the devlink lock. - devlink_nl_health_reporter_diagnose_doit() invokes the driver's diagnose callback. - mlx5e_rx_reporter_diagnose() then attempts to acquire priv->state_lock. - Driver open flow: - mlx5e_open() acquires priv->state_lock. - If an error occurs, devlink_health_reporter may be called, attempting to acquire the devlink lock. To prevent this circular locking scenario, defer the RX timeout recovery by scheduling it via a workqueue. This ensures that the recovery work acquires locks in a consistent order: first the devlink lock, then priv->state_lock. Additionally, make the recovery work acquire the netdev instance lock to safely synchronize with the open/close channel flows, similar to mlx5e_tx_timeout_work. Repeatedly attempt to acquire the netdev instance lock until it is taken or the target RQ is no longer active, as indicated by the MLX5E_STATE_CHANNELS_ACTIVE bit. Fixes: 32c57fb26863 ("net/mlx5e: Report and recover from rx timeout") Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1753256672-337784-4-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15net/mlx5e: Remove skb secpath if xfrm state is not foundJianbo Liu1-0/+4
[ Upstream commit 6d19c44b5c6dd72f9a357d0399604ec16a77de3c ] Hardware returns a unique identifier for a decrypted packet's xfrm state, this state is looked up in an xarray. However, the state might have been freed by the time of this lookup. Currently, if the state is not found, only a counter is incremented. The secpath (sp) extension on the skb is not removed, resulting in sp->len becoming 0. Subsequently, functions like __xfrm_policy_check() attempt to access fields such as xfrm_input_state(skb)->xso.type (which dereferences sp->xvec[sp->len - 1]) without first validating sp->len. This leads to a crash when dereferencing an invalid state pointer. This patch prevents the crash by explicitly removing the secpath extension from the skb if the xfrm state is not found after hardware decryption. This ensures downstream functions do not operate on a zero-length secpath. BUG: unable to handle page fault for address: ffffffff000002c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__xfrm_policy_check+0x61a/0xa30 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? try_to_wake_up+0x108/0x4c0 ? udp4_lib_lookup2+0xbe/0x150 ? udp_lib_lport_inuse+0x100/0x100 ? __udp4_lib_lookup+0x2b0/0x410 __xfrm_policy_check2.constprop.0+0x11e/0x130 udp_queue_rcv_one_skb+0x1d/0x530 udp_unicast_rcv_skb+0x76/0x90 __udp4_lib_rcv+0xa64/0xe90 ip_protocol_deliver_rcu+0x20/0x130 ip_local_deliver_finish+0x75/0xa0 ip_local_deliver+0xc1/0xd0 ? ip_protocol_deliver_rcu+0x130/0x130 ip_sublist_rcv+0x1f9/0x240 ? ip_rcv_finish_core+0x430/0x430 ip_list_rcv+0xfc/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x200/0x360 ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core] gro_receive_skb+0xfd/0x210 mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core] mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core] ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core] mlx5e_napi_poll+0x114/0xab0 [mlx5_core] __napi_poll+0x25/0x170 net_rx_action+0x32d/0x3a0 ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core] ? notifier_call_chain+0x33/0xa0 handle_softirqs+0xda/0x250 irq_exit_rcu+0x6d/0xc0 common_interrupt+0x81/0xa0 </IRQ> Fixes: b2ac7541e377 ("net/mlx5e: IPsec: Add Connect-X IPsec Rx data path offload") Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Yael Chemla <ychemla@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1753256672-337784-3-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15net/mlx5e: Clear Read-Only port buffer size in PBMC before updateAlexei Lazar1-0/+3
[ Upstream commit fd4b97246a23c1149479b88490946bcfbd28de63 ] When updating the PBMC register, we read its current value, modify desired fields, then write it back. The port_buffer_size field within PBMC is Read-Only (RO). If this RO field contains a non-zero value when read, attempting to write it back will cause the entire PBMC register update to fail. This commit ensures port_buffer_size is explicitly cleared to zero after reading the PBMC register but before writing back the modified value. This allows updates to other fields in the PBMC register to succeed. Fixes: 0696d60853d5 ("net/mlx5e: Receive buffer configuration") Signed-off-by: Alexei Lazar <alazar@nvidia.com> Reviewed-by: Yael Chemla <ychemla@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1753256672-337784-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15can: kvaser_usb: Assign netdev.dev_port based on device channel indexJimmy Assarsson1-0/+1
[ Upstream commit c151b06a087a61c7a1790b75ee2f1d6edb6a8a45 ] Assign netdev.dev_port based on the device channel index, to indicate the port number of the network device. While this driver already uses netdev.dev_id for that purpose, dev_port is more appropriate. However, retain dev_id to avoid potential regressions. Fixes: 3e66d0138c05 ("can: populate netdev::dev_id for udev discrimination") Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123452.41-4-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15can: kvaser_pciefd: Store device channel indexJimmy Assarsson1-0/+1
[ Upstream commit d54b16b40ddadb7d0a77fff48af7b319a0cd6aae ] Store device channel index in netdev.dev_port. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123230.8-6-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15can: tscan1: CAN_TSCAN1 can depend on PC104Randy Dunlap1-1/+1
[ Upstream commit b7d012e59627c1d1bb2ad5d71efc69a070ef767d ] Add a dependency on PC104 to limit (restrict) this driver kconfig prompt to kernel configs that have PC104 set. Add COMPILE_TEST as a possibility for more complete build coverage. I tested this build config on x86_64 5 times without problems. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://patch.msgid.link/20250721002823.3548945-1-rdunlap@infradead.org [mkl: fix conflict, remove Fixes: tag] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15can: tscan1: Kconfig: add COMPILE_TESTVincent Mailhol1-1/+1
[ Upstream commit 5323af351e7524497930b7793153ff68ee5c0ec1 ] tscan1 depends on ISA. It also has a hidden dependency on HAS_IOPORT as reported by the kernel test bot [1]. That dependency is implied by ISA which explains why this was not an issue so far. Add both COMPILE_TEST and HAS_IOPORT to the dependency list so that this driver can also be built on other platforms. [1] https://lore.kernel.org/linux-can/202507141417.qAMrchyV-lkp@intel.com/ Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://patch.msgid.link/20250715-can-compile-test-v2-3-f7fd566db86f@wanadoo.fr Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Stable-dep-of: b7d012e59627 ("can: tscan1: CAN_TSCAN1 can depend on PC104") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15can: peak_usb: fix USB FD devices potential malfunctionStephane Grosjean1-8/+9
[ Upstream commit 788199b73b6efe4ee2ade4d7457b50bb45493488 ] The latest firmware versions of USB CAN FD interfaces export the EP numbers to be used to dialog with the device via the "type" field of a response to a vendor request structure, particularly when its value is greater than or equal to 2. Correct the driver's test of this field. Fixes: 4f232482467a ("can: peak_usb: include support for a new MCU") Signed-off-by: Stephane Grosjean <stephane.grosjean@hms-networks.com> Link: https://patch.msgid.link/20250724081550.11694-1-stephane.grosjean@free.fr Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> [mkl: rephrase commit message] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15Bluetooth: btintel_pcie: Make driver wait for alive interruptKiran K1-13/+17
[ Upstream commit 69b3d3acf3dba21e2abad863c80c7114eb110b3d ] The firmware raises an alive interrupt upon receiving the HCI_RESET or BTINTEL_HCI_OP_RESET (Intel reset - 0xfc01) command. This change fixes the driver to properly wait for the alive interrupt to avoid driver sending commands to firmware before it is ready to process. For details on the handshake between the driver and firmware, refer to commit 05c200c8f029 ("Bluetooth: btintel_pcie: Add handshake between driver and firmware"). As the driver needs to handle two interrupts for HCI_OP_RESET and BTINTEL_HCI_OP_RESET, the firmware ensures that the TX completion interrupt is always followed by the alive interrupt. Fixes: 05c200c8f029 ("Bluetooth: btintel_pcie: Add handshake between driver and firmware") Signed-off-by: Sai Teja Aluvala <aluvala.sai.teja@intel.com> Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15Bluetooth: btintel: Define a macro for Intel Reset vendor commandKiran K5-17/+19
[ Upstream commit 15843c7fdba65568704245fd3ea2aa3aa2d50825 ] Use macro for Intel Reset command (0xfc01) instead of hard coded value. Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Stable-dep-of: 69b3d3acf3db ("Bluetooth: btintel_pcie: Make driver wait for alive interrupt") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15Bluetooth: btusb: Fix potential NULL dereference on kmalloc failureZhongqiu Han1-0/+2
[ Upstream commit b505902c66a282dcb01bcdc015aa1fdfaaa075db ] Avoid potential NULL pointer dereference by checking the return value of kmalloc and handling allocation failure properly. Fixes: 7d70989fcea7 ("Bluetooth: btusb: Add HCI Drv commands for configuring altsetting") Signed-off-by: Zhongqiu Han <quic_zhonhan@quicinc.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15wifi: brcmfmac: fix EXTSAE WPA3 connection failure due to AUTH TX failureTing-Ying Li2-21/+35
[ Upstream commit f2d7c3c380bf0c38c395d50de3a7c1a6275983cb ] For WPA3-SAE Connection in EXTSAE mode, the userspace daemon is allowed to generate the SAE Auth frames. The driver uses the "mgmt_frame" FW IOVAR to transmit this MGMT frame. Before sending the IOVAR, the Driver is incorrectly treating the channel number read from the FW as a frequency value and again attempts to convert this into a channel number using ieee80211_frequency_to_channel(). This added an invalid channel number as part of the IOVAR request to the FW And some FW which strictly expects a valid channel would return BAD_CHAN error, while failing to transmit the driver requested SAE Auth MGMT frame. Fix this in the CYW vendor specific MGMT TX cfg80211 ops handler, by not treating the channel number read from the FW as frequency value and skip the attempt to convert it again into a channel number. Also fix this in the generic MGMT TX cfg80211 ops handler. Fixes: c2ff8cad6423 ("brcm80211: make mgmt_tx in brcmfmac accept a NULL channel") Fixes: 66f909308a7c ("wifi: brcmfmac: cyw: support external SAE authentication in station mode") Signed-off-by: Ting-Ying Li <tingying.li@cypress.com> Signed-off-by: Gokul Sivakumar <gokulkumar.sivakumar@infineon.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>> Link: https://patch.msgid.link/20250723105918.5229-1-gokulkumar.sivakumar@infineon.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15iommu/vt-d: Fix UAF on sva unbind with pending IOPFsLu Baolu1-1/+1
[ Upstream commit f0b9d31c6edd50a6207489cd1bd4ddac814b9cd2 ] Commit 17fce9d2336d ("iommu/vt-d: Put iopf enablement in domain attach path") disables IOPF on device by removing the device from its IOMMU's IOPF queue when the last IOPF-capable domain is detached from the device. Unfortunately, it did this in a wrong place where there are still pending IOPFs. As a result, a use-after-free error is potentially triggered and eventually a kernel panic with a kernel trace similar to the following: refcount_t: underflow; use-after-free. WARNING: CPU: 3 PID: 313 at lib/refcount.c:28 refcount_warn_saturate+0xd8/0xe0 Workqueue: iopf_queue/dmar0-iopfq iommu_sva_handle_iopf Call Trace: <TASK> iopf_free_group+0xe/0x20 process_one_work+0x197/0x3d0 worker_thread+0x23a/0x350 ? rescuer_thread+0x4a0/0x4a0 kthread+0xf8/0x230 ? finish_task_switch.isra.0+0x81/0x260 ? kthreads_online_cpu+0x110/0x110 ? kthreads_online_cpu+0x110/0x110 ret_from_fork+0x13b/0x170 ? kthreads_online_cpu+0x110/0x110 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- The intel_pasid_tear_down_entry() function is responsible for blocking hardware from generating new page faults and flushing all in-flight ones. Therefore, moving iopf_for_domain_remove() after this function should resolve this. Fixes: 17fce9d2336d ("iommu/vt-d: Put iopf enablement in domain attach path") Reported-by: Ethan Milon <ethan.milon@eviden.com> Closes: https://lore.kernel.org/r/e8b37f3e-8539-40d4-8993-43a1f3ffe5aa@eviden.com Suggested-by: Ethan Milon <ethan.milon@eviden.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20250723072045.1853328-1-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-03 22:14:52 +0300