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

xen/efi: Set nonblocking callbacks

2019-10-29T08:21:34+00:00

[ Upstream commit df359f0d09dc029829b66322707a2f558cb720f7 ]

Other parts of the kernel expect these nonblocking EFI callbacks to
exist and crash when running under Xen. Since the implementations of
xen_efi_set_variable() and xen_efi_query_variable_info() do not take any
locks, use them for the nonblocking callbacks too.

Signed-off-by: Ross Lagerwall 
Reviewed-by: Juergen Gross 
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin

ARM: dts: am4372: Set memory bandwidth limit for DISPC

2019-10-29T08:21:33+00:00

[ Upstream commit f90ec6cdf674248dcad85bf9af6e064bf472b841 ]

Set memory bandwidth limit to filter out resolutions above 720p@60Hz to
avoid underflow errors due to the bandwidth needs of higher resolutions.

am43xx can not provide enough bandwidth to DISPC to correctly handle
'high' resolutions.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

ARM: OMAP2+: Fix warnings with broken omap2_set_init_voltage()

2019-10-29T08:21:28+00:00

[ Upstream commit cf395f7ddb9ebc6b2d28d83b53d18aa4e7c19701 ]

This code is currently unable to find the dts opp tables as ti-cpufreq
needs to set them up first based on speed binning.

We stopped initializing the opp tables with platform code years ago for
device tree based booting with commit 92d51856d740 ("ARM: OMAP3+: do not
register non-dt OPP tables for device tree boot"), and all of mach-omap2
is now booting using device tree.

We currently get the following errors on init:

omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu
omap2_set_init_voltage: unable to set vdd_mpu
omap2_set_init_voltage: unable to find boot up OPP for vdd_core
omap2_set_init_voltage: unable to set vdd_core
omap2_set_init_voltage: unable to find boot up OPP for vdd_iva
omap2_set_init_voltage: unable to set vdd_iva

Let's just drop the unused code. Nowadays ti-cpufreq should be used to
to initialize things properly.

Cc: Adam Ford 
Cc: André Roth 
Cc: "H. Nikolaus Schaller" 
Cc: Nishanth Menon 
Cc: Tero Kristo 
Tested-by: Adam Ford  #logicpd-torpedo-37xx-devkit
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

ARM: OMAP2+: Add missing LCDC midlemode for am335x

2019-10-29T08:21:28+00:00

[ Upstream commit 17529d43b21c72466e9109d602c6f5c360a1a9e8 ]

TRM "Table 13-34. SYSCONFIG Register Field Descriptions" lists both
standbymode and idlemode that should be just the sidle and midle
registers where midle is currently unconfigured for lcdc_sysc. As
the dts data has been generated based on lcdc_sysc, we now have an
empty "ti,sysc-midle" property.

And so we currently get a warning for lcdc because of a difference
with dts provided configuration compared to the legacy platform
data. This is because lcdc has SYSC_HAS_MIDLEMODE configured in
the platform data without configuring the modes.

Let's fix the issue by adding the missing midlemode to lcdc_sysc,
and configuring the "ti,sysc-midle" property based on the TRM
values.

Fixes: f711c575cfec ("ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data")
Cc: Jyri Sarha 
Cc: Keerthy 
Cc: Robert Nelson 
Cc: Suman Anna 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

ARM: OMAP2+: Fix missing reset done flag for am3 and am43

2019-10-29T08:21:27+00:00

[ Upstream commit 8ad8041b98c665b6147e607b749586d6e20ba73a ]

For ti,sysc-omap4 compatible devices with no sysstatus register, we do have
reset done status available in the SOFTRESET bit that clears when the reset
is done. This is documented for example in am437x TRM for DMTIMER_TIOCP_CFG
register. The am335x TRM just says that SOFTRESET bit value 1 means reset is
ongoing, but it behaves the same way clearing after reset is done.

With the ti-sysc driver handling this automatically based on no sysstatus
register defined, we see warnings if SYSC_HAS_RESET_STATUS is missing in the
legacy platform data:

ti-sysc 48042000.target-module: sysc_flags 00000222 != 00000022
ti-sysc 48044000.target-module: sysc_flags 00000222 != 00000022
ti-sysc 48046000.target-module: sysc_flags 00000222 != 00000022
...

Let's fix these warnings by adding SYSC_HAS_RESET_STATUS. Let's also
remove the useless parentheses while at it.

If it turns out we do have ti,sysc-omap4 compatible devices without a
working SOFTRESET bit we can set up additional quirk handling for it.

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

ARM: dts: Fix gpio0 flags for am335x-icev2

2019-10-29T08:21:27+00:00

[ Upstream commit 4ef5d76b453908f21341e661a9b6f96862f6f589 ]

The ti,no-idle-on-init and ti,no-reset-on-init flags need to be at
the interconnect target module level for the modules that have it
defined. Otherwise we get the following warnings:

dts flag should be at module level for ti,no-idle-on-init
dts flag should be at module level for ti,no-reset-on-init

Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc")
Cc: Lokesh Vutla 
Reported-by: Suman Anna 
Reviewed-by: Lokesh Vutla 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

ARM: dts: Fix wrong clocks for dra7 mcasp

2019-10-29T08:21:24+00:00

[ Upstream commit 2d3c8ba3cffa00f76bedb713c8c2126c82d8cd13 ]

The ahclkr clkctrl clock bit 28 only exists for mcasp 1 and 2 on dra7.
This causes the following warning on beagle-x15:

ti-sysc 48468000.target-module: could not add child clock ahclkr: -19

Also the mcasp clkctrl clock bits are wrong:

For mcasp1 and 2 we have four clocks at bits 28, 24, 22 and 0:

bit 28 is ahclkr
bit 24 is ahclkx
bit 22 is auxclk
bit 0 is fck

For mcasp3 to 8 we have three clocks at bits 24, 22 and 0.

bit 24 is ahclkx
bit 22 is auxclk
bit 0 is fck

We do not have currently mapped auxclk at bit 22 for the drivers, that can
be added if needed.

Fixes: 5241ccbf2819 ("ARM: dts: Add missing ranges for dra7 mcasp l3 ports")
Cc: Suman Anna 
Cc: Tero Kristo 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

USB: rio500: Remove Rio 500 kernel driver

2019-10-17T20:46:30+00:00

commit 015664d15270a112c2371d812f03f7c579b35a73 upstream.

The Rio500 kernel driver has not been used by Rio500 owners since 2001
not long after the rio500 project added support for a user-space USB stack
through the very first versions of usbdevfs and then libusb.

Support for the kernel driver was removed from the upstream utilities
in 2008:
https://gitlab.freedesktop.org/hadess/rio500/commit/943f624ab721eb8281c287650fcc9e2026f6f5db

Cc: Cesar Miquel 
Signed-off-by: Bastien Nocera 
Cc: stable 
Link: https://lore.kernel.org/r/6251c17584d220472ce882a3d9c199c401a51a71.camel@hadess.net
Signed-off-by: Greg Kroah-Hartman

DTS: ARM: gta04: introduce legacy spi-cs-high to make display work again

2019-10-11T16:36:21+00:00

commit f1f028ff89cb0d37db299d48e7b2ce19be040d52 upstream.

commit 6953c57ab172 "gpio: of: Handle SPI chipselect legacy bindings"

did introduce logic to centrally handle the legacy spi-cs-high property
in combination with cs-gpios. This assumes that the polarity
of the CS has to be inverted if spi-cs-high is missing, even
and especially if non-legacy GPIO_ACTIVE_HIGH is specified.

The DTS for the GTA04 was orginally introduced under the assumption
that there is no need for spi-cs-high if the gpio is defined with
proper polarity GPIO_ACTIVE_HIGH.

This was not a problem until gpiolib changed the interpretation of
GPIO_ACTIVE_HIGH and missing spi-cs-high.

The effect is that the missing spi-cs-high is now interpreted as CS being
low (despite GPIO_ACTIVE_HIGH) which turns off the SPI interface when the
panel is to be programmed by the panel driver.

Therefore, we have to add the redundant and legacy spi-cs-high property
to properly activate CS.

Cc: stable@vger.kernel.org
Signed-off-by: H. Nikolaus Schaller 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

arm: use STACK_TOP when computing mmap base address

2019-10-07T17:01:45+00:00

[ Upstream commit 86e568e9c0525fc40e76d827212d5e9721cf7504 ]

mmap base address must be computed wrt stack top address, using TASK_SIZE
is wrong since STACK_TOP and TASK_SIZE are not equivalent.

Link: http://lkml.kernel.org/r/20190730055113.23635-8-alex@ghiti.fr
Signed-off-by: Alexandre Ghiti 
Acked-by: Kees Cook 
Reviewed-by: Luis Chamberlain 
Cc: Albert Ou 
Cc: Alexander Viro 
Cc: Catalin Marinas 
Cc: Christoph Hellwig 
Cc: Christoph Hellwig 
Cc: James Hogan 
Cc: Palmer Dabbelt 
Cc: Paul Burton 
Cc: Ralf Baechle 
Cc: Russell King 
Cc: Will Deacon 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin