Commit Graph

12942 Commits

Author SHA1 Message Date
Jason Liu
2f68e5475b Merge tag 'v5.4.70' into imx_5.4.y
* tag 'v5.4.70': (3051 commits)
  Linux 5.4.70
  netfilter: ctnetlink: add a range check for l3/l4 protonum
  ep_create_wakeup_source(): dentry name can change under you...
  ...

 Conflicts:
	arch/arm/mach-imx/pm-imx6.c
	arch/arm64/boot/dts/freescale/imx8mm-evk.dts
	arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
	drivers/crypto/caam/caamalg.c
	drivers/gpu/drm/imx/dw_hdmi-imx.c
	drivers/gpu/drm/imx/imx-ldb.c
	drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c
	drivers/mmc/host/sdhci-esdhc-imx.c
	drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
	drivers/net/ethernet/freescale/enetc/enetc.c
	drivers/net/ethernet/freescale/enetc/enetc_pf.c
	drivers/thermal/imx_thermal.c
	drivers/usb/cdns3/ep0.c
	drivers/xen/swiotlb-xen.c
	sound/soc/fsl/fsl_esai.c
	sound/soc/fsl/fsl_sai.c

Signed-off-by: Jason Liu <jason.hui.liu@nxp.com>
2020-10-08 17:46:51 +08:00
Daniel Baluta
024566cea6 MLK-24615-5 arm64: defconfig: Remove FSL_DAI config option
Because FSL DAI driver was removed, we no longer
need the FSL_DAI config option.

Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
2020-10-07 15:40:50 +03:00
Daniel Baluta
c19a2d13c1 MLK-24615-3 arm64: dts: imx8mp-sof-wm8960: Remove FSL DAI generic node
This removes FSL DAI generic node (as per upstream guidance)
and moves all resource handling to dsp node.

Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
2020-10-07 11:59:39 +03:00
Daniel Baluta
2cc8fc5c0d MLK-24668-6 arm64: dts: imx8qxp-sof-cs4288: Remove FSL DAI generic node
This removes FSL DAI generic node (as per upstream guidance)
and move all resource handling to dsp node.

Reviewed-by: Paul Olaru <paul.olaru@nxp.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
2020-10-06 13:30:05 +03:00
Daniel Baluta
d1a296c0ba MLK-24668-5 arm64: dts: imx8qm-sof-wm8960: Remove FSL DAI generic node
This removes FSL DAI generic node (as per upstream guidance)
and move all resource handling to dsp node.

Reviewed-by: Paul Olaru <paul.olaru@nxp.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
2020-10-06 13:30:00 +03:00
Daniel Baluta
4b99159456 MLK-24668-4 arm64: dts: imx8qxp-sof-wm8960: Remove FSL DAI generic node
This removes FSL DAI generic node (as per upstream guidance)
and move all resource handling to dsp node.

Reviewed-by: Paul Olaru <paul.olaru@nxp.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
2020-10-06 13:29:55 +03:00
Daniel Baluta
4bf6280655 MLK-24668-3 arm64: dts: imx8qxp-sof-cs4288: Remove FSL DAI generic node
This removes FSL DAI generic node (as per upstream guidance)
and move all resource handling to dsp node.

Reviewed-by: Paul Olaru <paul.olaru@nxp.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
2020-10-06 13:29:49 +03:00
Marc Zyngier
c9bfb7b4d9 KVM: arm64: Assume write fault on S1PTW permission fault on instruction fetch
commit c4ad98e4b72cb5be30ea282fce935248f2300e62 upstream.

KVM currently assumes that an instruction abort can never be a write.
This is in general true, except when the abort is triggered by
a S1PTW on instruction fetch that tries to update the S1 page tables
(to set AF, for example).

This can happen if the page tables have been paged out and brought
back in without seeing a direct write to them (they are thus marked
read only), and the fault handling code will make the PT executable(!)
instead of writable. The guest gets stuck forever.

In these conditions, the permission fault must be considered as
a write so that the Stage-1 update can take place. This is essentially
the I-side equivalent of the problem fixed by 60e21a0ef5 ("arm64: KVM:
Take S1 walks into account when determining S2 write faults").

Update kvm_is_write_fault() to return true on IABT+S1PTW, and introduce
kvm_vcpu_trap_is_exec_fault() that only return true when no faulting
on a S1 fault. Additionally, kvm_vcpu_dabt_iss1tw() is renamed to
kvm_vcpu_abt_iss1tw(), as the above makes it plain that it isn't
specific to data abort.

Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Will Deacon <will@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200915104218.1284701-2-maz@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-01 13:18:25 +02:00
Anshuman Khandual
180e60f154 arm64/cpufeature: Drop TraceFilt feature exposure from ID_DFR0 register
[ Upstream commit 1ed1b90a0594c8c9d31e8bb8be25a2b37717dc9e ]

ID_DFR0 based TraceFilt feature should not be exposed to guests. Hence lets
drop it.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org

Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/1589881254-10082-3-git-send-email-anshuman.khandual@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01 13:18:03 +02:00
James Morse
af02933d59 arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work
[ Upstream commit 8fcc4ae6faf8b455eeef00bc9ae70744e3b0f462 ]

APEI is unable to do all of its error handling work in nmi-context, so
it defers non-fatal work onto the irq_work queue. arch_irq_work_raise()
sends an IPI to the calling cpu, but this is not guaranteed to be taken
before returning to user-space.

Unless the exception interrupted a context with irqs-masked,
irq_work_run() can run immediately. Otherwise return -EINPROGRESS to
indicate ghes_notify_sea() found some work to do, but it hasn't
finished yet.

With this apei_claim_sea() returning '0' means this external-abort was
also notification of a firmware-first RAS error, and that APEI has
processed the CPER records.

Signed-off-by: James Morse <james.morse@arm.com>
Tested-by: Tyler Baicar <baicar@os.amperecomputing.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01 13:18:02 +02:00
Will Deacon
8e32fed034 arm64: cpufeature: Relax checks for AArch32 support at EL[0-2]
[ Upstream commit 98448cdfe7060dd5491bfbd3f7214ffe1395d58e ]

We don't need to be quite as strict about mismatched AArch32 support,
which is good because the friendly hardware folks have been busy
mismatching this to their hearts' content.

  * We don't care about EL2 or EL3 (there are silly comments concerning
    the latter, so remove those)

  * EL1 support is gated by the ARM64_HAS_32BIT_EL1 capability and handled
    gracefully when a mismatch occurs

  * EL0 support is gated by the ARM64_HAS_32BIT_EL0 capability and handled
    gracefully when a mismatch occurs

Relax the AArch32 checks to FTR_NONSTRICT.

Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20200421142922.18950-8-will@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01 13:17:57 +02:00
Mark Rutland
3283bd6d19 arm64: insn: consistently handle exit text
[ Upstream commit ca2ef4ffabbef25644e02a98b0f48869f8be0375 ]

A kernel built with KASAN && FTRACE_WITH_REGS && !MODULES, produces a
boot-time splat in the bowels of ftrace:

| [    0.000000] ftrace: allocating 32281 entries in 127 pages
| [    0.000000] ------------[ cut here ]------------
| [    0.000000] WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:2019 ftrace_bug+0x27c/0x328
| [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.4.0-rc3-00008-g7f08ae53a7e3 #13
| [    0.000000] Hardware name: linux,dummy-virt (DT)
| [    0.000000] pstate: 60000085 (nZCv daIf -PAN -UAO)
| [    0.000000] pc : ftrace_bug+0x27c/0x328
| [    0.000000] lr : ftrace_init+0x640/0x6cc
| [    0.000000] sp : ffffa000120e7e00
| [    0.000000] x29: ffffa000120e7e00 x28: ffff00006ac01b10
| [    0.000000] x27: ffff00006ac898c0 x26: dfffa00000000000
| [    0.000000] x25: ffffa000120ef290 x24: ffffa0001216df40
| [    0.000000] x23: 000000000000018d x22: ffffa0001244c700
| [    0.000000] x21: ffffa00011bf393c x20: ffff00006ac898c0
| [    0.000000] x19: 00000000ffffffff x18: 0000000000001584
| [    0.000000] x17: 0000000000001540 x16: 0000000000000007
| [    0.000000] x15: 0000000000000000 x14: ffffa00010432770
| [    0.000000] x13: ffff940002483519 x12: 1ffff40002483518
| [    0.000000] x11: 1ffff40002483518 x10: ffff940002483518
| [    0.000000] x9 : dfffa00000000000 x8 : 0000000000000001
| [    0.000000] x7 : ffff940002483519 x6 : ffffa0001241a8c0
| [    0.000000] x5 : ffff940002483519 x4 : ffff940002483519
| [    0.000000] x3 : ffffa00011780870 x2 : 0000000000000001
| [    0.000000] x1 : 1fffe0000d591318 x0 : 0000000000000000
| [    0.000000] Call trace:
| [    0.000000]  ftrace_bug+0x27c/0x328
| [    0.000000]  ftrace_init+0x640/0x6cc
| [    0.000000]  start_kernel+0x27c/0x654
| [    0.000000] random: get_random_bytes called from print_oops_end_marker+0x30/0x60 with crng_init=0
| [    0.000000] ---[ end trace 0000000000000000 ]---
| [    0.000000] ftrace faulted on writing
| [    0.000000] [<ffffa00011bf393c>] _GLOBAL__sub_D_65535_0___tracepoint_initcall_level+0x4/0x28
| [    0.000000] Initializing ftrace call sites
| [    0.000000] ftrace record flags: 0
| [    0.000000]  (0)
| [    0.000000]  expected tramp: ffffa000100b3344

This is due to an unfortunate combination of several factors.

Building with KASAN results in the compiler generating anonymous
functions to register/unregister global variables against the shadow
memory. These functions are placed in .text.startup/.text.exit, and
given mangled names like _GLOBAL__sub_{I,D}_65535_0_$OTHER_SYMBOL. The
kernel linker script places these in .init.text and .exit.text
respectively, which are both discarded at runtime as part of initmem.

Building with FTRACE_WITH_REGS uses -fpatchable-function-entry=2, which
also instruments KASAN's anonymous functions. When these are discarded
with the rest of initmem, ftrace removes dangling references to these
call sites.

Building without MODULES implicitly disables STRICT_MODULE_RWX, and
causes arm64's patch_map() function to treat any !core_kernel_text()
symbol as something that can be modified in-place. As core_kernel_text()
is only true for .text and .init.text, with the latter depending on
system_state < SYSTEM_RUNNING, we'll treat .exit.text as something that
can be patched in-place. However, .exit.text is mapped read-only.

Hence in this configuration the ftrace init code blows up while trying
to patch one of the functions generated by KASAN.

We could try to filter out the call sites in .exit.text rather than
initializing them, but this would be inconsistent with how we handle
.init.text, and requires hooking into core bits of ftrace. The behaviour
of patch_map() is also inconsistent today, so instead let's clean that
up and have it consistently handle .exit.text.

This patch teaches patch_map() to handle .exit.text at init time,
preventing the boot-time splat above. The flow of patch_map() is
reworked to make the logic clearer and minimize redundant
conditionality.

Fixes: 3b23e4991fb66f6d ("arm64: implement ftrace with regs")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Amit Daniel Kachhap <amit.kachhap@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Torsten Duwe <duwe@suse.de>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01 13:17:23 +02:00
Shengjiu Wang
9b8509a9ea MLK-24845: arm64: dts: imx8mn-ddr3l: Add ak5558 and LPA support
Add ak5558 and LPA support, these dts are derived from
imx8mn-evk-ak5558.dts and imx8mn-evk-rpmsg.dts

Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
2020-09-25 16:23:45 +08:00
Ilias Apalodimas
ecd219c729 arm64: bpf: Fix branch offset in JIT
[ Upstream commit 32f6865c7aa3c422f710903baa6eb81abc6f559b ]

Running the eBPF test_verifier leads to random errors looking like this:

[ 6525.735488] Unexpected kernel BRK exception at EL1
[ 6525.735502] Internal error: ptrace BRK handler: f2000100 [#1] SMP
[ 6525.741609] Modules linked in: nls_utf8 cifs libdes libarc4 dns_resolver fscache binfmt_misc nls_ascii nls_cp437 vfat fat aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce gf128mul efi_pstore sha2_ce sha256_arm64 sha1_ce evdev efivars efivarfs ip_tables x_tables autofs4 btrfs blake2b_generic xor xor_neon zstd_compress raid6_pq libcrc32c crc32c_generic ahci xhci_pci libahci xhci_hcd igb libata i2c_algo_bit nvme realtek usbcore nvme_core scsi_mod t10_pi netsec mdio_devres of_mdio gpio_keys fixed_phy libphy gpio_mb86s7x
[ 6525.787760] CPU: 3 PID: 7881 Comm: test_verifier Tainted: G        W         5.9.0-rc1+ #47
[ 6525.796111] Hardware name: Socionext SynQuacer E-series DeveloperBox, BIOS build #1 Jun  6 2020
[ 6525.804812] pstate: 20000005 (nzCv daif -PAN -UAO BTYPE=--)
[ 6525.810390] pc : bpf_prog_c3d01833289b6311_F+0xc8/0x9f4
[ 6525.815613] lr : bpf_prog_d53bb52e3f4483f9_F+0x38/0xc8c
[ 6525.820832] sp : ffff8000130cbb80
[ 6525.824141] x29: ffff8000130cbbb0 x28: 0000000000000000
[ 6525.829451] x27: 000005ef6fcbf39b x26: 0000000000000000
[ 6525.834759] x25: ffff8000130cbb80 x24: ffff800011dc7038
[ 6525.840067] x23: ffff8000130cbd00 x22: ffff0008f624d080
[ 6525.845375] x21: 0000000000000001 x20: ffff800011dc7000
[ 6525.850682] x19: 0000000000000000 x18: 0000000000000000
[ 6525.855990] x17: 0000000000000000 x16: 0000000000000000
[ 6525.861298] x15: 0000000000000000 x14: 0000000000000000
[ 6525.866606] x13: 0000000000000000 x12: 0000000000000000
[ 6525.871913] x11: 0000000000000001 x10: ffff8000000a660c
[ 6525.877220] x9 : ffff800010951810 x8 : ffff8000130cbc38
[ 6525.882528] x7 : 0000000000000000 x6 : 0000009864cfa881
[ 6525.887836] x5 : 00ffffffffffffff x4 : 002880ba1a0b3e9f
[ 6525.893144] x3 : 0000000000000018 x2 : ffff8000000a4374
[ 6525.898452] x1 : 000000000000000a x0 : 0000000000000009
[ 6525.903760] Call trace:
[ 6525.906202]  bpf_prog_c3d01833289b6311_F+0xc8/0x9f4
[ 6525.911076]  bpf_prog_d53bb52e3f4483f9_F+0x38/0xc8c
[ 6525.915957]  bpf_dispatcher_xdp_func+0x14/0x20
[ 6525.920398]  bpf_test_run+0x70/0x1b0
[ 6525.923969]  bpf_prog_test_run_xdp+0xec/0x190
[ 6525.928326]  __do_sys_bpf+0xc88/0x1b28
[ 6525.932072]  __arm64_sys_bpf+0x24/0x30
[ 6525.935820]  el0_svc_common.constprop.0+0x70/0x168
[ 6525.940607]  do_el0_svc+0x28/0x88
[ 6525.943920]  el0_sync_handler+0x88/0x190
[ 6525.947838]  el0_sync+0x140/0x180
[ 6525.951154] Code: d4202000 d4202000 d4202000 d4202000 (d4202000)
[ 6525.957249] ---[ end trace cecc3f93b14927e2 ]---

The reason is the offset[] creation and later usage, while building
the eBPF body. The code currently omits the first instruction, since
build_insn() will increase our ctx->idx before saving it.
That was fine up until bounded eBPF loops were introduced. After that
introduction, offset[0] must be the offset of the end of prologue which
is the start of the 1st insn while, offset[n] holds the
offset of the end of n-th insn.

When "taken loop with back jump to 1st insn" test runs, it will
eventually call bpf2a64_offset(-1, 2, ctx). Since negative indexing is
permitted, the current outcome depends on the value stored in
ctx->offset[-1], which has nothing to do with our array.
If the value happens to be 0 the tests will work. If not this error
triggers.

commit 7c2e988f40 ("bpf: fix x64 JIT code generation for jmp to 1st insn")
fixed an indentical bug on x86 when eBPF bounded loops were introduced.

So let's fix it by creating the ctx->offset[] differently. Track the
beginning of instruction and account for the extra instruction while
calculating the arm instruction offsets.

Fixes: 2589726d12 ("bpf: introduce bounded loops")
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Reported-by: Jiri Olsa <jolsa@kernel.org>
Co-developed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Co-developed-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20200917084925.177348-1-ilias.apalodimas@linaro.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-23 12:40:42 +02:00
Marc Zyngier
cdf990e2b2 arm64: Allow CPUs unffected by ARM erratum 1418040 to come in late
[ Upstream commit ed888cb0d1ebce69f12794e89fbd5e2c86d40b8d ]

Now that we allow CPUs affected by erratum 1418040 to come in late,
this prevents their unaffected sibblings from coming in late (or
coming back after a suspend or hotplug-off, which amounts to the
same thing).

To allow this, we need to add ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU,
which amounts to set .type to ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE.

Fixes: bf87bb0881d0 ("arm64: Allow booting of late CPUs affected by erratum 1418040")
Reported-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20200911181611.2073183-1-maz@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-23 12:40:40 +02:00
Clark Wang
76dbd91bd7 MLK-24833-3 arm64: dts: imx8qm: add lpi2c4 node
Add lpi2c4 node for i.MX8QM.

Reviewed-by: Fugang Duan <fugang.duan@nxp.com>
Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
2020-09-23 15:49:53 +08:00
Sherry Sun
fcea4ac4b8 MLK-24818: arm64: dts: imx8/imx8m: remove the reserved-region property
of pcie nodes

Remove the reserved-region property of pcie nodes for imx8m and imx8
platform since for the new pcie frame, we don't need them any more.

Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Reviewed-by: Fugang Duan <fugang.duan@nxp.com>
Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
2020-09-23 09:37:34 +08:00
Clark Wang
3ac4d58d5d MLK-24827 ARM64: dts: imx8-dma: change spi and i2c irq number to non-combined
Combined interrupt number may cause unexcepted irq event when using DMA
and too many interrupts are generated.
So change all spi and i2c interrupts number to non-combined for
imx8qxp/8qm/8dxl.

Reviewed-by: Fugang Duan <fugang.duan@nxp.com>
Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
2020-09-22 16:27:39 +08:00
Sherry Sun
5a50ac86e8 MLK-24796-4: arm64: configs: imx_mic_card/host: add i.MX MIC support
Add i.MX MIC support based on VOP framework. Here build imx_mic and vop
drivers as modules.

Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Fugang Duan <fugang.duan@nxp.com>
2020-09-22 14:48:51 +08:00
Sherry Sun
95922e6ee9 MLK-24796-3: dts: imx8qm: add imx_mic_intr for ep and add cma node for rc
For rc, use cma node to allocate share memory from rc ddr dynamically.
So add a new imx8qm-mek-vop.dts file for rc.
For ep, add an imx_mic_intr node to config the power and clock of
mu8a/mu8b, which are used to generate interrupts from rc to ep.

Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Fugang Duan <fugang.duan@nxp.com>
2020-09-22 14:48:51 +08:00
Sherry Sun
a734d2ab64 MLK-24796-2: dts: imx8qxp: add imx_mic_intr for ep and add cma node for rc
For rc, use cma node to allocate share memory from rc ddr dynamically.
So add a new imx8qxp-mek-vop.dts file for rc.
For ep, add an imx_mic_intr node to config the power and clock of
mu8a/mu8b, which are used to generate interrupts from rc to ep.

Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Fugang Duan <fugang.duan@nxp.com>
2020-09-22 14:48:51 +08:00
Robert Chiras
4096b5014e MLK-24805-4: arm64: dts: add DTS for DCSS and rm67199
Add support for the new DSI panel: Raydium RM67199 when used with DCSS.

Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
Reviewed-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
2020-09-22 09:32:20 +03:00
Robert Chiras
0fd53b4b2e MLK-24805-3: arm64: dts: imx8mq-evk: create dts file for lcdif-rm67199
Add support fot the new DSI panel: Raydium RM67199 when used with LCDIF.

Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
Reviewed-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
2020-09-22 09:32:15 +03:00
Jacky Bai
dd1f3a8955 MLK-24822 arm64: dts: freescale: Add imx8mn ddr3l evk board support
Add i.MX8MN DDR3L EVK board support.

Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Anson Huang <Anson.Huang@nxp.com>
2020-09-21 13:43:16 +08:00
Jessica Yu
ff37a26364 arm64/module: set trampoline section flags regardless of CONFIG_DYNAMIC_FTRACE
[ Upstream commit e0328feda79d9681b3e3245e6e180295550c8ee9 ]

In the arm64 module linker script, the section .text.ftrace_trampoline
is specified unconditionally regardless of whether CONFIG_DYNAMIC_FTRACE
is enabled (this is simply due to the limitation that module linker
scripts are not preprocessed like the vmlinux one).

Normally, for .plt and .text.ftrace_trampoline, the section flags
present in the module binary wouldn't matter since module_frob_arch_sections()
would assign them manually anyway. However, the arm64 module loader only
sets the section flags for .text.ftrace_trampoline when CONFIG_DYNAMIC_FTRACE=y.
That's only become problematic recently due to a recent change in
binutils-2.35, where the .text.ftrace_trampoline section (along with the
.plt section) is now marked writable and executable (WAX).

We no longer allow writable and executable sections to be loaded due to
commit 5c3a7db0c7ec ("module: Harden STRICT_MODULE_RWX"), so this is
causing all modules linked with binutils-2.35 to be rejected under arm64.
Drop the IS_ENABLED(CONFIG_DYNAMIC_FTRACE) check in module_frob_arch_sections()
so that the section flags for .text.ftrace_trampoline get properly set to
SHF_EXECINSTR|SHF_ALLOC, without SHF_WRITE.

Signed-off-by: Jessica Yu <jeyu@kernel.org>
Acked-by: Will Deacon <will@kernel.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: http://lore.kernel.org/r/20200831094651.GA16385@linux-8ccs
Link: https://lore.kernel.org/r/20200901160016.3646-1-jeyu@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-17 13:47:49 +02:00
Florian Fainelli
75a81be8fb arm64: dts: ns2: Fixed QSPI compatible string
[ Upstream commit 686e0a0c8c61e0e3f55321d0181fece3efd92777 ]

The string was incorrectly defined before from least to most specific,
swap the compatible strings accordingly.

Fixes: ff73917d38 ("ARM64: dts: Add QSPI Device Tree node for NS2")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-17 13:47:45 +02:00
Krzysztof Kozlowski
af0d981845 arm64: dts: imx8mq: Fix TMU interrupt property
[ Upstream commit 1f2f98f2703e8134678fe20982886085631eda23 ]

"interrupt" is not a valid property.  Using proper name fixes dtbs_check
warning:

  arch/arm64/boot/dts/freescale/imx8mq-zii-ultra-zest.dt.yaml: tmu@30260000: 'interrupts' is a required property

Fixes: e464fd2ba4 ("arm64: dts: imx8mq: enable the multi sensor TMU")
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-17 13:47:42 +02:00
Ye Li
c06ed9363c MLK-24794 arm64: dts: imx8dxl: Rename DDR3 VAL board to EVK
Per marketing request, rename this board from validation board to
EVK board.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
2020-09-16 19:31:12 -07:00
Joakim Zhang
59c2d372b4 MLK-24752-3 arch: arm64: imx8mn-ddr4: add IR device node
Add device node for imx8mn ddr4 evk board.

Reviewed-by: Fugang Duan <fugang.duan@nxp.com>
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
2020-09-16 19:15:09 +08:00
Iuliana Prodan
aee8fd4709 MLK-24762 ARM64: configs: imx_v8_defconfig: enable DM_CRYPT
Enable DM_CRYPT, as module, to have an out-of-the-box
solution for dm-crypt with black keys and blobs.

Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
2020-09-11 12:17:31 +03:00
Li Jun
c0420229f2 MLK-24747-1 arm64: dtsi: imx8mp: add suspend clk for usb glue node
It turns out the usb suspend clk IMX8MP_CLK_USB_ROOT should be on to
support usb wakeup, so add the suspend clk to glue layer node for
handling.

Reviewed-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Li Jun <jun.li@nxp.com>
2020-09-11 16:11:52 +08:00
Peng Fan
46c4bcf45b MLK-24275 arm64: imx_v8_defconfig: build xen netback as module
Build xen netback as module, then we could have paravirtualized network
support.

Reviewed-by: Alice Guo <alice.guo@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
2020-09-11 16:15:28 +08:00
Peng Fan
b30136bea1 MLK-24763 arm64: dts: imx8qm-dom0: disable uart0_lpcg
uart0 is used by XEN, we should not allow linux to touch
the clk to avoid uart being broken.

Reviewed-by: Fugang Duan <fugang.duan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
(cherry picked from commit 24947e556d05f16bfca1327ebba047b874c2a5d4)
2020-09-10 18:41:33 +08:00
Wenbin Mei
2816ccd071 arm64: dts: mt7622: add reset node for mmc device
commit d6f6cbeee4e5ee6976792851e0461c19f1ede864 upstream.

This commit adds reset node for mmc device.

Cc: <stable@vger.kernel.org> # v5.4+
Fixes: 966580ad23 ("mmc: mediatek: add support for MT7622 SoC")
Signed-off-by: Wenbin Mei <wenbin.mei@mediatek.com>
Tested-by: Frank Wunderlich <frank-w@public-files.de>
Acked-by: Matthias Brugger <matthias.bgg@gmail.com>
Link: https://lore.kernel.org/r/20200814014346.6496-3-wenbin.mei@mediatek.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-09 19:12:33 +02:00
Adrian Alonso
67a6a0ff58 MLK-24700-3: dts: arm64: freescale: imx8mn ddr4 ab2 add i2c4
Add i2c4 port used by hdmi daughter cards on Audio Board
2.0 targets

Signed-off-by: Adrian Alonso <adrian.alonso@nxp.com>
Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
2020-09-08 09:58:20 -05:00
Adrian Alonso
5938e9fb2b MLK-24700-2: dts: arm64: freescale: imx8mn ab2 add i2c4
Add i2c4 port used by hdmi daughter cards on Audio Board
2.0 targets

Signed-off-by: Adrian Alonso <adrian.alonso@nxp.com>
Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
2020-09-08 09:58:06 -05:00
Adrian Alonso
c38112c9ed MLK-24700-1: dts: arm64: freescale: imx8mm ab2 add i2c4
Add i2c4 port used by hdmi daughter cards on Audio Board
2.0 targets

Signed-off-by: Adrian Alonso <adrian.alonso@nxp.com>
Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
2020-09-08 09:57:54 -05:00
Adrian Alonso
7597adf8d2 MLK-24702-2: dts: arm64 freescale: imx8mn ab2 regulator power tree
Follow the same regulator power tree as imx8mm ab2
target platforms

Signed-off-by: Adrian Alonso <adrian.alonso@nxp.com>
Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
2020-09-08 09:57:41 -05:00
Adrian Alonso
6c65808df8 MLK-24702-1: dts: arm64: freescale: imx8mn ddr4 ab2 regulator tree
Aling to use the same regulator power tree as imx8mm ab2
target boards

Signed-off-by: Adrian Alonso <adrian.alonso@nxp.com>
Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
2020-09-08 09:57:27 -05:00
Adrian Alonso
6b5ae3257d MLK-24701: dts: arm64: freescale: imx8mm ab2: sai1 rx pads
Add SAI1 RX pads to support hdmi daughter cards with
I2S audio extraction.

Signed-off-by: Adrian Alonso <adrian.alonso@nxp.com>
Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
2020-09-08 09:56:47 -05:00
Joakim Zhang
826c9b5d0d MLK-24752-2 arch: arm64: config: imx_v8_defconfig: enable Remote Controller
Enable all RC decoder that kernel supported and GPIO RC device.

Reviewed-by: Fugang Duan <fugang.duan@nxp.com>
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
2020-09-09 02:45:38 +08:00
Joakim Zhang
65aa1b7ba2 MLK-24752-1 arch: arm64: imx8m: add IR support
Add IR support for i.MX8MM/MN/MQ.

Reviewed-by: Fugang Duan <fugang.duan@nxp.com>
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
2020-09-09 02:45:38 +08:00
Sowjanya Komatineni
eda97e9d90 arm64: tegra: Add missing timeout clock to Tegra210 SDMMC
commit 679f71fa0db2d777f39c7a5af7f7c0689fc713fa upstream.

commit 742af7e7a0 ("arm64: tegra: Add Tegra210 support")

Tegra210 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.

Tegra SDMMC advertises 12Mhz as timeout clock frequency in host
capability register.

So, this clock should be kept enabled by SDMMC driver.

Fixes: 742af7e7a0 ("arm64: tegra: Add Tegra210 support")
Cc: stable <stable@vger.kernel.org> # 5.4
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Link: https://lore.kernel.org/r/1598548861-32373-5-git-send-email-skomatineni@nvidia.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-05 11:22:51 +02:00
Sowjanya Komatineni
5cd8c5979e arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes
commit baba217d2c4446b6eef309d81d8776cb5c68cb55 upstream.

commit 39cb62cb89 ("arm64: tegra: Add Tegra186 support")

Tegra186 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.

Tegra186 SDMMC advertises 12Mhz as timeout clock frequency in host
capability register and uses it by default.

So, this clock should be kept enabled by the SDMMC driver.

Fixes: 39cb62cb89 ("arm64: tegra: Add Tegra186 support")
Cc: stable <stable@vger.kernel.org> # 5.4
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Link: https://lore.kernel.org/r/1598548861-32373-6-git-send-email-skomatineni@nvidia.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-05 11:22:50 +02:00
Sowjanya Komatineni
ef8b5f3337 arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes
commit c956c0cd4f6f4aac4f095621b1c4e1c5ee1df877 upstream.

commit 5425fb15d8 ("arm64: tegra: Add Tegra194 chip device tree")

Tegra194 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.

Tegra194 SDMMC advertises 12Mhz as timeout clock frequency in host
capability register.

So, this clock should be kept enabled by SDMMC driver.

Fixes: 5425fb15d8 ("arm64: tegra: Add Tegra194 chip device tree")
Cc: stable <stable@vger.kernel.org> # 5.4
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Link: https://lore.kernel.org/r/1598548861-32373-7-git-send-email-skomatineni@nvidia.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-05 11:22:50 +02:00
James Morse
d2ac42e61e KVM: arm64: Set HCR_EL2.PTW to prevent AT taking synchronous exception
commit 71a7f8cb1ca4ca7214a700b1243626759b6c11d4 upstream.

AT instructions do a translation table walk and return the result, or
the fault in PAR_EL1. KVM uses these to find the IPA when the value is
not provided by the CPU in HPFAR_EL1.

If a translation table walk causes an external abort it is taken as an
exception, even if it was due to an AT instruction. (DDI0487F.a's D5.2.11
"Synchronous faults generated by address translation instructions")

While we previously made KVM resilient to exceptions taken due to AT
instructions, the device access causes mismatched attributes, and may
occur speculatively. Prevent this, by forbidding a walk through memory
described as device at stage2. Now such AT instructions will report a
stage2 fault.

Such a fault will cause KVM to restart the guest. If the AT instructions
always walk the page tables, but guest execution uses the translation cached
in the TLB, the guest can't make forward progress until the TLB entry is
evicted. This isn't a problem, as since commit 5dcd0fdbb4 ("KVM: arm64:
Defer guest entry when an asynchronous exception is pending"), KVM will
return to the host to process IRQs allowing the rest of the system to keep
running.

Cc: stable@vger.kernel.org # <v5.3: 5dcd0fdbb4 ("KVM: arm64: Defer guest entry when an asynchronous exception is pending")
Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-05 11:22:50 +02:00
James Morse
ffad02f9e3 KVM: arm64: Survive synchronous exceptions caused by AT instructions
commit 88a84ccccb3966bcc3f309cdb76092a9892c0260 upstream.

KVM doesn't expect any synchronous exceptions when executing, any such
exception leads to a panic(). AT instructions access the guest page
tables, and can cause a synchronous external abort to be taken.

The arm-arm is unclear on what should happen if the guest has configured
the hardware update of the access-flag, and a memory type in TCR_EL1 that
does not support atomic operations. B2.2.6 "Possible implementation
restrictions on using atomic instructions" from DDI0487F.a lists
synchronous external abort as a possible behaviour of atomic instructions
that target memory that isn't writeback cacheable, but the page table
walker may behave differently.

Make KVM robust to synchronous exceptions caused by AT instructions.
Add a get_user() style helper for AT instructions that returns -EFAULT
if an exception was generated.

While KVM's version of the exception table mixes synchronous and
asynchronous exceptions, only one of these can occur at each location.

Re-enter the guest when the AT instructions take an exception on the
assumption the guest will take the same exception. This isn't guaranteed
to make forward progress, as the AT instructions may always walk the page
tables, but guest execution may use the translation cached in the TLB.

This isn't a problem, as since commit 5dcd0fdbb4 ("KVM: arm64: Defer guest
entry when an asynchronous exception is pending"), KVM will return to the
host to process IRQs allowing the rest of the system to keep running.

Cc: stable@vger.kernel.org # <v5.3: 5dcd0fdbb4 ("KVM: arm64: Defer guest entry when an asynchronous exception is pending")
Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-05 11:22:50 +02:00
James Morse
1744237ca0 KVM: arm64: Add kvm_extable for vaxorcism code
commit e9ee186bb735bfc17fa81dbc9aebf268aee5b41e upstream.

KVM has a one instruction window where it will allow an SError exception
to be consumed by the hypervisor without treating it as a hypervisor bug.
This is used to consume asynchronous external abort that were caused by
the guest.

As we are about to add another location that survives unexpected exceptions,
generalise this code to make it behave like the host's extable.

KVM's version has to be mapped to EL2 to be accessible on nVHE systems.

The SError vaxorcism code is a one instruction window, so has two entries
in the extable. Because the KVM code is copied for VHE and nVHE, we end up
with four entries, half of which correspond with code that isn't mapped.

Cc: <stable@vger.kernel.org> # 5.4.x
Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-05 11:22:50 +02:00
Richard Zhu
4f60600cb9 MLK-24712 arm64: dts: imx8: use rpmsg dts in ep enable dts
As linux_m4 flash is default boot flash for iMX8QXP/iMX8QM/iMX8DXL,
enabble PCIe EP based on default boot RPMSG DTS file.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Fugang Duan <fugang.duan@nxp.com>
2020-09-04 15:11:34 +08:00
Frank van der Linden
7ded78a8c8 arm64: vdso32: make vdso32 install conditional
commit 5d28ba5f8a0cfa3a874fa96c33731b8fcd141b3a upstream.

vdso32 should only be installed if CONFIG_COMPAT_VDSO is enabled,
since it's not even supposed to be compiled otherwise, and arm64
builds without a 32bit crosscompiler will fail.

Fixes: 8d75785a8142 ("ARM64: vdso32: Install vdso32 from vdso_install")
Signed-off-by: Frank van der Linden <fllinden@amazon.com>
Cc: stable@vger.kernel.org [5.4+]
Link: https://lore.kernel.org/r/20200827234012.19757-1-fllinden@amazon.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03 11:27:05 +02:00