linux-stable.git/arch/arm, branch v5.4.112

ARM: dts: imx6: pbab01: Set vmmc supply for both SD interfaces

2021-04-14T06:24:15+00:00

[ Upstream commit f57011e72f5fe0421ec7a812beb1b57bdf4bb47f ]

Setting the vmmc supplies is crucial since otherwise the supplying
regulators get disabled and the SD interfaces are no longer powered
which leads to system failures if the system is booted from that SD
interface.

Fixes: 1e44d3f880d5 ("ARM i.MX6Q: dts: Enable I2C1 with EEPROM and PMIC on Phytec phyFLEX-i.MX6 Ouad module")
Signed-off-by: Stefan Riedmueller 
Reviewed-by: Fabio Estevam 
Signed-off-by: Shawn Guo 
Signed-off-by: Sasha Levin

ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin

2021-04-14T06:24:11+00:00

commit a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 upstream.

Use the `marvell,reg-init` DT property to configure the LED[2]/INTn pin
of the Marvell 88E1514 ethernet PHY on Turris Omnia into interrupt mode.

Without this the pin is by default in LED[2] mode, and the Marvell PHY
driver configures LED[2] into "On - Link, Blink - Activity" mode.

This fixes the issue where the pca9538 GPIO/interrupt controller (which
can't mask interrupts in HW) received too many interrupts and after a
time started ignoring the interrupt with error message:
  IRQ 71: nobody cared

There is a work in progress to have the Marvell PHY driver support
parsing PHY LED nodes from OF and registering the LEDs as Linux LED
class devices. Once this is done the PHY driver can also automatically
set the pin into INTn mode if it does not find LED[2] in OF.

Until then, though, we fix this via `marvell,reg-init` DT property.

Signed-off-by: Marek Behún 
Reported-by: Rui Salvaterra 
Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
Cc: Uwe Kleine-König 
Cc: linux-arm-kernel@lists.infradead.org
Cc: Andrew Lunn 
Cc: Gregory CLEMENT 
Cc: 
Tested-by: Rui Salvaterra 
Reviewed-by: Andrew Lunn 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: am33xx: add aliases for mmc interfaces

2021-04-10T11:34:30+00:00

[ Upstream commit 9bbce32a20d6a72c767a7f85fd6127babd1410ac ]

Without DT aliases, the numbering of mmc interfaces is unpredictable.
Adding them makes it possible to refer to devices consistently.  The
popular suggestion to use UUIDs obviously doesn't work with a blank
device fresh from the factory.

See commit fa2d0aa96941 ("mmc: core: Allow setting slot index via
device tree alias") for more discussion.

Signed-off-by: Mans Rullgard 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

ARM: dts: at91-sama5d27_som1: fix phy address to 7

2021-03-30T12:35:24+00:00

commit 221c3a09ddf70a0a51715e6c2878d8305e95c558 upstream.

Fix the phy address to 7 for Ethernet PHY on SAMA5D27 SOM1. No
connection established if phy address 0 is used.

The board uses the 24 pins version of the KSZ8081RNA part, KSZ8081RNA
pin 16 REFCLK as PHYAD bit [2] has weak internal pull-down.  But at
reset, connected to PD09 of the MPU it's connected with an internal
pull-up forming PHYAD[2:0] = 7.

Signed-off-by: Claudiu Beznea 
Fixes: 2f61929eb10a ("ARM: dts: at91: at91-sama5d27_som1: fix PHY ID")
Cc: Ludovic Desroches 
Signed-off-by: Nicolas Ferre 
Cc:  # 4.14+
Signed-off-by: Greg Kroah-Hartman

ARM: 9044/1: vfp: use undef hook for VFP support detection

2021-03-24T10:26:35+00:00

commit 3cce9d44321e460e7c88cdec4e4537a6e9ad7c0d upstream.

Commit f77ac2e378be9dd6 ("ARM: 9030/1: entry: omit FP emulation for UND
exceptions taken in kernel mode") failed to take into account that there
is in fact a case where we relied on this code path: during boot, the
VFP detection code issues a read of FPSID, which will trigger an undef
exception on cores that lack VFP support.

So let's reinstate this logic using an undef hook which is registered
only for the duration of the initcall to vpf_init(), and which sets
VFP_arch to a non-zero value - as before - if no VFP support is present.

Fixes: f77ac2e378be9dd6 ("ARM: 9030/1: entry: omit FP emulation for UND ...")
Reported-by: "kernelci.org bot" 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Russell King 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Greg Kroah-Hartman

ARM: 9030/1: entry: omit FP emulation for UND exceptions taken in kernel mode

2021-03-24T10:26:35+00:00

commit f77ac2e378be9dd61eb88728f0840642f045d9d1 upstream.

There are a couple of problems with the exception entry code that deals
with FP exceptions (which are reported as UND exceptions) when building
the kernel in Thumb2 mode:
- the conditional branch to vfp_kmode_exception in vfp_support_entry()
  may be out of range for its target, depending on how the linker decides
  to arrange the sections;
- when the UND exception is taken in kernel mode, the emulation handling
  logic is entered via the 'call_fpe' label, which means we end up using
  the wrong value/mask pairs to match and detect the NEON opcodes.

Since UND exceptions in kernel mode are unlikely to occur on a hot path
(as opposed to the user mode version which is invoked for VFP support
code and lazy restore), we can use the existing undef hook machinery for
any kernel mode instruction emulation that is needed, including calling
the existing vfp_kmode_exception() routine for unexpected cases. So drop
the call to call_fpe, and instead, install an undef hook that will get
called for NEON and VFP instructions that trigger an UND exception in
kernel mode.

While at it, make sure that the PC correction is accurate for the
execution mode where the exception was taken, by checking the PSR
Thumb bit.

[nd: fix conflict in arch/arm/vfp/vfphw.S due to missing
     commit 2cbd1cc3dcd3 ("ARM: 8991/1: use VFP assembler mnemonics if
     available")]

Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections")
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Russell King 
Signed-off-by: Nick Desaulniers 
Reviewed-by: Linus Walleij 
Reviewed-by: Nick Desaulniers 
Cc: Dmitry Osipenko 
Cc: Kees Cook 
Signed-off-by: Greg Kroah-Hartman

KVM: arm64: Ensure I-cache isolation between vcpus of a same VM

2021-03-17T16:03:57+00:00

Commit 01dc9262ff5797b675c32c0c6bc682777d23de05 upstream.

It recently became apparent that the ARMv8 architecture has interesting
rules regarding attributes being used when fetching instructions
if the MMU is off at Stage-1.

In this situation, the CPU is allowed to fetch from the PoC and
allocate into the I-cache (unless the memory is mapped with
the XN attribute at Stage-2).

If we transpose this to vcpus sharing a single physical CPU,
it is possible for a vcpu running with its MMU off to influence
another vcpu running with its MMU on, as the latter is expected to
fetch from the PoU (and self-patching code doesn't flush below that
level).

In order to solve this, reuse the vcpu-private TLB invalidation
code to apply the same policy to the I-cache, nuking it every time
the vcpu runs on a physical CPU that ran another vcpu of the same
VM in the past.

This involve renaming __kvm_tlb_flush_local_vmid() to
__kvm_flush_cpu_context(), and inserting a local i-cache invalidation
there.

Cc: stable@vger.kernel.org
Signed-off-by: Marc Zyngier 
Acked-by: Will Deacon 
Acked-by: Catalin Marinas 
Link: https://lore.kernel.org/r/20210303164505.68492-1-maz@kernel.org
[maz: added 32bit ARM support]
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman

Xen/gnttab: handle p2m update errors on a per-slot basis

2021-03-07T11:20:49+00:00

commit 8310b77b48c5558c140e7a57a702e7819e62f04e upstream.

Bailing immediately from set_foreign_p2m_mapping() upon a p2m updating
error leaves the full batch in an ambiguous state as far as the caller
is concerned. Instead flags respective slots as bad, unmapping what
was mapped there right away.

HYPERVISOR_grant_table_op()'s return value and the individual unmap
slots' status fields get used only for a one-time - there's not much we
can do in case of a failure.

Note that there's no GNTST_enomem or alike, so GNTST_general_error gets
used.

The map ops' handle fields get overwritten just to be on the safe side.

This is part of XSA-367.

Cc: 
Signed-off-by: Jan Beulich 
Reviewed-by: Juergen Gross 
Link: https://lore.kernel.org/r/96cccf5d-e756-5f53-b91a-ea269bfb9be0@suse.com
Signed-off-by: Juergen Gross 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: aspeed: Add LCLK to lpc-snoop

2021-03-04T09:26:54+00:00

commit d050d049f8b8077025292c1ecf456c4ee7f96861 upstream.

Signed-off-by: John Wang 
Reviewed-by: Joel Stanley 
Link: https://lore.kernel.org/r/20201202051634.490-2-wangzhiqiang.bj@bytedance.com
Signed-off-by: Joel Stanley 
Signed-off-by: Greg Kroah-Hartman

ARM: 9046/1: decompressor: Do not clear SCTLR.nTLSMD for ARMv7+ cores

2021-03-04T09:26:32+00:00

[ Upstream commit 2acb909750431030b65a0a2a17fd8afcbd813a84 ]

It was observed that decompressor running on hardware implementing ARM v8.2
Load/Store Multiple Atomicity and Ordering Control (LSMAOC), say, as guest,
would stuck just after:

Uncompressing Linux... done, booting the kernel.

The reason is that it clears nTLSMD bit when disabling caches:

nTLSMD, bit [3]

When ARMv8.2-LSMAOC is implemented:

No Trap Load Multiple and Store Multiple to
Device-nGRE/Device-nGnRE/Device-nGnRnE memory.

0b0 All memory accesses by A32 and T32 Load Multiple and Store
Multiple at EL1 or EL0 that are marked at stage 1 as
Device-nGRE/Device-nGnRE/Device-nGnRnE memory are trapped and
generate a stage 1 Alignment fault.

0b1 All memory accesses by A32 and T32 Load Multiple and Store
Multiple at EL1 or EL0 that are marked at stage 1 as
Device-nGRE/Device-nGnRE/Device-nGnRnE memory are not trapped.

This bit is permitted to be cached in a TLB.

This field resets to 1.

Otherwise:

Reserved, RES1

So as effect we start getting traps we are not quite ready for.

Looking into history it seems that mask used for SCTLR clear came from
the similar code for ARMv4, where bit[3] is the enable/disable bit for
the write buffer. That not applicable to ARMv7 and onwards, so retire
that bit from the masks.

Fixes: 7d09e85448dfa78e3e58186c934449aaf6d49b50 ("[ARM] 4393/2: ARMv7: Add uncompressing code for the new CPU Id format")
Signed-off-by: Vladimir Murzin
Signed-off-by: Russell King
Signed-off-by: Sasha Levin