linux-stable.git/arch, branch v4.14.166

hexagon: work around compiler crash

2020-01-17T18:45:55+00:00

[ Upstream commit 63e80314ab7cf4783526d2e44ee57a90514911c9 ]

Clang cannot translate the string "r30" into a valid register yet.

Link: https://github.com/ClangBuiltLinux/linux/issues/755
Link: http://lkml.kernel.org/r/20191028155722.23419-1-ndesaulniers@google.com
Signed-off-by: Nick Desaulniers 
Suggested-by: Sid Manning 
Reviewed-by: Brian Cain 
Cc: Allison Randal 
Cc: Greg Kroah-Hartman 
Cc: Richard Fontana 
Cc: Thomas Gleixner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

hexagon: parenthesize registers in asm predicates

2020-01-17T18:45:54+00:00

[ Upstream commit 780a0cfda9006a9a22d6473c2d4c527f5c68eb2e ]

Hexagon requires that register predicates in assembly be parenthesized.

Link: https://github.com/ClangBuiltLinux/linux/issues/754
Link: http://lkml.kernel.org/r/20191209222956.239798-3-ndesaulniers@google.com
Signed-off-by: Nick Desaulniers 
Suggested-by: Sid Manning 
Acked-by: Brian Cain 
Cc: Lee Jones 
Cc: Andy Shevchenko 
Cc: Tuowen Zhao 
Cc: Mika Westerberg 
Cc: Luis Chamberlain 
Cc: Greg Kroah-Hartman 
Cc: Alexios Zavras 
Cc: Allison Randal 
Cc: Will Deacon 
Cc: Richard Fontana 
Cc: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Boqun Feng 
Cc: Ingo Molnar 
Cc: Geert Uytterhoeven 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

MIPS: Prevent link failure with kcov instrumentation

2020-01-17T18:45:54+00:00

[ Upstream commit a4a3893114a41e365274d5fab5d9ff5acc235ff0 ]

__sanitizer_cov_trace_pc() is not linked in and causing link
failure if KCOV_INSTRUMENT is enabled. Fix this by disabling
instrumentation for compressed image.

Signed-off-by: Jouni Hogander 
Signed-off-by: Paul Burton 
Cc: Lukas Bulwahn 
Cc: linux-mips@vger.kernel.org
Signed-off-by: Sasha Levin

mips: cacheinfo: report shared CPU map

2020-01-17T18:45:53+00:00

[ Upstream commit 3b1313eb32c499d46dc4c3e896d19d9564c879c4 ]

Report L1 caches as shared per core; L2 - per cluster.

This fixes "perf" that went crazy if shared_cpu_map attribute not
reported on sysfs, in form of

/sys/devices/system/cpu/cpu*/cache/index*/shared_cpu_list
/sys/devices/system/cpu/cpu*/cache/index*/shared_cpu_map

Signed-off-by: Vladimir Kondratiev 
Signed-off-by: Paul Burton 
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sasha Levin

powerpc/powernv: Disable native PCIe port management

2020-01-17T18:45:50+00:00

commit 9d72dcef891030545f39ad386a30cf91df517fb2 upstream.

On PowerNV the PCIe topology is (currently) managed by the powernv platform
code in Linux in cooperation with the platform firmware. Linux's native
PCIe port service drivers operate independently of both and this can cause
problems.

The main issue is that the portbus driver will conflict with the platform
specific hotplug driver (pnv_php) over ownership of the MSI used to notify
the host when a hotplug event occurs. The portbus driver claims this MSI on
behalf of the individual port services because the same interrupt is used
for hotplug events, PMEs (on root ports), and link bandwidth change
notifications. The portbus driver will always claim the interrupt even if
the individual port service drivers, such as pciehp, are compiled out.

The second, bigger, problem is that the hotplug port service driver
fundamentally does not work on PowerNV. The platform assumes that all
PCI devices have a corresponding arch-specific handle derived from the DT
node for the device (pci_dn) and without one the platform will not allow
a PCI device to be enabled. This problem is largely due to historical
baggage, but it can't be resolved without significant re-factoring of the
platform PCI support.

We can fix these problems in the interim by setting the
"pcie_ports_disabled" flag during platform initialisation. The flag
indicates the platform owns the PCIe ports which stops the portbus driver
from being registered.

This does have the side effect of disabling all port services drivers
that is: AER, PME, BW notifications, hotplug, and DPC. However, this is
not a huge disadvantage on PowerNV since these services are either unused
or handled through other means.

Fixes: 66725152fb9f ("PCI/hotplug: PowerPC PowerNV PCI hotplug driver")
Signed-off-by: Oliver O'Halloran 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20191118065553.30362-1-oohall@gmail.com
Signed-off-by: Greg Kroah-Hartman

arm64: dts: apq8096-db820c: Increase load on l21 for SDCARD

2020-01-17T18:45:49+00:00

commit e38161bd325ea541ef2f258d8e28281077dde524 upstream.

In the same way as for msm8974-hammerhead, l21 load, used for SDCARD
VMMC, needs to be increased in order to prevent any voltage drop issues
(due to limited current) happening with some SDCARDS or during specific
operations (e.g. write).

Reviewed-by: Bjorn Andersson 
Fixes: 660a9763c6a9 (arm64: dts: qcom: db820c: Add pm8994 regulator node)
Signed-off-by: Loic Poulain 
Signed-off-by: Bjorn Andersson 
Signed-off-by: Greg Kroah-Hartman

arm64: Check for errata before evaluating cpu features

2020-01-17T18:45:46+00:00

commit dc0e36581eb2da1aa3c63ceeff0f10ef1e899b2a upstream.

Since commit d3aec8a28be3b8 ("arm64: capabilities: Restrict KPTI
detection to boot-time CPUs") we rely on errata flags being already
populated during feature enumeration. The order of errata and
features was flipped as part of commit ed478b3f9e4a ("arm64:
capabilities: Group handling of features and errata workarounds").

Return to the orginal order of errata and feature evaluation to
ensure errata flags are present during feature evaluation.

Fixes: ed478b3f9e4a ("arm64: capabilities: Group handling of
    features and errata workarounds")
CC: Suzuki K Poulose 
CC: Marc Zyngier 
Signed-off-by: Dirk Mueller 
Reviewed-by: Suzuki K Poulose 
Signed-off-by: Will Deacon 
Signed-off-by: Juerg Haefliger 
Signed-off-by: Greg Kroah-Hartman

arm64: add sentinel to kpti_safe_list

2020-01-17T18:45:46+00:00

commit 71c751f2a43fa03fae3cf5f0067ed3001a397013 upstream.

We're missing a sentinel entry in kpti_safe_list. Thus is_midr_in_range_list()
can walk past the end of kpti_safe_list. Depending on the contents of memory,
this could erroneously match a CPU's MIDR, cause a data abort, or other bad
outcomes.

Add the sentinel entry to avoid this.

Fixes: be5b299830c63ed7 ("arm64: capabilities: Add support for checks based on a list of MIDRs")
Signed-off-by: Mark Rutland 
Reported-by: Jan Kiszka 
Tested-by: Jan Kiszka 
Reviewed-by: Suzuki K Poulose 
Cc: Catalin Marinas 
Cc: Suzuki K Poulose 
Cc: Will Deacon 
Signed-off-by: Will Deacon 
Signed-off-by: Juerg Haefliger 
Signed-off-by: Greg Kroah-Hartman

arm64: Make sure permission updates happen for pmd/pud

2020-01-17T18:45:42+00:00

commit 82034c23fcbc2389c73d97737f61fa2dd6526413 upstream.

Commit 15122ee2c515 ("arm64: Enforce BBM for huge IO/VMAP mappings")
disallowed block mappings for ioremap since that code does not honor
break-before-make. The same APIs are also used for permission updating
though and the extra checks prevent the permission updates from happening,
even though this should be permitted. This results in read-only permissions
not being fully applied. Visibly, this can occasionaly be seen as a failure
on the built in rodata test when the test data ends up in a section or
as an odd RW gap on the page table dump. Fix this by using
pgattr_change_is_safe instead of p*d_present for determining if the
change is permitted.

Reviewed-by: Kees Cook 
Tested-by: Peter Robinson 
Reported-by: Peter Robinson 
Fixes: 15122ee2c515 ("arm64: Enforce BBM for huge IO/VMAP mappings")
Signed-off-by: Laura Abbott 
Signed-off-by: Will Deacon 
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

arm64: Enforce BBM for huge IO/VMAP mappings

2020-01-17T18:45:41+00:00

commit 15122ee2c515a253b0c66a3e618bc7ebe35105eb upstream.

ioremap_page_range doesn't honour break-before-make and attempts to put
down huge mappings (using p*d_set_huge) over the top of pre-existing
table entries. This leads to us leaking page table memory and also gives
rise to TLB conflicts and spurious aborts, which have been seen in
practice on Cortex-A75.

Until this has been resolved, refuse to put block mappings when the
existing entry is found to be present.

Fixes: 324420bf91f60 ("arm64: add support for ioremap() block mappings")
Reported-by: Hanjun Guo 
Reported-by: Lei Li 
Acked-by: Ard Biesheuvel 
Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman