summaryrefslogtreecommitdiff
path: root/arch/arm
AgeCommit message (Collapse)AuthorFilesLines
2024-06-20Merge tag 'imx-fixes-6.10' of ↵Arnd Bergmann2-3/+5
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes i.MX fixes for 6.10: - Fix GPIO number for reg_usdhc2_vmmc on imx8qm-mek board. - Enable hysteresis for SODIMM_17 pin on imx8mm-verdin board to increase immunity against noise. - Remove 'no-sdio' property for uSDHC2 on imx93-11x11-evk board, so that SDIO cards could also work. - Fix BT shutdown GPIO for imx8mp-venice-gw73xx-2x board. - Fix panel node deleting on imx53-qsb-hdmi, as /delete-node/ directive doesn't really delete a node in a DT overlay. - Fix TC9595 input clock on DH i.MX8M Plus DHCOM SoM. - Fix GPU speed for imx8mm-verdin board by enabling overdrive mode in the SOM dtsi. * tag 'imx-fixes-6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: arm64: dts: imx8qm-mek: fix gpio number for reg_usdhc2_vmmc arm64: dts: freescale: imx8mm-verdin: enable hysteresis on slow input pin arm64: dts: imx93-11x11-evk: Remove the 'no-sdio' property arm64: dts: freescale: imx8mp-venice-gw73xx-2x: fix BT shutdown GPIO arm: dts: imx53-qsb-hdmi: Disable panel instead of deleting node arm64: dts: imx8mp: Fix TC9595 input clock on DH i.MX8M Plus DHCOM SoM arm64: dts: freescale: imx8mm-verdin: Fix GPU speed Link: https://lore.kernel.org/r/Zm+xVUmFtaOnYBb4@dragon Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-06-18Merge tag 'efi-fixes-for-v6.10-3' of ↵Linus Torvalds1-0/+13
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fixes from Ard Biesheuvel: "Another small set of EFI fixes. Only the x86 one is likely to affect any actual users (and has a cc:stable), but the issue it fixes was only observed in an unusual context (kexec in a confidential VM). - Ensure that EFI runtime services are not unmapped by PAN on ARM - Avoid freeing the memory holding the EFI memory map inadvertently on x86 - Avoid a false positive kmemleak warning on arm64" * tag 'efi-fixes-for-v6.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi/arm64: Fix kmemleak false positive in arm64_efi_rt_init() efi/x86: Free EFI memory map only when installing a new one. efi/arm: Disable LPAE PAN when calling EFI runtime services
2024-06-17ARM: dts: rockchip: rk3066a: add #sound-dai-cells to hdmi nodeJohan Jonker1-0/+1
'#sound-dai-cells' is required to properly interpret the list of DAI specified in the 'sound-dai' property, so add them to the 'hdmi' node for 'rk3066a.dtsi'. Fixes: fadc78062477 ("ARM: dts: rockchip: add rk3066 hdmi nodes") Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/8b229dcc-94e4-4bbc-9efc-9d5ddd694532@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-17ARM: dts: e60k02: fix aliases for mmcAndreas Kemnade1-0/+4
Since commit fa2d0aa96941 ("mmc: core: Allow setting slot index via device tree alias") mmc numbering are changed, confusing boot scripts. Fix that by adding proper aliases Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-06-16ARM: imx_v6_v7_defconfig: enable DRM_SII902X and DRM_DISPLAY_CONNECTORDmitry Baryshkov1-0/+2
Enable the LVDS-to-HDMI bridge and the HDMI display connector drivers used on the iMX53 QSB and QSRB boards with the HDMI mezzanine. Cc: Chris Healy <cphealy@gmail.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Chris Healy <cphealy@gmail.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-06-16ARM: imx_v6_v7_defconfig: Enable drivers for TQMa7x/MBa7xAlexander Stein1-0/+5
Enable drivers for devices/features used on MBa7x. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-06-15ARM: dts: imx: Add LVDS port data mapping on M53 MenloMarek Vasut1-0/+1
Describe LVDS data mapping of the LVDS-to-DPI decoder input port. This fixes a warning reported by lvds-codec driver: " lvds-codec lvds-decoder: missing 'data-mapping' DT property " Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-06-15efi/arm: Disable LPAE PAN when calling EFI runtime servicesArd Biesheuvel1-0/+13
EFI runtime services are remapped into the lower 1 GiB of virtual address space at boot, so they are guaranteed to be able to co-exist with the kernel virtual mappings without the need to allocate space for them in the kernel's vmalloc region, which is rather small. This means those mappings are covered by TTBR0 when LPAE PAN is enabled, and so 'user' access must be enabled while such calls are in progress. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-06-15arm: dts: imx53-qsb-hdmi: Disable panel instead of deleting nodeLiu Ying2-3/+5
We cannot use /delete-node/ directive to delete a node in a DT overlay. The node won't be deleted effectively. Instead, set the node's status property to "disabled" to achieve something similar. Fixes: eeb403df953f ("ARM: dts: imx53-qsb: add support for the HDMI expander") Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-06-15ARM: dts: imx28-tx28: drop redundant 'panel-name' propertyKrzysztof Kozlowski1-6/+0
Panel timing bindings do not allow 'panel-name' and there seems to be no users of it: neither Linux kernel drivers, nor U-boot as of v2024.07-rc2. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-06-15ARM: dts: imx: drop redundant 'u-boot,panel-name' propertyKrzysztof Kozlowski2-9/+0
Panel timing bindings do not allow 'u-boot,panel-name' and there seems to be no users of it: neither Linux kernel drivers, nor U-boot as of v2024.07-rc2. Reported by dtbs_check: imx6qp-tx6qp-8037.dtb: display-timings: timing-et0700: 'u-boot,panel-name' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-06-15ARM: dts: imx6dl-aristainetos2_4: drop redundant 'power-on-delay' propertyKrzysztof Kozlowski1-1/+0
LG4573 panel bindings do not allow 'power-on-delay' property. Linux driver does not use it, either. Reported by dtbs_check: imx6dl-aristainetos2_4.dtb: display@0: Unevaluated properties are not allowed ('power-on-delay' was unexpected) Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-06-15ARM: dts: imx: correct choice of panel native modeKrzysztof Kozlowski6-6/+6
Bindings and Linux driver expect native-mode to be a phandle to one of the timings node, not a boolean property. Correct the DTS to fix dtbs_check warnings like: imx53-m53evk.dtb: display-timings: timing-800x480p60: 'native-mode' does not match any of the regexes: 'pinctrl-[0-9]+' This should not have actual effect for Linux kernel (no real bug affecting choice of native-mode), because the first timing node is chosen in absence of proper native-mode property. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-06-15ARM: dts: imx: align panel timings node name with dtschemaKrzysztof Kozlowski19-47/+47
DT schema expects panel timings node to follow certain pattern, dtbs_check warnings: imx6dl-gw54xx.dtb: display-timings: 'hsd100pxn1' does not match any of the regexes: '^timing', 'pinctrl-[0-9]+' Linux drivers do not care about node name, so this should not have effect on Linux. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-06-13ARM: dts: qcom: motorola-falcon: add accelerometer, magnetometerStanislav Jakubek1-0/+53
Add the accelerometer and magnetometer that are present on the Motorola Moto G (2013) device. Signed-off-by: Stanislav Jakubek <stano.jakubek@gmail.com> Link: https://lore.kernel.org/r/ZmWMh6fuLasvGkR/@standask-GA-A55M-S2HP Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-12ARM: dts: cirrus: align panel timings node name with dtschemaKrzysztof Kozlowski1-1/+1
DT schema expects panel timings node to follow certain pattern. Linux drivers do not care about node name, so this should not have effect on Linux. Link: https://lore.kernel.org/r/20240509104825.216696-1-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-06-12ARM: dts: vt8500: align panel timings node name with dtschemaKrzysztof Kozlowski4-4/+4
DT schema expects panel timings node to follow certain pattern, dtbs_check warnings: vt8500-bv07.dtb: display-timings: '800x480' does not match any of the regexes: '^timing', 'pinctrl-[0-9]+' Linux drivers do not care about node name, so this should not have effect on Linux. Link: https://lore.kernel.org/r/20240509104749.216605-1-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-06-12ARM: dts: vt8500: replace "uhci" nodename with generic name "usb"Mohammad Shehar Yaar Tausif5-7/+7
Replace "uhci" nodenames with "usb" as it's generic and aligns with the schema binding. Signed-off-by: Mohammad Shehar Yaar Tausif <sheharyaar48@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240423150728.91527-1-sheharyaar48@gmail.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-06-12x86, arm: Add missing license tag to syscall tables filesMarcin Juszkiewicz1-0/+1
syscall*.tbl files were added to make it easier to check which system calls are supported on each architecture and to check for their numbers. Arm and x86 files lack Linux-syscall-note license exception present in files for all other architectures. Signed-off-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: linux-arm-kernel@lists.infradead.org Link: https://lore.kernel.org/r/20240229145101.553998-1-marcin@juszkiewicz.com.pl
2024-06-10ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATIONYuntao Liu6-7/+11
The current arm32 architecture does not yet support the HAVE_LD_DEAD_CODE_DATA_ELIMINATION feature. arm32 is widely used in embedded scenarios, and enabling this feature would be beneficial for reducing the size of the kernel image. In order to make this work, we keep the necessary tables by annotating them with KEEP, also it requires further changes to linker script to KEEP some tables and wildcard compiler generated sections into the right place. When using ld.lld for linking, KEEP is not recognized within the OVERLAY command, and Ard proposed a concise method to solve this problem. It boots normally with defconfig, vexpress_defconfig and tinyconfig. The size comparison of zImage is as follows: defconfig vexpress_defconfig tinyconfig 5137712 5138024 424192 no dce 5032560 4997824 298384 dce 2.0% 2.7% 29.7% shrink When using smaller config file, there is a significant reduction in the size of the zImage. We also tested this patch on a commercially available single-board computer, and the comparison is as follows: a15eb_config 2161384 no dce 2092240 dce 3.2% shrink The zImage size has been reduced by approximately 3.2%, which is 70KB on 2.1M. Signed-off-by: Yuntao Liu <liuyuntao12@huawei.com> Tested-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-06-10ARM: 9403/1: Alpine: Spelling s/initialiing/initializing/Geert Uytterhoeven1-1/+1
Fix a misspelling of "initializing". Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-06-10ARM: 9402/1: Kconfig: Spelling s/Cortex A-/Cortex-A/Geert Uytterhoeven1-1/+1
Fix a misspelling of "Cortex-A9", to make it easier to find which errata are applicable to Cortex-A9 CPU cores. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-06-10ARM: 9400/1: Remove unused struct 'mod_unwind_map'Dr. David Alan Gilbert1-5/+0
I think this has been unused since Commit b6f21d14f1ac ("ARM: 9204/2: module: Add all unwind tables when load module") Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-06-10ARM: 9405/1: ftrace: Don't assume stack frames are contiguous in memoryArd Biesheuvel1-2/+15
The frame pointer unwinder relies on a standard layout of the stack frame, consisting of (in downward order) Calling frame: PC <---------+ LR | SP | FP | .. locals .. | Callee frame: | PC | LR | SP | FP ----------+ where after storing its previous value on the stack, FP is made to point at the location of PC in the callee stack frame, using the canonical prologue: mov ip, sp stmdb sp!, {fp, ip, lr, pc} sub fp, ip, #4 The ftrace code assumes that this activation record is pushed first, and that any stack space for locals is allocated below this. Strict adherence to this would imply that the caller's value of SP at the time of the function call can always be obtained by adding 4 to FP (which points to PC in the callee frame). However, recent versions of GCC appear to deviate from this rule, and so the only reliable way to obtain the caller's value of SP is to read it from the activation record. Since this involves a read from memory rather than simple arithmetic, we need to use the uaccess API here which protects against inadvertent data aborts resulting from attempts to dereference bogus FP values. The plain uaccess API is ftrace instrumented itself, so to avoid unbounded recursion, use the __get_kernel_nofault() primitive directly. Closes: https://lore.kernel.org/all/alp44tukzo6mvcwl4ke4ehhmojrqnv6xfcdeuliybxfjfvgd3e@gpjvwj33cc76 Closes: https://lore.kernel.org/all/d870c149-4363-43de-b0ea-7125dec5608e@broadcom.com/ Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reported-by: Justin Chen <justin.chen@broadcom.com> Tested-by: Thorsten Scherer <t.scherer@eckelmann.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-06-09ARM: configs: at91: Enable LVDS serializer supportDharma Balasubiramani1-0/+1
Enable LVDS serializer support for display pipeline. Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com> Acked-by: Hari Prasath Gujulan Elango <hari.prasathge@microchip.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20240421011050.43265-5-dharma.b@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2024-06-06ARM: dts: qcom: Add initial support for HTC One (M8)Alexandre Messier2-0/+354
Add initial device tree for the HTC One (M8) smartphone. Initial support includes: - eMMC - Power button - USB - Vibrator - Volume buttons (GPIO) - Wi-Fi Signed-off-by: Alexandre Messier <alex@me.ssier.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240603-m8-support-v1-2-c7b6a1941ed2@me.ssier.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-05ARM: dts: stm32: osd32: move pwr_regulators to commonSean Nyekjaer3-10/+5
According to the OSD32MP1 Power System overview[1] pwr_regulators; vdd-supply and vdd_3v3_usbfs-supply are hard-wired internally in the SIP module to vdd and ldo4. [1]: https://octavosystems.com/app_notes/osd32mp1-power-system-overview/#connections Signed-off-by: Sean Nyekjaer <sean@geanix.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-06-05ARM: dts: stm32: osd32: move usb phy power to commonSean Nyekjaer3-16/+8
According to the OSD32MP1 Power System overview[1] usb phy power is hard-wired internally in the SIP module to ldo4. [1]: https://octavosystems.com/app_notes/osd32mp1-power-system-overview/#connections Signed-off-by: Sean Nyekjaer <sean@geanix.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-06-05ARM: dts: stm32: Add arm,no-tick-in-suspend to STM32MP15xx STGEN timerMarek Vasut1-0/+1
STM32MP15xx RM0436 Rev 6 section 46.3 System timer generator (STGEN) states " Arm recommends that the system counter is in an always-on power domain. This is not supported in the current implementation, therefore STGEN should be saved and restored before Standby mode entry, and restored at Standby exit by secure software. ... " Instead of piling up workarounds in the firmware which is difficult to update, add "arm,no-tick-in-suspend" DT property into the timer node to indicate the timer is stopped in suspend, and let the kernel fix the timer up. Fixes: 8471a20253eb ("ARM: dts: stm32: add stm32mp157c initial support") Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-06-05ARM: dts: stm32: add goodix touchscreen on stm32mp135f-dkYannick Fertre2-0/+36
Touchscreen reset needs to be configured via the pinctrl not the driver (a pull-down resistor has been soldered onto the reset line which forces the touchscreen to reset state). Interrupt line must have a pull-down resistor in order to freeze the i2c address at 0x5D. Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-06-05ARM: dts: stm32: enable camera support on stm32mp135f-dk boardAlain Volmat1-0/+87
On STM32MP135F-DK board the camera support is made of the CSI based GC2145 sensor, connected to the ST-MIPID02 CSI to parallel bridge, connected to the DCMIPP parallel input. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-06-05ARM: dts: stm32: add DCMIPP pinctrl on STM32MP13x SoC familyAlain Volmat1-0/+33
Adds DCMIPP pinctrl support and assigns dedicated GPIO pins. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-06-04ARM: dts: qcom: msm8974: Use mboxes properties for APCSLuca Weiss1-7/+7
Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240424-apcs-mboxes-v1-2-6556c47cb501@z3ntu.xyz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-03ARM: dts: sunxi: remove duplicated entries in makefilePavel Löbl1-62/+0
During introduction of DTS vendor subdirectories in 724ba6751532, sun8i section of the makefile got duplicated. Clean that up. Fixes: 724ba6751532 ("ARM: dts: Move .dts files to vendor sub-directories") Signed-off-by: Pavel Löbl <pavel@loebl.cz> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Link: https://lore.kernel.org/r/20240320061027.4078852-1-pavel@loebl.cz Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2024-06-01ARM: dts: qcom: mdm9615: drop #power-domain-cells property of GCCDmitry Baryshkov1-1/+0
On MDM9615 the Global Clock Controller (GCC) doesn't provide power domains. Drop the #power-domain-cells property from the controller device node. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240529-qcom-gdscs-v2-9-69c63d0ae1e7@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-01ARM: dts: qcom: ipq8064: drop #power-domain-cells property of GCCDmitry Baryshkov1-1/+0
On IPQ8064 the Global Clock Controller (GCC) doesn't provide power domains. Drop the #power-domain-cells property from the controller device node. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240529-qcom-gdscs-v2-8-69c63d0ae1e7@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-01ARM: dts: qcom: ipq4019: drop #power-domain-cells property of GCCDmitry Baryshkov1-1/+0
On IPQ4019 the Global Clock Controller (GCC) doesn't provide power domains. Drop the #power-domain-cells property from the controller device node. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240529-qcom-gdscs-v2-7-69c63d0ae1e7@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-01ARM: dts: qcom: msm8960: drop #power-domain-cells property of GCCDmitry Baryshkov1-1/+0
On MSM8960 the Global Clock Controller (GCC) doesn't provide power domains. Drop the #power-domain-cells property from the controller device node. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240529-qcom-gdscs-v2-6-69c63d0ae1e7@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-01ARM: dts: qcom: msm8660: drop #power-domain-cells property of GCCDmitry Baryshkov1-1/+0
On MSM8660 the Global Clock Controller (GCC) doesn't provide power domains. Drop the #power-domain-cells property from the controller device node. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240529-qcom-gdscs-v2-5-69c63d0ae1e7@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-01ARM: dts: qcom: apq8064: drop #power-domain-cells property of GCCDmitry Baryshkov1-1/+0
On APQ8064 the Global Clock Controller (GCC) doesn't provide power domains. Drop the #power-domain-cells property from the controller device node. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240529-qcom-gdscs-v2-4-69c63d0ae1e7@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-05-30arm: vexpress: Remove obsolete RTSM DCSCB supportRob Herring (Arm)5-219/+0
The Arm Versatile DCSCB support is unused as the compatible "arm,rtsm,dcscb" is unused in any .dts file. It was only ever implemented on a s/w model (RTSM). Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240510123238.3904779-1-robh@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-05-28ARM: dts: qcom: msm8974: Use proper compatible for APCS sysconLuca Weiss1-2/+4
Use the apcs-kpss-global compatible for the APCS global mailbox block found on this SoC. This also resolves a dt-binding checker warning: arch/arm/boot/dts/qcom/qcom-msm8974pro-fairphone-fp2.dtb: syscon@f9011000: compatible: 'anyOf' conditional failed, one must be fixed: ['syscon'] is too short 'syscon' is not one of ['allwinner,sun8i-a83t-system-controller', 'allwinner,sun8i-h3-system-controller', 'allwinner,sun8i-v3s-system-controller', 'allwinner,sun50i-a64-system-controller', 'amd,pensando-elba-syscon', 'brcm,cru-clkset', 'freecom,fsg-cs2-system-controller', 'fsl,imx93-aonmix-ns-syscfg', 'fsl,imx93-wakeupmix-syscfg', 'hisilicon,dsa-subctrl', 'hisilicon,hi6220-sramctrl', 'hisilicon,pcie-sas-subctrl', 'hisilicon,peri-subctrl', 'hpe,gxp-sysreg', 'intel,lgm-syscon', 'loongson,ls1b-syscon', 'loongson,ls1c-syscon', 'marvell,armada-3700-usb2-host-misc', 'mediatek,mt8135-pctl-a-syscfg', 'mediatek,mt8135-pctl-b-syscfg', 'mediatek,mt8365-syscfg', 'microchip,lan966x-cpu-syscon', 'microchip,sparx5-cpu-syscon', 'mstar,msc313-pmsleep', 'nuvoton,ma35d1-sys', 'nuvoton,wpcm450-shm', 'rockchip,px30-qos', 'rockchip,rk3036-qos', 'rockchip,rk3066-qos', 'rockchip,rk3128-qos', 'rockchip,rk3228-qos', 'rockchip,rk3288-qos', 'rockchip,rk3368-qos', 'rockchip,rk3399-qos', 'rockchip,rk356 8-qos', 'rockchip,rk3588-qos', 'rockchip,rv1126-qos', 'starfive,jh7100-sysmain', 'ti,am62-usb-phy-ctrl', 'ti,am654-dss-oldi-io-ctrl', 'ti,am654-serdes-ctrl', 'ti,j784s4-pcie-ctrl'] from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml# Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20240408-msm8974-apcs-v1-2-90cb7368836e@z3ntu.xyz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-05-28ARM: dts: qcom: msm8974-hammerhead: Update gpio hog node nameLuca Weiss1-1/+1
Follow the gpio-hog bindings and use otg-hog as node name. Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20240409-qcom-pmic-gpio-hog-v2-2-5ff812d2baed@z3ntu.xyz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-05-28ARM: dts: renesas: r9a06g032: Describe GMAC1Clément Léger1-0/+18
The r9a06g032 SoC of the RZ/N1 family features two GMAC devices named GMAC1/2, that are based on Synopsys cores. GMAC1 is connected to a RGMII/RMII converter that is already described in this device tree. Signed-off-by: Clément Léger <clement.leger@bootlin.com> [rgantois: commit log] Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Romain Gantois <romain.gantois@bootlin.com> Link: https://lore.kernel.org/r/20240513-rzn1-gmac1-v7-7-6acf58b5440d@bootlin.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-05-27ARM: dts: qcom: msm8974: Add Samsung Galaxy Note 3Adam Honse2-0/+402
Add the devicetree for this "phablet" using the Snapdragon 800 SoC. Signed-off-by: Adam Honse <calcprogrammer1@gmail.com> [luca@z3ntu.xyz: clean up, prepare for upstream] Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240314-samsung-hlte-v2-2-84094b41c033@z3ntu.xyz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-05-27ARM: dts: qcom: msm8974-hammerhead: Hook up backlightLuca Weiss1-1/+3
Connect the panel with the backlight nodes so that the backlight can be turned off when the display is blanked. Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Link: https://lore.kernel.org/r/20240220-lm3630a-fixups-v1-4-9ca62f7e4a33@z3ntu.xyz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-05-27ARM: dts: qcom: Add support for Samsung Galaxy Tab 4 8.0 Wi-FiBryant Mairs2-0/+574
Add support for this tablet based on the MSM8226 SoC, codenamed "milletwifi". Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Luca Weiss <luca@z3ntu.xyz> Signed-off-by: Bryant Mairs <bryant@mai.rs> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240219214643.197116-3-bryant@mai.rs Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-05-27ARM: dts: qcom: msm8226-microsoft-common: Enable smbb explicitlyRayyan Ansari1-0/+4
Enable the smbb node explicitly for MSM8x26 Lumia devices. These devices rely on the smbb driver in order to detect USB state. It seems that this was accidentally missed in the commit that this fixes. Fixes: c9c8179d0ccd ("ARM: dts: qcom: Disable pm8941 & pm8226 smbb charger by default") Signed-off-by: Rayyan Ansari <rayyan@ansari.sh> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240424174206.4220-1-rayyan@ansari.sh Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-05-24mseal: wire up mseal syscallJeff Xu1-0/+1
Patch series "Introduce mseal", v10. This patchset proposes a new mseal() syscall for the Linux kernel. In a nutshell, mseal() protects the VMAs of a given virtual memory range against modifications, such as changes to their permission bits. Modern CPUs support memory permissions, such as the read/write (RW) and no-execute (NX) bits. Linux has supported NX since the release of kernel version 2.6.8 in August 2004 [1]. The memory permission feature improves the security stance on memory corruption bugs, as an attacker cannot simply write to arbitrary memory and point the code to it. The memory must be marked with the X bit, or else an exception will occur. Internally, the kernel maintains the memory permissions in a data structure called VMA (vm_area_struct). mseal() additionally protects the VMA itself against modifications of the selected seal type. Memory sealing is useful to mitigate memory corruption issues where a corrupted pointer is passed to a memory management system. For example, such an attacker primitive can break control-flow integrity guarantees since read-only memory that is supposed to be trusted can become writable or .text pages can get remapped. Memory sealing can automatically be applied by the runtime loader to seal .text and .rodata pages and applications can additionally seal security critical data at runtime. A similar feature already exists in the XNU kernel with the VM_FLAGS_PERMANENT [3] flag and on OpenBSD with the mimmutable syscall [4]. Also, Chrome wants to adopt this feature for their CFI work [2] and this patchset has been designed to be compatible with the Chrome use case. Two system calls are involved in sealing the map: mmap() and mseal(). The new mseal() is an syscall on 64 bit CPU, and with following signature: int mseal(void addr, size_t len, unsigned long flags) addr/len: memory range. flags: reserved. mseal() blocks following operations for the given memory range. 1> Unmapping, moving to another location, and shrinking the size, via munmap() and mremap(), can leave an empty space, therefore can be replaced with a VMA with a new set of attributes. 2> Moving or expanding a different VMA into the current location, via mremap(). 3> Modifying a VMA via mmap(MAP_FIXED). 4> Size expansion, via mremap(), does not appear to pose any specific risks to sealed VMAs. It is included anyway because the use case is unclear. In any case, users can rely on merging to expand a sealed VMA. 5> mprotect() and pkey_mprotect(). 6> Some destructive madvice() behaviors (e.g. MADV_DONTNEED) for anonymous memory, when users don't have write permission to the memory. Those behaviors can alter region contents by discarding pages, effectively a memset(0) for anonymous memory. The idea that inspired this patch comes from Stephen Röttger’s work in V8 CFI [5]. Chrome browser in ChromeOS will be the first user of this API. Indeed, the Chrome browser has very specific requirements for sealing, which are distinct from those of most applications. For example, in the case of libc, sealing is only applied to read-only (RO) or read-execute (RX) memory segments (such as .text and .RELRO) to prevent them from becoming writable, the lifetime of those mappings are tied to the lifetime of the process. Chrome wants to seal two large address space reservations that are managed by different allocators. The memory is mapped RW- and RWX respectively but write access to it is restricted using pkeys (or in the future ARM permission overlay extensions). The lifetime of those mappings are not tied to the lifetime of the process, therefore, while the memory is sealed, the allocators still need to free or discard the unused memory. For example, with madvise(DONTNEED). However, always allowing madvise(DONTNEED) on this range poses a security risk. For example if a jump instruction crosses a page boundary and the second page gets discarded, it will overwrite the target bytes with zeros and change the control flow. Checking write-permission before the discard operation allows us to control when the operation is valid. In this case, the madvise will only succeed if the executing thread has PKEY write permissions and PKRU changes are protected in software by control-flow integrity. Although the initial version of this patch series is targeting the Chrome browser as its first user, it became evident during upstream discussions that we would also want to ensure that the patch set eventually is a complete solution for memory sealing and compatible with other use cases. The specific scenario currently in mind is glibc's use case of loading and sealing ELF executables. To this end, Stephen is working on a change to glibc to add sealing support to the dynamic linker, which will seal all non-writable segments at startup. Once this work is completed, all applications will be able to automatically benefit from these new protections. In closing, I would like to formally acknowledge the valuable contributions received during the RFC process, which were instrumental in shaping this patch: Jann Horn: raising awareness and providing valuable insights on the destructive madvise operations. Liam R. Howlett: perf optimization. Linus Torvalds: assisting in defining system call signature and scope. Theo de Raadt: sharing the experiences and insight gained from implementing mimmutable() in OpenBSD. MM perf benchmarks ================== This patch adds a loop in the mprotect/munmap/madvise(DONTNEED) to check the VMAs’ sealing flag, so that no partial update can be made, when any segment within the given memory range is sealed. To measure the performance impact of this loop, two tests are developed. [8] The first is measuring the time taken for a particular system call, by using clock_gettime(CLOCK_MONOTONIC). The second is using PERF_COUNT_HW_REF_CPU_CYCLES (exclude user space). Both tests have similar results. The tests have roughly below sequence: for (i = 0; i < 1000, i++) create 1000 mappings (1 page per VMA) start the sampling for (j = 0; j < 1000, j++) mprotect one mapping stop and save the sample delete 1000 mappings calculates all samples. Below tests are performed on Intel(R) Pentium(R) Gold 7505 @ 2.00GHz, 4G memory, Chromebook. Based on the latest upstream code: The first test (measuring time) syscall__ vmas t t_mseal delta_ns per_vma % munmap__ 1 909 944 35 35 104% munmap__ 2 1398 1502 104 52 107% munmap__ 4 2444 2594 149 37 106% munmap__ 8 4029 4323 293 37 107% munmap__ 16 6647 6935 288 18 104% munmap__ 32 11811 12398 587 18 105% mprotect 1 439 465 26 26 106% mprotect 2 1659 1745 86 43 105% mprotect 4 3747 3889 142 36 104% mprotect 8 6755 6969 215 27 103% mprotect 16 13748 14144 396 25 103% mprotect 32 27827 28969 1142 36 104% madvise_ 1 240 262 22 22 109% madvise_ 2 366 442 76 38 121% madvise_ 4 623 751 128 32 121% madvise_ 8 1110 1324 215 27 119% madvise_ 16 2127 2451 324 20 115% madvise_ 32 4109 4642 534 17 113% The second test (measuring cpu cycle) syscall__ vmas cpu cmseal delta_cpu per_vma % munmap__ 1 1790 1890 100 100 106% munmap__ 2 2819 3033 214 107 108% munmap__ 4 4959 5271 312 78 106% munmap__ 8 8262 8745 483 60 106% munmap__ 16 13099 14116 1017 64 108% munmap__ 32 23221 24785 1565 49 107% mprotect 1 906 967 62 62 107% mprotect 2 3019 3203 184 92 106% mprotect 4 6149 6569 420 105 107% mprotect 8 9978 10524 545 68 105% mprotect 16 20448 21427 979 61 105% mprotect 32 40972 42935 1963 61 105% madvise_ 1 434 497 63 63 115% madvise_ 2 752 899 147 74 120% madvise_ 4 1313 1513 200 50 115% madvise_ 8 2271 2627 356 44 116% madvise_ 16 4312 4883 571 36 113% madvise_ 32 8376 9319 943 29 111% Based on the result, for 6.8 kernel, sealing check adds 20-40 nano seconds, or around 50-100 CPU cycles, per VMA. In addition, I applied the sealing to 5.10 kernel: The first test (measuring time) syscall__ vmas t tmseal delta_ns per_vma % munmap__ 1 357 390 33 33 109% munmap__ 2 442 463 21 11 105% munmap__ 4 614 634 20 5 103% munmap__ 8 1017 1137 120 15 112% munmap__ 16 1889 2153 263 16 114% munmap__ 32 4109 4088 -21 -1 99% mprotect 1 235 227 -7 -7 97% mprotect 2 495 464 -30 -15 94% mprotect 4 741 764 24 6 103% mprotect 8 1434 1437 2 0 100% mprotect 16 2958 2991 33 2 101% mprotect 32 6431 6608 177 6 103% madvise_ 1 191 208 16 16 109% madvise_ 2 300 324 24 12 108% madvise_ 4 450 473 23 6 105% madvise_ 8 753 806 53 7 107% madvise_ 16 1467 1592 125 8 108% madvise_ 32 2795 3405 610 19 122% The second test (measuring cpu cycle) syscall__ nbr_vma cpu cmseal delta_cpu per_vma % munmap__ 1 684 715 31 31 105% munmap__ 2 861 898 38 19 104% munmap__ 4 1183 1235 51 13 104% munmap__ 8 1999 2045 46 6 102% munmap__ 16 3839 3816 -23 -1 99% munmap__ 32 7672 7887 216 7 103% mprotect 1 397 443 46 46 112% mprotect 2 738 788 50 25 107% mprotect 4 1221 1256 35 9 103% mprotect 8 2356 2429 72 9 103% mprotect 16 4961 4935 -26 -2 99% mprotect 32 9882 10172 291 9 103% madvise_ 1 351 380 29 29 108% madvise_ 2 565 615 49 25 109% madvise_ 4 872 933 61 15 107% madvise_ 8 1508 1640 132 16 109% madvise_ 16 3078 3323 245 15 108% madvise_ 32 5893 6704 811 25 114% For 5.10 kernel, sealing check adds 0-15 ns in time, or 10-30 CPU cycles, there is even decrease in some cases. It might be interesting to compare 5.10 and 6.8 kernel The first test (measuring time) syscall__ vmas t_5_10 t_6_8 delta_ns per_vma % munmap__ 1 357 909 552 552 254% munmap__ 2 442 1398 956 478 316% munmap__ 4 614 2444 1830 458 398% munmap__ 8 1017 4029 3012 377 396% munmap__ 16 1889 6647 4758 297 352% munmap__ 32 4109 11811 7702 241 287% mprotect 1 235 439 204 204 187% mprotect 2 495 1659 1164 582 335% mprotect 4 741 3747 3006 752 506% mprotect 8 1434 6755 5320 665 471% mprotect 16 2958 13748 10790 674 465% mprotect 32 6431 27827 21397 669 433% madvise_ 1 191 240 49 49 125% madvise_ 2 300 366 67 33 122% madvise_ 4 450 623 173 43 138% madvise_ 8 753 1110 357 45 147% madvise_ 16 1467 2127 660 41 145% madvise_ 32 2795 4109 1314 41 147% The second test (measuring cpu cycle) syscall__ vmas cpu_5_10 c_6_8 delta_cpu per_vma % munmap__ 1 684 1790 1106 1106 262% munmap__ 2 861 2819 1958 979 327% munmap__ 4 1183 4959 3776 944 419% munmap__ 8 1999 8262 6263 783 413% munmap__ 16 3839 13099 9260 579 341% munmap__ 32 7672 23221 15549 486 303% mprotect 1 397 906 509 509 228% mprotect 2 738 3019 2281 1140 409% mprotect 4 1221 6149 4929 1232 504% mprotect 8 2356 9978 7622 953 423% mprotect 16 4961 20448 15487 968 412% mprotect 32 9882 40972 31091 972 415% madvise_ 1 351 434 82 82 123% madvise_ 2 565 752 186 93 133% madvise_ 4 872 1313 442 110 151% madvise_ 8 1508 2271 763 95 151% madvise_ 16 3078 4312 1234 77 140% madvise_ 32 5893 8376 2483 78 142% From 5.10 to 6.8 munmap: added 250-550 ns in time, or 500-1100 in cpu cycle, per vma. mprotect: added 200-750 ns in time, or 500-1200 in cpu cycle, per vma. madvise: added 33-50 ns in time, or 70-110 in cpu cycle, per vma. In comparison to mseal, which adds 20-40 ns or 50-100 CPU cycles, the increase from 5.10 to 6.8 is significantly larger, approximately ten times greater for munmap and mprotect. When I discuss the mm performance with Brian Makin, an engineer who worked on performance, it was brought to my attention that such performance benchmarks, which measuring millions of mm syscall in a tight loop, may not accurately reflect real-world scenarios, such as that of a database service. Also this is tested using a single HW and ChromeOS, the data from another HW or distribution might be different. It might be best to take this data with a grain of salt. This patch (of 5): Wire up mseal syscall for all architectures. Link: https://lkml.kernel.org/r/20240415163527.626541-1-jeffxu@chromium.org Link: https://lkml.kernel.org/r/20240415163527.626541-2-jeffxu@chromium.org Signed-off-by: Jeff Xu <jeffxu@chromium.org> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Guenter Roeck <groeck@chromium.org> Cc: Jann Horn <jannh@google.com> [Bug #2] Cc: Jeff Xu <jeffxu@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Jorge Lucangeli Obes <jorgelo@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Muhammad Usama Anjum <usama.anjum@collabora.com> Cc: Pedro Falcato <pedro.falcato@gmail.com> Cc: Stephen Röttger <sroettger@google.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Amer Al Shanawany <amer.shanawany@gmail.com> Cc: Javier Carrasco <javier.carrasco.cruz@gmail.com> Cc: Shuah Khan <shuah@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-05-23Merge tag 'mm-nonmm-stable-2024-05-22-17-30' of ↵Linus Torvalds3-2/+23
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull more non-mm updates from Andrew Morton: - A series ("kbuild: enable more warnings by default") from Arnd Bergmann which enables a number of additional build-time warnings. We fixed all the fallout which we could find, there may still be a few stragglers. - Samuel Holland has developed the series "Unified cross-architecture kernel-mode FPU API". This does a lot of consolidation of per-architecture kernel-mode FPU usage and enables the use of newer AMD GPUs on RISC-V. - Tao Su has fixed some selftests build warnings in the series "Selftests: Fix compilation warnings due to missing _GNU_SOURCE definition". - This pull also includes a nilfs2 fixup from Ryusuke Konishi. * tag 'mm-nonmm-stable-2024-05-22-17-30' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (23 commits) nilfs2: make block erasure safe in nilfs_finish_roll_forward() selftests/harness: use 1024 in place of LINE_MAX Revert "selftests/harness: remove use of LINE_MAX" selftests/fpu: allow building on other architectures selftests/fpu: move FP code to a separate translation unit drm/amd/display: use ARCH_HAS_KERNEL_FPU_SUPPORT drm/amd/display: only use hard-float, not altivec on powerpc riscv: add support for kernel-mode FPU x86: implement ARCH_HAS_KERNEL_FPU_SUPPORT powerpc: implement ARCH_HAS_KERNEL_FPU_SUPPORT LoongArch: implement ARCH_HAS_KERNEL_FPU_SUPPORT lib/raid6: use CC_FLAGS_FPU for NEON CFLAGS arm64: crypto: use CC_FLAGS_FPU for NEON CFLAGS arm64: implement ARCH_HAS_KERNEL_FPU_SUPPORT ARM: crypto: use CC_FLAGS_FPU for NEON CFLAGS ARM: implement ARCH_HAS_KERNEL_FPU_SUPPORT arch: add ARCH_HAS_KERNEL_FPU_SUPPORT x86/fpu: fix asm/fpu/types.h include guard kbuild: enable -Wcast-function-type-strict unconditionally kbuild: enable -Wformat-truncation on clang ...