summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-02-01Merge branches 'for-next/sysreg', 'for-next/compat-hwcap' and ↵Catalin Marinas
'for-next/sme2' into for-next/sysreg-hwcaps Patches on this branch depend on the branches merged above.
2023-02-01md: use MD_RESYNC_* whenever possibleHou Tao
Just replace magic numbers by MD_RESYNC_* enumerations. Signed-off-by: Hou Tao <houtao1@huawei.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Song Liu <song@kernel.org>
2023-02-01dt-bindings: phy: rename phy-rockchip-inno-usb2.yamlJohan Jonker
Rename phy-rockchip-inno-usb2.yaml to a more common format of rockchip,inno-usb2phy.yaml Signed-off-by: Johan Jonker <jbx6244@gmail.com> Acked-By: Vinod Koul <vkoul@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/99794484-d67e-ee1f-4e76-200de20a879c@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2023-02-01arm64: dts: ti: Makefile: Rearrange entries alphabeticallyVignesh Raghavendra
Entries are first grouped as per SoC present on the board. Groups are sorted alphabetically. This makes it easy to know SoC to board mapping and also add new entries in alphabetical order. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20230126071159.2337584-1-vigneshr@ti.com
2023-02-01arch: arm64: dts: Add support for AM69 Starter KitDasnavis Sabiya
AM69 Starter Kit is a single board designed for TI AM69 SOC that provides advanced system integration in automotive ADAS applications, autonomous mobile robot and edge AI applications. The SOC comprises of Cortex-A72s in dual clusters, lockstep capable dual Cortex-R5F MCUs, Vision Processing Accelerators (VPAC) with Image Signal Processor (ISP) and multiple vision assist accelerators, Depth and Motion Processing Accelerators (DMPAC), Deep-learning Matrix Multiply Accelerator(MMA) and C7x floating point vector DSP AM69 SK supports the following interfaces: * 32 GB LPDDR4 RAM * x1 Gigabit Ethernet interface * x3 USB 3.0 Type-A ports * x1 USB 3.0 Type-C port * x1 UHS-1 capable micro-SD card slot * x4 MCAN instances * 32 GB eMMC Flash * 512 Mbit OSPI flash * x2 Display connectors * x1 PCIe M.2 M Key * x1 PCIe M.2 E Key * x1 4L PCIe Card Slot * x3 CSI2 Camera interface * 40-pin Raspberry Pi header Add initial support for the AM69 SK board. Design Files: https://www.ti.com/lit/zip/SPRR466 TRM: https://www.ti.com/lit/zip/spruj52 Signed-off-by: Dasnavis Sabiya <sabiya.d@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20230119132958.124435-3-sabiya.d@ti.com
2023-02-01dt-bindings: arm: ti: Add binding for AM69 Starter KitDasnavis Sabiya
AM69 Starter Kit is a single board designed for TI AM69 SoC. The AM69 SoC belongs to the K3 Multicore SoC architecture platform, providing advanced system integration in automotive ADAS applications, autonomous mobile robot and edge AI applications. Add DT binding for AM69 Starter Kit. Signed-off-by: Dasnavis Sabiya <sabiya.d@ti.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20230119132958.124435-2-sabiya.d@ti.com
2023-02-01kselftest/arm64: Fix enumeration of systems without 128 bit SME for SSVE+ZAMark Brown
The current signal handling tests for SME do not account for the fact that unlike SVE all SME vector lengths are optional so we can't guarantee that we will encounter the minimum possible VL, they will hang enumerating VLs on such systems. Abort enumeration when we find the lowest VL in the newly added ssve_za_regs test. Fixes: bc69da5ff087 ("kselftest/arm64: Verify simultaneous SSVE and ZA context generation") Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230131-arm64-kselftest-sig-sme-no-128-v1-2-d47c13dc8e1e@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2023-02-01kselftest/arm64: Fix enumeration of systems without 128 bit SMEMark Brown
The current signal handling tests for SME do not account for the fact that unlike SVE all SME vector lengths are optional so we can't guarantee that we will encounter the minimum possible VL, they will hang enumerating VLs on such systems. Abort enumeration when we find the lowest VL. Fixes: 4963aeb35a9e ("kselftest/arm64: signal: Add SME signal handling tests") Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230131-arm64-kselftest-sig-sme-no-128-v1-1-d47c13dc8e1e@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2023-02-01kselftest/arm64: Don't require FA64 for streaming SVE testsMark Brown
During early development a dependedncy was added on having FA64 available so we could use the full FPSIMD register set in the signal handler. Subsequently the ABI was finialised so the handler is run with streaming mode disabled meaning this is redundant but the dependency was never removed, do so now. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230131-arm64-kselfetest-ssve-fa64-v1-1-f418efcc2b60@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2023-02-01objtool: Optimize layout of struct special_altThomas Weißschuh
Reduce the size of struct special_alt from 72 to 64 bytes. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20221216-objtool-memory-v2-7-17968f85a464@weissschuh.net Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
2023-02-01objtool: Optimize layout of struct symbolThomas Weißschuh
Reduce the size of struct symbol on x86_64 from 208 to 200 bytes. This structure is allocated a lot and never freed. This reduces maximum memory usage while processing vmlinux.o from 2919716 KB to 2917988 KB (-0.5%) on my notebooks "localmodconfig". Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20221216-objtool-memory-v2-6-17968f85a464@weissschuh.net Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
2023-02-01objtool: Allocate multiple structures with calloc()Thomas Weißschuh
By using calloc() instead of malloc() in a loop, libc does not have to keep around bookkeeping information for each single structure. This reduces maximum memory usage while processing vmlinux.o from 3153325 KB to 3035668 KB (-3.7%) on my notebooks "localmodconfig". Note this introduces memory leaks, because some additional structs get added to the lists later after reading the symbols and sections from the original object. Luckily we don't really care about memory leaks in objtool. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20221216-objtool-memory-v2-3-17968f85a464@weissschuh.net Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
2023-02-01objtool: Make struct check_options staticThomas Weißschuh
It is not used outside of builtin-check.c. Also remove the unused declaration from builtin.h . Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20221216-objtool-memory-v2-2-17968f85a464@weissschuh.net Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
2023-02-01objtool: Make struct entries[] static and constThomas Weißschuh
This data is not modified and not used outside of special.c. Also adapt its users to the constness. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20221216-objtool-memory-v2-1-17968f85a464@weissschuh.net Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
2023-02-01objtool: Fix HOSTCC flag usageIan Rogers
HOSTCC is always wanted when building objtool. Setting CC to HOSTCC happens after tools/scripts/Makefile.include is included, meaning flags (like CFLAGS) are set assuming say CC is gcc, but then it can be later set to HOSTCC which may be clang. tools/scripts/Makefile.include is needed for host set up and common macros in objtool's Makefile. Rather than override the CC variable to HOSTCC, just pass CC as HOSTCC to the sub-makes of Makefile.build, the libsubcmd builds and also to the linkage step. Signed-off-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20230126190606.40739-4-irogers@google.com Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
2023-02-01ARM: Add wpcm450_defconfig for Nuvoton WPCM450Jonathan Neuschäfer
This defconfig aims to offer a reasonable set of defaults for all systems running on a Nuvoton WPCM450 chip. Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20230129041547.942335-1-j.neuschaefer@gmx.net Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20230201051534.1005847-1-joel@jms.id.au Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01md: Free writes_pending in md_stopXiao Ni
dm raid calls md_stop to stop the raid device. It needs to free the writes_pending here. Signed-off-by: Xiao Ni <xni@redhat.com> Signed-off-by: Song Liu <song@kernel.org>
2023-02-01md: Change active_io to percpuXiao Ni
Now the type of active_io is atomic. It's used to count how many ios are in the submitting process and it's added and decreased very time. But it only needs to check if it's zero when suspending the raid. So we can switch atomic to percpu to improve the performance. After switching active_io to percpu type, we use the state of active_io to judge if the raid device is suspended. And we don't need to wake up ->sb_wait in md_handle_request anymore. It's done in the callback function which is registered when initing active_io. The argument mddev->suspended is only used to count how many users are trying to set raid to suspend state. Signed-off-by: Xiao Ni <xni@redhat.com> Signed-off-by: Song Liu <song@kernel.org>
2023-02-01md: Factor out is_md_suspended helperXiao Ni
This helper function will be used in next patch. It's easy for understanding. Signed-off-by: Xiao Ni <xni@redhat.com> Signed-off-by: Song Liu <song@kernel.org>
2023-02-01md: don't update recovery_cp when curr_resync is ACTIVEHou Tao
Don't update recovery_cp when curr_resync is MD_RESYNC_ACTIVE, otherwise md may skip the resync of the first 3 sectors if the resync procedure is interrupted before the first calling of ->sync_request() as shown below: md_do_sync thread control thread // setup resync mddev->recovery_cp = 0 j = 0 mddev->curr_resync = MD_RESYNC_ACTIVE // e.g., set array as idle set_bit(MD_RECOVERY_INTR, &&mddev_recovery) // resync loop // check INTR before calling sync_request !test_bit(MD_RECOVERY_INTR, &mddev->recovery // resync interrupted // update recovery_cp from 0 to 3 // the resync of three 3 sectors will be skipped mddev->recovery_cp = 3 Fixes: eac58d08d493 ("md: Use enum for overloaded magic numbers used by mddev->curr_resync") Cc: stable@vger.kernel.org # 6.0+ Signed-off-by: Hou Tao <houtao1@huawei.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Song Liu <song@kernel.org>
2023-02-01usb: ohci-omap: avoid unused-variable warningArnd Bergmann
The dead code removal has led to 'need_transceiver' not being used at all when OTG support is disabled: drivers/usb/host/ohci-omap.c: In function 'ohci_omap_reset': drivers/usb/host/ohci-omap.c:99:33: error: unused variable 'need_transceiver' [-Werror=unused-variable] 99 | int need_transceiver = (config->otg != 0); Change the #ifdef check into an IS_ENABLED() check to make the code more readable and let the compiler see where it is used. Fixes: 8825acd7cc8a ("ARM: omap1: remove dead code") Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01ARM: debug: remove references in DEBUG_UART_8250_SHIFT to removed configsLukas Bulwahn
Commit 67d3928c3df5 ("ARM: omap1: remove unused board files") removes configs DEBUG_OMAP7XXUART{1,2,3}. The config DEBUG_UART_8250_SHIFT still refers to those removed configs. Remove those obsolete references. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01ARM: s3c: remove obsolete s3c-cpu-freq headerLukas Bulwahn
The s3c-cpu-freq header was previously included by: ./arch/arm/mach-s3c/mach-bast.c ./arch/arm/mach-s3c/mach-osiris-dvs.c ./arch/arm/mach-s3c/mach-osiris.c ./include/linux/soc/samsung/s3c-cpufreq-core.h Commit a4946a153cb9 ("ARM: s3c: remove all s3c24xx support") removes the files in ./arch/arm/mach-s3c/; commit daf0ee583fc7 ("cpufreq: remove s3c24xx drivers") removes the file s3c-cpufreq-core.h. Remove this obsolete header file. This issue was identified, as s3c-cpu-freq.h referred to the removed config ARM_S3C_CPUFREQ. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01MAINTAINERS: adjust SAMSUNG SOC CLOCK DRIVERS after s3c24xx support removalLukas Bulwahn
Commit a4946a153cb9 ("ARM: s3c: remove all s3c24xx support") removes all files that match the file pattern 'include/dt-bindings/clock/s3c*.h'. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about a obsolete file pattern in SAMSUNG SOC CLOCK DRIVERS, as it does not match any file in the repository after the commit above. Remove this obsolete file entry in SAMSUNG SOC CLOCK DRIVERS. Fixes: a4946a153cb9 ("ARM: s3c: remove all s3c24xx support") Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01MAINTAINERS: update file entries after arm multi-platform rework and ↵Lukas Bulwahn
mach-pxa removal In the work of Arnd's arm multi-platform support, various files in arch/arm are moved and after the arm mach-pxa removal, only a few files remain to be not aligned with entries in MAINTAINERS. These file movements still require adjustments in MAINTAINERS: Files in arch/arm/mach-ep93xx/include/mach/ are made local: arch/arm/{mach-ep93xx/include/mach/uncompress.h => boot/compressed/misc-ep93xx.h} arch/arm/mach-ep93xx/{include/mach => }/ep93xx-regs.h arch/arm/mach-ep93xx/{include/mach => }/mach/irqs.h Files in arch/arm/mach-vexpress/ are moved to mach-versatile. Correct the remaining references accordingly after these refactorings. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01ARM: remove CONFIG_UNUSED_BOARD_FILESArnd Bergmann
All unused board files are removed, so the Kconfig symbol is no longer needed. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01mfd: remove htc-pasic3 driverArnd Bergmann
The htc-pasic3 MFD device was only used in the PXA magician machine that is now removed, so this can be recycled as well. Cc: Lee Jones <lee@kernel.org> Cc: Philipp Zabel <philipp.zabel@gmail.com> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01w1: remove ds1wm driverArnd Bergmann
This driver was used by the mfd/asic3 and mfd/htc-pasic3 drivers, but both of those are removed as part of the PXA spring cleaning, which leaves the w1 support orphaned as well. Cc: Evgeniy Polyakov <zbr@ioremap.net> Cc: Szabolcs Gyurko <szabolcs.gyurko@tlt.hu> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01usb: remove ohci-tmio driverArnd Bergmann
The TMIO MFD driver is getting removed, so its OHCI portion is not used any more either. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: linux-usb@vger.kernel.org Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01fbdev: remove w100fb driverArnd Bergmann
The w100fb was used on various PXA based pocketpc machines, all of which are now removed, so remove this dirver sd well. Cc: Helge Deller <deller@gmx.de> Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01fbdev: remove tmiofb driverArnd Bergmann
With the TMIO MFD support removed, the framebuffer driver can be removed as well. Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Acked-by: Helge Deller <deller@gmx.de> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01mmc: remove tmio_mmc driverArnd Bergmann
With the TMIO MFD support gone, the corresponding MMC host driver can be removed as well. The remaining tmio_mmc_core module however is still used by both the Renesas and Socionext host drivers. Cc: Ian Molton <spyro@f2s.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: linux-mmc@vger.kernel.org Cc: linux-renesas-soc@vger.kernel.org Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01mfd: remove ucb1400 supportArnd Bergmann
The ucb1400 MFD driver and its gpio and touchscreen child drivers were only used on a few PXA machines that were unused for a while and are now removed. Removing these leaves the AC97 support as ALSA specific, no other drivers are now connected through this interface. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Bartosz Golaszewski <brgl@bgdev.pl> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Lee Jones <lee@kernel.org> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Cc: Marek Vasut <marex@denx.de> Cc: linux-kernel@vger.kernel.org Cc: linux-gpio@vger.kernel.org Cc: linux-input@vger.kernel.org Cc: alsa-devel@alsa-project.org Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01mfd: remove toshiba tmio driversArnd Bergmann
Four separate mfd drivers are in the "tmio" family, and all of them were used in now-removed PXA machines (eseries, tosa, and hx4700), so the mfd drivers and all its children can be removed as well. Cc: Lee Jones <lee@kernel.org> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: linux-kernel@vger.kernel.org Cc: linux-mmc@vger.kernel.org Cc: linux-renesas-soc@vger.kernel.org Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01rtc: remove v3020 driverArnd Bergmann
The v3020 RTC driver was exclusively used by the now removed cm-x300.c machine. Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: linux-kernel@vger.kernel.org Cc: linux-rtc@vger.kernel.org Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01power: remove pda_power supply driverArnd Bergmann
This driver was used for a couple of Intel PXA and Samsung S3C24xx based PDAs, but all of those are now removed from the kernel, so the driver itself is no longer useful. Cc: Anton Vorontsov <cbou@mail.ru> Cc: linux-pm@vger.kernel.org Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01ASoC: pxa: remove unused board supportArnd Bergmann
Most PXA/MMP boards were removed, so the board specific ASoC support is no longer needed, leaving only support for DT based ones, as well as the "gumstix" and "spitz" machines that may get converted to DT later. Cc: Ian Molton <spyro@f2s.com> Cc: Ken McGuire <kenm@desertweyr.com> Cc: Marek Vasut <marek.vasut@gmail.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Cc: alsa-devel@alsa-project.org Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01pcmcia: remove unused pxa/sa1100 driversArnd Bergmann
A number of boards got removed, so this code is now orphaned. Cc: Dominik Brodowski <linux@dominikbrodowski.net> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01input: remove zylonite touchscreen driverArnd Bergmann
The PXA zylonite platform was removed, so this driver has no remaining users. Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: linux-input@vger.kernel.org Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01input: remove pxa930_rotary keyboard driverArnd Bergmann
The pxa930 platform is getting removed and no upstream machine ever defined a rotary keyboard device. Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: linux-input@vger.kernel.org Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01input: remove pxa930_trkball driverArnd Bergmann
The pxa930 SoC support is getting removed, and no upstream board ever provided the trkball device that this driver relies on. Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: linux-input@vger.kernel.org Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01Merge tag 'zynq-soc-for-v6.3' of https://github.com/Xilinx/linux-xlnx into ↵Arnd Bergmann
arm/soc ARM: Zynq SoC changes for v6.3 - Fix refcount leak in zynq_early_slcr_init * tag 'zynq-soc-for-v6.3' of https://github.com/Xilinx/linux-xlnx: ARM: zynq: Fix refcount leak in zynq_early_slcr_init Link: https://lore.kernel.org/r/5d7785ca-7fe0-1597-c56a-7a0f4d230db8@monstr.eu Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01ARM: dts: wpcm450: Add nuvoton,shm = <&shm> to FIU nodeJonathan Neuschäfer
The Flash Interface Unit (FIU) should have a reference to the Shared Memory controller (SHM) so that flash access from the host (x86 computer managed by the WPCM450 BMC) can be blocked during flash access by the FIU driver. Fixes: 38abcb0d68767 ("ARM: dts: wpcm450: Add FIU SPI controller node") Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Link: https://lore.kernel.org/r/20230129112611.1176517-1-j.neuschaefer@gmx.net Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20230201044158.962417-1-joel@jms.id.au Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01MAINTAINERS: Update entry for MediaTek SoC supportMatthias Brugger
The linux-mediatek IRC channel has moved to liber.chat for quite some time. Apart from that, not all patches are also send to LKML, so add this ML explicitly. And last but not least: Angelo does a wunderfull job in reviewing patches for all kind of devices from MediaTek. Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20230201152256.19514-1-matthias.bgg@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01Merge tag 'zynq-dt-for-v6.3' of https://github.com/Xilinx/linux-xlnx into arm/dtArnd Bergmann
ARM: Zynq DT changes for v6.3 - Fix node names to be aligned with dt schema - Describe qspi controller - Use xlnx prefix for ethernet IP * tag 'zynq-dt-for-v6.3' of https://github.com/Xilinx/linux-xlnx: ARM: zynq: Use recommended dma-controller name instead of dmac ARM: dts: zynq: Add xlnx prefix to GEM compatible string ARM: zynq: Comment interrupt names IRQs for pl330 ARM: dts: zynq: add QSPI controller node Link: https://lore.kernel.org/r/850bb18f-ca22-f3d7-71a7-f367bfef4ccc@monstr.eu Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01Merge tag 'zynqmp-dt-for-v6.3' of https://github.com/Xilinx/linux-xlnx into ↵Arnd Bergmann
arm/dt arm64: ZynqMP SOC changes for v6.3 - Fix node names to be aligned with dt schema - Rename DT overlay files to dtso - Add snps,resume-hs-terminations to usb nodes - Describe gpio-modepin node - Use xlnx prefix for ethernet IP * tag 'zynqmp-dt-for-v6.3' of https://github.com/Xilinx/linux-xlnx: arm64: dts: zynqmp: Add xlnx prefix to GEM compatible string arm64: dts: zynqmp: Remove clock-names from GEM in zynqmp-clk-ccf.dtsi arm64: dts: zynqmp: Add mode-pin GPIO controller DT node arm64: zynqmp: Enable hs termination flag for USB dwc3 controller arm64: dts: xilinx: Rename DTB overlay source files from .dts to .dtso arm64: xilinx: Fix opp-table-cpu arm64: dts: xilinx: align LED node names with dtschema Link: https://lore.kernel.org/r/89d82a7e-6b42-97ce-2912-aa7dec965ff2@monstr.eu Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-02-01loop: Improve the hw_queue_depth kernel module parameter implementationBart Van Assche
Make the following minor changes which were reported by colleagues while reviewing this code: - Remove the parentheses from around the LOOP_DEFAULT_HW_Q_DEPTH definition since these are superfluous. - Accept other number formats than decimal, e.g. hexadecimal. - Do not set hw_queue_depth to an out-of-range value, even if that value won't be used. - Use the LOOP_DEFAULT_HW_Q_DEPTH macro in the kernel module parameter description to prevent that the description gets out of sync. This patch has been tested as follows: # modprobe -r loop # modprobe loop hw_queue_depth=-1 modprobe: ERROR: could not insert 'loop': Invalid argument # modprobe loop hw_queue_depth=0 modprobe: ERROR: could not insert 'loop': Invalid argument # modprobe loop hw_queue_depth=1; cat /sys/module/loop/parameters/hw_queue_depth 1 # modprobe -r loop; modprobe loop; cat /sys/module/loop/parameters/hw_queue_depth hw_queue_depth=0x10 16 # modprobe -r loop; modprobe loop; cat /sys/module/loop/parameters/hw_queue_depth hw_queue_depth=128 128 # modprobe -r loop; modprobe loop hw_queue_depth=129; cat /sys/module/loop/parameters/hw_queue_depth 129 # modprobe -r loop; modprobe loop hw_queue_depth=$((1<<32)) modprobe: ERROR: could not insert 'loop': Numerical result out of range See also commit ef44c50837ab ("loop: allow user to set the queue depth"). Cc: Chaitanya Kulkarni <kch@nvidia.com> Cc: Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Link: https://lore.kernel.org/r/20230130211347.832110-1-bvanassche@acm.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-02-01nvme-auth: use workqueue dedicated to authenticationShin'ichiro Kawasaki
NVMe In-Band authentication uses two kinds of works: chap->auth_work and ctrl->dhchap_auth_work. The latter work flushes or cancels the former work. However, the both works are queued to the same workqueue nvme-wq. It results in the lockdep WARNING as follows: WARNING: possible recursive locking detected 6.2.0-rc4+ #1 Not tainted -------------------------------------------- kworker/u16:7/69 is trying to acquire lock: ffff902d52e65548 ((wq_completion)nvme-wq){+.+.}-{0:0}, at: start_flush_work+0x2c5/0x380 but task is already holding lock: ffff902d52e65548 ((wq_completion)nvme-wq){+.+.}-{0:0}, at: process_one_work+0x210/0x410 To avoid the WARNING, introduce a new workqueue nvme-auth-wq dedicated to chap->auth_work. Reported-by: Daniel Wagner <dwagner@suse.de> Link: https://lore.kernel.org/linux-nvme/20230130110802.paafkiipmitwtnwr@carbon.lan/ Fixes: f50fff73d620 ("nvme: implement In-Band authentication") Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com> Tested-by: Daniel Wagner <dwagner@suse.de> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de>
2023-02-01nvme: mask CSE effects for security receiveKeith Busch
The nvme driver will freeze the IO queues in response to an admin command with CSE bits set. These bits notify the host that the command that's about to be executed needs to be done exclusively, hence the freeze. The Security Receive command is often reported by multiple vendors with CSE bits set. The reason for this is that the result depends on the previous Security Send. This has nothing to do with IO queues, though, so the driver is taking an overly cautious response to seeing this passthrough command, while unable to fufill the intended admin queue action. Rather than freeze IO during this harmless command, mask off the effects. This freezing is observed to cause IO latency spikes when host software periodically validates the security state of the drives. Signed-off-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Jens Axboe <axboe@kernel.dk> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2023-02-01nvme: always initialize known command effectsKeith Busch
Instead of appending command effects flags per IO, set the known effects flags the driver needs to react to just once during initial setup. Signed-off-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Kanchan Joshi <joshi.k@samsung.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Christoph Hellwig <hch@lst.de>