summaryrefslogtreecommitdiff
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2023-04-26KVM: arm64: Fix buffer overflow in kvm_arm_set_fw_reg()Dan Carpenter1-0/+2
commit a25bc8486f9c01c1af6b6c5657234b2eee2c39d6 upstream. The KVM_REG_SIZE() comes from the ioctl and it can be a power of two between 0-32768 but if it is more than sizeof(long) this will corrupt memory. Fixes: 99adb567632b ("KVM: arm/arm64: Add save/restore support for firmware workaround state") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/4efbab8c-640f-43b2-8ac6-6d68e08280fe@kili.mountain Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-26KVM: arm64: Make vcpu flag updates non-preemptibleMarc Zyngier1-1/+18
commit 35dcb3ac663a16510afc27ba2725d70c15e012a5 upstream. Per-vcpu flags are updated using a non-atomic RMW operation. Which means it is possible to get preempted between the read and write operations. Another interesting thing to note is that preemption also updates flags, as we have some flag manipulation in both the load and put operations. It is thus possible to lose information communicated by either load or put, as the preempted flag update will overwrite the flags when the thread is resumed. This is specially critical if either load or put has stored information which depends on the physical CPU the vcpu runs on. This results in really elusive bugs, and kudos must be given to Mostafa for the long hours of debugging, and finally spotting the problem. Fix it by disabling preemption during the RMW operation, which ensures that the state stays consistent. Also upgrade vcpu_get_flag path to use READ_ONCE() to make sure the field is always atomically accessed. Fixes: e87abb73e594 ("KVM: arm64: Add helpers to manipulate vcpu flags among a set") Reported-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230418125737.2327972-1-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-26arm64: dts: imx8mp-verdin: correct off-on-delayPeng Fan2-3/+3
[ Upstream commit 02c447a0d79f0c966563e5095a017cbf9477ca6d ] The property should be off-on-delay-us, not off-on-delay Fixes: a39ed23bdf6e ("arm64: dts: freescale: add initial support for verdin imx8m plus") Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-26arm64: dts: imx8mm-verdin: correct off-on-delayPeng Fan1-2/+2
[ Upstream commit 130c1f4306d56301216baaea68afdd909892c73f ] The property should be off-on-delay-us, not off-on-delay Fixes: 6a57f224f734 ("arm64: dts: freescale: add initial support for verdin imx8m mini") Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-26arm64: dts: imx8mm-evk: correct pmic clock sourcePeng Fan1-1/+1
[ Upstream commit 85af7ffd24da38e416a14bd6bf207154d94faa83 ] The osc_32k supports #clock-cells as 0, using an id is wrong, drop it. Fixes: a6a355ede574 ("arm64: dts: imx8mm-evk: Add 32.768 kHz clock to PMIC") Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-26arm64: dts: qcom: sc8280xp-pmics: fix pon compatible and registersJohan Hovold1-2/+3
[ Upstream commit ad8cd35c58ca3ec5e93f52a0124899627b98efb2 ] The pmk8280 PMIC PON peripheral is gen3 and uses two sets of registers; hlos and pbs. This specifically fixes the following error message during boot when the pbs registers are not defined: PON_PBS address missing, can't read HW debounce time Note that this also enables the spurious interrupt workaround introduced by commit 0b65118e6ba3 ("Input: pm8941-pwrkey - add software key press debouncing support") (which may or may not be needed). Fixes: ccd3517faf18 ("arm64: dts: qcom: sc8280xp: Add reference device") Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Steev Klimaszewski <steev@kali.org> #Thinkpad X13s Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230327122948.4323-1-johan+linaro@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-26arm64: dts: meson-g12-common: specify full DMC rangeMarc Gonzalez1-2/+1
[ Upstream commit aec4353114a408b3a831a22ba34942d05943e462 ] According to S905X2 Datasheet - Revision 07: DRAM Memory Controller (DMC) register area spans ff638000-ff63a000. According to DeviceTree Specification - Release v0.4-rc1: simple-bus nodes do not require reg property. Fixes: 1499218c80c99a ("arm64: dts: move common G12A & G12B modes to meson-g12-common.dtsi") Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20230327120932.2158389-2-mgonzalez@freebox.fr Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-26arm64: dts: qcom: ipq8074-hk10: enable QMP device, not the PHY nodeDmitry Baryshkov1-2/+2
[ Upstream commit 1dc40551f206d20b7e46ea7dd538dcdd928451c6 ] Correct PCIe PHY enablement to refer the QMP device nodes rather than PHY device nodes. QMP nodes have 'status = "disabled"' property in the ipq8074.dtsi, while PHY nodes do not correspond to the actual device and do not have the status property. Fixes: 1ed34da63a37 ("arm64: dts: qcom: Add board support for HK10") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230324021651.1799969-2-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-26arm64: dts: qcom: hk10: use "okay" instead of "ok"Robert Marko1-8/+8
[ Upstream commit 7284a3943909606016128b79fb18dd107bc0fe26 ] Use "okay" instead of "ok" in USB nodes as "ok" is deprecated. Signed-off-by: Robert Marko <robimarko@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221107092930.33325-1-robimarko@gmail.com Stable-dep-of: 1dc40551f206 ("arm64: dts: qcom: ipq8074-hk10: enable QMP device, not the PHY node") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-26arm64: dts: qcom: ipq8074-hk01: enable QMP device, not the PHY nodeDmitry Baryshkov1-2/+2
[ Upstream commit 72630ba422b70ea0874fc90d526353cf71c72488 ] Correct PCIe PHY enablement to refer the QMP device nodes rather than PHY device nodes. QMP nodes have 'status = "disabled"' property in the ipq8074.dtsi, while PHY nodes do not correspond to the actual device and do not have the status property. Fixes: e8a7fdc505bb ("arm64: dts: ipq8074: qcom: Re-arrange dts nodes based on address") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230324021651.1799969-1-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-26arm64: dts: rockchip: Lower sd speed on rk3566-soquartzDan Johansen1-1/+1
[ Upstream commit 5912b647bd0732ae8c78a6e5b259c82efd177d93 ] Just like the Quartz64 Model B the previously stated speed of sdr-104 in soquartz is too high for the hardware to reliably communicate with some fast SD cards. Especially on some carrierboards. Lower this to sd-uhs-sdr50 to fix this. Fixes: 5859b5a9c3ac ("arm64: dts: rockchip: add SoQuartz CM4IO dts") Signed-off-by: Dan Johansen <strit@manjaro.org> Acked-by: Peter Geis <pgwipeout@gmail.com> Link: https://lore.kernel.org/r/20230304164135.28430-1-strit@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-20KVM: arm64: Advertise ID_AA64PFR0_EL1.CSV2/3 to protected VMsFuad Tabba3-9/+29
[ Upstream commit e81625218bf7986ba1351a98c43d346b15601d26 ] The existing pKVM code attempts to advertise CSV2/3 using values initialized to 0, but never set. To advertise CSV2/3 to protected guests, pass the CSV2/3 values to hyp when initializing hyp's view of guests' ID_AA64PFR0_EL1. Similar to non-protected KVM, these are system-wide, rather than per cpu, for simplicity. Fixes: 6c30bfb18d0b ("KVM: arm64: Add handlers for protected VM System Registers") Signed-off-by: Fuad Tabba <tabba@google.com> Link: https://lore.kernel.org/r/20230404152321.413064-1-tabba@google.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-20KVM: arm64: Initialise hypervisor copies of host symbols unconditionallyWill Deacon1-6/+9
[ Upstream commit 6c165223e9a6384aa1e934b90f2650e71adb972a ] The nVHE object at EL2 maintains its own copies of some host variables so that, when pKVM is enabled, the host cannot directly modify the hypervisor state. When running in normal nVHE mode, however, these variables are still mirrored at EL2 but are not initialised. Initialise the hypervisor symbols from the host copies regardless of pKVM, ensuring that any reference to this data at EL2 with normal nVHE will return a sensibly initialised value. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Vincent Donnefort <vdonnefort@google.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20221110190259.26861-16-will@kernel.org Stable-dep-of: e81625218bf7 ("KVM: arm64: Advertise ID_AA64PFR0_EL1.CSV2/3 to protected VMs") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-20bpf, arm64: Fixed a BTI error on returning to patched functionXu Kuohai2-1/+6
[ Upstream commit 738a96c4a8c36950803fdd27e7c30aca92dccefd ] When BPF_TRAMP_F_CALL_ORIG is set, BPF trampoline uses BLR to jump back to the instruction next to call site to call the patched function. For BTI-enabled kernel, the instruction next to call site is usually PACIASP, in this case, it's safe to jump back with BLR. But when the call site is not followed by a PACIASP or bti, a BTI exception is triggered. Here is a fault log: Unhandled 64-bit el1h sync exception on CPU0, ESR 0x0000000034000002 -- BTI CPU: 0 PID: 263 Comm: test_progs Tainted: GF Hardware name: linux,dummy-virt (DT) pstate: 40400805 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=-c) pc : bpf_fentry_test1+0xc/0x30 lr : bpf_trampoline_6442573892_0+0x48/0x1000 sp : ffff80000c0c3a50 x29: ffff80000c0c3a90 x28: ffff0000c2e6c080 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000050 x23: 0000000000000000 x22: 0000ffffcfd2a7f0 x21: 000000000000000a x20: 0000ffffcfd2a7f0 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffcfd2a7f0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff80000914f5e4 x9 : ffff8000082a1528 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0101010101010101 x5 : 0000000000000000 x4 : 00000000fffffff2 x3 : 0000000000000001 x2 : ffff8001f4b82000 x1 : 0000000000000000 x0 : 0000000000000001 Kernel panic - not syncing: Unhandled exception CPU: 0 PID: 263 Comm: test_progs Tainted: GF Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0xec/0x144 show_stack+0x24/0x7c dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 panic+0x1cc/0x3ec __el0_error_handler_common+0x0/0x130 el1h_64_sync_handler+0x60/0xd0 el1h_64_sync+0x78/0x7c bpf_fentry_test1+0xc/0x30 bpf_fentry_test1+0xc/0x30 bpf_prog_test_run_tracing+0xdc/0x2a0 __sys_bpf+0x438/0x22a0 __arm64_sys_bpf+0x30/0x54 invoke_syscall+0x78/0x110 el0_svc_common.constprop.0+0x6c/0x1d0 do_el0_svc+0x38/0xe0 el0_svc+0x30/0xd0 el0t_64_sync_handler+0x1ac/0x1b0 el0t_64_sync+0x1a0/0x1a4 Kernel Offset: disabled CPU features: 0x0000,00034c24,f994fdab Memory Limit: none And the instruction next to call site of bpf_fentry_test1 is ADD, not PACIASP: <bpf_fentry_test1>: bti c nop nop add w0, w0, #0x1 paciasp For BPF prog, JIT always puts a PACIASP after call site for BTI-enabled kernel, so there is no problem. To fix it, replace BLR with RET to bypass the branch target check. Fixes: efc9909fdce0 ("bpf, arm64: Add bpf trampoline for arm64") Reported-by: Florent Revest <revest@chromium.org> Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Tested-by: Florent Revest <revest@chromium.org> Acked-by: Florent Revest <revest@chromium.org> Link: https://lore.kernel.org/bpf/20230401234144.3719742-1-xukuohai@huaweicloud.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-20KVM: arm64: PMU: Restore the guest's EL0 event counting after migrationReiji Watanabe2-1/+1
commit f9ea835e99bc8d049bf2a3ec8fa5a7cb4fcade23 upstream. Currently, with VHE, KVM enables the EL0 event counting for the guest on vcpu_load() or KVM enables it as a part of the PMU register emulation process, when needed. However, in the migration case (with VHE), the same handling is lacking, as vPMU register values that were restored by userspace haven't been propagated yet (the PMU events haven't been created) at the vcpu load-time on the first KVM_RUN (kvm_vcpu_pmu_restore_guest() called from vcpu_load() on the first KVM_RUN won't do anything as events_{guest,host} of kvm_pmu_events are still zero). So, with VHE, enable the guest's EL0 event counting on the first KVM_RUN (after the migration) when needed. More specifically, have kvm_pmu_handle_pmcr() call kvm_vcpu_pmu_restore_guest() so that kvm_pmu_handle_pmcr() on the first KVM_RUN can take care of it. Fixes: d0c94c49792c ("KVM: arm64: Restore PMU configuration on first run") Cc: stable@vger.kernel.org Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Reiji Watanabe <reijiw@google.com> Link: https://lore.kernel.org/r/20230329023944.2488484-1-reijiw@google.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-13arm64: compat: Work around uninitialized variable warningArd Biesheuvel1-18/+14
[ Upstream commit 32d85999680601d01b2a36713c9ffd7397c8688b ] Dan reports that smatch complains about a potential uninitialized variable being used in the compat alignment fixup code. The logic is not wrong per se, but we do end up using an uninitialized variable if reading the instruction that triggered the alignment fault from user space faults, even if the fault ensures that the uninitialized value doesn't propagate any further. Given that we just give up and return 1 if any fault occurs when reading the instruction, let's get rid of the 'success handling' pattern that captures the fault in a variable and aborts later, and instead, just return 1 immediately if any of the get_user() calls result in an exception. Fixes: 3fc24ef32d3b ("arm64: compat: Implement misalignment fixups for multiword loads") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Link: https://lore.kernel.org/r/202304021214.gekJ8yRc-lkp@intel.com/ Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20230404103625.2386382-1-ardb@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-13KVM: arm64: PMU: Don't save PMCR_EL0.{C,P} for the vCPUReiji Watanabe1-1/+2
[ Upstream commit f6da81f650fa47b61b847488f3938d43f90d093d ] Presently, when a guest writes 1 to PMCR_EL0.{C,P}, which is WO/RAZ, KVM saves the register value, including these bits. When userspace reads the register using KVM_GET_ONE_REG, KVM returns the saved register value as it is (the saved value might have these bits set). This could result in userspace setting these bits on the destination during migration. Consequently, KVM may end up resetting the vPMU counter registers (PMCCNTR_EL0 and/or PMEVCNTR<n>_EL0) to zero on the first KVM_RUN after migration. Fix this by not saving those bits when a guest writes 1 to those bits. Fixes: ab9468340d2b ("arm64: KVM: Add access handler for PMCR register") Cc: stable@vger.kernel.org Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Reiji Watanabe <reijiw@google.com> Link: https://lore.kernel.org/r/20230313033234.1475987-1-reijiw@google.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-13KVM: arm64: PMU: Sanitise PMCR_EL0.LP on first vcpu runMarc Zyngier2-2/+6
[ Upstream commit 64d6820d64c0a206e744bd8945374d563a76c16c ] Userspace can play some dirty tricks on us by selecting a given PMU version (such as PMUv3p5), restore a PMCR_EL0 value that has PMCR_EL0.LP set, and then switch the PMU version to PMUv3p1, for example. In this situation, we end-up with PMCR_EL0.LP being set and spreading havoc in the PMU emulation. This is specially hard as the first two step can be done on one vcpu and the third step on another, meaning that we need to sanitise *all* vcpus when the PMU version is changed. In orer to avoid a pretty complicated locking situation, defer the sanitisation of PMCR_EL0 to the point where the vcpu is actually run for the first tine, using the existing KVM_REQ_RELOAD_PMU request that calls into kvm_pmu_handle_pmcr(). There is still an obscure corner case where userspace could do the above trick, and then save the VM without running it. They would then observe an inconsistent state (PMUv3.1 + LP set), but that state will be fixed on the first run anyway whenever the guest gets restored on a host. Reported-by: Reiji Watanabe <reijiw@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Stable-dep-of: f6da81f650fa ("KVM: arm64: PMU: Don't save PMCR_EL0.{C,P} for the vCPU") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-13KVM: arm64: PMU: Distinguish between 64bit counter and 64bit overflowMarc Zyngier1-12/+31
[ Upstream commit c82d28cbf1d4f9fe174041b4485c635cb970afa7 ] The PMU architecture makes a subtle difference between a 64bit counter and a counter that has a 64bit overflow. This is for example the case of the cycle counter, which can generate an overflow on a 32bit boundary if PMCR_EL0.LC==0 despite the accumulation being done on 64 bits. Use this distinction in the few cases where it matters in the code, as we will reuse this with PMUv3p5 long counters. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20221113163832.3154370-5-maz@kernel.org Stable-dep-of: f6da81f650fa ("KVM: arm64: PMU: Don't save PMCR_EL0.{C,P} for the vCPU") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-13KVM: arm64: PMU: Align chained counter implementation with architecture ↵Marc Zyngier1-234/+86
pseudocode [ Upstream commit bead02204e9806807bb290137b1ccabfcb4b16fd ] Ricardo recently pointed out that the PMU chained counter emulation in KVM wasn't quite behaving like the one on actual hardware, in the sense that a chained counter would expose an overflow on both halves of a chained counter, while KVM would only expose the overflow on the top half. The difference is subtle, but significant. What does the architecture say (DDI0087 H.a): - Up to PMUv3p4, all counters but the cycle counter are 32bit - A 32bit counter that overflows generates a CHAIN event on the adjacent counter after exposing its own overflow status - The CHAIN event is accounted if the counter is correctly configured (CHAIN event selected and counter enabled) This all means that our current implementation (which uses 64bit perf events) prevents us from emulating this overflow on the lower half. How to fix this? By implementing the above, to the letter. This largely results in code deletion, removing the notions of "counter pair", "chained counters", and "canonical counter". The code is further restructured to make the CHAIN handling similar to SWINC, as the two are now extremely similar in behaviour. Reported-by: Ricardo Koller <ricarkol@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Reiji Watanabe <reijiw@google.com> Link: https://lore.kernel.org/r/20221113163832.3154370-3-maz@kernel.org Stable-dep-of: f6da81f650fa ("KVM: arm64: PMU: Don't save PMCR_EL0.{C,P} for the vCPU") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-06KVM: arm64: Disable interrupts while walking userspace PTsMarc Zyngier1-7/+38
commit e86fc1a3a3e9b4850fe74d738e3cfcf4297d8bba upstream. We walk the userspace PTs to discover what mapping size was used there. However, this can race against the userspace tables being freed, and we end-up in the weeds. Thankfully, the mm code is being generous and will IPI us when doing so. So let's implement our part of the bargain and disable interrupts around the walk. This ensures that nothing terrible happens during that time. We still need to handle the removal of the page tables before the walk. For that, allow get_user_mapping_size() to return an error, and make sure this error can be propagated all the way to the the exit handler. Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230316174546.3777507-2-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-06KVM: arm64: PMU: Fix GET_ONE_REG for vPMC regs to return the current valueReiji Watanabe1-2/+19
commit 9228b26194d1cc00449f12f306f53ef2e234a55b upstream. Have KVM_GET_ONE_REG for vPMU counter (vPMC) registers (PMCCNTR_EL0 and PMEVCNTR<n>_EL0) return the sum of the register value in the sysreg file and the current perf event counter value. Values of vPMC registers are saved in sysreg files on certain occasions. These saved values don't represent the current values of the vPMC registers if the perf events for the vPMCs count events after the save. The current values of those registers are the sum of the sysreg file value and the current perf event counter value. But, when userspace reads those registers (using KVM_GET_ONE_REG), KVM returns the sysreg file value to userspace (not the sum value). Fix this to return the sum value for KVM_GET_ONE_REG. Fixes: 051ff581ce70 ("arm64: KVM: Add access handler for event counter register") Cc: stable@vger.kernel.org Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Reiji Watanabe <reijiw@google.com> Link: https://lore.kernel.org/r/20230313033208.1475499-1-reijiw@google.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-06arm64: efi: Set NX compat flag in PE/COFF headerArd Biesheuvel1-1/+1
[ Upstream commit 3c66bb1918c262dd52fb4221a8d372619c5da70a ] The PE/COFF header has a NX compat flag which informs the firmware that the application does not rely on memory regions being mapped with both executable and writable permissions at the same time. This is typically used by the firmware to decide whether it can set the NX attribute on all allocations it returns, but going forward, it may be used to enforce a policy that only permits applications with the NX flag set to be loaded to begin wiht in some configurations, e.g., when Secure Boot is in effect. Even though the arm64 version of the EFI stub may relocate the kernel before executing it, it always did so after disabling the MMU, and so we were always in line with what the NX compat flag conveys, we just never bothered to set it. So let's set the flag now. Cc: <stable@vger.kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30arm64: dts: qcom: sm8150: Fix the iommu mask used for PCIe controllersManivannan Sadhasivam1-2/+2
commit 672a58fc7c477e59981653a11241566870fff852 upstream. The iommu mask should be 0x3f as per Qualcomm internal documentation. Without the correct mask, the PCIe transactions from the endpoint will result in SMMU faults. Hence, fix it! Cc: stable@vger.kernel.org # 5.19 Fixes: a1c86c680533 ("arm64: dts: qcom: sm8150: Add PCIe nodes") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230224080045.6577-1-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-30arm64: dts: qcom: sc7280: Mark PCIe controller as cache coherentKrishna chaitanya chundru1-0/+2
commit 8a63441e83724fee1ef3fd37b237d40d90780766 upstream. If the controller is not marked as cache coherent, then kernel will try to ensure coherency during dma-ops and that may cause data corruption. So, mark the PCIe node as dma-coherent as the devices on PCIe bus are cache coherent. Cc: stable@vger.kernel.org Fixes: 92e0ee9f83b3 ("arm64: dts: qcom: sc7280: Add PCIe and PHY related node") Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/1677584952-17496-1-git-send-email-quic_krichai@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-30arm64: dts: imx8mm-nitrogen-r2: fix WM8960 clock nameKrzysztof Kozlowski1-1/+1
commit 32f86da7c86b27ebed31c24453a0713f612e43fb upstream. The WM8960 Linux driver expects the clock to be named "mclk". Otherwise the clock will be ignored and not prepared/enabled by the driver. Fixes: 40ba2eda0a7b ("arm64: dts: imx8mm-nitrogen-r2: add audio") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-30arm64: dts: imx93: add missing #address-cells and #size-cells to i2c nodesAlexander Stein1-0/+16
[ Upstream commit b3cdf730486b048ca0bf23bef050550d9fd40422 ] Add them to the SoC .dtsi, so that not every board has to specify them. Fixes: 1225396fefea ("arm64: dts: imx93: add lpi2c nodes") Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30arm64: dts: imx8mn: specify #sound-dai-cells for SAI nodesMarek Vasut1-0/+5
[ Upstream commit 62fb54148cd6eb456ff031be8fb447c98cf0bd9b ] Add #sound-dai-cells properties to SAI nodes. Reviewed-by: Adam Ford <aford173@gmail.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Fixes: 9e9860069725 ("arm64: dts: imx8mn: Add SAI nodes") Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30arm64: dts: imx8dxl-evk: Fix eqos phy reset gpioAndrew Halaney1-2/+3
[ Upstream commit feafeb53140af3cde3fba46b292b15b3a0c0635c ] The deprecated property is named snps,reset-gpio, but this devicetree used snps,reset-gpios instead which results in the reset not being used and the following make dtbs_check error: ./arch/arm64/boot/dts/freescale/imx8dxl-evk.dtb: ethernet@5b050000: 'snps,reset-gpio' is a dependency of 'snps,reset-delays-us' From schema: ./Documentation/devicetree/bindings/net/snps,dwmac.yaml Use the preferred method of defining the reset gpio in the phy node itself. Note that this drops the 10 us pre-delay, but prior this wasn't used at all and a pre-delay doesn't make much sense in this context so it should be fine. Fixes: 8dd495d12374 ("arm64: dts: freescale: add support for i.MX8DXL EVK board") Signed-off-by: Andrew Halaney <ahalaney@redhat.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30arm64: dts: imx8dxl-evk: Disable hibernation mode of AR8031 for EQOSWei Fang1-0/+1
[ Upstream commit 0deefb5bd1382aae0aed7c8b266d5088a5308a26 ] The hibernation mode of AR8031 PHY defaults to be enabled after hardware reset. When the cable is unplugged, the PHY will enter hibernation mode after about 10 senconds and the PHY clocks will be stopped to save power. However, due to the design of EQOS, the mac needs the RX_CLK of PHY for software reset to complete. Otherwise the software reset of EQOS will be failed and do not work correctly. The only way is to disable hibernation mode of AR8031 PHY for EQOS, the "qca,disable-hibernation-mode" property is used for this purpose and has already been submitted to the upstream, for more details please refer to the below link: https://lore.kernel.org/netdev/20220818030054.1010660-2-wei.fang@nxp.com/ This issue is easy to reproduce, just unplug the cable and "ifconfig eth0 down", after about 10 senconds, then "ifconfig eth0 up", you will see failure log on the serial port. The log is shown as following: root@imx8dxlevk:~# [34.941970] imx-dwmac 5b050000.ethernet eth0: Link is Down root@imx8dxlevk:~# ifconfig eth0 down [35.437814] imx-dwmac 5b050000.ethernet eth0: FPE workqueue stop [35.507913] imx-dwmac 5b050000.ethernet eth0: PHY [stmmac-1:00] driver [Qualcomm Atheros AR8031/AR8033] (irq=POLL) [35.518613] imx-dwmac 5b050000.ethernet eth0: configuring for phy/rgmii-id link mode root@imx8dxlevk:~# ifconfig eth0 up [71.143044] imx-dwmac 5b050000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [71.215855] imx-dwmac 5b050000.ethernet eth0: PHY [stmmac-1:00] driver [Qualcomm Atheros AR8031/AR8033] (irq=POLL) [72.230417] imx-dwmac 5b050000.ethernet: Failed to reset the dma [72.236512] imx-dwmac 5b050000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed [72.245258] imx-dwmac 5b050000.ethernet eth0: __stmmac_open: Hw setup failed SIOCSIFFLAGS: Connection timed out After applying this patch, the software reset of EQOS will be successful. And the log is shown as below. root@imx8dxlevk:~# ifconfig eth0 up [96.114344] imx-dwmac 5b050000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [96.171466] imx-dwmac 5b050000.ethernet eth0: PHY [stmmac-1:00] driver [Qualcomm Atheros AR8031/AR8033] (irq=POLL) [96.188883] imx-dwmac 5b050000.ethernet eth0: No Safety Features support found [96.196221] imx-dwmac 5b050000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported [96.204846] imx-dwmac 5b050000.ethernet eth0: registered PTP clock [96.225558] imx-dwmac 5b050000.ethernet eth0: FPE workqueue start [96.236858] imx-dwmac 5b050000.ethernet eth0: configuring for phy/rgmii-id link mode [96.249358] 8021q: adding VLAN 0 to HW filter on device eth0 Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Clark Wang <xiaoning.wang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Stable-dep-of: feafeb53140a ("arm64: dts: imx8dxl-evk: Fix eqos phy reset gpio") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30arm64: dts: qcom: sm8450: Mark UFS controller as cache coherentManivannan Sadhasivam1-0/+1
[ Upstream commit 8ba961d4339c5db0e69ff6627606fe1f34c838e5 ] The UFS controller on SM8450 supports cache coherency, hence add the "dma-coherent" property to mark it as such. Fixes: 07fa917a335e ("arm64: dts: qcom: sm8450: add ufs nodes") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230307153201.180626-2-manivannan.sadhasivam@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-11arm64: Reset KASAN tag in copy_highpage with HW tags onlyPeter Collingbourne1-1/+2
commit e74a68468062d7ebd8ce17069e12ccc64cc6a58c upstream. During page migration, the copy_highpage function is used to copy the page data to the target page. If the source page is a userspace page with MTE tags, the KASAN tag of the target page must have the match-all tag in order to avoid tag check faults during subsequent accesses to the page by the kernel. However, the target page may have been allocated in a number of ways, some of which will use the KASAN allocator and will therefore end up setting the KASAN tag to a non-match-all tag. Therefore, update the target page's KASAN tag to match the source page. We ended up unintentionally fixing this issue as a result of a bad merge conflict resolution between commit e059853d14ca ("arm64: mte: Fix/clarify the PG_mte_tagged semantics") and commit 20794545c146 ("arm64: kasan: Revert "arm64: mte: reset the page tag in page->flags""), which preserved a tag reset for PG_mte_tagged pages which was considered to be unnecessary at the time. Because SW tags KASAN uses separate tag storage, update the code to only reset the tags when HW tags KASAN is enabled. Signed-off-by: Peter Collingbourne <pcc@google.com> Link: https://linux-review.googlesource.com/id/If303d8a709438d3ff5af5fd85706505830f52e0c Reported-by: "Kuan-Ying Lee (李冠穎)" <Kuan-Ying.Lee@mediatek.com> Cc: <stable@vger.kernel.org> # 6.1 Fixes: 20794545c146 ("arm64: kasan: Revert "arm64: mte: reset the page tag in page->flags"") Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com> Link: https://lore.kernel.org/r/20230215050911.1433132-1-pcc@google.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-11arm64: mte: Fix/clarify the PG_mte_tagged semanticsCatalin Marinas11-18/+56
commit e059853d14ca4ed0f6a190d7109487918a22a976 upstream. Currently the PG_mte_tagged page flag mostly means the page contains valid tags and it should be set after the tags have been cleared or restored. However, in mte_sync_tags() it is set before setting the tags to avoid, in theory, a race with concurrent mprotect(PROT_MTE) for shared pages. However, a concurrent mprotect(PROT_MTE) with a copy on write in another thread can cause the new page to have stale tags. Similarly, tag reading via ptrace() can read stale tags if the PG_mte_tagged flag is set before actually clearing/restoring the tags. Fix the PG_mte_tagged semantics so that it is only set after the tags have been cleared or restored. This is safe for swap restoring into a MAP_SHARED or CoW page since the core code takes the page lock. Add two functions to test and set the PG_mte_tagged flag with acquire and release semantics. The downside is that concurrent mprotect(PROT_MTE) on a MAP_SHARED page may cause tag loss. This is already the case for KVM guests if a VMM changes the page protection while the guest triggers a user_mem_abort(). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> [pcc@google.com: fix build with CONFIG_ARM64_MTE disabled] Signed-off-by: Peter Collingbourne <pcc@google.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Steven Price <steven.price@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Marc Zyngier <maz@kernel.org> Cc: Peter Collingbourne <pcc@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20221104011041.290951-3-pcc@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-11arm64: efi: Make efi_rt_lock a raw_spinlockPierre Gondois2-4/+4
commit 0e68b5517d3767562889f1d83fdb828c26adb24f upstream. Running a rt-kernel base on 6.2.0-rc3-rt1 on an Ampere Altra outputs the following: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 9, name: kworker/u320:0 preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 3 locks held by kworker/u320:0/9: #0: ffff3fff8c27d128 ((wq_completion)efi_rts_wq){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41) #1: ffff80000861bdd0 ((work_completion)(&efi_rts_work.work)){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41) #2: ffffdf7e1ed3e460 (efi_rt_lock){+.+.}-{3:3}, at: efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101) Preemption disabled at: efi_virtmap_load (./arch/arm64/include/asm/mmu_context.h:248) CPU: 0 PID: 9 Comm: kworker/u320:0 Tainted: G W 6.2.0-rc3-rt1 Hardware name: WIWYNN Mt.Jade Server System B81.03001.0005/Mt.Jade Motherboard, BIOS 1.08.20220218 (SCP: 1.08.20220218) 2022/02/18 Workqueue: efi_rts_wq efi_call_rts Call trace: dump_backtrace (arch/arm64/kernel/stacktrace.c:158) show_stack (arch/arm64/kernel/stacktrace.c:165) dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4)) dump_stack (lib/dump_stack.c:114) __might_resched (kernel/sched/core.c:10134) rt_spin_lock (kernel/locking/rtmutex.c:1769 (discriminator 4)) efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101) [...] This seems to come from commit ff7a167961d1 ("arm64: efi: Execute runtime services from a dedicated stack") which adds a spinlock. This spinlock is taken through: efi_call_rts() \-efi_call_virt() \-efi_call_virt_pointer() \-arch_efi_call_virt_setup() Make 'efi_rt_lock' a raw_spinlock to avoid being preempted. [ardb: The EFI runtime services are called with a different set of translation tables, and are permitted to use the SIMD registers. The context switch code preserves/restores neither, and so EFI calls must be made with preemption disabled, rather than only disabling migration.] Fixes: ff7a167961d1 ("arm64: efi: Execute runtime services from a dedicated stack") Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Cc: <stable@vger.kernel.org> # v6.1+ Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-10arm64: mm: hugetlb: Disable HUGETLB_PAGE_OPTIMIZE_VMEMMAPCatalin Marinas1-1/+0
commit 060a2c92d1b627c86c5c42ca69baf00457c00c5a upstream. Revert the HUGETLB_PAGE_FREE_VMEMMAP selection from commit 1e63ac088f20 ("arm64: mm: hugetlb: enable HUGETLB_PAGE_FREE_VMEMMAP for arm64") but keep the flush_dcache_page() compound_head() change as it aligns with the corresponding check in the __sync_icache_dcache() function. The original config option was renamed in commit 47010c040dec ("mm: hugetlb_vmemmap: cleanup CONFIG_HUGETLB_PAGE_FREE_VMEMMAP*") to HUGETLB_PAGE_OPTIMIZE_VMEMMAP and the flush_dcache_page() check was further simplified by commit 2da1c30929a2 ("mm: hugetlb_vmemmap: delete hugetlb_optimize_vmemmap_enabled()"). The reason for the revert is that the generic vmemmap_remap_pte() function changes both the permissions (writeable to read-only) and the output address (pfn) of the vmemmap ptes. This is deemed UNPREDICTABLE by the Arm architecture without a break-before-make sequence (make the PTE invalid, TLBI, write the new valid PTE). However, such sequence is not possible since the vmemmap may be concurrently accessed by the kernel. Disable the optimisation until a better solution is found. Fixes: 1e63ac088f20 ("arm64: mm: hugetlb: enable HUGETLB_PAGE_FREE_VMEMMAP for arm64") Cc: <stable@vger.kernel.org> # 5.19.x Cc: Muchun Song <muchun.song@linux.dev> Cc: Will Deacon <will@kernel.org> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/Y9pZALdn3pKiJUeQ@arm.com Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/20230222175232.540851-1-catalin.marinas@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-10arm64: zynqmp: Enable hs termination flag for USB dwc3 controllerMichael Grzeschik1-0/+2
[ Upstream commit 32405e532d358a2f9d4befae928b9883c8597616 ] Since we need to support legacy phys with the dwc3 controller, we enable this quirk on the zynqmp platforms. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20221023215649.221726-1-m.grzeschik@pengutronix.de Signed-off-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: msm8996: Add additional A2NoC clocksKonrad Dybcio1-2/+4
[ Upstream commit 67fb53745e0b38275fa0b422b6a3c6c1c028c9a2 ] On eMMC devices, the UFS clocks aren't started in the bootloader (or well, at least it should not be, as that would just leak power..), which results in platform reboots when trying to access the unclocked UFS hardware, which unfortunately happens on each and every boot, as interconnect calls sync_state and goes over each and every path. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> #db820c Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221210200353.418391-6-konrad.dybcio@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64/cpufeature: Fix field sign for DIT hwcap detectionMark Brown1-1/+1
[ Upstream commit 50daf5b7c4ec4efcaf49a4128930f872bec7dbc0 ] Since it was added our hwcap for DIT has specified that DIT is a signed field but this appears to be incorrect, the two values for the enumeration are: 0b0000 NI 0b0001 IMP which look like a normal unsigned enumeration and the in-kernel DIT usage added by 01ab991fc0ee ("arm64: Enable data independent timing (DIT) in the kernel") detects the feature with an unsigned enum. Fix the hwcap to specify the field as unsigned. Fixes: 7206dc93a58f ("arm64: Expose Arm v8.4 features") Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221207-arm64-sysreg-helpers-v3-1-0d71a7b174a8@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: pmk8350: Use the correct PON compatibleKonrad Dybcio1-1/+1
[ Upstream commit c0ee8e0ba5cc17623e63349a168b41e407b1eef0 ] A special compatible was introduced for PMK8350 both in the driver and the bindings to facilitate for 2 base registers (PBS & HLOS). Use it. Fixes: b2de43136058 ("arm64: dts: qcom: pmk8350: Add peripherals for pmk8350") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230213212930.2115182-1-konrad.dybcio@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: pmk8350: Specify PBS register for PONKonrad Dybcio1-1/+2
[ Upstream commit f46ef374e0dcb8fd2f272a376cf0dcdab7e52fc2 ] PMK8350 is the first PMIC to require both HLOS and PBS registers for PON to function properly (at least in theory, sm8350 sees no change). The support for it on the driver side has been added long ago, but it has never been wired up. Do so. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221115132626.7465-1-konrad.dybcio@linaro.org Stable-dep-of: c0ee8e0ba5cc ("arm64: dts: qcom: pmk8350: Use the correct PON compatible") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: msm8992-lg-bullhead: Enable regulatorsPetr Vorel1-22/+10
[ Upstream commit 2866527093ddbc6356bb31f560f0b4b4decf3e2e ] Enable pm8994_s1, pm8994_l{26,29,30,32} regulators. Use values from downstream kernel on bullhead rev 1.01. NOTE: downstream kernel on angler rev 1.01 differences: * pm8994_l29: regulator-min-microvolt = <2700000> * pm8994_l{20,28,31}: use regulator-boot-on Verification: [ 1.832460] s1: Bringing 0uV into 1025000-1025000uV ... [ 2.057667] l26: Bringing 0uV into 987500-987500uV ... [ 2.075722] l29: Bringing 0uV into 2800000-2800000uV [ 2.076604] l30: Bringing 0uV into 1800000-1800000uV [ 2.082431] l31: Bringing 0uV into 1262500-1262500uV [ 2.095767] l32: Bringing 0uV into 1800000-1800000uV Fixes: f3b2c99e73be ("arm64: dts: Enable onboard SDHCI on msm8992") Signed-off-by: Petr Vorel <pvorel@suse.cz> Tested-by: Jamie Douglass <jamiemdouglass@gmail.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230203100952.13857-1-pvorel@suse.cz Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: msm8992-*: Fix up commentsKonrad Dybcio4-22/+28
[ Upstream commit 290d43062d261cebd17ff590dc91f1d1e3fe6eed ] Make sure all multiline C-style commends begin with just '/*' with the comment text starting on a new line. Also, trim off downstream regulator properties from comments to prevent them from accidentally landing into mainline one day.. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221107145522.6706-9-konrad.dybcio@linaro.org Stable-dep-of: 2866527093dd ("arm64: dts: qcom: msm8992-lg-bullhead: Enable regulators") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: msm8953: correct TLMM gpio-rangesKrzysztof Kozlowski1-1/+1
[ Upstream commit a4fb71497df23cb0d02d70fa2b8f8786328e325d ] Correct the number of GPIOs in TLMM pin controller. Fixes: 9fb08c801923 ("arm64: dts: qcom: Add MSM8953 device tree") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Luca Weiss <luca@z3ntu.xyz> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230202104452.299048-10-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: msm8992-lg-bullhead: Correct memory overlaps with the SMEM ↵Jamie Douglass1-2/+7
and MPSS memory regions [ Upstream commit d44106883d74992343710f18c4aaae937c7cefab ] The memory region reserved by a previous commit (see fixes tag below) overlaps with the SMEM and MPSS memory regions, causing error messages in dmesg: OF: reserved mem: OVERLAP DETECTED! reserved@5000000 (0x0000000005000000--0x0000000007200000) overlaps with smem_region@6a00000 (0x0000000006a00000--0x0000000006c00000) OF: reserved mem: OVERLAP DETECTED! reserved@6c00000 (0x0000000006c00000--0x0000000007200000) overlaps with memory@7000000 (0x0000000007000000--0x000000000ca00000) This patch resolves both of these by splitting the previously reserved memory region into two sections either side of the SMEM region and by cutting off the second memory region to 0x7000000. Fixes: 22c7e1a0fa45 ("arm64: dts: msm8992-bullhead: add memory hole region") Signed-off-by: Jamie Douglass <jamiemdouglass@gmail.com> Reviewed-by: Petr Vorel <pvorel@suse.cz> Tested-by: Petr Vorel <pvorel@suse.cz> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230202054819.16079-1-jamiemdouglass@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: sm8450: drop incorrect cells from serialKrzysztof Kozlowski1-4/+0
[ Upstream commit 60d2da2c916956535cf37b7bf1ae8fefbf432e55 ] The serial/UART device node does not have children with unit addresses, so address/size cells are not correct. Fixes: f5837418479a ("arm64: dts: qcom: sm8450: add uart20 node") Fixes: 5188049c9b36 ("arm64: dts: qcom: Add base SM8450 DTSI") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230124084951.38195-3-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: sm8350: drop incorrect cells from serialKrzysztof Kozlowski1-2/+0
[ Upstream commit 6027331e6eae9eb957d1b73a7e3255f4151d6163 ] The serial/UART device node does not have children with unit addresses, so address/size cells are not correct. Fixes: cf03cd7e12bd ("arm64: dts: qcom: sm8350: Set up WRAP0 QUPs") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230124084951.38195-2-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: msm8996 switch from RPM_SMD_BB_CLK1 to RPM_SMD_XO_CLK_SRCDmitry Baryshkov1-7/+7
[ Upstream commit 8ae72166c2b73b0f2ce498ea15d4feceb9fef50e ] The vendor kernel uses RPM_SMD_XO_CLK_SRC clock as an CXO clock rather than using the RPM_SMD_BB_CLK1 directly. Follow this example and switch msm8996.dtsi to use RPM_SMD_XO_CLK_SRC clock instead of RPM_SMB_BB_CLK1. Fixes: 2b8c9c77c268 ("arm64: dts: qcom: msm8996: convert xo_board to RPM_SMD_BB_CLK1") Suggested-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230120061417.2623751-7-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: msm8996: support using GPLL0 as kryocc inputDmitry Baryshkov1-2/+2
[ Upstream commit ac0d84d4556cecf81ba0b1631d25d9a395235a5c ] In some cases the driver might need using GPLL0 to drive CPU clocks. Bring it in through the sys_apcs_aux clock. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230113120544.59320-15-dmitry.baryshkov@linaro.org Stable-dep-of: 8ae72166c2b7 ("arm64: dts: qcom: msm8996 switch from RPM_SMD_BB_CLK1 to RPM_SMD_XO_CLK_SRC") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: mediatek: mt7986: Fix watchdog compatibleAllen-KH Cheng1-2/+1
[ Upstream commit 70d24df30d06e5c822ba94751166ef55d0e28a89 ] MT7986's watchdog embeds a reset controller and needs only the mediatek,mt7986-wdt compatible string as the MT6589 one is there for watchdogs that don't have any reset controller capability. Fixes: 50137c150f5f ("arm64: dts: mediatek: add basic mt7986 support") Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20221108033209.22751-4-allen-kh.cheng@mediatek.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: mediatek: mt8195: Fix watchdog compatibleAngeloGioacchino Del Regno1-2/+1
[ Upstream commit 02938f460cde0d360dde48056c4d1c0a4bd49230 ] MT8195's watchdog embeds a reset controller and needs only the mediatek,mt8195-wdt compatible string as the MT6589 one is there for watchdogs that don't have any reset controller capability. Fixes: 37f2582883be ("arm64: dts: Add mediatek SoC mt8195 and evaluation board") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Co-developed-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20221108033209.22751-3-allen-kh.cheng@mediatek.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>