linux-stable.git/arch/arm, branch v4.19.76

ARM: 8901/1: add a criteria for pfn_valid of arm

2019-09-21T05:17:05+00:00

[ Upstream commit 5b3efa4f1479c91cb8361acef55f9c6662feba57 ]

pfn_valid can be wrong when parsing a invalid pfn whose phys address
exceeds BITS_PER_LONG as the MSB will be trimed when shifted.

The issue originally arise from bellowing call stack, which corresponding to
an access of the /proc/kpageflags from userspace with a invalid pfn parameter
and leads to kernel panic.

[46886.723249] c7 [] (stable_page_flags) from []
[46886.723264] c7 [] (kpageflags_read) from []
[46886.723280] c7 [] (proc_reg_read) from []
[46886.723290] c7 [] (__vfs_read) from []
[46886.723301] c7 [] (vfs_read) from []
[46886.723315] c7 [] (SyS_pread64) from []
(ret_fast_syscall+0x0/0x28)

Signed-off-by: Zhaoyang Huang 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin

ARM: 8874/1: mm: only adjust sections of valid mm structures

2019-09-21T05:16:58+00:00

[ Upstream commit c51bc12d06b3a5494fbfcbd788a8e307932a06e9 ]

A timing hazard exists when an early fork/exec thread begins
exiting and sets its mm pointer to NULL while a separate core
tries to update the section information.

This commit ensures that the mm pointer is not NULL before
setting its section parameters. The arguments provided by
commit 11ce4b33aedc ("ARM: 8672/1: mm: remove tasklist locking
from update_sections_early()") are equally valid for not
requiring grabbing the task_lock around this check.

Fixes: 08925c2f124f ("ARM: 8464/1: Update all mm structures with section adjustments")
Signed-off-by: Doug Berger 
Acked-by: Laura Abbott 
Cc: Mike Rapoport 
Cc: Andrew Morton 
Cc: Florian Fainelli 
Cc: Rob Herring 
Cc: "Steven Rostedt (VMware)" 
Cc: Peng Fan 
Cc: Geert Uytterhoeven 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin

ARM: OMAP1: ams-delta-fiq: Fix missing irq_ack

2019-09-21T05:16:50+00:00

[ Upstream commit fa8397e45c64e60c80373bc19ee56e42a6bed9b6 ]

Non-serio path of Amstrad Delta FIQ deferred handler depended on
irq_ack() method provided by OMAP GPIO driver.  That method has been
removed by commit 693de831c6e5 ("gpio: omap: remove irq_ack method").
Remove useless code from the deferred handler and reimplement the
missing operation inside the base FIQ handler.

Should another dependency - irq_unmask() - be ever removed from the OMAP
GPIO driver, WARN once if missing.

Signed-off-by: Janusz Krzysztofik 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

ARM: dts: dra74x: Fix iodelay configuration for mmc3

2019-09-21T05:16:50+00:00

[ Upstream commit 07f9a8be66a9bd86f9eaedf8f8aeb416195adab8 ]

According to the latest am572x[1] and dra74x[2] data manuals, mmc3
default, hs, sdr12 and sdr25 modes use iodelay values given in
MMC3_MANUAL1. Set the MODE_SELECT bit for these so that manual mode is
selected and correct iodelay values can be configured.

[1] http://www.ti.com/lit/ds/symlink/am5728.pdf
[2] http://www.ti.com/lit/ds/symlink/dra746.pdf

Signed-off-by: Faiz Abbas 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

ARM: OMAP2+: Fix omap4 errata warning on other SoCs

2019-09-21T05:16:49+00:00

[ Upstream commit 45da5e09dd32fa98c32eaafe2513db6bd75e2f4f ]

We have errata i688 workaround produce warnings on SoCs other than
omap4 and omap5:

omap4_sram_init:Unable to allocate sram needed to handle errata I688
omap4_sram_init:Unable to get sram pool needed to handle errata I688

This is happening because there is no ti,omap4-mpu node, or no SRAM
to configure for the other SoCs, so let's remove the warning based
on the SoC revision checks.

As nobody has complained it seems that the other SoC variants do not
need this workaround.

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

ARM: OMAP2+: Fix missing SYSC_HAS_RESET_STATUS for dra7 epwmss

2019-09-21T05:16:48+00:00

[ Upstream commit afd58b162e48076e3fe66d08a69eefbd6fe71643 ]

TRM says PWMSS_SYSCONFIG bit for SOFTRESET changes to zero when
reset is completed. Let's configure it as otherwise we get warnings
on boot when we check the data against dts provided data. Eventually
the legacy platform data will be just dropped, but let's fix the
warning first.

Reviewed-by: Suman Anna 
Tested-by: Keerthy 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

ARM: dts: am57xx: Disable voltage switching for SD card

2019-09-21T05:16:47+00:00

[ Upstream commit fb59ee37cfe20d10d19568899d1458a58361246c ]

If UHS speed modes are enabled, a compatible SD card switches down to
1.8V during enumeration. If after this a software reboot/crash takes
place and on-chip ROM tries to enumerate the SD card, the difference in
IO voltages (host @ 3.3V and card @ 1.8V) may end up damaging the card.

The fix for this is to have support for power cycling the card in
hardware (with a PORz/soft-reset line causing a power cycle of the
card). Because the beaglebone X15 (rev A,B and C), am57xx-idks and
am57xx-evms don't have this capability, disable voltage switching for
these boards.

The major effect of this is that the maximum supported speed
mode is now high speed(50 MHz) down from SDR104(200 MHz).

commit 88a748419b84 ("ARM: dts: am57xx-idk: Remove support for voltage
switching for SD card") did this only for idk boards. Do it for all
affected boards.

Signed-off-by: Faiz Abbas 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

ARM: dts: gemini: Set DIR-685 SPI CS as active low

2019-09-16T06:22:19+00:00

[ Upstream commit f90b8fda3a9d72a9422ea80ae95843697f94ea4a ]

The SPI to the display on the DIR-685 is active low, we were
just saved by the SPI library enforcing active low on everything
before, so set it as active low to avoid ambiguity.

Link: https://lore.kernel.org/r/20190715202101.16060-1-linus.walleij@linaro.org
Cc: stable@vger.kernel.org
Signed-off-by: Linus Walleij 
Signed-off-by: Olof Johansson 
Signed-off-by: Sasha Levin

ARM: dts: qcom: ipq4019: enlarge PCIe BAR range

2019-09-16T06:22:11+00:00

[ Upstream commit f3e35357cd460a8aeb48b8113dc4b761a7d5c828 ]

David Bauer reported that the VDSL modem (attached via PCIe)
on his AVM Fritz!Box 7530 was complaining about not having
enough space in the BAR. A closer inspection of the old
qcom-ipq40xx.dtsi pulled from the GL-iNet repository listed:

| qcom,pcie@80000 {
|	compatible = "qcom,msm_pcie";
|	reg = <0x80000 0x2000>,
|	      <0x99000 0x800>,
|	      <0x40000000 0xf1d>,
|	      <0x40000f20 0xa8>,
|	      <0x40100000 0x1000>,
|	      <0x40200000 0x100000>,
|	      <0x40300000 0xd00000>;
|	reg-names = "parf", "phy", "dm_core", "elbi",
|			"conf", "io", "bars";

Matching the reg-names with the listed reg leads to
<0xd00000> as the size for the "bars".

Cc: stable@vger.kernel.org
BugLink: https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg45212.html
Reported-by: David Bauer 
Signed-off-by: Christian Lamparter 
Signed-off-by: Andy Gross 
Signed-off-by: Sasha Levin

ARM: dts: qcom: ipq4019: Fix MSI IRQ type

2019-09-16T06:22:11+00:00

[ Upstream commit 97131f85c08e024df49480ed499aae8fb754067f ]

The databook clearly states that the MSI IRQ (msi_ctrl_int) is a level
triggered interrupt.

The msi_ctrl_int will be high for as long as any MSI status bit is set,
thus the IRQ type should be set to IRQ_TYPE_LEVEL_HIGH, causing the
IRQ handler to keep getting called, as long as any MSI status bit is set.

A git grep shows that ipq4019 is the only SoC using snps,dw-pcie that has
configured this IRQ incorrectly.

Not having the correct IRQ type defined will cause us to lose interrupts,
which in turn causes timeouts in the PCIe endpoint drivers.

Signed-off-by: Niklas Cassel 
Reviewed-by: Bjorn Andersson 
Signed-off-by: Andy Gross 
Signed-off-by: Sasha Levin