linux-stable.git/arch/arm/boot, branch v4.4.26

ARM: dts: MSM8064 remove flags from SPMI/MPP IRQs

2016-10-16T15:36:15+00:00

commit ca88696e8b73a9fa2b1de445747e9235c3a7bd50 upstream.

The Qualcomm PMIC GPIO and MPP lines are problematic: the
are fetched from the main MFD driver with platform_get_irq()
which means that at this point they will all be assigned the
flags set up for the interrupts in the device tree.

That is problematic since these are flagged as rising edge
and an this point the interrupt descriptor is assigned a
rising edge, while the only thing the GPIO/MPP drivers really
do is issue irq_get_irqchip_state() on the line to read it
out and to provide a .to_irq() helper for *other* IRQ
consumers.

If another device tree node tries to flag the same IRQ
for use as something else than rising edge, the kernel
irqdomain core will protest like this:

  type mismatch, failed to map hwirq-NN for !

Which is what happens when the device tree defines two
contradictory flags for the same interrupt line.

To work around this and alleviate the problem, assign 0
as flag for the interrupts taken by the PM GPIO and MPP
drivers. This will lead to the flag being unset, and a
second consumer requesting rising, falling, both or level
interrupts will be respected. This is what the qcom-pm*.dtsi
files already do.

Switched to using the symbolic name IRQ_TYPE_NONE so that
we get this more readable.

Fixes: bce360469676 ("ARM: dts: apq8064: add pm8921 mpp support")
Fixes: 874443fe9e33 ("ARM: dts: apq8064: Add pm8921 mfd and its gpio node")
Cc: Srinivas Kandagatla 
Cc: Stephen Boyd 
Cc: Björn Andersson 
Cc: Ivan T. Ivanov 
Cc: John Stultz 
Cc: Andy Gross 
Signed-off-by: Linus Walleij 
Signed-off-by: Andy Gross 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: mvebu: armada-390: add missing compatibility string and bracket

2016-10-16T15:36:15+00:00

commit 061492cfad9f11dbc32df741a7164f307b69b6e6 upstream.

The armada-390.dtsi was broken since the first patch which adds Device Tree
files for Armada 39x SoC was introduced.

Signed-off-by: Grzegorz Jaszczyk 
Acked-by: Gregory CLEMENT 
Fixes 538da83 ("ARM: mvebu: add Device Tree files for Armada 39x SoC and board")
Signed-off-by: Greg Kroah-Hartman 

Signed-off-by: Gregory CLEMENT

ARM: sun5i: Fix typo in trip point temperature

2016-10-07T13:23:43+00:00

commit 539d5c48a4aff5a4afcff117418618b49126c54c upstream.

Set cpu_alert0 temperature to 85°C instead of 850°C.

Fixes: 32a5d2d170cc ("ARM: dts: sun5i: Add cpu thermal zones to dtsi")
Signed-off-by: Hugo Grostabussiat 
Acked-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
Signed-off-by: Greg Kroah-Hartman

ARM: 8618/1: decompressor: reset ttbcr fields to use TTBR0 on ARMv7

2016-10-07T13:23:42+00:00

commit 117e5e9c4cfcb7628f08de074fbfefec1bb678b7 upstream.

If the bootloader uses the long descriptor format and jumps to
kernel decompressor code, TTBCR may not be in a right state.
Before enabling the MMU, it is required to clear the TTBCR.PD0
field to use TTBR0 for translation table walks.

The commit dbece45894d3a ("ARM: 7501/1: decompressor:
reset ttbcr for VMSA ARMv7 cores") does the reset of TTBCR.N, but
doesn't consider all the bits for the size of TTBCR.N.

Clear TTBCR.PD0 field and reset all the three bits of TTBCR.N to
indicate the use of TTBR0 and the correct base address width.

Fixes: dbece45894d3 ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores")
Acked-by: Robin Murphy 
Signed-off-by: Srinivas Ramana 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: STiH407-family: Provide interconnect clock for consumption in ST SDHCI

2016-09-24T08:07:40+00:00

commit 78567f135d9bbbaf4538f63656d3e4d957c35fe9 upstream.

The STiH4{07,10} platform contains some interconnect clocks which are used
by various IPs.  If these clocks aren't handled correctly by ST's SDHCI
driver MMC will break and the following output can be observed:

[   13.916949] mmc0: Timeout waiting for hardware interrupt.
[   13.922349] sdhci: =========== REGISTER DUMP (mmc0)===========
[   13.928175] sdhci: Sys addr: 0x00000000 | Version:  0x00001002
[   13.933999] sdhci: Blk size: 0x00007040 | Blk cnt:  0x00000001
[   13.939825] sdhci: Argument: 0x00fffff0 | Trn mode: 0x00000013
[   13.945650] sdhci: Present:  0x1fff0206 | Host ctl: 0x00000011
[   13.951475] sdhci: Power:    0x0000000f | Blk gap:  0x00000080
[   13.957300] sdhci: Wake-up:  0x00000000 | Clock:    0x00003f07
[   13.963126] sdhci: Timeout:  0x00000004 | Int stat: 0x00000000
[   13.968952] sdhci: Int enab: 0x02ff008b | Sig enab: 0x02ff008b
[   13.974777] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
[   13.980602] sdhci: Caps:     0x21ed3281 | Caps_1:   0x00000000
[   13.986428] sdhci: Cmd:      0x0000063a | Max curr: 0x00000000
[   13.992252] sdhci: Host ctl2: 0x00000000
[   13.996166] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x7c048200
[   14.001990] sdhci: ===========================================
[   14.009802] mmc0: Got data interrupt 0x02000000 even though no data operation was in progress.

Tested-by: Peter Griffin 
Signed-off-by: Lee Jones 
Acked-by: Patrice Chotard 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: overo: fix gpmc nand on boards with ethernet

2016-09-24T08:07:40+00:00

commit 153b58ea932b2d0642fa5cd41c93bb0555f3f09b upstream.

The gpmc ranges property for NAND at CS0 was being overridden by later
includes that defined gpmc ethernet nodes, effectively breaking NAND on
these systems:

	omap-gpmc 6e000000.gpmc: /ocp/gpmc@6e000000/nand@0,0 has
	malformed 'reg' property

Instead of redefining the NAND range in every such dtsi, define all
currently used ranges in omap3-overo-base.dtsi.

Fixes: 98ce6007efb4 ("ARM: dts: overo: Support PoP NAND")
Signed-off-by: Johan Hovold 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: overo: fix gpmc nand cs0 range

2016-09-24T08:07:40+00:00

commit 5e0568dfbfb8c13cdb69c9fd06d600593ad4b430 upstream.

The gpmc ranges property for NAND at CS0 has been broken since it was
first added.

This currently prevents the nand gpmc child node from being probed:

	omap-gpmc 6e000000.gpmc: /ocp/gpmc@6e000000/nand@0,0 has
	malformed 'reg' property

and consequently the NAND device from being registered.

Fixes: 98ce6007efb4 ("ARM: dts: overo: Support PoP NAND")
Signed-off-by: Johan Hovold 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: imx6qdl: Fix SPDIF regression

2016-09-24T08:07:40+00:00

commit f065e9e4addd75c21bb976bb2558648bf4f61de6 upstream.

Commit 833f2cbf7091 ("ARM: dts: imx6: change the core clock of spdif")
changed many more clocks than only the SPDIF core clock as stated in
the commit message.

The MLB clock has been added and this causes SPDIF regression as
reported by Xavi Drudis Ferran and also in this forum post:
https://forum.digikey.com/thread/34240

The MX6Q Reference Manual does not mention that MLB is a clock related
to SPDIF, so change it back to a dummy clock to restore SPDIF
functionality.

Thanks to Ambika for providing the fix at:
https://community.nxp.com/thread/387131

Fixes: 833f2cbf7091 ("ARM: dts: imx6: change the core clock of spdif")
Reported-by: Xavi Drudis Ferran 
Signed-off-by: Fabio Estevam 
Tested-by:  Xavi Drudis Ferran 
Signed-off-by: Shawn Guo 
Signed-off-by: Greg Kroah-Hartman

ARM: kirkwood: ib62x0: fix size of u-boot environment partition

2016-09-24T08:07:39+00:00

commit a778937888867aac17a33887d1c429120790fbc2 upstream.

Commit 148c274ea644 ("ARM: kirkwood: ib62x0: add u-boot environment
partition") split the "u-boot" partition into "u-boot" and "u-boot
environment".  However, instead of the size of the environment, an offset
was given, resulting in overlapping partitions.

Signed-off-by: Simon Baatz 
Fixes: 148c274ea644 ("ARM: kirkwood: ib62x0: add u-boot environment partition")
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Sebastian Hesselbarth 
Cc: Luka Perkov 
Reviewed-by: Andrew Lunn 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: STiH410: Handle interconnect clock required by EHCI/OHCI (USB)

2016-09-24T08:07:39+00:00

commit 7e9d2850a8db4e0d85a20bb692198bf2cc4be3b7 upstream.

The STiH4{07,10} platform contains some interconnect clocks which are used
by various IPs.  If this clock isn't handled correctly by ST's EHCI/OHCI
drivers, their hub won't be found, the following error be shown and the
result will be non-working USB:

  [   97.221963] hub 2-1:1.0: hub_ext_port_status failed (err = -110)

Tested-by: Peter Griffin 
Signed-off-by: Lee Jones 
Acked-by: Patrice Chotard 
Signed-off-by: Greg Kroah-Hartman