summaryrefslogtreecommitdiff
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2024-04-13arm64: dts: rockchip: fix rk3399 hdmi ports nodeJohan Jonker1-2/+10
[ Upstream commit f051b6ace7ffcc48d6d1017191f167c0a85799f6 ] Fix rk3399 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/a6ab6f75-3b80-40b1-bd30-3113e14becdd@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-13arm64: dts: rockchip: fix rk3328 hdmi ports nodeJohan Jonker1-1/+10
[ Upstream commit 1d00ba4700d1e0f88ae70d028d2e17e39078fa1c ] Fix rk3328 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/e5dea3b7-bf84-4474-9530-cc2da3c41104@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-10arm64: dts: qcom: sc7180-trogdor: mark bluetooth address as brokenJohan Hovold1-0/+2
commit e12e28009e584c8f8363439f6a928ec86278a106 upstream. Several Qualcomm Bluetooth controllers lack persistent storage for the device address and instead one can be provided by the boot firmware using the 'local-bd-address' devicetree property. The Bluetooth bindings clearly states that the address should be specified in little-endian order, but due to a long-standing bug in the Qualcomm driver which reversed the address some boot firmware has been providing the address in big-endian order instead. The boot firmware in SC7180 Trogdor Chromebooks is known to be affected so mark the 'local-bd-address' property as broken to maintain backwards compatibility with older firmware when fixing the underlying driver bug. Note that ChromeOS always updates the kernel and devicetree in lockstep so that there is no need to handle backwards compatibility with older devicetrees. Fixes: 7ec3e67307f8 ("arm64: dts: qcom: sc7180-trogdor: add initial trogdor and lazor dt") Cc: stable@vger.kernel.org # 5.10 Cc: Rob Clark <robdclark@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Acked-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-03arm64: dts: qcom: sc7280: Add additional MSI interruptsKrishna chaitanya chundru1-2/+10
[ Upstream commit b8ba66b40da3230a8675cb5dd5c2dea5bce24d62 ] Current MSI's mapping doesn't have all the vectors. This platform supports 8 vectors each vector supports 32 MSI's, so total MSI's supported is 256. Add all the MSI groups supported for this PCIe instance in this platform. Fixes: 92e0ee9f83b3 ("arm64: dts: qcom: sc7280: Add PCIe and PHY related nodes") cc: stable@vger.kernel.org Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> Link: https://lore.kernel.org/r/20231218-additional_msi-v1-1-de6917392684@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: broadcom: bcmbca: bcm4908: drop invalid switch cellsRafał Miłecki1-3/+0
[ Upstream commit 27058b95fbb784406ea4c40b20caa3f04937140c ] Ethernet switch does not have addressable subnodes. This fixes: arch/arm64/boot/dts/broadcom/bcmbca/bcm4908-asus-gt-ac5300.dtb: ethernet-switch@0: '#address-cells', '#size-cells' do not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/net/dsa/brcm,sf2.yaml# Fixes: 527a3ac9bdf8 ("arm64: dts: broadcom: bcm4908: describe internal switch") Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20240111115636.12095-1-zajec5@gmail.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: rockchip: add missing interrupt-names for rk356x vdpuHeiko Stuebner1-0/+1
[ Upstream commit d1c44d9afa6f89aa0e10a191f30868eb12cd719f ] The video-codec@fdea0400 was missing the interrupt-names property that is part of the binding. Add it. Fixes: 944be6fba401 ("arm64: dts: rockchip: Add VPU support for RK3568/RK3566") Cc: Piotr Oniszczuk <piotr.oniszczuk@gmail.com> Acked-by: Uwe Kleine-König <ukleinek@debian.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20240227173526.710056-1-heiko@sntech.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: marvell: reorder crypto interrupts on Armada SoCsRafał Miłecki2-10/+10
[ Upstream commit ec55a22149d64f9ac41845d923b884d4a666bf4d ] Match order specified in binding documentation. It says "mem" should be the last interrupt. This fixes: arch/arm64/boot/dts/marvell/armada-3720-db.dtb: crypto@90000: interrupt-names:0: 'ring0' was expected from schema $id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml# arch/arm64/boot/dts/marvell/armada-3720-db.dtb: crypto@90000: interrupt-names:1: 'ring1' was expected from schema $id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml# arch/arm64/boot/dts/marvell/armada-3720-db.dtb: crypto@90000: interrupt-names:2: 'ring2' was expected from schema $id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml# arch/arm64/boot/dts/marvell/armada-3720-db.dtb: crypto@90000: interrupt-names:3: 'ring3' was expected from schema $id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml# arch/arm64/boot/dts/marvell/armada-3720-db.dtb: crypto@90000: interrupt-names:4: 'eip' was expected from schema $id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml# arch/arm64/boot/dts/marvell/armada-3720-db.dtb: crypto@90000: interrupt-names:5: 'mem' was expected from schema $id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml# Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: allwinner: h6: Add RX DMA channel for SPDIFChen-Yu Tsai3-4/+7
[ Upstream commit 7b59348c11f3355e284d77bbe3d33632ddadcfc2 ] The SPDIF hardware found on the H6 supports both transmit and receive functions. However it is missing the RX DMA channel. Add the SPDIF hardware block's RX DMA channel. Also remove the by-default pinmux, since the end device can choose to implement either or both functionalities. Fixes: f95b598df419 ("arm64: dts: allwinner: Add SPDIF node for Allwinner H6") Signed-off-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20240127163247.384439-6-wens@kernel.org Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: renesas: r8a779g0: Correct avb[01] reg sizesGeert Uytterhoeven1-2/+2
[ Upstream commit 7edbb5880dc3317a5eaec2166de71ff394598e6b ] All Ethernet AVB instances on R-Car V4H have registers related to UDP/IP support, but the declared register blocks for the first two instances are too small to cover them. Fix this by extending the register block sizes. Fixes: 848c82db56923a8b ("arm64: dts: renesas: r8a779g0: Add RAVB nodes") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/83437778614a7c96f4d8f1be98dffeee29bb4a0b.1707660323.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: renesas: r8a779a0: Correct avb[01] reg sizesGeert Uytterhoeven1-2/+2
[ Upstream commit 0c51912331f8ba5ce5fb52f46e340945160672a3 ] All Ethernet AVB instances on R-Car V3U have registers related to UDP/IP support, but the declared register blocks for the first two instances are too small to cover them. Fix this by extending the register block sizes. Fixes: 5a633320f08b8c9b ("arm64: dts: renesas: r8a779a0: Add Ethernet-AVB support") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/ce6ce3c4b1495e02e7c1803fca810a7178a84500.1707660323.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: renesas: r8a779a0: Update to R-Car Gen4 compatible valuesGeert Uytterhoeven1-12/+12
[ Upstream commit a1ca409cc050166a9e8ed183c1d4192f511cf6a2 ] Despite the name, R-Car V3U is the first member of the R-Car Gen4 family. Hence update the compatible properties in various device nodes to include family-specific compatible values for R-Car Gen4 instead of R-Car Gen3: - EtherAVB, - MSIOF. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/387168aef20d399d4f4318f4ecab9c3b016fd6f2.1666605756.git.geert+renesas@glider.be Stable-dep-of: 0c51912331f8 ("arm64: dts: renesas: r8a779a0: Correct avb[01] reg sizes") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: renesas: rzg2l: Add missing interrupts to IRQC nodesLad Prabhakar3-4/+52
[ Upstream commit 14fe225dd5fcd5928583b0bcc34398a581f51602 ] The IRQC IP block supports Bus error and ECCRAM interrupts on RZ/G2L and alike SoC's (listed below). Update the IRQC nodes with the missing interrupts, and additionally, include the 'interrupt-names' properties in the IRQC nodes so that the driver can parse interrupts by name. - R9A07G043U - RZ/G2UL - R9A07G044L/R9A07G044LC - RZ/{G2L,G2LC} - R9A07G054 - RZ/V2L Fixes: 5edc51af5b30 ("arm64: dts: renesas: r9a07g044: Add IRQC node") Fixes: 48ab6eddd8bb ("arm64: dts: renesas: r9a07g043u: Add IRQC node") Fixes: 379478ab09e0 ("arm64: dts: renesas: r9a07g054: Add IRQC node") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20240205144421.51195-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: renesas: r9a07g043u: Add IRQC nodeLad Prabhakar1-0/+68
[ Upstream commit 48ab6eddd8bbcf7e9c8ae27bf42d0b52a777aaba ] Add IRQC node to R9A07G043 (RZ/G2UL) SoC DTSI. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230102221815.273719-5-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Stable-dep-of: 14fe225dd5fc ("arm64: dts: renesas: rzg2l: Add missing interrupts to IRQC nodes") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: renesas: r9a07g043: Split out RZ/G2UL SoC specific partsLad Prabhakar2-53/+61
[ Upstream commit b9a0be2054964026aa58966ce9724b672f210835 ] Move RZ/G2UL SoC specific parts to r9a07g043u.dtsi so that r9a07g043.dtsi can be shared with RZ/Five (RISC-V SoC). Below are the changes due to which SoC specific parts are moved to r9a07g043u.dtsi: - RZ/G2UL has Cortex-A55 (ARM64) whereas RZ/Five has AX45MP (RISC-V), - RZ/G2UL has GICv3 as interrupt controller whereas RZ/Five has PLIC, - RZ/G2UL has interrupts for SYSC block whereas interrupts are missing for SYSC block on RZ/Five, - RZ/G2UL has armv8-timer whereas RZ/Five has riscv-timer, - RZ/G2UL has PSCI whereas RZ/Five have OpenSBI. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20221025220629.79321-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Stable-dep-of: 14fe225dd5fc ("arm64: dts: renesas: rzg2l: Add missing interrupts to IRQC nodes") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: mt8195-cherry-tomato: change watchdog reset boot flowHsin-Te Yuan3-0/+12
[ Upstream commit ef569d5db50e7edd709e482157769a5b3c367e22 ] The external output reset signal was originally disabled and sent from firmware. However, an unfixed bug in the firmware on tomato prevents the signal from being sent, causing the device to fail to boot. To fix this, enable external output reset signal to allow the device to reboot normally. Fixes: 5eb2e303ec6b ("arm64: dts: mediatek: Introduce MT8195 Cherry platform's Tomato") Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240124-send-upstream-v3-1-5097c9862a73@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: qcom: sm8150: correct PCIe wake-gpiosKrzysztof Kozlowski1-1/+1
[ Upstream commit 7c38989d0f7a35c83e7c4781271d42662903fa8d ] Bindings allow a "wake", not "enable", GPIO. Schematics also use WAKE name for the pin: sa8155p-adp.dtb: pcie@1c00000: Unevaluated properties are not allowed ('enable-gpio' was unexpected) Fixes: a1c86c680533 ("arm64: dts: qcom: sm8150: Add PCIe nodes") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240108131216.53867-2-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: qcom: sm8150: use 'gpios' suffix for PCI GPIOsKrzysztof Kozlowski1-2/+2
[ Upstream commit af6f6778d34cb40e60368e288767f674cc0c5f60 ] Linux handles both versions, but bindings expect GPIO properties to have 'gpios' suffix instead of 'gpio': sa8155p-adp.dtb: pci@1c00000: Unevaluated properties are not allowed ('perst-gpio' was unexpected) Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231111164229.63803-3-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Stable-dep-of: 7c38989d0f7a ("arm64: dts: qcom: sm8150: correct PCIe wake-gpios") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: qcom: sdm845-db845c: correct PCIe wake-gpiosKrzysztof Kozlowski1-1/+1
[ Upstream commit 584a327c5cffc36369b2a8953d9448826240f1ac ] Bindings allow a "wake", not "enable", GPIO. Schematics also use WAKE name for the pin: sdm845-db845c.dtb: pcie@1c00000: Unevaluated properties are not allowed ('enable-gpio' was unexpected) Fixes: 4a657c264b78 ("arm64: dts: qcom: db845c: Enable PCIe controllers") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240108131216.53867-1-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: mediatek: mt7622: add missing "device_type" to memory nodesRafał Miłecki2-0/+2
[ Upstream commit 99d100e00144bc01b49a697f4bc4398f2f7e7ce4 ] This fixes: arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: /: memory@40000000: 'device_type' is a required property from schema $id: http://devicetree.org/schemas/memory.yaml# arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dtb: /: memory@40000000: 'device_type' is a required property from schema $id: http://devicetree.org/schemas/memory.yaml# Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240122132357.31264-1-zajec5@gmail.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: mediatek: mt8192: fix vencoder clock nameEugen Hristev1-1/+1
[ Upstream commit 76aac0f2a46847ed4a7a4fdd848dd66023c19ad1 ] Clock name should be `venc_sel` as per binding. Fix the warning message : arch/arm64/boot/dts/mediatek/mt8192-asurada-hayato-r1.dtb: vcodec@17020000: clock-names:0: 'venc_sel' was expected from schema $id: http://devicetree.org/schemas/media/mediatek,vcodec-encoder.yaml# Fixes: aa8f3711fc87 ("arm64: dts: mt8192: Add H264 venc device node") Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231228113245.174706-4-eugen.hristev@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: mediatek: mt8192-asurada: Remove CrosEC base detection nodeNícolas F. R. A. Prado1-4/+0
[ Upstream commit 9b49cabe631b0a25aaf8fc2ba81b5b9ea6ff01b7 ] The commit adding the ChromeOS EC to the Asurada Devicetree mistakenly added a base detection node. While tablet mode detection is supported by CrosEC and used by Hayato, it is done through the cros-ec-keyb driver. The base detection node, which is handled by the hid-google-hammer driver, also provides tablet mode detection but by checking base attachment status on the CrosEC, which is not supported for Asurada. Hence, remove the unused CrosEC base detection node for Asurada. Fixes: eb188a2aaa82 ("arm64: dts: mediatek: asurada: Add ChromeOS EC") Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20240207-mt8192-asurada-cbas-remove-v1-1-04cb65951975@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: mediatek: mt7986: add "#reset-cells" to infracfgRafał Miłecki1-0/+1
[ Upstream commit d993daff5962b2dd08f32a83bb1c0e5fa75732ea ] MT7986's Infrastructure System Configuration Controller includes reset controller. It can reset blocks as specified in the include/dt-bindings/reset/mt7986-resets.h . Add #reset-cells so it can be referenced properly. This fixes: arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: infracfg@10001000: '#reset-cells' is a required property from schema $id: http://devicetree.org/schemas/arm/mediatek/mediatek,infracfg.yaml# Fixes: 1f9986b258c2 ("arm64: dts: mediatek: add clock support for mt7986a") Cc: Sam Shih <sam.shih@mediatek.com> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20240101182040.28538-2-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: mt8183: Move CrosEC base detection node to kukui-based DTsNícolas F. R. A. Prado4-4/+12
[ Upstream commit 04bd6411f506357fd1faedc2b2156e7ef206aa9a ] The cbas node is used to describe base detection functionality in the ChromeOS EC, which is used for units that have a detachable keyboard and thus rely on this functionality to switch between tablet and laptop mode. Despite the original commit having added the cbas node to the mt8183-kukui.dtsi, not all machines that include it are detachables. In fact all machines that include from mt8183-kukui-jacuzzi.dtsi are either clamshells (ie normal laptops) or convertibles, meaning the keyboard can be flipped but not detached. The detection for the keyboard getting flipped is handled by the driver bound to the keyboard-controller node in the EC. Move the base detection node from the base kukui dtsi to the dtsis where all machines are detachables, and thus actually make use of the node. Fixes: 4fa8492d1e5b ("arm64: dts: mt8183: add cbas node under cros_ec") Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240116-mt8183-kukui-cbas-remove-v3-1-055e21406e86@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: mt8183: kukui: Split out keyboard node and describe detachablesHsin-Yi Wang5-1/+20
[ Upstream commit 82492c4ef8f65f93cd4a35c4b52518935acbb2fa ] Kukui devices krane, kodana, and kakadu use detachable keyboards, which only have switches to be registered. Change the keyboard node's compatible of those boards to the newly introduced "google,cros-ec-keyb-switches", which won't include matrix properties. Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Link: https://lore.kernel.org/r/20220527045353.2483042-1-hsinyi@chromium.org Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Stable-dep-of: 04bd6411f506 ("arm64: dts: mt8183: Move CrosEC base detection node to kukui-based DTs") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: imx8mm-venice-gw71xx: fix USB OTG VBUSTim Harvey1-20/+9
[ Upstream commit ec2cb52fcfef5d58574f2cfbc9a99ffc20ae5a9d ] The GW71xx does not have a gpio controlled vbus regulator but it does require some pinctrl. Remove the regulator and move the valid pinctrl into the usbotg1 node. Fixes: bd306fdb4e60 ("arm64: dts: imx8mm-venice-gw71xx: fix USB OTG VBUS") Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: imx8mm-kontron: Fix interrupt for RTC on OSM-S i.MX8MM moduleFrieder Schrempf1-1/+1
[ Upstream commit 8d0f39b7d04d864e89b84063b124fd10aa4b8809 ] The level of the interrupt signal is active low instead. Fix this. Fixes: de9618e84f76 ("arm64: dts: Add support for Kontron SL/BL i.MX8MM OSM-S") Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: imx8mm-kontron: Disable pull resistors for SD card signals on BL ↵Frieder Schrempf1-9/+9
board [ Upstream commit 008820524844326ffb3123cebceba1960c0ad0dc ] Some signals have external pullup resistors on the board and don't need the internal ones to be enabled. Due to silicon errata ERR050080 let's disable the internal pull resistors whererever possible and prevent any unwanted behavior in case they wear out. Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards") Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: imx8mm-kontron: Disable pull resistors for SD card signals on BL ↵Frieder Schrempf1-9/+9
OSM-S board [ Upstream commit 5a940ba3e4d7c8710c9073ff5d0ca4644d4da9db ] Some signals have external pullup resistors on the board and don't need the internal ones to be enabled. Due to silicon errata ERR050080 let's disable the internal pull resistors whererever possible and prevent any unwanted behavior in case they wear out. Fixes: de9618e84f76 ("arm64: dts: Add support for Kontron SL/BL i.MX8MM OSM-S") Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: imx8mm-kontron: Disable pullups for onboard UART signals on BL boardFrieder Schrempf1-8/+8
[ Upstream commit 162aadaa0df8217b0cc49d919dd00022fef65e78 ] These signals are actively driven by the SoC or by the onboard transceiver. There's no need to enable the internal pull resistors and due to silicon errata ERR050080 let's disable the internal ones to prevent any unwanted behavior in case they wear out. Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards") Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: imx8mm-kontron: Disable pullups for onboard UART signals on BL ↵Frieder Schrempf1-8/+8
OSM-S board [ Upstream commit c6d9b5672a0e2c4b1079a50d2fc8780c40cfd3eb ] These signals are actively driven by the SoC or by the onboard transceiver. There's no need to enable the internal pull resistors and due to silicon errata ERR050080 let's disable the internal ones to prevent any unwanted behavior in case they wear out. Fixes: de9618e84f76 ("arm64: dts: Add support for Kontron SL/BL i.MX8MM OSM-S") Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: imx8mm-kontron: Disable pullups for I2C signals on SL/BL i.MX8MMFrieder Schrempf2-4/+4
[ Upstream commit f19e5bb91d53264d7dac5d845a4825afadf72440 ] There are external pullup resistors on the board and due to silicon errata ERR050080 let's disable the internal ones to prevent any unwanted behavior in case they wear out. Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards") Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: imx8mm-kontron: Disable pullups for I2C signals on OSM-S i.MX8MMFrieder Schrempf2-4/+4
[ Upstream commit 96293af54f6aa859015d8ca40a1437d3115ad50c ] There are external pullup resistors on the board and due to silicon errata ERR050080 let's disable the internal ones to prevent any unwanted behavior in case they wear out. Fixes: de9618e84f76 ("arm64: dts: Add support for Kontron SL/BL i.MX8MM OSM-S") Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: tegra: Set the correct PHY mode for MGBEThierry Reding1-1/+1
[ Upstream commit 4c892121d43bc2b45896ca207b54f39a8fa6b852 ] The PHY is configured in 10GBASE-R, so make sure to reflect that in DT. Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: dts: Fix dtc interrupt_provider warningsRob Herring9-5/+7
[ Upstream commit 91adecf911e5df78ea3e8f866e69db2c33416a5c ] 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: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> # Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Florian Fainelli <florian.fainelli@broadcom.com> #Broadcom Acked-by: Chanho Min <chanho.min@lge.com> Link: https://lore.kernel.org/r/20240213-arm-dt-cleanups-v1-3-f2dee1292525@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64/sve: Lower the maximum allocation for the SVE ptrace regsetMark Brown2-7/+8
[ Upstream commit 2813926261e436d33bc74486b51cce60b76edf78 ] Doug Anderson observed that ChromeOS crashes are being reported which include failing allocations of order 7 during core dumps due to ptrace allocating storage for regsets: chrome: page allocation failure: order:7, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=urgent,mems_allowed=0 ... regset_get_alloc+0x1c/0x28 elf_core_dump+0x3d8/0xd8c do_coredump+0xeb8/0x1378 with further investigation showing that this is: [ 66.957385] DOUG: Allocating 279584 bytes which is the maximum size of the SVE regset. As Doug observes it is not entirely surprising that such a large allocation of contiguous memory might fail on a long running system. The SVE regset is currently sized to hold SVE registers with a VQ of SVE_VQ_MAX which is 512, substantially more than the architectural maximum of 16 which we might see even in a system emulating the limits of the architecture. Since we don't expose the size we tell the regset core externally let's define ARCH_SVE_VQ_MAX with the actual architectural maximum and use that for the regset, we'll still overallocate most of the time but much less so which will be helpful even if the core is fixed to not require contiguous allocations. Specify ARCH_SVE_VQ_MAX in terms of the maximum value that can be written into ZCR_ELx.LEN (where this is set in the hardware). For consistency update the maximum SME vector length to be specified in the same style while we are at it. We could also teach the ptrace core about runtime discoverable regset sizes but that would be a more invasive change and this is being observed in practical systems. Reported-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org> Tested-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20240213-arm64-sve-ptrace-regset-size-v2-1-c7600ca74b9b@kernel.org Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-06arm64: efi: Limit allocations to 48-bit addressable physical regionArd Biesheuvel1-0/+1
From: Ard Biesheuvel <ardb@kernel.org> [ Commit a37dac5c5dcfe0f1fd58513c16cdbc280a47f628 upstream ] The UEFI spec does not mention or reason about the configured size of the virtual address space at all, but it does mention that all memory should be identity mapped using a page size of 4 KiB. This means that a LPA2 capable system that has any system memory outside of the 48-bit addressable physical range and follows the spec to the letter may serve page allocation requests from regions of memory that the kernel cannot access unless it was built with LPA2 support and enables it at runtime. So let's ensure that all page allocations are limited to the 48-bit range. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-06crypto: arm64/neonbs - fix out-of-bounds access on short inputArd Biesheuvel1-0/+11
commit 1c0cf6d19690141002889d72622b90fc01562ce4 upstream. The bit-sliced implementation of AES-CTR operates on blocks of 128 bytes, and will fall back to the plain NEON version for tail blocks or inputs that are shorter than 128 bytes to begin with. It will call straight into the plain NEON asm helper, which performs all memory accesses in granules of 16 bytes (the size of a NEON register). For this reason, the associated plain NEON glue code will copy inputs shorter than 16 bytes into a temporary buffer, given that this is a rare occurrence and it is not worth the effort to work around this in the asm code. The fallback from the bit-sliced NEON version fails to take this into account, potentially resulting in out-of-bounds accesses. So clone the same workaround, and use a temp buffer for short in/outputs. Fixes: fc074e130051 ("crypto: arm64/aes-neonbs-ctr - fallback to plain NEON for final chunk") Cc: <stable@vger.kernel.org> Reported-by: syzbot+f1ceaa1a09ab891e1934@syzkaller.appspotmail.com Reviewed-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-01arm64/sme: Restore SME registers on exit from suspendMark Brown3-0/+19
[ Upstream commit 9533864816fb4a6207c63b7a98396351ce1a9fae ] The fields in SMCR_EL1 and SMPRI_EL1 reset to an architecturally UNKNOWN value. Since we do not otherwise manage the traps configured in this register at runtime we need to reconfigure them after a suspend in case nothing else was kind enough to preserve them for us. The vector length will be restored as part of restoring the SME state for the next SME using task. Fixes: a1f4ccd25cc2 ("arm64/sme: Provide Kconfig for SME") Reported-by: Jackson Cooper-Driver <Jackson.Cooper-Driver@arm.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20240213-arm64-sme-resume-v3-1-17e05e493471@kernel.org Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-01arm64: dts: rockchip: set num-cs property for spi on px30Heiko Stuebner1-0/+2
[ Upstream commit 334bf0710c98d391f4067b72f535d6c4c84dfb6f ] The px30 has two spi controllers with two chip-selects each. The num-cs property is specified as the total number of chip selects a controllers has and is used since 2020 to find uses of chipselects outside that range in the Rockchip spi driver. Without the property set, the default is 1, so spi devices using the second chipselect will not be created. Fixes: eb1262e3cc8b ("spi: spi-rockchip: use num-cs property and ctlr->enable_gpiods") Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Link: https://lore.kernel.org/r/20240119101656.965744-1-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-01KVM: arm64: vgic-its: Test for valid IRQ in its_sync_lpi_pending_table()Oliver Upton1-0/+3
commit 8d3a7dfb801d157ac423261d7cd62c33e95375f8 upstream. vgic_get_irq() may not return a valid descriptor if there is no ITS that holds a valid translation for the specified INTID. If that is the case, it is safe to silently ignore it and continue processing the LPI pending table. Cc: stable@vger.kernel.org Fixes: 33d3bc9556a7 ("KVM: arm64: vgic-its: Read initial LPI pending table") Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20240221092732.4126848-2-oliver.upton@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-01KVM: arm64: vgic-its: Test for valid IRQ in MOVALL handlerOliver Upton1-0/+2
commit 85a71ee9a0700f6c18862ef3b0011ed9dad99aca upstream. It is possible that an LPI mapped in a different ITS gets unmapped while handling the MOVALL command. If that is the case, there is no state that can be migrated to the destination. Silently ignore it and continue migrating other LPIs. Cc: stable@vger.kernel.org Fixes: ff9c114394aa ("KVM: arm/arm64: GICv4: Handle MOVALL applied to a vPE") Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20240221092732.4126848-3-oliver.upton@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-23arm64: Subscribe Microsoft Azure Cobalt 100 to ARM Neoverse N2 errataEaswar Hariharan2-0/+7
commit fb091ff394792c018527b3211bbdfae93ea4ac02 upstream. Add the MIDR value of Microsoft Azure Cobalt 100, which is a Microsoft implemented CPU based on r0p0 of the ARM Neoverse N2 CPU, and therefore suffers from all the same errata. CC: stable@vger.kernel.org # 5.15+ Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20240214175522.2457857-1-eahariha@linux.microsoft.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-23kbuild: Drop -Wdeclaration-after-statementPeter Zijlstra1-2/+0
commit b5ec6fd286dfa466f64cb0e56ed768092d0342ae upstream. With the advent on scope-based resource management it comes really tedious to abide by the contraints of -Wdeclaration-after-statement. It will still be recommeneded to place declarations at the start of a scope where possible, but it will no longer be enforced. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/CAHk-%3Dwi-RyoUhbChiVaJZoZXheAwnJ7OO%3DGxe85BkPAd93TwDA%40mail.gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-23arm64: dts: qcom: sm8150: fix USB SS wakeupJohan Hovold1-2/+2
[ Upstream commit cc4e1da491b84ca05339a19893884cda78f74aef ] The USB SS PHY interrupts need to be provided by the PDC interrupt controller in order to be able to wake the system up from low-power states. Fixes: 0c9dde0d2015 ("arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes") Fixes: b33d2868e8d3 ("arm64: dts: qcom: sm8150: Add USB and PHY device nodes") Cc: stable@vger.kernel.org # 5.10 Cc: Jack Pham <quic_jackp@quicinc.com> Cc: Jonathan Marek <jonathan@marek.ca> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20231213173403.29544-6-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-23arm64: dts: qcom: sdm845: fix USB SS wakeupJohan Hovold1-2/+2
[ Upstream commit 971f5d8b0618d09db75184ddd8cca0767514db5d ] The USB SS PHY interrupts need to be provided by the PDC interrupt controller in order to be able to wake the system up from low-power states. Fixes: ca4db2b538a1 ("arm64: dts: qcom: sdm845: Add USB-related nodes") Cc: stable@vger.kernel.org # 4.20 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20231213173403.29544-4-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-23arm64: dts: qcom: msm8916: Make blsp_dma controlled-remotelyStephan Gerhold1-0/+1
[ Upstream commit 7c45b6ddbcff01f9934d11802010cfeb0879e693 ] The blsp_dma controller is shared between the different subsystems, which is why it is already initialized by the firmware. We should not reinitialize it from Linux to avoid potential other users of the DMA engine to misbehave. In mainline this can be described using the "qcom,controlled-remotely" property. In the downstream/vendor kernel from Qualcomm there is an opposite "qcom,managed-locally" property. This property is *not* set for the qcom,sps-dma@7884000 [1] so adding "qcom,controlled-remotely" upstream matches the behavior of the downstream/vendor kernel. Adding this seems to fix some weird issues with UART where both input/output becomes garbled with certain obscure firmware versions on some devices. [1]: https://git.codelinaro.org/clo/la/kernel/msm-3.10/-/blob/LA.BR.1.2.9.1-02310-8x16.0/arch/arm/boot/dts/qcom/msm8916.dtsi#L1466-1472 Cc: stable@vger.kernel.org # 6.5 Fixes: a0e5fb103150 ("arm64: dts: qcom: Add msm8916 BLSP device nodes") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20231204-msm8916-blsp-dma-remote-v1-1-3e49c8838c8d@gerhold.net Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-23arm64: dts: qcom: msm8916: Enable blsp_dma by defaultStephan Gerhold2-5/+0
[ Upstream commit 0154d3594af3c198532ac7b4ab70f50fb5207a15 ] Adding the "dmas" to the I2C controllers prevents probing them if blsp_dma is disabled (infinite probe deferral). Avoid this by enabling blsp_dma by default - it's an integral part of the SoC that is almost always used (even if just for UART). Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230107110958.5762-2-stephan@gerhold.net Stable-dep-of: 7c45b6ddbcff ("arm64: dts: qcom: msm8916: Make blsp_dma controlled-remotely") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-23work around gcc bugs with 'asm goto' with outputsLinus Torvalds2-4/+4
commit 68fb3ca0e408e00db1c3f8fccdfa19e274c033be 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'. 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-05arm64: irq: set the correct node for shadow call stackHuang Shijie1-1/+1
commit 7b1a09e44dc64f4f5930659b6d14a27183c00705 upstream. The init_irq_stacks() has been changed to use the correct node: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=75b5e0bf90bf The init_irq_scs() has the same issue with init_irq_stacks(): cpu_to_node() is not initialized yet, it does not work. This patch uses early_cpu_to_node() to set the init_irq_scs() with the correct node. Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20231213012046.12014-1-shijie@os.amperecomputing.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-05arm64: dts: amlogic: fix format for s4 uart nodeXianwei Zhao2-4/+4
[ Upstream commit eb54ef36282f670c704ed5af8593da62bebba80d ] Aliases use lowercase letters and place status in end. Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20231215-s4-dts-v1-1-7831ab6972be@amlogic.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-03-18 11:44:43 +0300