summaryrefslogtreecommitdiff
path: root/arch/arm
AgeCommit message (Collapse)AuthorFilesLines
2024-06-16ARM: dts: samsung: exynos4412-origen: fix keypad no-autorepeatKrzysztof Kozlowski1-1/+1
commit 88208d3cd79821117fd3fb80d9bcab618467d37b upstream. Although the Samsung SoC keypad binding defined linux,keypad-no-autorepeat property, Linux driver never implemented it and always used linux,input-no-autorepeat. Correct the DTS to use property actually implemented. This also fixes dtbs_check errors like: exynos4412-origen.dtb: keypad@100a0000: 'linux,keypad-no-autorepeat' does not match any of the regexes: '^key-[0-9a-z]+$', 'pinctrl-[0-9]+' Cc: <stable@vger.kernel.org> Fixes: bd08f6277e44 ("ARM: dts: Add keypad entries to Exynos4412 based Origen") Link: https://lore.kernel.org/r/20240312183105.715735-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-16ARM: dts: samsung: smdk4412: fix keypad no-autorepeatKrzysztof Kozlowski1-1/+1
commit 4ac4c1d794e7ff454d191bbdab7585ed8dbf3758 upstream. Although the Samsung SoC keypad binding defined linux,keypad-no-autorepeat property, Linux driver never implemented it and always used linux,input-no-autorepeat. Correct the DTS to use property actually implemented. This also fixes dtbs_check errors like: exynos4412-smdk4412.dtb: keypad@100a0000: 'key-A', 'key-B', 'key-C', 'key-D', 'key-E', 'linux,keypad-no-autorepeat' do not match any of the regexes: '^key-[0-9a-z]+$', 'pinctrl-[0-9]+' Cc: <stable@vger.kernel.org> Fixes: c9b92dd70107 ("ARM: dts: Add keypad entries to SMDK4412") Link: https://lore.kernel.org/r/20240312183105.715735-3-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-16ARM: dts: samsung: smdkv310: fix keypad no-autorepeatKrzysztof Kozlowski1-1/+1
commit 87d8e522d6f5a004f0aa06c0def302df65aff296 upstream. Although the Samsung SoC keypad binding defined linux,keypad-no-autorepeat property, Linux driver never implemented it and always used linux,input-no-autorepeat. Correct the DTS to use property actually implemented. This also fixes dtbs_check errors like: exynos4210-smdkv310.dtb: keypad@100a0000: 'linux,keypad-no-autorepeat' does not match any of the regexes: '^key-[0-9a-z]+$', 'pinctrl-[0-9]+' Cc: <stable@vger.kernel.org> Fixes: 0561ceabd0f1 ("ARM: dts: Add intial dts file for EXYNOS4210 SoC, SMDKV310 and ORIGEN") Link: https://lore.kernel.org/r/20240312183105.715735-1-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12kbuild: unify vdso_install rulesMasahiro Yamada2-31/+1
[ Upstream commit 56769ba4b297a629148eb24d554aef72d1ddfd9e ] Currently, there is no standard implementation for vdso_install, leading to various issues: 1. Code duplication Many architectures duplicate similar code just for copying files to the install destination. Some architectures (arm, sparc, x86) create build-id symlinks, introducing more code duplication. 2. Unintended updates of in-tree build artifacts The vdso_install rule depends on the vdso files to install. It may update in-tree build artifacts. This can be problematic, as explained in commit 19514fc665ff ("arm, kbuild: make "make install" not depend on vmlinux"). 3. Broken code in some architectures Makefile code is often copied from one architecture to another without proper adaptation. 'make vdso_install' for parisc does not work. 'make vdso_install' for s390 installs vdso64, but not vdso32. To address these problems, this commit introduces a generic vdso_install rule. Architectures that support vdso_install need to define vdso-install-y in arch/*/Makefile. vdso-install-y lists the files to install. For example, arch/x86/Makefile looks like this: vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix, if exists, stripped away. vdso-install-y can optionally take the second field after the colon separator. This is needed because some architectures install a vdso file as a different base name. The following is a snippet from arch/arm64/Makefile. vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so This will rename vdso.so.dbg to vdso32.so during installation. If such architectures change their implementation so that the base names match, this workaround will go away. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Sven Schnelle <svens@linux.ibm.com> # s390 Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Reviewed-by: Guo Ren <guoren@kernel.org> Acked-by: Helge Deller <deller@gmx.de> # parisc Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Stable-dep-of: fc2f5f10f9bc ("s390/vdso: Create .build-id links for unstripped vdso files") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12ARM: configs: sunxi: Enable DRM_DW_HDMIMaxime Ripard1-0/+1
[ Upstream commit deff401b14e2d832b25b55862ad6c73378fe034e ] Commit 4fc8cb47fcfd ("drm/display: Move HDMI helpers into display-helper module") turned the DRM_DW_HDMI dependency of DRM_SUN8I_DW_HDMI into a depends on which ended up disabling the driver in the defconfig. Make sure it's still enabled. Fixes: 4fc8cb47fcfd ("drm/display: Move HDMI helpers into display-helper module") Reported-by: Mark Brown <broonie@kernel.org> Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20240403-fix-dw-hdmi-kconfig-v1-5-afbc4a835c38@kernel.org Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-17ARM: 9381/1: kasan: clear stale stack poisonBoy.Wu1-0/+4
[ Upstream commit c4238686f9093b98bd6245a348bcf059cdce23af ] We found below OOB crash: [ 33.452494] ================================================================== [ 33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0 [ 33.455515] [ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1 [ 33.456880] Hardware name: Generic DT based system [ 33.457555] unwind_backtrace from show_stack+0x18/0x1c [ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c [ 33.459072] dump_stack_lvl from print_report+0x158/0x4a4 [ 33.459863] print_report from kasan_report+0x9c/0x148 [ 33.460616] kasan_report from kasan_check_range+0x94/0x1a0 [ 33.461424] kasan_check_range from memset+0x20/0x3c [ 33.462157] memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.463064] refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c [ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354 [ 33.465029] do_idle from cpu_startup_entry+0x20/0x24 [ 33.465769] cpu_startup_entry from rest_init+0xf0/0xf4 [ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18 [ 33.467397] [ 33.467644] The buggy address belongs to stack of task swapper/0/0 [ 33.468493] and is located at offset 112 in frame: [ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec [ 33.469917] [ 33.470165] This frame has 2 objects: [ 33.470696] [32, 76) 'global_zone_diff' [ 33.470729] [112, 276) 'global_node_diff' [ 33.471294] [ 33.472095] The buggy address belongs to the physical page: [ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03 [ 33.473944] flags: 0x1000(reserved|zone=0) [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001 [ 33.475656] raw: 00000000 [ 33.476050] page dumped because: kasan: bad access detected [ 33.476816] [ 33.477061] Memory state around the buggy address: [ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 [ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1 [ 33.480415] ^ [ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3 [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.482978] ================================================================== We find the root cause of this OOB is that arm does not clear stale stack poison in the case of cpuidle. This patch refer to arch/arm64/kernel/sleep.S to resolve this issue. From cited commit [1] that explain the problem Functions which the compiler has instrumented for KASAN place poison on the stack shadow upon entry and remove this poison prior to returning. In the case of cpuidle, CPUs exit the kernel a number of levels deep in C code. Any instrumented functions on this critical path will leave portions of the stack shadow poisoned. If CPUs lose context and return to the kernel via a cold path, we restore a prior context saved in __cpu_suspend_enter are forgotten, and we never remove the poison they placed in the stack shadow area by functions calls between this and the actual exit of the kernel. Thus, (depending on stackframe layout) subsequent calls to instrumented functions may hit this stale poison, resulting in (spurious) KASAN splats to the console. To avoid this, clear any stale poison from the idle thread for a CPU prior to bringing a CPU online. From cited commit [2] Extend to check for CONFIG_KASAN_STACK [1] commit 0d97e6d8024c ("arm64: kasan: clear stale stack poison") [2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK") Signed-off-by: Boy Wu <boy.wu@mediatek.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Andrey Ryabinin <ryabinin.a.a@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Fixes: 5615f69bc209 ("ARM: 9016/2: Initialize the mapping of KASan shadow memory") Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-02ARM: dts: imx6ull-tarragon: fix USB over-current polarityMichael Heimpold1-0/+1
[ Upstream commit d7f3040a565214a30e2f07dc9b91566d316e2d36 ] Our Tarragon platform uses a active-low signal to inform the i.MX6ULL about the over-current detection. Fixes: 5e4f393ccbf0 ("ARM: dts: imx6ull: Add chargebyte Tarragon support") Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com> Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-02ARM: dts: microchip: at91-sama7g5ek: Replace regulator-suspend-voltage with ↵Andrei Simion1-4/+4
the valid property [ Upstream commit e027b71762e84ee9d4ba9ad5401b956b9e83ed2a ] By checking the pmic node with microchip,mcp16502.yaml# 'regulator-suspend-voltage' does not match any of the regexes 'pinctrl-[0-9]+' from schema microchip,mcp16502.yaml# which inherits regulator.yaml#. So replace regulator-suspend-voltage with regulator-suspend-microvolt to avoid the inconsitency. Fixes: 85b1304b9daa ("ARM: dts: at91: sama7g5ek: set regulator voltages for standby state") Signed-off-by: Andrei Simion <andrei.simion@microchip.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20240404123824.19182-2-andrei.simion@microchip.com [claudiu.beznea: added a dot before starting the last sentence in commit description] Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-27ASoC: ti: Convert Pandora ASoC to GPIO descriptorsLinus Walleij1-0/+10
[ Upstream commit 319e6ac143b9e9048e527ab9dd2aabb8fdf3d60f ] The Pandora uses GPIO descriptors pretty much exclusively, but not for ASoC, so let's fix it. Register the pins in a descriptor table in the machine since the ASoC device is not using device tree. Use static locals for the GPIO descriptors because I'm not able to experient with better state storage on any real hardware. Others using the Pandora can come afterwards and improve this. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Link: https://lore.kernel.org/r/20230926-descriptors-asoc-ti-v1-4-60cf4f8adbc5@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-17ARM: OMAP2+: fix USB regression on Nokia N8x0Aaro Koskinen1-4/+2
[ Upstream commit 4421405e3634a3189b541cf1e34598e44260720d ] GPIO chip labels are wrong for OMAP2, so the USB does not work. Fix. Fixes: 8e0285ab95a9 ("ARM/musb: omap2: Remove global GPIO numbers from TUSB6010") Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Message-ID: <20240223181656.1099845-1-aaro.koskinen@iki.fi> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-17ARM: OMAP2+: fix N810 MMC gpiod tableAaro Koskinen1-3/+5
[ Upstream commit 480d44d0820dd5ae043dc97c0b46dabbe53cb1cf ] Trying to append a second table for the same dev_id doesn't seem to work. The second table is just silently ignored. As a result eMMC GPIOs are not present. Fix by using separate tables for N800 and N810. Fixes: e519f0bb64ef ("ARM/mmc: Convert old mmci-omap to GPIO descriptors") Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Message-ID: <20240223181439.1099750-3-aaro.koskinen@iki.fi> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-17ARM: OMAP2+: fix bogus MMC GPIO labels on Nokia N8x0Aaro Koskinen1-6/+3
[ Upstream commit 95f37eb52e18879a1b16e51b972d992b39e50a81 ] The GPIO bank width is 32 on OMAP2, so all labels are incorrect. Fixes: e519f0bb64ef ("ARM/mmc: Convert old mmci-omap to GPIO descriptors") Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Message-ID: <20240223181439.1099750-2-aaro.koskinen@iki.fi> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-17ARM: dts: imx7s-warp: Pass OV2680 link-frequenciesFabio Estevam1-0/+1
commit 135f218255b28c5bbf71e9e32a49e5c734cabbe5 upstream. Since commit 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification") the ov2680 no longer probes on a imx7s-warp7: ov2680 1-0036: error -EINVAL: supported link freq 330000000 not found ov2680 1-0036: probe with driver ov2680 failed with error -22 Fix it by passing the required 'link-frequencies' property as recommended by: https://www.kernel.org/doc/html/v6.9-rc1/driver-api/media/camera-sensor.html#handling-clocks Cc: stable@vger.kernel.org Fixes: 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification") Signed-off-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-13ARM: dts: rockchip: fix rk322x hdmi ports nodeJohan Jonker1-5/+11
[ Upstream commit 15a5ed03000cf61daf87d14628085cb1bc8ae72c ] Fix rk322x hdmi ports node so that it matches the rockchip,dw-hdmi.yaml binding. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/9b84adf0-9312-47fd-becc-cadd06941f70@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-13ARM: dts: rockchip: fix rk3288 hdmi ports nodeJohan Jonker1-3/+13
[ Upstream commit 585e4dc07100a6465b3da8d24e46188064c1c925 ] Fix rk3288 hdmi ports node so that it matches the rockchip,dw-hdmi.yaml binding with some reordering to align with the (new) documentation about property ordering. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/cc3a9b4f-076d-4660-b464-615003b6a066@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-03ARM: prctl: reject PR_SET_MDWE on pre-ARMv6Zev Weiss1-0/+14
commit 166ce846dc5974a266f6c2a2896dbef5425a6f21 upstream. On v5 and lower CPUs we can't provide MDWE protection, so ensure we fail any attempt to enable it via prctl(PR_SET_MDWE). Previously such an attempt would misleadingly succeed, leading to any subsequent mmap(PROT_READ|PROT_WRITE) or execve() failing unconditionally (the latter somewhat violently via force_fatal_sig(SIGSEGV) due to READ_IMPLIES_EXEC). Link: https://lkml.kernel.org/r/20240227013546.15769-6-zev@bewilderbeest.net Signed-off-by: Zev Weiss <zev@bewilderbeest.net> Cc: <stable@vger.kernel.org> [6.3+] Cc: Borislav Petkov <bp@alien8.de> Cc: David Hildenbrand <david@redhat.com> Cc: Florent Revest <revest@chromium.org> Cc: Helge Deller <deller@gmx.de> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: Josh Triplett <josh@joshtriplett.org> Cc: Kees Cook <keescook@chromium.org> Cc: Miguel Ojeda <ojeda@kernel.org> Cc: Mike Rapoport (IBM) <rppt@kernel.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Ondrej Mosnacek <omosnace@redhat.com> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: Russell King (Oracle) <linux@armlinux.org.uk> Cc: Sam James <sam@gentoo.org> Cc: Stefan Roesch <shr@devkernel.io> Cc: Yang Shi <yang@os.amperecomputing.com> Cc: Yin Fengwei <fengwei.yin@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-03ARM: 9359/1: flush: check if the folio is reserved for no-mapping addressesYongqiang Liu1-0/+3
[ Upstream commit 0c66c6f4e21cb22220cbd8821c5c73fc157d20dc ] Since commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account freed memory map alignment") changes the semantics of pfn_valid() to check presence of the memory map for a PFN. A valid page for an address which is reserved but not mapped by the kernel[1], the system crashed during some uio test with the following memory layout: node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff] node 0: [mem 0x00000000d0000000-0x00000000da1fffff] the uio layout is：0xc0900000, 0x100000 the crash backtrace like: Unable to handle kernel paging request at virtual address bff00000 [...] CPU: 1 PID: 465 Comm: startapp.bin Tainted: G O 5.10.0 #1 Hardware name: Generic DT based system PC is at b15_flush_kern_dcache_area+0x24/0x3c LR is at __sync_icache_dcache+0x6c/0x98 [...] (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98) (__sync_icache_dcache) from (set_pte_at+0x28/0x54) (set_pte_at) from (remap_pfn_range+0x1a0/0x274) (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio]) (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4) (__mmap_region) from (__do_mmap_mm+0x3ec/0x440) (__do_mmap_mm) from (do_mmap+0x50/0x58) (do_mmap) from (vm_mmap_pgoff+0xfc/0x188) (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4) (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c) Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e) ---[ end trace 09cf0734c3805d52 ]--- Kernel panic - not syncing: Fatal exception So check if PG_reserved was set to solve this issue. [1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/ Fixes: a4d5613c4dc6 ("arm: extend pfn_valid to take into account freed memory map alignment") Suggested-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-03ARM: 9352/1: iwmmxt: Remove support for PJ4/PJ4B coresArd Biesheuvel4-177/+15
[ Upstream commit b9920fdd5a751df129808e7fa512e9928223ee05 ] PJ4 is a v7 core that incorporates a iWMMXt coprocessor. However, GCC does not support this combination (its iWMMXt configuration always implies v5te), and so there is no v6/v7 user space that actually makes use of this, beyond generic support for things like setjmp() that preserve/restore the iWMMXt register file using generic LDC/STC instructions emitted in assembler. As [0] appears to imply, this logic is triggered for the init process at boot, and so most user threads will have a iWMMXt register context associated with it, even though it is never used. At this point, it is highly unlikely that such GCC support will ever materialize (and Clang does not implement support for iWMMXt to begin with). This means that advertising iWMMXt support on these cores results in context switch overhead without any associated benefit, and so it is better to simply ignore the iWMMXt unit on these systems. So rip out the support. Doing so also fixes the issue reported in [0] related to UNDEF handling of co-processor #0/#1 instructions issued from user space running in Thumb2 mode. The PJ4 cores are used in four platforms: Armada 370/xp, Dove (Cubox, d2plug), MMP2 (xo-1.75) and Berlin (Google TV). Out of these, only the first is still widely used, but that one actually doesn't have iWMMXt but instead has only VFPV3-D16, and so it is not impacted by this change. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218427 [0] Fixes: 8bcba70cb5c22 ("ARM: entry: Disregard Thumb undef exception ...") Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Nicolas Pitre <nico@fluxnic.net> Reviewed-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-03ARM: imx_v6_v7_defconfig: Restore CONFIG_BACKLIGHT_CLASS_DEVICEFabio Estevam1-0/+1
commit 2b0a5a8a397c0ae8f8cd25e7d3857c749239ceb8 upstream. Since commit bfac19e239a7 ("fbdev: mx3fb: Remove the driver") backlight is no longer functional. The fbdev mx3fb driver used to automatically select CONFIG_BACKLIGHT_CLASS_DEVICE. Now that the mx3fb driver has been removed, enable the CONFIG_BACKLIGHT_CLASS_DEVICE option so that backlight can still work by default. Tested on a imx6dl-sabresd board. Cc: stable@vger.kernel.org Fixes: bfac19e239a7 ("fbdev: mx3fb: Remove the driver") Signed-off-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Tested-by: Francesco Dolcini <francesco.dolcini@toradex.com> # Toradex Colibri iMX7 Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-03arm: dts: marvell: Fix maxium->maxim typo in brownstone dtsDuje Mihanović1-1/+1
[ Upstream commit 831e0cd4f9ee15a4f02ae10b67e7fdc10eb2b4fc ] Fix an obvious spelling error in the PMIC compatible in the MMP2 Brownstone DTS file. Fixes: 58f1193e6210 ("mfd: max8925: Add dts") Cc: <stable@vger.kernel.org> Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr> Reported-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Closes: https://lore.kernel.org/linux-devicetree/1410884282-18041-1-git-send-email-k.kozlowski@samsung.com/ Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20240125-brownstone-typo-fix-v2-1-45bc48a0c81c@skole.hr [krzysztof: Just 10 years to take a patch, not bad! Rephrased commit msg] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27crypto: arm/sha - fix function cast warningsArnd Bergmann2-15/+10
[ Upstream commit 53cc9baeb9bc2a187eb9c9790d30995148852b12 ] clang-16 warns about casting between incompatible function types: arch/arm/crypto/sha256_glue.c:37:5: error: cast from 'void (*)(u32 *, const void *, unsigned int)' (aka 'void (*)(unsigned int *, const void *, unsigned int)') to 'sha256_block_fn *' (aka 'void (*)(struct sha256_state *, const unsigned char *, int)') converts to incompatible function type [-Werror,-Wcast-function-type-strict] 37 | (sha256_block_fn *)sha256_block_data_order); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/arm/crypto/sha512-glue.c:34:3: error: cast from 'void (*)(u64 *, const u8 *, int)' (aka 'void (*)(unsigned long long *, const unsigned char *, int)') to 'sha512_block_fn *' (aka 'void (*)(struct sha512_state *, const unsigned char *, int)') converts to incompatible function type [-Werror,-Wcast-function-type-strict] 34 | (sha512_block_fn *)sha512_block_data_order); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fix the prototypes for the assembler functions to match the typedef. The code already relies on the digest being the first part of the state structure, so there is no change in behavior. Fixes: c80ae7ca3726 ("crypto: arm/sha512 - accelerated SHA-512 using ARM generic ASM and NEON") Fixes: b59e2ae3690c ("crypto: arm/sha256 - move SHA-224/256 ASM/NEON implementation to base layer") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27ARM: dts: imx6dl-yapp4: Move the internal switch PHYs under the switch nodeMichal Vokáč1-8/+15
[ Upstream commit 79978bff2e4b8e05ebdf5fc3ee6b794002393484 ] We identified that the PHYs actually do not work since commit 7da7b84fee58 ("ARM: dts: imx6dl-yapp4: Move phy reset into switch node") as a coincidence of several circumstances. The reset signal is kept asserted by a pull-down resistor on the board unless it is deasserted by GPIO from the SoC. This is to keep the switch dead until it is configured properly by the kernel and user space. Prior to the referenced commit the switch was reset by the FEC driver and the reset GPIO was actively deasserted. The mdio-bus was scanned and the attached switch and its PHYs were found and configured. With the referenced commit the switch is reset by the qca8k driver. Because of another bug in the qca8k driver, functionality of the reset pin depends on its pre-kernel configuration. See commit c44fc98f0a8f ("net: dsa: qca8k: fix illegal usage of GPIO") The problem did not appear until we removed support for the switch and configuration of its reset pin from the bootloader. To fix that, properly describe the internal mdio-bus configuration of the qca8334 switch. The PHYs are internal to the switch and sit on its internal mdio-bus. Fixes: 7da7b84fee58 ("ARM: dts: imx6dl-yapp4: Move phy reset into switch node") Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27ARM: dts: imx6dl-yapp4: Fix typo in the QCA switch register addressMichal Vokáč1-1/+1
[ Upstream commit 023bd910d3ab735459f84b22bb99fb9e00bd9d76 ] This change does not have any functional effect. The switch works just fine without this patch as it has full access to all the addresses on the bus. This is simply a clean-up to set the node name address and reg address to the same value. Fixes: 15b43e497ffd ("ARM: dts: imx6dl-yapp4: Use correct pseudo PHY address for the switch") Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27ARM: dts: arm: realview: Fix development chip ROM compatible valueGeert Uytterhoeven1-1/+1
[ Upstream commit 3baa4c5143d65ebab2de0d99a395e5f4f1f46608 ] When the development chip ROM was added, the "direct-mapped" compatible value was already obsolete. In addition, the device node lacked the accompanying "probe-type" property, causing the old physmap_of_core driver to fall back to trying all available probe types. Unfortunately this fallback was lost when the DT and pdata cases were merged. Fix this by using the modern "mtd-rom" compatible value instead. Fixes: 5c3f5edbe0a1dff3 ("ARM: realview: add flash devices to the PB1176 DTS") Fixes: 642b1e8dbed7bbbf ("mtd: maps: Merge physmap_of.c into physmap-core.c") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27ARM: dts: qcom: msm8974: correct qfprom node sizeCraig Tatlor1-1/+1
[ Upstream commit 724c4bf0e4bf81dba77736afb93964c986c3c123 ] The qfprom actually is bigger than 0x1000, so adjust the reg. Note that the non-ECC-corrected qfprom can be found at 0xfc4b8000 (-0x4000). The current reg points to the ECC-corrected qfprom block which should have equivalent values at all offsets compared to the non-corrected version. [luca@z3ntu.xyz: extract to standalone patch and adjust for review comments] Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and qfprom nodes") Signed-off-by: Craig Tatlor <ctatlor97@gmail.com> Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240210-msm8974-qfprom-v3-1-26c424160334@z3ntu.xyz Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27ARM: dts: renesas: r8a73a4: Fix external clocks and clock rateGeert Uytterhoeven2-3/+18
[ Upstream commit 090c4094574705b0afc7d37825cdc5d06f0e7e02 ] External clocks should be defined as zero-Hz clocks in the SoC .dtsi, and overridden in the board .dts when present. Correct the clock rate of extal1 from 25 to 26 MHz, to match the crystal oscillator present on the APE6-EVM board. Fixes: a76809a329d6ebae ("ARM: shmobile: r8a73a4: Common clock framework DT description") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/1692bc8cd465d62168cbf110522ad62a7af3f606.1705315614.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27ARM: dts: renesas: rcar-gen2: Add missing #interrupt-cells to DA9063 nodesGeert Uytterhoeven8-0/+8
[ Upstream commit 8c987693dc2d292d777f1be63cb35233049ae25e ] make dtbs_check W=2: arch/arm/boot/dts/renesas/r8a7790-lager.dts:444.11-458.5: Warning (interrupt_provider): /i2c-mux4/pmic@58: Missing '#interrupt-cells' in interrupt provider ... Fix this by adding the missing #interrupt-cells properties. Reported-by: Rob Herring <robh@kernel.org> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/a351e503ea97fb1af68395843f513925ff1bdf26.1707922460.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm: dts: Fix dtc interrupt_map warningsRob Herring3-4/+8
[ Upstream commit f02b0f0dc26fbb77fe47b6e47cc5c211f0432c37 ] The dtc interrupt_map warning is off because its dependency, interrupt_provider, is off by default. Fix all the warnings so it can be enabled. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240213-arm-dt-cleanups-v1-4-f2dee1292525@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm: dts: Fix dtc interrupt_provider warningsRob Herring24-58/+18
[ Upstream commit 96fd598e9c34cfa68402a4da3020c9236cfacf35 ] The dtc interrupt_provider warning is off by default. Fix all the warnings so it can be enabled. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au> Reviewed-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Acked-by: Florian Fainelli <florian.fainelli@broadcom.com> #Broadcom Acked-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20240213-arm-dt-cleanups-v1-2-f2dee1292525@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27ARM: dts: rockchip: Drop interrupts property from pwm-rockchip nodesUwe Kleine-König1-8/+0
[ Upstream commit f98643d8daf3443e3b414a82d0cb3d745f8c8bbc ] The binding doesn't define interrupts and adding such a definition was refused because it's unclear how they should ever be used and the relevant registers are outside the PWM range. So drop them fixing several dtbs_check warnings like: arch/arm/boot/dts/rockchip/rv1108-elgin-r1.dtb: pwm@10280030: 'interrupts' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/pwm/pwm-rockchip.yaml# Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20240129113205.2453029-2-u.kleine-koenig@pengutronix.de Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-01ARM: ep93xx: Add terminator to gpiod_lookup_tableNikita Shubin1-0/+1
commit fdf87a0dc26d0550c60edc911cda42f9afec3557 upstream. Without the terminator, if a con_id is passed to gpio_find() that does not exist in the lookup table the function will not stop looping correctly, and eventually cause an oops. Cc: stable@vger.kernel.org Fixes: b2e63555592f ("i2c: gpio: Convert to use descriptors") Reported-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Link: https://lore.kernel.org/r/20240205102337.439002-1-alexander.sverdlin@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-01ARM: dts: Fix TPM schema violationsLukas Wunner7-10/+10
[ Upstream commit 8412c47d68436b9f9a260039a4a773daa6824925 ] Since commit 26c9d152ebf3 ("dt-bindings: tpm: Consolidate TCG TIS bindings"), several issues are reported by "make dtbs_check" for ARM devicetrees: The nodename needs to be "tpm@0" rather than "tpmdev@0" and the compatible property needs to contain the chip's name in addition to the generic "tcg,tpm_tis-spi" or "tcg,tpm-tis-i2c": tpmdev@0: $nodename:0: 'tpmdev@0' does not match '^tpm(@[0-9a-f]+)?$' from schema $id: http://devicetree.org/schemas/tpm/tcg,tpm_tis-spi.yaml# tpm@2e: compatible: 'oneOf' conditional failed, one must be fixed: ['tcg,tpm-tis-i2c'] is too short from schema $id: http://devicetree.org/schemas/tpm/tcg,tpm-tis-i2c.yaml# Fix these schema violations. Aspeed Facebook BMCs use an Infineon SLB9670: https://lore.kernel.org/all/ZZSmMJ%2F%2Fl972Qbxu@fedora/ https://lore.kernel.org/all/ZZT4%2Fw2eVzMhtsPx@fedora/ https://lore.kernel.org/all/ZZTS0p1hdAchIbKp@heinlein.vulture-banana.ts.net/ Aspeed Tacoma uses a Nuvoton NPCT75X per commit 39d8a73c53a2 ("ARM: dts: aspeed: tacoma: Add TPM"). phyGATE-Tauri uses an Infineon SLB9670: https://lore.kernel.org/all/ab45c82485fa272f74adf560cbb58ee60cc42689.camel@phytec.de/ A single schema violation remains in am335x-moxa-uc-2100-common.dtsi because it is unknown which chip is used on the board. The devicetree's author has been asked for clarification but has not responded so far: https://lore.kernel.org/all/20231220090910.GA32182@wunner.de/ Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Patrick Williams <patrick@stwcx.xyz> Reviewed-by: Tao Ren <rentao.bupt@gmail.com> Reviewed-by: Bruno Thomsen <bruno.thomsen@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-23work around gcc bugs with 'asm goto' with outputsLinus Torvalds1-2/+2
commit 4356e9f841f7fbb945521cef3577ba394c65f3fc upstream. We've had issues with gcc and 'asm goto' before, and we created a 'asm_volatile_goto()' macro for that in the past: see commits 3f0116c3238a ("compiler/gcc4: Add quirk for 'asm goto' miscompilation bug") and a9f180345f53 ("compiler/gcc4: Make quirk for asm_volatile_goto() unconditional"). Then, much later, we ended up removing the workaround in commit 43c249ea0b1e ("compiler-gcc.h: remove ancient workaround for gcc PR 58670") because we no longer supported building the kernel with the affected gcc versions, but we left the macro uses around. Now, Sean Christopherson reports a new version of a very similar problem, which is fixed by re-applying that ancient workaround. But the problem in question is limited to only the 'asm goto with outputs' cases, so instead of re-introducing the old workaround as-is, let's rename and limit the workaround to just that much less common case. It looks like there are at least two separate issues that all hit in this area: (a) some versions of gcc don't mark the asm goto as 'volatile' when it has outputs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98619 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110420 which is easy to work around by just adding the 'volatile' by hand. (b) Internal compiler errors: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110422 which are worked around by adding the extra empty 'asm' as a barrier, as in the original workaround. but the problem Sean sees may be a third thing since it involves bad code generation (not an ICE) even with the manually added 'volatile'. but the same old workaround works for this case, even if this feels a bit like voodoo programming and may only be hiding the issue. Reported-and-tested-by: Sean Christopherson <seanjc@google.com> Link: https://lore.kernel.org/all/20240208220604.140859-1-seanjc@google.com/ Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Uros Bizjak <ubizjak@gmail.com> Cc: Jakub Jelinek <jakub@redhat.com> Cc: Andrew Pinski <quic_apinski@quicinc.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-16mm: Introduce flush_cache_vmap_early()Alexandre Ghiti1-0/+2
[ Upstream commit 7a92fc8b4d20680e4c20289a670d8fca2d1f2c1b ] The pcpu setup when using the page allocator sets up a new vmalloc mapping very early in the boot process, so early that it cannot use the flush_cache_vmap() function which may depend on structures not yet initialized (for example in riscv, we currently send an IPI to flush other cpus TLB). But on some architectures, we must call flush_cache_vmap(): for example, in riscv, some uarchs can cache invalid TLB entries so we need to flush the new established mapping to avoid taking an exception. So fix this by introducing a new function flush_cache_vmap_early() which is called right after setting the new page table entry and before accessing this new mapping. This new function implements a local flush tlb on riscv and is no-op for other architectures (same as today). Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Dennis Zhou <dennis@kernel.org> Stable-dep-of: d9807d60c145 ("riscv: mm: execute local TLB flush after populating vmemmap") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-05ARM: dts: imx23/28: Fix the DMA controller node nameFabio Estevam2-2/+2
[ Upstream commit 858d83ca4b50bbc8693d95cc94310e6d791fb2e6 ] Per fsl,mxs-dma.yaml, the node name should be 'dma-controller'. Change it to fix the following dt-schema warning. imx28-apf28.dtb: dma-apbx@80024000: $nodename:0: 'dma-apbx@80024000' does not match '^dma-controller(@.*)?$' from schema $id: http://devicetree.org/schemas/dma/fsl,mxs-dma.yaml# Signed-off-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-05ARM: dts: imx23-sansa: Use preferred i2c-gpios propertiesFabio Estevam1-8/+4
[ Upstream commit e3aa1a82fb20ee97597022f6528823a8ab82bde6 ] The 'gpios' property to describe the SDA and SCL GPIOs is considered deprecated according to i2c-gpio.yaml. Switch to the preferred 'sda-gpios' and 'scl-gpios' properties. This fixes the following schema warnings: imx23-sansa.dtb: i2c-0: 'sda-gpios' is a required property from schema $id: http://devicetree.org/schemas/i2c/i2c-gpio.yaml# imx23-sansa.dtb: i2c-0: 'scl-gpios' is a required property from schema $id: http://devicetree.org/schemas/i2c/i2c-gpio.yaml# Signed-off-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-05ARM: dts: imx27-apf27dev: Fix LED nameFabio Estevam1-1/+1
[ Upstream commit dc35e253d032b959d92e12f081db5b00db26ae64 ] Per leds-gpio.yaml, the led names should start with 'led'. Change it to fix the following dt-schema warning: imx27-apf27dev.dtb: leds: 'user' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/leds/leds-gpio.yaml# Signed-off-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-05ARM: dts: imx25/27: Pass timing0Fabio Estevam8-8/+8
[ Upstream commit 11ab7ad6f795ae23c398a4a5c56505d3dab27c4c ] Per display-timings.yaml, the 'timing' pattern should be used to describe the display timings. Change it accordingly to fix the following dt-schema warning: imx27-apf27dev.dtb: display-timings: '800x480' does not match any of the regexes: '^timing', 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/display/panel/display-timings.yaml# Signed-off-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-05ARM: dts: imx25: Fix the iim compatible stringFabio Estevam1-1/+1
[ Upstream commit f0b929f58719fc57a4926ab4fc972f185453d6a5 ] Per imx-iim.yaml, the compatible string should only contain a single entry. Use it as "fsl,imx25-iim" to fix the following dt-schema warning: imx25-karo-tx25.dtb: efuse@53ff0000: compatible: ['fsl,imx25-iim', 'fsl,imx27-iim'] is too long from schema $id: http://devicetree.org/schemas/nvmem/imx-iim.yaml# Signed-off-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-05ARM: dts: imx1: Fix sram nodeFabio Estevam1-1/+4
[ Upstream commit c248e535973088ba7071ff6f26ab7951143450af ] Per sram.yaml, address-cells, size-cells and ranges are mandatory. The node name should be sram. Change the node name and pass the required properties to fix the following dt-schema warnings: imx1-apf9328.dtb: esram@300000: $nodename:0: 'esram@300000' does not match '^sram(@.*)?' from schema $id: http://devicetree.org/schemas/sram/sram.yaml# imx1-apf9328.dtb: esram@300000: '#address-cells' is a required property from schema $id: http://devicetree.org/schemas/sram/sram.yaml# imx1-apf9328.dtb: esram@300000: '#size-cells' is a required property from schema $id: http://devicetree.org/schemas/sram/sram.yaml# imx1-apf9328.dtb: esram@300000: 'ranges' is a required property from schema $id: http://devicetree.org/schemas/sram/sram.yaml# Signed-off-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-05ARM: dts: imx27: Fix sram nodeFabio Estevam1-0/+3
[ Upstream commit 2fb7b2a2f06bb3f8321cf26c33e4e820c5b238b6 ] Per sram.yaml, address-cells, size-cells and ranges are mandatory. Pass them to fix the following dt-schema warnings: Signed-off-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-05ARM: dts: imx: Use flash@0,0 patternFabio Estevam4-4/+4
[ Upstream commit 1e1d7cc478fb16816de09740e3c323c0c188d58f ] Per mtd-physmap.yaml, 'nor@0,0' is not a valid node pattern. Change it to 'flash@0,0' to fix the following dt-schema warning: imx1-ads.dtb: nor@0,0: $nodename:0: 'nor@0,0' does not match '^(flash|.*sram|nand)(@.*)?$' from schema $id: http://devicetree.org/schemas/mtd/mtd-physmap.yaml# Signed-off-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-05ARM: dts: imx25/27-eukrea: Fix RTC node nameFabio Estevam2-2/+2
[ Upstream commit 68c711b882c262e36895547cddea2c2d56ce611d ] Node names should be generic. Use 'rtc' as node name to fix the following dt-schema warning: imx25-eukrea-mbimxsd25-baseboard.dtb: pcf8563@51: $nodename:0: 'pcf8563@51' does not match '^rtc(@.*|-([0-9]|[1-9][0-9]+))?$' from schema $id: http://devicetree.org/schemas/rtc/nxp,pcf8563.yaml# Signed-off-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-05ARM: dts: rockchip: fix rk3036 hdmi ports nodeJohan Jonker1-3/+11
[ Upstream commit 27ded76ef0fcfcf939914532aae575cf23c221b4 ] Fix hdmi ports node so that it matches the rockchip,inno-hdmi.yaml binding. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/9a2afac1-ed5c-382d-02b0-b2f5f1af3abb@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-05ARM: dts: imx7s: Fix nand-controller #size-cellsAlexander Stein1-1/+1
[ Upstream commit 4aadb841ed49bada1415c48c44d21f5b69e01299 ] nand-controller.yaml bindings says #size-cells shall be set to 0. Fixes the dtbs_check warning: arch/arm/boot/dts/nxp/imx/imx7s-mba7.dtb: nand-controller@33002000: #size-cells:0:0: 0 was expected from schema $id: http://devicetree.org/schemas/mtd/gpmi-nand.yaml# Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-05ARM: dts: imx7s: Fix lcdif compatibleAlexander Stein1-1/+1
[ Upstream commit 5f55da4cc37051cda600ea870ce8cf29f1297715 ] imx7d-lcdif is compatible to imx6sx-lcdif. MXSFB_V6 supports overlay by using LCDC_AS_CTRL register. This registers used by overlay plane: * LCDC_AS_CTRL * LCDC_AS_BUF * LCDC_AS_NEXT_BUF are listed in i.MX7D RM as well. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-05ARM: dts: imx7d: Fix coresight funnel portsAlexander Stein2-4/+5
[ Upstream commit 0d4ac04fa7c3f6dc263dba6f575a2ec7a2d4eca8 ] imx7d uses two ports for 'in-ports', so the syntax port@<num> has to be used. imx7d has both port and port@1 nodes present, raising these error: funnel@30041000: in-ports: More than one condition true in oneOf schema funnel@30041000: Unevaluated properties are not allowed ('in-ports' was unexpected) Fix this by also using port@0 for imx7s as well. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-05ARM: dts: samsung: s5pv210: fix camera unit addresses/rangesKrzysztof Kozlowski1-9/+9
[ Upstream commit 07e6a553c2f1d385edfc9185081dee442a9dd38d ] The camera node has both unit address and children within the same bus mapping, thus needs proper ranges property to fix dtc W=1 warnings: Warning (unit_address_vs_reg): /soc/camera@fa600000: node has a unit name, but no reg or ranges property Warning (simple_bus_reg): /soc/camera@fa600000: missing or empty reg/ranges property Subtract 0xfa600000 from all its children nodes. No functional impact expected. Link: https://lore.kernel.org/r/20230722121719.150094-3-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-05ARM: dts: samsung: exynos4: fix camera unit addresses/rangesKrzysztof Kozlowski2-21/+22
[ Upstream commit ba2a45a48503665f7e8eeec51f8b40456566b0cd ] The camera node has both unit address and children within the same bus mapping, thus needs proper ranges property to fix dtc W=1 warnings: Warning (unit_address_vs_reg): /soc/camera@11800000: node has a unit name, but no reg or ranges property Warning (simple_bus_reg): /soc/camera@11800000: missing or empty reg/ranges property Subtract 0x11800000 from all its children nodes. No functional impact expected. Link: https://lore.kernel.org/r/20230722121719.150094-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-05ARM: dts: qcom: msm8660: fix PMIC node labelsDmitry Baryshkov2-10/+10
[ Upstream commit c6d86aa8a12194d1c9c2f9108910a46c8a3ddc90 ] Change PM8058 node labels to start with pm8058_ prefix, following other Qualcomm PMIC device nodes. Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230928110309.1212221-11-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-07-10 07:44:40 +0300