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: resolve conflict between canvas & pmuMarc Gonzalez1-6/+6
[ Upstream commit 33acea2049b5058b93d1dabb536b494f543f02a2 ] According to S905X2 Datasheet - Revision 07: DMC_MON area spans 0xff638080-0xff6380c0 DDR_PLL area spans 0xff638c00-0xff638c34 Round DDR_PLL area size up to 0x40 Fixes: 90cf8e21016fa3 ("arm64: dts: meson: Add DDR PMU node") Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230327120932.2158389-3-mgonzalez@freebox.fr Signed-off-by: Neil Armstrong <neil.armstrong@linaro.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: 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-20arm64: dts: qcom: sa8540p-ride: correct name of remoteproc_nsp0 firmwareBrian Masney1-1/+1
[ Upstream commit b891251b40d4dc4cfd28341f62f6784c02ad3a78 ] The cdsp.mbn firmware that's referenced in sa8540p-ride.dts is actually named cdsp0.mbn in the deliverables from Qualcomm. Let's go ahead and correct the name to match what's in Qualcomm's deliverable. Signed-off-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230307232340.2370476-1-bmasney@redhat.com 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-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-06KVM: arm64: Check for kvm_vma_mte_allowed in the critical sectionMarc Zyngier1-2/+6
commit 8c2e8ac8ad4be68409e806ce1cc78fc7a04539f3 upstream. On page fault, we find about the VMA that backs the page fault early on, and quickly release the mmap_read_lock. However, using the VMA pointer after the critical section is pretty dangerous, as a teardown may happen in the meantime and the VMA be long gone. Move the sampling of the MTE permission early, and NULL-ify the VMA pointer after that, just to be on the safe side. Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230316174546.3777507-3-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: 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: Retry fault if vma_lookup() results become invalidDavid Matlack1-27/+21
commit 13ec9308a85702af7c31f3638a2720863848a7f2 upstream. Read mmu_invalidate_seq before dropping the mmap_lock so that KVM can detect if the results of vma_lookup() (e.g. vma_shift) become stale before it acquires kvm->mmu_lock. This fixes a theoretical bug where a VMA could be changed by userspace after vma_lookup() and before KVM reads the mmu_invalidate_seq, causing KVM to install page table entries based on a (possibly) no-longer-valid vma_shift. Re-order the MMU cache top-up to earlier in user_mem_abort() so that it is not done after KVM has read mmu_invalidate_seq (i.e. so as to avoid inducing spurious fault retries). This bug has existed since KVM/ARM's inception. It's unlikely that any sane userspace currently modifies VMAs in such a way as to trigger this race. And even with directed testing I was unable to reproduce it. But a sufficiently motivated host userspace might be able to exploit this race. Fixes: 94f8e6418d39 ("KVM: ARM: Handle guest faults in KVM") Cc: stable@vger.kernel.org Reported-by: Sean Christopherson <seanjc@google.com> Signed-off-by: David Matlack <dmatlack@google.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230313235454.2964067-1-dmatlack@google.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-06KVM: arm64: PMU: Don't save PMCR_EL0.{C,P} for the vCPUReiji Watanabe1-1/+2
commit f6da81f650fa47b61b847488f3938d43f90d093d upstream. 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: 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-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: qcom: sc8280xp-x13s: mark s11b regulator as always-onJohan Hovold1-0/+1
commit b8838e653034425cd26983c7d96535e2742a6212 upstream. The s11b supply is used by the wlan module (as well as some of the pmics) which are not yet fully described in the devicetree. Mark the regulator as always-on for now. Fixes: 123b30a75623 ("arm64: dts: qcom: sc8280xp-x13s: enable WiFi controller") Cc: stable@vger.kernel.org # 6.2 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230322113318.17908-2-johan+linaro@kernel.org 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: efi: Set NX compat flag in PE/COFF headerArd Biesheuvel1-1/+1
commit 3c66bb1918c262dd52fb4221a8d372619c5da70a upstream. 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: 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-30arm64: dts: qcom: sm8450: correct WSA2 assigned clocksKrzysztof Kozlowski1-2/+2
[ Upstream commit 6df6fab9320bc9ebdf50136a01e7bf0ee5984c62 ] The WSA2 assigned-clocks were copied from WSA, but the WSA2 uses its own. Fixes: 14341e76dbc7 ("arm64: dts: qcom: sm8450: add Soundwire and LPASS") 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/20230308123129.232642-1-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30arm64: dts: qcom: sm6375: Add missing power-domain-named to CDSPKonrad Dybcio1-0/+1
[ Upstream commit 11d5e41f5e129e39bddedc7244a0946a802d2e8e ] This was omitted when first introducing the node. Fix it. Fixes: fe6fd26aeddf ("arm64: dts: qcom: sm6375: Add ADSP&CDSP") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230109135647.339224-5-konrad.dybcio@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30arm64: dts: qcom: sc8280xp: Add label property to vadc channel nodesManivannan Sadhasivam1-0/+13
[ Upstream commit 8013295662f55696e5953ef14c31ba03721adf8f ] For uniquely identifying the vadc channels, label property has to be used. The initial commit adding vadc support assumed that the driver will use the unit address along with the node name to identify the channels. But this assumption is now broken by, commit 701c875aded8 ("iio: adc: qcom-spmi-adc5: Fix the channel name") that stripped unit address from channel names. This results in probe failure of the vadc driver: [ 8.380370] iio iio:device0: tried to double register : in_temp_pmic-die-temp_input [ 8.380383] qcom-spmi-adc5 c440000.spmi:pmic@0:adc@3100: Failed to register sysfs interfaces [ 8.380386] qcom-spmi-adc5: probe of c440000.spmi:pmic@0:adc@3100 failed with error -16 Hence, let's get rid of the assumption about drivers and rely on label property to uniquely identify the channels. The labels are derived from the schematics for each PMIC. For internal adc channels such as die and xo, the PMIC names are used as a prefix. Fixes: 7c0151347401 ("arm64: dts: qcom: sc8280xp-x13s: Add PM8280_{1/2} ADC_TM5 channels") Fixes: 9d41cd17394a ("arm64: dts: qcom: sc8280xp-x13s: Add PMR735A VADC channel") Fixes: 3375151a7185 ("arm64: dts: qcom: sc8280xp-x13s: Add PM8280_{1/2} VADC channels") Fixes: 9a6b3042c533 ("arm64: dts: qcom: sc8280xp-x13s: Add PMK8280 VADC channels") Reported-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230211052415.14581-1-manivannan.sadhasivam@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30arm64: dts: freescale: imx8-ss-lsio: Fix flexspi clock orderAlexander Stein1-1/+1
[ Upstream commit fd4334a06d452ce89a0bb831b03130c51331d927 ] The correct clock order is "fspi_en" and "fspi". As they are identical just reordering the names is sufficient. Fixes: 6276d66984e9 ("arm64: dts: imx8dxl: add flexspi0 support") 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-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: 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-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: acpi: Fix possible memory leak of ffh_ctxtSudeep Holla1-4/+4
commit 1b561d3949f8478c5403c9752b5533211a757226 upstream. Allocated 'ffh_ctxt' memory leak is possible if the SMCCC version and conduit checks fail and -EOPNOTSUPP is returned without freeing the allocated memory. Fix the same by moving the allocation after the SMCCC version and conduit checks. Fixes: 1d280ce099db ("arm64: Add architecture specific ACPI FFH Opregion callbacks") Cc: <stable@vger.kernel.org> # 6.2.x Cc: Will Deacon <will@kernel.org> Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Suggested-by: Dan Carpenter <error27@gmail.com> Link: https://lore.kernel.org/r/202302191417.dAl9NuE8-lkp@intel.com/ Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Link: https://lore.kernel.org/r/20230223135742.2952091-1-sudeep.holla@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/sysreg: Fix errors in 32 bit enumeration valuesMark Brown1-4/+4
[ Upstream commit 8c6e105558628b63292ae770198f11a1d5535660 ] The recently converted 32 bit ID registers have errors in MVFR0_EL1.FPSP, MVFR0_EL1.SIMDReg and MVFR1_EL1.SIMDHP where enumeration values which should be 0b0010 are specified as 0b0001. Correct these. Fixes: e79c94a2a487 ("arm64/sysreg: Convert MVFR0_EL1 to automatic generation") Fixes: c9b718eda706 ("arm64/sysreg: Convert MVFR1_EL1 to automatic generation") 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-2-0d71a7b174a8@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> 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: 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: sm6115: correct TLMM gpio-rangesKrzysztof Kozlowski1-1/+1
[ Upstream commit 272fc52431611d779de132c4e03de6e0c1199731 ] Correct the number of GPIOs in TLMM pin controller. Fixes: 97e563bf5ba1 ("arm64: dts: qcom: sm6115: Add basic soc dtsi") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Iskren Chernev <me@iskren.info> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230202104452.299048-11-krzysztof.kozlowski@linaro.org 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>
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-28 00:24:04 +0300