summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-11-17mtd: rawnand: lpc32xx_slc: Convert to use devm_gpiod_get_optional()Haotian Zhang
The initial fix for a GPIO descriptor leak added manual gpiod_put() calls in the error path and remove function. This follow-up patch improves upon the fix by switching to the resource-managed devm_gpiod_get_optional() API. Suggested-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2025-11-17mtd: mtdpart: ignore error -ENOENT from parsers on subpartitionsChristian Marangi
Commit 5c2f7727d437 ("mtd: mtdpart: check for subpartitions parsing result") introduced some kind of regression with parser on subpartitions where if a parser emits an error then the entire parsing process from the upper parser fails and partitions are deleted. Not checking for error in subpartitions was originally intended as special parser can emit error also in the case of the partition not correctly init (for example a wiped partition) or special case where the partition should be skipped due to some ENV variables externally provided (from bootloader for example) One example case is the TRX partition where, in the context of a wiped partition, returns a -ENOENT as the trx_magic is not found in the expected TRX header (as the partition is wiped) To better handle this and still keep some kind of error tracking (for example to catch -ENOMEM errors or -EINVAL errors), permit parser on subpartition to emit -ENOENT error, print a debug log and skip them accordingly. This results in giving better tracking of the status of the parser (instead of returning just 0, dropping any kind of signal that there is something wrong with the parser) and to some degree restore the original logic of the subpartitions parse. (worth to notice that some special partition might have all the special header present for the parser and declare 0 partition in it, this is why it would be wrong to simply return 0 in the case of a special partition that is NOT init for the scanning parser) Cc: stable@vger.kernel.org Fixes: 5c2f7727d437 ("mtd: mtdpart: check for subpartitions parsing result") Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2025-11-17mtd: maps: pcmciamtd: fix potential memory leak in pcmciamtd_detach()Abdun Nihaal
The memory allocated for struct pcmciamtd_dev in pcmciamtd_probe() is not freed in the corresponding remove function pcmciamtd_detach(). Fix that by freeing it in the remove function. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2025-11-17USB: serial: ftdi_sio: drop NDI quirk module parameterJohan Hovold
NDI devices have been using a latency timer of 1 ms since commit b760dac290c3 ("USB: ftdi: support NDI devices"), which also added a vendor specific module parameter that could be used to override the default value for these devices. Module parameters should generally be avoided as they apply to all devices managed by a driver and vendor specific hacks should be kept out of mainline. Drop the module parameter in favour of the generic sysfs interface for setting the latency timer (e.g. using udev rules) while keeping the default 1 ms timer for NDI devices. Note that there seems to be no (correct) public references to the module parameter and most likely no one is using it. Cc: Ryan Mann <rmann@ndigital.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2025-11-17USB: serial: ftdi_sio: clean up NDI speed hackJohan Hovold
NDI devices remap the 19200 line speed to 1.2 Mbps. Use the quirk pointer from the match table to enable the quirk instead of comparing PIDs on every speed change. Signed-off-by: Johan Hovold <johan@kernel.org>
2025-11-17USB: serial: ftdi_sio: enable NDI speed hack consistentlyJohan Hovold
The original submission adding support for NDI EMGUIDE Gemini enabled the existing NDI speed hack which remaps the 19200 line speed to 1.2 Mbps, but this silently fell out during resubmission. Enable the speed hack also for the new NDI product for consistency. This will also allow for cleaning up the implementation without resorting to overengineering. Link: https://lore.kernel.org/all/YQXPR01MB49870CB7B3075ADDF88A3FD4DF43A@YQXPR01MB4987.CANPRD01.PROD.OUTLOOK.COM/ Link: https://lore.kernel.org/all/YQXPR01MB4987F1E0DA41E689779E6958DF48A@YQXPR01MB4987.CANPRD01.PROD.OUTLOOK.COM/ Cc: Ryan Mann <rmann@ndigital.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2025-11-17USB: serial: ftdi_sio: rename quirk symbolsJohan Hovold
Use lower case names for the quirk symbols and rename the NDI quirk probe function for consistency. Signed-off-by: Johan Hovold <johan@kernel.org>
2025-11-17USB: serial: ftdi_sio: clean up quirk commentsJohan Hovold
Clean up the quirk function comments that were using odd formatting and were referring to a non-existing function. Signed-off-by: Johan Hovold <johan@kernel.org>
2025-11-17USB: serial: ftdi_sio: rewrite 8u2232c quirkJohan Hovold
Rewrite the 8u2232c quirk to avoid the manufacturer and product string comparisons for the second port which will always be bound. Signed-off-by: Johan Hovold <johan@kernel.org>
2025-11-17USB: serial: ftdi_sio: silence jtag probeJohan Hovold
Probe of a device should generally be silent unless errors are encountered. Stop logging that the JTAG port is ignored when probing devices with such a reserved port. This also maintains consistency with devices that match on interface number to avoid binding to reserved ports. Note that the message is not even correct for the second port of the ST Micro Connect Lite. Signed-off-by: Johan Hovold <johan@kernel.org>
2025-11-17USB: serial: ftdi_sio: match on interface number for jtagJohan Hovold
Some FTDI devices have the first port reserved for JTAG and have been using a dedicated quirk to prevent binding to it. As can be inferred directly or indirectly from the commit messages, almost all of these devices are dual port devices which means that the more recently added macro for matching on interface number can be used instead (and some such devices do so already). This avoids probing interfaces that will never be bound and cleans up the match table somewhat. Note that the JTAG quirk is kept for quad port devices, which would otherwise require three match entries. Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2025-11-17Merge branch 'compat-removal'Heiko Carstens
Heiko Carstens says: ==================== Remove s390 compat support to allow for code simplification and especially reduced test effort. To the best of our knowledge there aren't any 31 bit binaries out in the world anymore that would matter for newer kernels or newer distributions. Distributions do not provide compat packages since quite some time or even have CONFIG_COMPAT disabled. Instead of adding deprecation warnings to config option, or adding kernel messages, just remove the code. Deprecation warnings haven't proven to be useful. If it turns out there is still a reason to keep the compat support this series can be reverted at any time in the future. ==================== Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-11-17s390/syscalls: Switch to generic system call table generationHeiko Carstens
The s390 syscall.tbl format differs slightly from most others, and therefore requires an s390 specific system call table generation script. With compat support gone use the opportunity to switch to generic system call table generation. The abi for all 64 bit system calls is now common, since there is no need to specify if system call entry points are only for 64 bit anymore. Furthermore create the system call table in C instead of assembler code in order to get type checking for all system call functions contained within the table. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-11-17s390/syscalls: Remove system call table pointer from thread_structHeiko Carstens
With compat support gone there is only one system call table left. Therefore remove the sys_call_table pointer from thread_struct and use the sys_call_table directly. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-11-17s390/uapi: Remove 31 bit support from uapi header filesHeiko Carstens
Since the kernel does not support running 31 bit / compat binaries anymore, remove also the corresponding 31 bit support from uapi header files. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-11-17s390: Remove compat supportHeiko Carstens
There shouldn't be any 31 bit code around anymore that matters. Remove the compat layer support required to run 31 bit code. Reason for removal is code simplification and reduced test effort. Note that this comes without any deprecation warnings added to config options, or kernel messages, since most likely those would be ignored anyway. If it turns out there is still a reason to keep the compat layer this can be reverted at any time in the future. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-11-17tools: Remove s390 compat supportHeiko Carstens
Remove s390 compat support from everything within tools, since s390 compat support will be removed from the kernel. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Weißschuh <linux@weissschuh.net> # tools/nolibc selftests/nolibc Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> # selftests/vDSO Acked-by: Alexei Starovoitov <ast@kernel.org> # bpf bits Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-11-17s390/syscalls: Add pt_regs parameter to SYSCALL_DEFINE0() syscall wrapperHeiko Carstens
All system call wrappers should match the sys_call_ptr_t type. This is not the case for system calls without parameters. Add the missing pt_regs parameter there too. Note: this is currently not a problem, since the parameter is unused. However it prevents to create a correctly typed system call table in C. With the current assembler implementation this works because of missing type checking. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-11-17s390/kvm: Use psw32_t instead of psw_compat_tHeiko Carstens
kvm_s390_handle_lpsw() make use of the psw_compat_t type even though the code has nothing to do with CONFIG_COMPAT, for which the type is supposed to be used. Use psw32_t instead. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-11-17s390/ptrace: Rename psw_t32 to psw32_tHeiko Carstens
Use a standard "_t" suffix for psw_t32 and rename it to psw32_t. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-11-17gpio: tegra186: Fix GPIO name collisions for Tegra410Kartik Rajput
On Tegra410, Compute and System GPIOs have same port names. This results in the same GPIO names for both Compute and System GPIOs during initialization in `tegra186_gpio_probe()`, which results in following warnings: kernel: gpio gpiochip1: Detected name collision for GPIO name 'PA.00' kernel: gpio gpiochip1: Detected name collision for GPIO name 'PA.01' kernel: gpio gpiochip1: Detected name collision for GPIO name 'PA.02' kernel: gpio gpiochip1: Detected name collision for GPIO name 'PB.00' kernel: gpio gpiochip1: Detected name collision for GPIO name 'PB.01' ... Add GPIO name prefix in the SoC data and use it to initialize the GPIO name. Port names remain unchanged for previous SoCs. On Tegra410, Compute GPIOs are named COMPUTE-P<PORT>.GPIO, and System GPIOs are named SYSTEM-P<PORT>.GPIO. Fixes: 9631a10083d8 ("gpio: tegra186: Add support for Tegra410") Signed-off-by: Kartik Rajput <kkartik@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20251113163112.885900-1-kkartik@nvidia.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-11-17gpiolib: legacy: Allow to kill devm_gpio_request_one() independentlyAndy Shevchenko
Allow to kill devm_gpio_request_one() independently by converting it to use legacy APIs that will be alive a bit longer. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20251112093608.1481030-3-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-11-17gpiolib: legacy: Make sure we kill gpio_request_one() firstAndy Shevchenko
Make sure we kill gpio_request_one() first by converting it to use legacy APIs that will be alive a bit longer. In particular, this also shows the code we will use in another function to make it die independently. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20251112093608.1481030-2-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-11-17Merge tag 'gpio/shared-gpios-for-v6.19-rc1' of ↵Bartosz Golaszewski
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git into gpio/for-next Immutable branch between the GPIO, ASoC and regulator trees for v6.19-rc1 Add better support for GPIOs shared by multiple consumers.
2025-11-17tee: qcomtee: initialize result before use in release workerAmirreza Zarrabi
Initialize result to 0 so the error path doesn't read it uninitialized when the invoke fails. Fixes a Smatch warning. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/op-tee/7c1e0de2-7d42-4c6b-92fe-0e4fe5d650b5@oss.qualcomm.com/ Fixes: d6e290837e50 ("tee: add Qualcomm TEE driver") Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2025-11-17gpio: provide gpiod_is_shared()Bartosz Golaszewski
Provide an interface allowing consumers to check if a GPIO descriptor represents a GPIO that can potentially be shared by multiple consumers at the same time. This is exposed to allow subsystems that already work around the limitations of the current non-exclusive GPIO handling in some ways, to gradually convert to relying on the new shared GPIO feature of GPIOLIB. Extend the gpiolib-shared module to mark the GPIO shared proxy descriptors with a flag checked by the new interface. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-6-b51f97b1abd8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-11-17arm64: select HAVE_SHARED_GPIOS for ARCH_QCOMBartosz Golaszewski
Some qualcomm platforms use shared GPIOs. Enable support for them by selecting the Kconfig switch provided by GPIOLIB. Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Bjorn Andersson <andersson@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-7-b51f97b1abd8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-11-17gpiolib: support shared GPIOs in core subsystem codeBartosz Golaszewski
As the final step in adding official support for shared GPIOs, enable the previously added elements in core GPIO subsystem code. Set-up shared GPIOs when adding a GPIO chip, tear it down on removal and check if a GPIO descriptor looked up during the firmware-node stage is shared and fall-back to machine lookup in this case. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-5-b51f97b1abd8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-11-17gpio: shared-proxy: implement the shared GPIO proxy driverBartosz Golaszewski
Add a virtual GPIO proxy driver which arbitrates access to a single shared GPIO by multiple users. It works together with the core shared GPIO support from GPIOLIB and functions by acquiring a reference to a shared GPIO descriptor exposed by gpiolib-shared and making sure that the state of the GPIO stays consistent. In general: if there's only one user at the moment: allow it to do anything as if this was a normal GPIO (in essence: just propagate calls to the underlying real hardware driver). If there are more users: don't allow to change the direction set by the initial user, allow to change configuration options but warn about possible conflicts and finally: treat the output-high value as a reference counted, logical "GPIO enabled" setting, meaning: the GPIO value is set to high when the first user requests it to be high and back to low once the last user stops "voting" for high. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-4-b51f97b1abd8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-11-17gpiolib: implement low-level, shared GPIO supportBartosz Golaszewski
This module scans the device tree (for now only OF nodes are supported but care is taken to make other fwnode implementations easy to integrate) and determines which GPIO lines are shared by multiple users. It stores that information in memory. When the GPIO chip exposing shared lines is registered, the shared GPIO descriptors it exposes are marked as shared and virtual "proxy" devices that mediate access to the shared lines are created. When a consumer of a shared GPIO looks it up, its fwnode lookup is redirected to a just-in-time machine lookup that points to this proxy device. This code can be compiled out on platforms which don't use shared GPIOs. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-3-b51f97b1abd8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-11-17gpiolib: define GPIOD_FLAG_SHAREDBartosz Golaszewski
Define a new GPIO descriptor flag for marking pins that are shared by multiple consumer. This flag will be used in several places so we need to do it in advance and separately from other changes. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-2-b51f97b1abd8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-11-17string: provide strends()Bartosz Golaszewski
Implement a function for checking if a string ends with a different string and add its kunit test cases. Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-1-b51f97b1abd8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-11-17iommu/tegra: fix device leak on probe_device()Johan Hovold
Make sure to drop the reference taken to the iommu platform device when looking up its driver data during probe_device(). Note that commit 9826e393e4a8 ("iommu/tegra-smmu: Fix missing put_device() call in tegra_smmu_find") fixed the leak in an error path, but the reference is still leaking on success. Fixes: 891846516317 ("memory: Add NVIDIA Tegra memory controller support") Cc: stable@vger.kernel.org # 3.19: 9826e393e4a8 Cc: Miaoqian Lin <linmq006@gmail.com> Acked-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-17iommu/sun50i: fix device leak on of_xlate()Johan Hovold
Make sure to drop the reference taken to the iommu platform device when looking up its driver data during of_xlate(). Fixes: 4100b8c229b3 ("iommu: Add Allwinner H6 IOMMU driver") Cc: stable@vger.kernel.org # 5.8 Cc: Maxime Ripard <mripard@kernel.org> Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-17iommu/omap: simplify probe_device() error handlingJohan Hovold
Simplify the probe_device() error handling by dropping the iommu OF node reference sooner. Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-17iommu/omap: fix device leaks on probe_device()Johan Hovold
Make sure to drop the references taken to the iommu platform devices when looking up their driver data during probe_device(). Note that the arch data device pointer added by commit 604629bcb505 ("iommu/omap: add support for late attachment of iommu devices") has never been used. Remove it to underline that the references are not needed. Fixes: 9d5018deec86 ("iommu/omap: Add support to program multiple iommus") Fixes: 7d6827748d54 ("iommu/omap: Fix iommu archdata name for DT-based devices") Cc: stable@vger.kernel.org # 3.18 Cc: Suman Anna <s-anna@ti.com> Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-17iommu/mediatek-v1: add missing larb count sanity checkJohan Hovold
Add the missing larb count sanity check to avoid writing beyond a fixed sized array in case of a malformed devicetree. Acked-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-17iommu/mediatek-v1: fix device leaks on probe()Johan Hovold
Make sure to drop the references taken to the larb devices during probe on probe failure (e.g. probe deferral) and on driver unbind. Fixes: b17336c55d89 ("iommu/mediatek: add support for mtk iommu generation one HW") Cc: stable@vger.kernel.org # 4.8 Cc: Honghui Zhang <honghui.zhang@mediatek.com> Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-17iommu/mediatek-v1: fix device leak on probe_device()Johan Hovold
Make sure to drop the reference taken to the iommu platform device when looking up its driver data during probe_device(). Fixes: b17336c55d89 ("iommu/mediatek: add support for mtk iommu generation one HW") Cc: stable@vger.kernel.org # 4.8 Cc: Honghui Zhang <honghui.zhang@mediatek.com> Acked-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-17iommu/mediatek: simplify dt parsing error handlingJohan Hovold
As previously documented by commit 26593928564c ("iommu/mediatek: Add error path for loop of mm_dts_parse"), the id mapping may not be linear so the whole larb array needs to be iterated on devicetree parsing errors. Simplify the loop by iterating from index zero while dropping the redundant NULL check for consistency with later cleanups. Also add back the comment which was removed by commit 462e768b55a2 ("iommu/mediatek: Fix forever loop in error handling") to prevent anyone from trying to optimise the loop by iterating backwards from 'i'. Cc: Yong Wu <yong.wu@mediatek.com> Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-17iommu/mediatek: fix use-after-free on probe deferralJohan Hovold
The driver is dropping the references taken to the larb devices during probe after successful lookup as well as on errors. This can potentially lead to a use-after-free in case a larb device has not yet been bound to its driver so that the iommu driver probe defers. Fix this by keeping the references as expected while the iommu driver is bound. Fixes: 26593928564c ("iommu/mediatek: Add error path for loop of mm_dts_parse") Cc: stable@vger.kernel.org Cc: Yong Wu <yong.wu@mediatek.com> Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-17iommu/mediatek: fix device leak on of_xlate()Johan Hovold
Make sure to drop the reference taken to the iommu platform device when looking up its driver data during of_xlate(). Fixes: 0df4fabe208d ("iommu/mediatek: Add mt8173 IOMMU driver") Cc: stable@vger.kernel.org # 4.6 Acked-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-17iommu/ipmmu-vmsa: fix device leak on of_xlate()Johan Hovold
Make sure to drop the reference taken to the iommu platform device when looking up its driver data during of_xlate(). Fixes: 7b2d59611fef ("iommu/ipmmu-vmsa: Replace local utlb code with fwspec ids") Cc: stable@vger.kernel.org # 4.14 Cc: Magnus Damm <damm+renesas@opensource.se> Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-17iommu/exynos: fix device leak on of_xlate()Johan Hovold
Make sure to drop the reference taken to the iommu platform device when looking up its driver data during of_xlate(). Note that commit 1a26044954a6 ("iommu/exynos: add missing put_device() call in exynos_iommu_of_xlate()") fixed the leak in a couple of error paths, but the reference is still leaking on success. Fixes: aa759fd376fb ("iommu/exynos: Add callback for initializing devices from device tree") Cc: stable@vger.kernel.org # 4.2: 1a26044954a6 Cc: Yu Kuai <yukuai3@huawei.com> Acked-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-17iommu/qcom: fix device leak on of_xlate()Johan Hovold
Make sure to drop the reference taken to the iommu platform device when looking up its driver data during of_xlate(). Note that commit e2eae09939a8 ("iommu/qcom: add missing put_device() call in qcom_iommu_of_xlate()") fixed the leak in a couple of error paths, but the reference is still leaking on success and late failures. Fixes: 0ae349a0f33f ("iommu/qcom: Add qcom_iommu") Cc: stable@vger.kernel.org # 4.14: e2eae09939a8 Cc: Rob Clark <robin.clark@oss.qualcomm.com> Cc: Yu Kuai <yukuai3@huawei.com> Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-17iommu/apple-dart: fix device leak on of_xlate()Johan Hovold
Make sure to drop the reference taken to the iommu platform device when looking up its driver data during of_xlate(). Fixes: 46d1fb072e76 ("iommu/dart: Add DART iommu driver") Cc: stable@vger.kernel.org # 5.15 Cc: Sven Peter <sven@kernel.org> Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-17iommupt: Actually correct pt_test_sw_bit_{acquire_release}() parameter ↵Bagas Sanjaya
description In review comment for v1 of genpt documentation fixes [1], Randy suggested that pt_test_sw_bit_acquire() parameters description should be written using "to read". Commit e4dfaf25df1210 ("iommupt: Describe @bitnr parameter"), however, misunderstood the review by instead using "to read" on @bitnr parameter on both pt_test_sw_bit_acquire() and pt_test_sw_bit_release(). Actually correct the description. [1]: https://lore.kernel.org/linux-doc/9dba0eb7-6f32-41b7-b70b-12379364585f@infradead.org/ Fixes: e4dfaf25df1210 ("iommupt: Describe @bitnr parameter") Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-17arm64: dts: freescale: add Toradex SMARC iMX95Max Krummenacher
Add DT support for Toradex SMARC iMX95 SoM and Development carrier board. The module consists of an NXP i.MX95 family SoC, up to 16GB of LPDDR5 RAM and up to 128GB of storage, a USB 3.0 Host Hub and 2.0 OTG, two Gigabit Ethernet PHYs, a 10 Gigabit Ethernet interface, an I2C EEPROM and Temperature Sensor, an RX8130 RTC, a Quad/Dual lane CSI interface, and some optional addons: TPM 2.0, DSI, LVDS, DisplayPort (through a DSI-DP bridge), and Wi-Fi/BT module. Link: https://www.toradex.com/computer-on-modules/smarc-arm-family/nxp-imx95 Link: https://www.toradex.com/products/carrier-board/smarc-development-board-kit Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com> Co-developed-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com> Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com> Co-developed-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Co-developed-by: João Paulo Gonçalves <joao.goncalves@toradex.com> Signed-off-by: João Paulo Gonçalves <joao.goncalves@toradex.com> Co-developed-by: Vitor Soares <vitor.soares@toradex.com> Signed-off-by: Vitor Soares <vitor.soares@toradex.com> Co-developed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-11-17dt-bindings: arm: fsl: add Toradex SMARC iMX95João Paulo Gonçalves
Add DT compatible strings for Toradex SMARC iMX95 SoM and Toradex SMARC Development carrier board. Link: https://www.toradex.com/computer-on-modules/smarc-arm-family/nxp-imx95 Link: https://www.toradex.com/products/carrier-board/smarc-development-board-kit Signed-off-by: João Paulo Gonçalves <joao.goncalves@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-11-17fs/ntfs3: Fix spelling mistake "recommened" -> "recommended"Colin Ian King
There is a spelling mistake in a ntfs_info message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>