summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2023-11-20arm64: dts: ti: Fix HDMI Audio overlay in MakefileAradhya Bhatia1-1/+4
[ Upstream commit 69c570ebc3964534c19dc4438d3b96f55d489fc3 ] Apply HDMI audio overlay to AM625 and AM62-LP SK-EVMs DT binaries, instead of leaving it in a floating state. Fixes: b50ccab9e07c ("arm64: dts: ti: am62x-sk: Add overlay for HDMI audio") Reported-by: Rob Herring <robh@kernel.org> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Link: https://lore.kernel.org/r/20231003092259.28103-1-a-bhatia1@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: ti: k3-am62a7-sk: Drop i2c-1 to 100KhzJai Luthra1-1/+1
[ Upstream commit 63e5aa69b821472a3203a29e17c025329c1b151f ] The TLV320AIC3106 audio codec is interfaced on the i2c-1 bus. With the default rate of 400Khz the i2c register writes fail to sync: [ 36.026387] tlv320aic3x 1-001b: Unable to sync registers 0x16-0x16. -110 [ 38.101130] omap_i2c 20010000.i2c: controller timed out Dropping the rate to 100Khz fixes the issue. Fixes: 38c4a08c820c ("arm64: dts: ti: Add support for AM62A7-SK") Reviewed-by: Devarsh Thakkar <devarsht@ti.com> Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Jai Luthra <j-luthra@ti.com> Link: https://lore.kernel.org/r/20231003-mcasp_am62a-v3-3-2b631ff319ca@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: ti: k3-am625-beagleplay: Fix typo in ramoops regWadim Egorov1-1/+1
[ Upstream commit 33269ac0b768b07da017df173d52952625c57870 ] Seems like the address value of the reg property was mistyped. Update reg to 0x9ca00000 to match node's definition. Fixes: f5a731f0787f ("arm64: dts: ti: Add k3-am625-beagleplay") Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Reviewed-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20230925151444.1856852-1-w.egorov@phytec.de Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: ti: verdin-am62: disable MIPI DSI bridgeFrancesco Dolcini1-0/+1
[ Upstream commit 664e2852aa9142193c2e241327631f032b966742 ] Keep the DPI to MIPI-DSI bridge disabled in the SoM dtsi file. The display chain is not wholly described in the device tree file, on Verdin product family the displays are additional accessories that are configured/enabled using DT overlays. With this enabled we have issues when a display is enabled on TIDSS port1 (LVDS) and port0 (DSI) is not used. Fixes: 9e77200356ba ("arm64: dts: ti: verdin-am62: Add DSI display support") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://lore.kernel.org/r/20230922123003.25002-1-francesco@dolcini.it Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: ti: k3-j721s2-evm-gesi: Specify base dtb for overlay fileSiddharth Vadapalli1-0/+2
[ Upstream commit 35be6ac964450687ab39b846d65ee1cb2a352280 ] Specify the base dtb file k3-j721s2-common-proc-board.dtb on which the k3-j721s2-evm-gesi-exp-board.dtbo overlay has to be applied. Name the resulting dtb as k3-j721s2-evm.dtb. Fixes: cac04e27f093 ("arm64: dts: ti: k3-j721s2: Add overlay to enable main CPSW2G with GESI") Reported-by: Rob Herring <robh+dt@kernel.org> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Link: https://lore.kernel.org/r/20230912043308.20629-1-s-vadapalli@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20ARM: dts: stm32: stm32f7-pinctrl: don't use multiple blank linesDario Binacchi1-1/+0
[ Upstream commit 88bb50edb61068c4416df2e55677fb3159f647f1 ] The patch fixes the following warning: arch/arm/dts/stm32f7-pinctrl.dtsi:380: check: Please don't use multiple blank lines Fixes: ba287d1a0137 ("ARM: dts: stm32: add pin map for LTDC on stm32f7") Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Raphaël Gallais-Pou <raphael.gallais-pou@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20ARM: dts: qcom: mdm9615: populate vsdcc fixed regulatorKrzysztof Kozlowski1-8/+6
[ Upstream commit 09f8ee81b6da5f76de8b83c8bfc4475b54e101e0 ] Fixed regulator put under "regulators" node will not be populated, unless simple-bus or something similar is used. Drop the "regulators" wrapper node to fix this. Fixes: 2c5e596524e7 ("ARM: dts: Add MDM9615 dtsi") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230924183914.51414-3-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20ARM: dts: qcom: apq8026-samsung-matisse-wifi: Fix inverted hall sensorMatti Lehtimäki1-2/+2
[ Upstream commit 0b73519790d29e4bc71afc4882a9aa9ea649bcf7 ] Fix hall sensor GPIO polarity and also allow disabling the sensor. Remove unneeded interrupt. Fixes: f15623bda1dc ("ARM: dts: qcom: Add support for Samsung Galaxy Tab 4 10.1 (SM-T530)") Signed-off-by: Matti Lehtimäki <matti.lehtimaki@gmail.com> Reviewed-by: Luca Weiss <luca@z3ntu.xyz> Link: https://lore.kernel.org/r/20230922011211.115234-1-matti.lehtimaki@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: qcom: apq8016-sbc: Add missing ADV7533 regulatorsStephan Gerhold1-0/+3
[ Upstream commit 33e9032a1875bb1aee3c68a4540f5a577ff44130 ] Add the missing regulator supplies to the ADV7533 HDMI bridge to fix the following dtbs_check warnings. They are all also supplied by pm8916_l6 so there is no functional difference. apq8016-sbc.dtb: bridge@39: 'dvdd-supply' is a required property apq8016-sbc.dtb: bridge@39: 'pvdd-supply' is a required property apq8016-sbc.dtb: bridge@39: 'a2vdd-supply' is a required property from schema display/bridge/adi,adv7533.yaml Fixes: 28546b095511 ("arm64: dts: apq8016-sbc: Add HDMI display support") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230922-db410c-adv7533-regulators-v1-1-68aba71e529b@gerhold.net Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20riscv: dts: allwinner: remove address-cells from intc nodeConor Dooley1-1/+0
[ Upstream commit 267860b10c67dd396c73a9e6e8103670d78a4c01 ] A recent submission [1] from Rob has added additionalProperties: false to the interrupt-controller child node of RISC-V cpus, highlighting that the D1 DT has been incorrectly using #address-cells since its introduction. It has no child nodes, so #address-cells is not needed. Remove it. Fixes: 077e5f4f5528 ("riscv: dts: allwinner: Add the D1/D1s SoC devicetree") Link: https://patchwork.kernel.org/project/linux-riscv/patch/20230915201946.4184468-1-robh@kernel.org/ [1] Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20230916-saddling-dastardly-8cf6d1263c24@spud Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: qcom: msm8939: Fix iommu local address rangeGaurav Kohli1-1/+1
[ Upstream commit d40291e52d5ac4d0ff18ca433e84e6ddccc13427 ] Fix the apps iommu local address space range as per data sheet. Fixes: 61550c6c156c ("arm64: dts: qcom: Add msm8939 SoC") Signed-off-by: Gaurav Kohli <quic_gkohli@quicinc.com> Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230917140039.25283-1-quic_gkohli@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: qcom: msm8976: Fix ipc bit shiftsAdam Skladowski1-4/+4
[ Upstream commit 684277525c70f329300cc687e27248e405a4ff9e ] Update bits to match downstream irq-bitmask values. Fixes: 0484d3ce0902 ("arm64: dts: qcom: Add DTS for MSM8976 and MSM8956 SoCs") Signed-off-by: Adam Skladowski <a39.skl@gmail.com> Link: https://lore.kernel.org/r/20230812112534.8610-8-a39.skl@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20ARM64: dts: marvell: cn9310: Use appropriate label for spi1 pinsChris Packham2-4/+4
[ Upstream commit 0878fd86f554ab98aa493996c7e0c72dff58437f ] Both the CN9130-CRB and CN9130-DB use the SPI1 interface but had the pinctrl node labelled as "cp0_spi0_pins". Use the label "cp0_spi1_pins" and update the node name to "cp0-spi-pins-1" to avoid confusion with the pinctrl options for SPI0. Fixes: 4c43a41e5b8c ("arm64: dts: cn913x: add device trees for topology B boards") Fixes: 5c0ee54723f3 ("arm64: dts: add support for Marvell cn9130-crb platform") Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: qcom: sdx75-idp: align RPMh regulator nodes with bindingsKrzysztof Kozlowski1-1/+1
[ Upstream commit 815ea491460766dbd4b39a3c9904b44b5880c41c ] Device node names should be generic and bindings expect certain pattern for RPMh regulator nodes: sdx75-idp.dtb: rsc@17a00000: 'pmx75-rpmh-regulators' does not match any of the regexes: '^regulators(-[0-9])?$', 'pinctrl-[0-9]+' Fixes: 8a2dc39d1043 ("arm64: dts: qcom: sdx75-idp: Add regulator nodes") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230905163103.257412-1-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: qcom: sdm845-mtp: fix WiFi configurationDmitry Baryshkov1-0/+2
[ Upstream commit b33868a52f342d9b1f20aa5bffe40cbd69bd0a4b ] Enable the host-cap-8bit quirk on this device. It is required for the WiFi to function properly. Fixes: 022bccb840b7 ("arm64: dts: sdm845: Add WCN3990 WLAN module device node") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230826221915.846937-2-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: qcom: sm8350: fix pinctrl for UART18Dmitry Baryshkov1-1/+1
[ Upstream commit c1efa960114f743924b884da098298512a7e9983 ] On sm8350 QUP18 uses GPIO 68/69, not 58/59. Fix correponding UART18 pinconf configuraion. Fixes: 98374e6925b8 ("arm64: dts: qcom: sm8350: Set up WRAP2 QUPs") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230825214550.1650938-1-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: qcom: sm8150: add ref clock to PCIe PHYsDmitry Baryshkov1-2/+10
[ Upstream commit c204b3709409279ac019f3d374e444bb0b1424f0 ] Follow the rest of the platforms and add "ref" clocks to both PCIe PHYs found on the Qualcomm SM8150 platform. Fixes: a1c86c680533 ("arm64: dts: qcom: sm8150: Add PCIe nodes") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230820142035.89903-15-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: qcom: sc7280: drop incorrect EUD port on SoC sideKrzysztof Kozlowski1-19/+2
[ Upstream commit 39c8af78cbefb8c71a5ad1fa088e761ef418f0a0 ] Qualcomm Embedded USB Debugger (EUD) second port should point to Type-C USB connector. Such connector was defined directly in root node of sc7280.dtsi which is clearly wrong. SC7280 is a chip, so physically it does not have USB Type-C port. The connector is usually accessible through some USB switch or controller. Doug Anderson said that he wasn't ever able to use EUD on Herobrine boards, probably because of invalid or missing DTS description - DTS is saying EUD is on usb_2 node, which is connected to a USB Hub, not to the Type-C port. Correct the EUD/USB connector topology by removing the top-level fake USB connector and EUD port pointing to it, and disabling the incomplete EUD device node. This fixes also dtbs_check warnings: sc7280-herobrine-crd.dtb: connector: ports:port@0: 'reg' is a required property Link: https://lore.kernel.org/all/CAD=FV=Xt26=rBf99mzkAuwwtb2f-jnKtnHaEhXnthz0a5zke4Q@mail.gmail.com/ Fixes: 9ee402ccfeb1 ("arm64: dts: qcom: sc7280: Fix EUD dt node syntax") Cc: Souradeep Chowdhury <quic_schowdhu@quicinc.com> Cc: Bhupesh Sharma <bhupesh.sharma@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230820075626.22600-1-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: qcom: sdm670: Fix pdc mappingKonrad Dybcio1-1/+2
[ Upstream commit ad75cda991f7b335d3b2417f82db07680f92648a ] As pointed out by Richard, I missed a non-continuity in one of the ranges. Fix it. Reported-by: Richard Acayan <mailingradian@gmail.com> Fixes: b51ee205dc4f ("arm64: dts: qcom: sdm670: Add PDC") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Richard Acayan <mailingradian@gmail.com> Link: https://lore.kernel.org/r/20230818-topic-670_pdc_fix-v1-1-1ba025041de7@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: qcom: qrb2210-rb1: Fix regulatorsKonrad Dybcio1-43/+43
[ Upstream commit 31bee70793b67f4b428825434542afc72ddb2b3b ] Commit b4fe47d12f1f ("arm64: dts: qcom: qrb2210-rb1: Add regulators") introduced regulator settings that were never put in place, as all of the properties ended 'microvolts' instead of 'microvolt' (which dt schema did not check for back then). Fix the microvolts-microvolt typo and adjust voltage ranges where it's necessary to fit within the volt = base + n*step formula. Reported-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Fixes: b4fe47d12f1f ("arm64: dts: qcom: qrb2210-rb1: Add regulators") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230906-topic-rb1_features_sans_icc-v1-2-e92ce6fbde16@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: qcom: qrb2210-rb1: Swap UART indexKonrad Dybcio1-2/+2
[ Upstream commit 973c015facabcbd320063648010942c51992c1a1 ] Newer RB1 board revisions have a debug UART on QUP0. Sadly, it looks like even when ordering one in retail, customers receive prototype boards with "Enginering Sample" written on them. Use QUP4 for UART to make all known RB1 boards boot. Fixes: e18771961336 ("arm64: dts: qcom: Add initial QTI RB1 device tree") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230906-topic-rb1_features_sans_icc-v1-1-e92ce6fbde16@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: qcom: sc7280: Add missing LMH interruptsKonrad Dybcio1-0/+8
[ Upstream commit 3f93d119c9d6e1744d55cd48af764160a1a3aca3 ] Hook up the interrupts that signal the Limits Management Hardware has started some sort of throttling action. Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230811-topic-7280_lmhirq-v1-1-c262b6a25c8f@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: qcom: sm6125: Pad APPS IOMMU address to 8 charactersMarijn Suijten1-1/+1
[ Upstream commit 310cdafc4a56827d1aeda7cc297939034adb8f99 ] APPS IOMMU is the only node in sm6125.dtsi that doesn't have its address padded to 8 hexadecimals; fix this by prepending a 0. Fixes: 8ddb4bc3d3b5 ("arm64: dts: qcom: sm6125: Configure APPS SMMU") Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Link: https://lore.kernel.org/r/20230723-sm6125-dpu-v4-2-a3f287dd6c07@somainline.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: qcom: msm8992-libra: drop duplicated reserved memoryKrzysztof Kozlowski1-5/+0
[ Upstream commit f32096602c19e68fb9bf04b494d13f1190602554 ] There are two entries for similar reserved memory: qseecom@cb400000 and audio@cb400000. Keep the qseecom as it is longer. Warning (unique_unit_address_if_enabled): /reserved-memory/audio@cb400000: duplicate unit-address (also used in node /reserved-memory/qseecom@cb400000) Fixes: 69876bc6fd4d ("arm64: dts: qcom: msm8992-libra: Fix the memory map") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230720072048.10093-2-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: qcom: msm8916: Fix iommu local address rangeGaurav Kohli1-1/+1
[ Upstream commit 2de8ee9f58fa51f707c71f8fbcd8470ab0078102 ] Fix the apps iommu local address space range as per data sheet. Fixes: 6a6729f38436 ("arm64: dts: qcom: msm8916: Add IOMMU support") Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Gaurav Kohli <quic_gkohli@quicinc.com> Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230915143304.477-1-quic_gkohli@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: qcom: sc7280: link usb3_phy_wrapper_gcc_usb30_pipe_clkDmitry Baryshkov1-1/+2
[ Upstream commit 70c4a1ca13b333b00e01266d299605fa1041b0d5 ] Use usb_1_ssphy's clock as gcc's usb3_phy_wrapper_gcc_usb30_pipe_clk clock source. Suggested-by: Neil Armstrong <neil.armstrong@linaro.org> Fixes: 1c39e6f9b534 ("arm64: dts: qcom: sc7280: Add USB related nodes") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230711120916.4165894-7-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: qcom: sdm845: cheza doesn't support LMh nodeDavid Heidelberg1-0/+12
[ Upstream commit 197ae69d1caedb3203e0b189a39efb820675fd5c ] Cheza firmware doesn't allow controlling LMh from the operating system. Fixes: 36c6581214c4 ("arm64: dts: qcom: sdm845: Add support for LMh node") Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: David Heidelberg <david@ixit.cz> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20230912071205.11502-2-david@ixit.cz Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64: dts: qcom: sdm845: Fix PSCI power domain namesDavid Heidelberg1-9/+11
[ Upstream commit a5f01673d3946e424091e6b8ff274716f9c21454 ] The original commit hasn't been updated according to refactoring done in sdm845.dtsi. Fixes: a1ade6cac5a2 ("arm64: dts: qcom: sdm845: Switch PSCI cpu idle states from PC to OSI") Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: David Heidelberg <david@ixit.cz> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20230912071205.11502-1-david@ixit.cz Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20ARM: dts: renesas: blanche: Fix typo in GP_11_2 pin nameGeert Uytterhoeven1-1/+1
[ Upstream commit edc6ef026fe69154bb6b70dd6e7f278cfd7d6919 ] On blanche, the GPIO keyboard fails to probe with: sh-pfc e6060000.pinctrl: could not map pin config for "GP_11_02" Fix this by correcting the name for this pin to "GP_11_2". Fixes: 1f27fedead91eb60 ("ARM: dts: blanche: Configure pull-up for SOFT_SW and SW25 GPIO keys") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/203128eca2261ffc33b83637818dd39c488f42b0.1693408326.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20clocksource/drivers/arm_arch_timer: limit XGene-1 workaroundAndre Przywara2-2/+3
[ Upstream commit 851354cbd12bb9500909733c3d4054306f61df87 ] The AppliedMicro XGene-1 CPU has an erratum where the timer condition would only consider TVAL, not CVAL. We currently apply a workaround when seeing the PartNum field of MIDR_EL1 being 0x000, under the assumption that this would match only the XGene-1 CPU model. However even the Ampere eMAG (aka XGene-3) uses that same part number, and only differs in the "Variant" and "Revision" fields: XGene-1's MIDR is 0x500f0000, our eMAG reports 0x503f0002. Experiments show the latter doesn't show the faulty behaviour. Increase the specificity of the check to only consider partnum 0x000 and variant 0x00, to exclude the Ampere eMAG. Fixes: 012f18850452 ("clocksource/drivers/arm_arch_timer: Work around broken CVAL implementations") Reported-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20231016153127.116101-1-andre.przywara@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64/arm: xen: enlighten: Fix KPTI checksMark Rutland1-9/+16
[ Upstream commit 20f3b8eafe0ba5d3c69d5011a9b07739e9645132 ] When KPTI is in use, we cannot register a runstate region as XEN requires that this is always a valid VA, which we cannot guarantee. Due to this, xen_starting_cpu() must avoid registering each CPU's runstate region, and xen_guest_init() must avoid setting up features that depend upon it. We tried to ensure that in commit: f88af7229f6f22ce (" xen/arm: do not setup the runstate info page if kpti is enabled") ... where we added checks for xen_kernel_unmapped_at_usr(), which wraps arm64_kernel_unmapped_at_el0() on arm64 and is always false on 32-bit arm. Unfortunately, as xen_guest_init() is an early_initcall, this happens before secondary CPUs are booted and arm64 has finalized the ARM64_UNMAP_KERNEL_AT_EL0 cpucap which backs arm64_kernel_unmapped_at_el0(), and so this can subsequently be set as secondary CPUs are onlined. On a big.LITTLE system where the boot CPU does not require KPTI but some secondary CPUs do, this will result in xen_guest_init() intializing features that depend on the runstate region, and xen_starting_cpu() registering the runstate region on some CPUs before KPTI is subsequent enabled, resulting the the problems the aforementioned commit tried to avoid. Handle this more robsutly by deferring the initialization of the runstate region until secondary CPUs have been initialized and the ARM64_UNMAP_KERNEL_AT_EL0 cpucap has been finalized. The per-cpu work is moved into a new hotplug starting function which is registered later when we're certain that KPTI will not be used. Fixes: f88af7229f6f ("xen/arm: do not setup the runstate info page if kpti is enabled") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Bertrand Marquis <bertrand.marquis@arm.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20x86/tdx: Zero out the missing RSI in TDX_HYPERCALL macroKai Huang1-0/+1
[ Upstream commit 5d092b66119d774853cc9308522620299048a662 ] In the TDX_HYPERCALL asm, after the TDCALL instruction returns from the untrusted VMM, the registers that the TDX guest shares to the VMM need to be cleared to avoid speculative execution of VMM-provided values. RSI is specified in the bitmap of those registers, but it is missing when zeroing out those registers in the current TDX_HYPERCALL. It was there when it was originally added in commit 752d13305c78 ("x86/tdx: Expand __tdx_hypercall() to handle more arguments"), but was later removed in commit 1e70c680375a ("x86/tdx: Do not corrupt frame-pointer in __tdx_hypercall()"), which was correct because %rsi is later restored in the "pop %rsi". However a later commit 7a3a401874be ("x86/tdx: Drop flags from __tdx_hypercall()") removed that "pop %rsi" but forgot to add the "xor %rsi, %rsi" back. Fix by adding it back. Fixes: 7a3a401874be ("x86/tdx: Drop flags from __tdx_hypercall()") Signed-off-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/all/e7d1157074a0b45d34564d5f17f3e0ffee8115e9.1692096753.git.kai.huang%40intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20bpf, x64: Fix tailcall infinite loopLeon Hwang1-6/+22
[ Upstream commit 2b5dcb31a19a2e0acd869b12c9db9b2d696ef544 ] From commit ebf7d1f508a73871 ("bpf, x64: rework pro/epilogue and tailcall handling in JIT"), the tailcall on x64 works better than before. From commit e411901c0b775a3a ("bpf: allow for tailcalls in BPF subprograms for x64 JIT"), tailcall is able to run in BPF subprograms on x64. From commit 5b92a28aae4dd0f8 ("bpf: Support attaching tracing BPF program to other BPF programs"), BPF program is able to trace other BPF programs. How about combining them all together? 1. FENTRY/FEXIT on a BPF subprogram. 2. A tailcall runs in the BPF subprogram. 3. The tailcall calls the subprogram's caller. As a result, a tailcall infinite loop comes up. And the loop would halt the machine. As we know, in tail call context, the tail_call_cnt propagates by stack and rax register between BPF subprograms. So do in trampolines. Fixes: ebf7d1f508a7 ("bpf, x64: rework pro/epilogue and tailcall handling in JIT") Fixes: e411901c0b77 ("bpf: allow for tailcalls in BPF subprograms for x64 JIT") Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Leon Hwang <hffilwlqm@gmail.com> Link: https://lore.kernel.org/r/20230912150442.2009-3-hffilwlqm@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20x86/nmi: Fix out-of-order NMI nesting checks & false positive warningPaul E. McKenney1-6/+7
[ Upstream commit f44075ecafb726830e63d33fbca29413149eeeb8 ] The ->idt_seq and ->recv_jiffies variables added by: 1a3ea611fc10 ("x86/nmi: Accumulate NMI-progress evidence in exc_nmi()") ... place the exit-time check of the bottom bit of ->idt_seq after the this_cpu_dec_return() that re-enables NMI nesting. This can result in the following sequence of events on a given CPU in kernels built with CONFIG_NMI_CHECK_CPU=y: o An NMI arrives, and ->idt_seq is incremented to an odd number. In addition, nmi_state is set to NMI_EXECUTING==1. o The NMI is processed. o The this_cpu_dec_return(nmi_state) zeroes nmi_state and returns NMI_EXECUTING==1, thus opting out of the "goto nmi_restart". o Another NMI arrives and ->idt_seq is incremented to an even number, triggering the warning. But all is just fine, at least assuming we don't get so many closely spaced NMIs that the stack overflows or some such. Experience on the fleet indicates that the MTBF of this false positive is about 70 years. Or, for those who are not quite that patient, the MTBF appears to be about one per week per 4,000 systems. Fix this false-positive warning by moving the "nmi_restart" label before the initial ->idt_seq increment/check and moving the this_cpu_dec_return() to follow the final ->idt_seq increment/check. This way, all nested NMIs that get past the NMI_NOT_RUNNING check get a clean ->idt_seq slate. And if they don't get past that check, they will set nmi_state to NMI_LATCHED, which will cause the this_cpu_dec_return(nmi_state) to restart. Fixes: 1a3ea611fc10 ("x86/nmi: Accumulate NMI-progress evidence in exc_nmi()") Reported-by: Chris Mason <clm@fb.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Link: https://lore.kernel.org/r/0cbff831-6e3d-431c-9830-ee65ee7787ff@paulmck-laptop Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20x86/apic: Fake primary thread mask for XEN/PVThomas Gleixner1-0/+11
[ Upstream commit 965e05ff8af98c44f9937366715c512000373164 ] The SMT control mechanism got added as speculation attack vector mitigation. The implemented logic relies on the primary thread mask to be set up properly. This turns out to be an issue with XEN/PV guests because their CPU hotplug mechanics do not enumerate APICs and therefore the mask is never correctly populated. This went unnoticed so far because by chance XEN/PV ends up with smp_num_siblings == 2. So cpu_smt_control stays at its default value CPU_SMT_ENABLED and the primary thread mask is never evaluated in the context of CPU hotplug. This stopped "working" with the upcoming overhaul of the topology evaluation which legitimately provides a fake topology for XEN/PV. That sets smp_num_siblings to 1, which causes the core CPU hot-plug core to refuse to bring up the APs. This happens because cpu_smt_control is set to CPU_SMT_NOT_SUPPORTED which causes cpu_bootable() to evaluate the unpopulated primary thread mask with the conclusion that all non-boot CPUs are not valid to be plugged. The core code has already been made more robust against this kind of fail, but the primary thread mask really wants to be populated to avoid other issues all over the place. Just fake the mask by pretending that all XEN/PV vCPUs are primary threads, which is consistent because all of XEN/PVs topology is fake or non-existent. Fixes: 6a4d2657e048 ("x86/smp: Provide topology_is_primary_thread()") Fixes: f54d4434c281 ("x86/apic: Provide cpu_primary_thread mask") Reported-by: Juergen Gross <jgross@suse.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Juergen Gross <jgross@suse.com> Tested-by: Sohil Mehta <sohil.mehta@intel.com> Tested-by: Michael Kelley <mikelley@microsoft.com> Tested-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Zhang Rui <rui.zhang@intel.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20230814085112.210011520@linutronix.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20x86/boot: Fix incorrect startup_gdt_descr.sizeYuntao Wang1-1/+1
[ Upstream commit 001470fed5959d01faecbd57fcf2f60294da0de1 ] Since the size value is added to the base address to yield the last valid byte address of the GDT, the current size value of startup_gdt_descr is incorrect (too large by one), fix it. [ mingo: This probably never mattered, because startup_gdt[] is only used in a very controlled fashion - but make it consistent nevertheless. ] Fixes: 866b556efa12 ("x86/head/64: Install startup GDT") Signed-off-by: Yuntao Wang <ytcoode@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Link: https://lore.kernel.org/r/20230807084547.217390-1-ytcoode@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20x86/sev-es: Allow copy_from_kernel_nofault() in earlier bootAdam Dunlap1-5/+14
[ Upstream commit f79936545fb122856bd78b189d3c7ee59928c751 ] Previously, if copy_from_kernel_nofault() was called before boot_cpu_data.x86_virt_bits was set up, then it would trigger undefined behavior due to a shift by 64. This ended up causing boot failures in the latest version of ubuntu2204 in the gcp project when using SEV-SNP. Specifically, this function is called during an early #VC handler which is triggered by a CPUID to check if NX is implemented. Fixes: 1aa9aa8ee517 ("x86/sev-es: Setup GHCB-based boot #VC handler") Suggested-by: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Adam Dunlap <acdunlap@google.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: Jacob Xu <jacobhxu@google.com> Link: https://lore.kernel.org/r/20230912002703.3924521-2-acdunlap@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20x86/numa: Introduce numa_fill_memblks()Alison Schofield2-0/+82
[ Upstream commit 8f012db27c9516be1a7aca93ea4a6ca9c75056c9 ] numa_fill_memblks() fills in the gaps in numa_meminfo memblks over an physical address range. The ACPI driver will use numa_fill_memblks() to implement a new Linux policy that prescribes extending proximity domains in a portion of a CFMWS window to the entire window. Dan Williams offered this explanation of the policy: A CFWMS is an ACPI data structure that indicates *potential* locations where CXL memory can be placed. It is the playground where the CXL driver has free reign to establish regions. That space can be populated by BIOS created regions, or driver created regions, after hotplug or other reconfiguration. When BIOS creates a region in a CXL Window it additionally describes that subset of the Window range in the other typical ACPI tables SRAT, SLIT, and HMAT. The rationale for BIOS not pre-describing the entire CXL Window in SRAT, SLIT, and HMAT is that it can not predict the future. I.e. there is nothing stopping higher or lower performance devices being placed in the same Window. Compare that to ACPI memory hotplug that just onlines additional capacity in the proximity domain with little freedom for dynamic performance differentiation. That leaves the OS with a choice, should unpopulated window capacity match the proximity domain of an existing region, or should it allocate a new one? This patch takes the simple position of minimizing proximity domain proliferation by reusing any proximity domain intersection for the entire Window. If the Window has no intersections then allocate a new proximity domain. Note that SRAT, SLIT and HMAT information can be enumerated dynamically in a standard way from device provided data. Think of CXL as the end of ACPI needing to describe memory attributes, CXL offers a standard discovery model for performance attributes, but Linux still needs to interoperate with the old regime. Reported-by: Derick Marks <derick.w.marks@intel.com> Suggested-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Alison Schofield <alison.schofield@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Tested-by: Derick Marks <derick.w.marks@intel.com> Link: https://lore.kernel.org/all/ef078a6f056ca974e5af85997013c0fda9e3326d.1689018477.git.alison.schofield%40intel.com Stable-dep-of: 8f1004679987 ("ACPI/NUMA: Apply SRAT proximity domain to entire CFMWS window") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20x86/srso: Fix unret validation dependenciesJosh Poimboeuf1-2/+2
[ Upstream commit eeb9f34df065f42f0c9195b322ba6df420c9fc92 ] CONFIG_CPU_SRSO isn't dependent on CONFIG_CPU_UNRET_ENTRY (AMD Retbleed), so the two features are independently configurable. Fix several issues for the (presumably rare) case where CONFIG_CPU_SRSO is enabled but CONFIG_CPU_UNRET_ENTRY isn't. Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation") Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/299fb7740174d0f2335e91c58af0e9c242b4bac1.1693889988.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20x86/srso: Fix vulnerability reporting for missing microcodeJosh Poimboeuf1-14/+22
[ Upstream commit dc6306ad5b0dda040baf1fde3cfd458e6abfc4da ] The SRSO default safe-ret mitigation is reported as "mitigated" even if microcode hasn't been updated. That's wrong because userspace may still be vulnerable to SRSO attacks due to IBPB not flushing branch type predictions. Report the safe-ret + !microcode case as vulnerable. Also report the microcode-only case as vulnerable as it leaves the kernel open to attacks. Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation") Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/a8a14f97d1b0e03ec255c81637afdf4cf0ae9c99.1693889988.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20x86/srso: Print mitigation for retbleed IBPB caseJosh Poimboeuf1-3/+3
[ Upstream commit de9f5f7b06a5b7adbfdd8016f011120a4e928add ] When overriding the requested mitigation with IBPB due to retbleed=ibpb, print the mitigation in the usual format instead of a custom error message. Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/ec3af919e267773d896c240faf30bfc6a1fd6304.1693889988.git.jpoimboe@kernel.org Stable-dep-of: dc6306ad5b0d ("x86/srso: Fix vulnerability reporting for missing microcode") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20x86/srso: Fix SBPB enablement for (possible) future fixed HWJosh Poimboeuf1-1/+1
[ Upstream commit 1d1142ac51307145dbb256ac3535a1d43a1c9800 ] Make the SBPB check more robust against the (possible) case where future HW has SRSO fixed but doesn't have the SRSO_NO bit set. Fixes: 1b5277c0ea0b ("x86/srso: Add SRSO_NO support") Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/cee5050db750b391c9f35f5334f8ff40e66c01b9.1693889988.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20iov_iter, x86: Be consistent about the __user tag on copy_mc_to_user()David Howells2-5/+5
[ Upstream commit 066baf92bed934c9fb4bcee97a193f47aa63431c ] copy_mc_to_user() has the destination marked __user on powerpc, but not on x86; the latter results in a sparse warning in lib/iov_iter.c. Fix this by applying the tag on x86 too. Fixes: ec6347bb4339 ("x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}()") Signed-off-by: David Howells <dhowells@redhat.com> Link: https://lore.kernel.org/r/20230925120309.1731676-3-dhowells@redhat.com cc: Dan Williams <dan.j.williams@intel.com> cc: Thomas Gleixner <tglx@linutronix.de> cc: Ingo Molnar <mingo@redhat.com> cc: Borislav Petkov <bp@alien8.de> cc: Dave Hansen <dave.hansen@linux.intel.com> cc: "H. Peter Anvin" <hpa@zytor.com> cc: Alexander Viro <viro@zeniv.linux.org.uk> cc: Jens Axboe <axboe@kernel.dk> cc: Christoph Hellwig <hch@lst.de> cc: Christian Brauner <christian@brauner.io> cc: Matthew Wilcox <willy@infradead.org> cc: Linus Torvalds <torvalds@linux-foundation.org> cc: David Laight <David.Laight@ACULAB.COM> cc: x86@kernel.org cc: linux-block@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-mm@kvack.org Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-28Merge tag 'x86-urgent-2023-10-28' of ↵Linus Torvalds5-9/+46
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull misc x86 fixes from Ingo Molnar: - Fix a possible CPU hotplug deadlock bug caused by the new TSC synchronization code - Fix a legacy PIC discovery bug that results in device troubles on affected systems, such as non-working keybards, etc - Add a new Intel CPU model number to <asm/intel-family.h> * tag 'x86-urgent-2023-10-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/tsc: Defer marking TSC unstable to a worker x86/i8259: Skip probing when ACPI/MADT advertises PCAT compatibility x86/cpu: Add model number for Intel Arrow Lake mobile processor
2023-10-28Merge tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds1-1/+1
Pull misc filesystem fixes from Al Viro: "Assorted fixes all over the place: literally nothing in common, could have been three separate pull requests. All are simple regression fixes, but not for anything from this cycle" * tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: ceph_wait_on_conflict_unlink(): grab reference before dropping ->d_lock io_uring: kiocb_done() should *not* trust ->ki_pos if ->{read,write}_iter() failed sparc32: fix a braino in fault handling in csum_and_copy_..._user()
2023-10-28sparc32: fix a braino in fault handling in csum_and_copy_..._user()Al Viro1-1/+1
Fault handler used to make non-trivial calls, so it needed to set a stack frame up. Used to be save ... - grab a stack frame, old %o... become %i... .... ret - go back to address originally in %o7, currently %i7 restore - switch to previous stack frame, in delay slot Non-trivial calls had been gone since ab5e8b331244 and that code should have become retl - go back to address in %o7 clr %o0 - have return value set to 0 What it had become instead was ret - go back to address in %i7 - return address of *caller* clr %o0 - have return value set to 0 which is not good, to put it mildly - we forcibly return 0 from csum_and_copy_{from,to}_iter() (which is what the call of that thing had been inlined into) and do that without dropping the stack frame of said csum_and_copy_..._iter(). Confuses the hell out of the caller of csum_and_copy_..._iter(), obviously... Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Fixes: ab5e8b331244 "sparc32: propagate the calling conventions change down to __csum_partial_copy_sparc_generic()" Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2023-10-27x86/tsc: Defer marking TSC unstable to a workerThomas Gleixner1-1/+9
Tetsuo reported the following lockdep splat when the TSC synchronization fails during CPU hotplug: tsc: Marking TSC unstable due to check_tsc_sync_source failed WARNING: inconsistent lock state inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. ffffffff8cfa1c78 (watchdog_lock){?.-.}-{2:2}, at: clocksource_watchdog+0x23/0x5a0 {IN-HARDIRQ-W} state was registered at: _raw_spin_lock_irqsave+0x3f/0x60 clocksource_mark_unstable+0x1b/0x90 mark_tsc_unstable+0x41/0x50 check_tsc_sync_source+0x14f/0x180 sysvec_call_function_single+0x69/0x90 Possible unsafe locking scenario: lock(watchdog_lock); <Interrupt> lock(watchdog_lock); stack backtrace: _raw_spin_lock+0x30/0x40 clocksource_watchdog+0x23/0x5a0 run_timer_softirq+0x2a/0x50 sysvec_apic_timer_interrupt+0x6e/0x90 The reason is the recent conversion of the TSC synchronization function during CPU hotplug on the control CPU to a SMP function call. In case that the synchronization with the upcoming CPU fails, the TSC has to be marked unstable via clocksource_mark_unstable(). clocksource_mark_unstable() acquires 'watchdog_lock', but that lock is taken with interrupts enabled in the watchdog timer callback to minimize interrupt disabled time. That's obviously a possible deadlock scenario, Before that change the synchronization function was invoked in thread context so this could not happen. As it is not crucical whether the unstable marking happens slightly delayed, defer the call to a worker thread which avoids the lock context problem. Fixes: 9d349d47f0e3 ("x86/smpboot: Make TSC synchronization function call based") Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87zg064ceg.ffs@tglx
2023-10-27x86/i8259: Skip probing when ACPI/MADT advertises PCAT compatibilityThomas Gleixner3-8/+35
David and a few others reported that on certain newer systems some legacy interrupts fail to work correctly. Debugging revealed that the BIOS of these systems leaves the legacy PIC in uninitialized state which makes the PIC detection fail and the kernel switches to a dummy implementation. Unfortunately this fallback causes quite some code to fail as it depends on checks for the number of legacy PIC interrupts or the availability of the real PIC. In theory there is no reason to use the PIC on any modern system when IO/APIC is available, but the dependencies on the related checks cannot be resolved trivially and on short notice. This needs lots of analysis and rework. The PIC detection has been added to avoid quirky checks and force selection of the dummy implementation all over the place, especially in VM guest scenarios. So it's not an option to revert the relevant commit as that would break a lot of other scenarios. One solution would be to try to initialize the PIC on detection fail and retry the detection, but that puts the burden on everything which does not have a PIC. Fortunately the ACPI/MADT table header has a flag field, which advertises in bit 0 that the system is PCAT compatible, which means it has a legacy 8259 PIC. Evaluate that bit and if set avoid the detection routine and keep the real PIC installed, which then gets initialized (for nothing) and makes the rest of the code with all the dependencies work again. Fixes: e179f6914152 ("x86, irq, pic: Probe for legacy PIC and set legacy_pic appropriately") Reported-by: David Lazar <dlazar@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: David Lazar <dlazar@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Cc: stable@vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218003 Link: https://lore.kernel.org/r/875y2u5s8g.ffs@tglx
2023-10-27x86/cpu: Add model number for Intel Arrow Lake mobile processorTony Luck1-0/+2
For "reasons" Intel has code-named this CPU with a "_H" suffix. [ dhansen: As usual, apply this and send it upstream quickly to make it easier for anyone who is doing work that consumes this. ] Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://lore.kernel.org/all/20231025202513.12358-1-tony.luck%40intel.com
2023-10-27Merge tag 'powerpc-6.6-6' of ↵Linus Torvalds3-11/+24
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: - Fix boot crash with FLATMEM since set_ptes() introduction - Avoid calling arch_enter/leave_lazy_mmu() in set_ptes() Thanks to Aneesh Kumar K.V and Erhard Furtner. * tag 'powerpc-6.6-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/mm: Avoid calling arch_enter/leave_lazy_mmu() in set_ptes powerpc/mm: Fix boot crash with FLATMEM
generated by cgit v1.2.3 (git 2.39.0) at 2025-03-03 02:52:40 +0300