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

ARM: dts: fix the SD card on the Snowball

2016-11-10T15:38:51+00:00

commit 1b283eea6228880b765bc40fe4e555416437ce58 upstream.

This fixes a very annoying regression on the Snowball SD card
that has been around for a while. It turns out that the device
tree does not configure the direction pins properly, nor sets
up the pins for the voltage converter properly at boot. Unless
all things are correctly set up, the feedback clock will not
work, and makes the driver spew messages in the console (but
it works, very slowly):

root@Ux500:/ mount /dev/mmcblk0p2 /mnt/
[    9.953460] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
[    9.960296] mmcblk0: error -110 sending status command, retrying
[    9.966461] mmcblk0: error -110 sending status command, retrying
[    9.972534] mmcblk0: error -110 sending status command, aborting

Fix this by rectifying the device tree to correspond to that of
the Ux500 HREF boards plus the DAT31DIR setting that is unique for
the Snowball, and things start working smoothly. Add in the SDR12
and SDR25 modes which this host can do without any problems.

I don't know if this has ever been correct, sadly. It works after
this patch.

Reported-by: Daniel Lezcano 
Cc: Ulf Hansson 
Signed-off-by: Linus Walleij 
Signed-off-by: Olof Johansson 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: omap3: overo: add missing unit name for lcd35 display

2016-10-31T11:02:15+00:00

commit 0b965a13ad81fa895e534d1f50b355ff8b0b3ed3 upstream.

Commit b8d368caa8dc ("ARM: dts: omap3: overo: remove unneded unit names
in display nodes") removed the unit names for all Overo display nodes
that didn't have a reg property.

But the display in arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi does
have a reg property so the correct fix was to make the unit name match
the value of the reg property, instead of removing it.

This patch fixes the following DTC warning for boards using this dtsi:

"ocp/spi@48098000/display has a reg or ranges property, but no unit name"

Fixes: b8d368caa8dc ("ARM: dts: omap3: overo: remove unneded unit names in display nodes")
Signed-off-by: Javier Martinez Canillas 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: fix RealView EB SMSC ethernet version

2016-10-31T11:02:15+00:00

commit c4ad72560df11961d3e57fb0fadfe88a9863c9ad upstream.

The ethernet version in the earlier RealView EB variants is
LAN91C111 and not LAN9118 according to ARM DUI 0303E
"RealView Emulation Baseboard User Guide" page 3-57.

Make sure that this is used for the base variant of the board.

As the DT bindings for LAN91C111 does not specify any power
supplies, these need to be deleted from the DTS file.

Fixes: 2440d29d2ae2 ("ARM: dts: realview: support all the RealView EB board variants")
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: NSP: Correct RAM amount for BCM958625HR board

2016-10-31T11:02:15+00:00

commit c53beb47f621e4a56f31af9f86470041655516c7 upstream.

The BCM958625HR board has 2GB of RAM available.  Increase the amount
from 512MB to 2GB and add the device type to the memory entry.

Fixes: 9a4865d42fe5 ("ARM: dts: NSP: Specify RAM amount for BCM958625HR board")
Signed-off-by: Jon Mason 
Signed-off-by: Florian Fainelli 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: sun9i: Add missing #interrupt-cells to R_PIO pinctrl device node

2016-10-31T11:02:14+00:00

commit 06ad11be7a9e13499ff8e55e46f09d22f9ee6fc0 upstream.

The R_PIO device node is missing #interrupt-cells, which causes
interrupt parsing to fail to match it as a valid interrupt controller.

Add #interrupt-cells to it. Also remove the unnecesary #address-cells
and #size-cells.

Fixes: 1ac56a6da9e1 ("ARM: dts: sun9i: Add A80 R_PIO pin controller device
		      node")
Signed-off-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
Signed-off-by: Greg Kroah-Hartman

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

2016-10-16T16:03:40+00:00

commit dcf5907e0e09a160a57160729f920add5df8e358 upstream.

The Qualcomm SPMI 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.

This misconfiguration was caused by a copy/pasting the
APQ8064 set-up, the latter has been fixed in a separate
patch.

Tested with one of the SPMI GPIOs: after this I can
successfully request one of these GPIOs as falling edge
from the device tree.

Fixes: 0840ea9e4457 ("ARM: dts: add GPIO and MPP to MSM8660 PMIC")
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: MSM8064 remove flags from SPMI/MPP IRQs

2016-10-16T16:03:40+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-16T16:03:40+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

Merge branch 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm

2016-10-02T22:23:00+00:00

Pull ARM fixes from Russell King:
 "Three relatively small fixes for ARM:

   - Roger noticed that dma_max_pfn() was calculating the upper limit
     wrongly, by adding the PFN offset of memory twice.

   - A fix from Robin to correct parsing of MPIDR values when the
     address size is larger than one BE32 unit.

   - A fix from Srinivas to ensure that we do not rely on the boot
     loader (or previous Linux kernel) setting the translation table
     base register a certain way in the decompressor, which can lead to
     crashes"

* 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm:
  ARM: 8618/1: decompressor: reset ttbcr fields to use TTBR0 on ARMv7
  ARM: 8617/1: dma: fix dma_max_pfn()
  ARM: 8616/1: dt: Respect property size when parsing CPUs

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

2016-10-02T19:05:14+00:00

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