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

ARM: OMAP4+: Fix bad fallthrough for cpuidle

2017-01-15T12:41:36+00:00

commit cbf2642872333547b56b8c4d943f5ed04ac9a4ee upstream.

We don't want to fall through to a bunch of errors for retention
if PM_OMAP4_CPU_OSWR_DISABLE is not configured for a SoC.

Fixes: 6099dd37c669 ("ARM: OMAP5 / DRA7: Enable CPU RET on suspend")
Acked-by: Santosh Shilimkar 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: zynq: Reserve correct amount of non-DMA RAM

2017-01-15T12:41:36+00:00

commit 7a3cc2a7b2c723aa552028f4e66841cec183756d upstream.

On Zynq, we haven't been reserving the correct amount of DMA-incapable
RAM to keep DMA away from it (per the Zynq TRM Section 4.1, it should be
the first 512k). In older kernels, this was masked by the
memblock_reserve call in arm_memblock_init(). Now, reserve the correct
amount excplicitly rather than relying on swapper_pg_dir, which is an
address and not a size anyway.

Fixes: 46f5b96 ("ARM: zynq: Reserve not DMAable space in front of the kernel")
Signed-off-by: Kyle Roeschley 
Tested-by: Nathan Rossi 
Signed-off-by: Michal Simek 
Signed-off-by: Greg Kroah-Hartman

crypto: arm/aes-ce - fix for big endian

2017-01-12T10:22:50+00:00

commit 58010fa6f71c9577922b22e46014b95a4ec80fa0 upstream.

The AES key schedule generation is mostly endian agnostic, with the
exception of the rotation and the incorporation of the round constant
at the start of each round. So implement a big endian specific version
of that part to make the whole routine big endian compatible.

Fixes: 86464859cc77 ("crypto: arm - AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions")
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: r8a7794: Correct hsusb parent clock

2017-01-12T10:22:47+00:00

commit dc8ee9dbdba509fb58e23ba79f2e6059fe5d8b3b upstream.

The parent clock of the HSUSB clock is the HP clock, not the MP clock.

Fixes: c7bab9f929e51761 ("ARM: shmobile: r8a7794: Add USB clocks to device tree")
Signed-off-by: Geert Uytterhoeven 
Acked-by: Yoshihiro Shimoda 
Signed-off-by: Simon Horman 
Signed-off-by: Greg Kroah-Hartman

ARM: davinci: da850: don't add emac clock to lookup table twice

2017-01-12T10:22:43+00:00

commit ef37427ac5677331145ab27a17e6f5f1b43f0c11 upstream.

Similarly to the aemif clock - this screws up the linked list of clock
children. Create a separate clock for mdio inheriting the rate from
emac_clk.

Signed-off-by: Bartosz Golaszewski 
[nsekhar@ti.com: add a comment over mdio_clk to explaing its existence +
		 commit headline updates]
Signed-off-by: Sekhar Nori 
Signed-off-by: Greg Kroah-Hartman

arm/xen: Use alloc_percpu rather than __alloc_percpu

2017-01-06T10:16:17+00:00

commit 24d5373dda7c00a438d26016bce140299fae675e upstream.

The function xen_guest_init is using __alloc_percpu with an alignment
which are not power of two.

However, the percpu allocator never supported alignments which are not power
of two and has always behaved incorectly in thise case.

Commit 3ca45a4 "percpu: ensure requested alignment is power of two"
introduced a check which trigger a warning [1] when booting linux-next
on Xen. But in reality this bug was always present.

This can be fixed by replacing the call to __alloc_percpu with
alloc_percpu. The latter will use an alignment which are a power of two.

[1]

[    0.023921] illegal size (48) or align (48) for percpu allocation
[    0.024167] ------------[ cut here ]------------
[    0.024344] WARNING: CPU: 0 PID: 1 at linux/mm/percpu.c:892 pcpu_alloc+0x88/0x6c0
[    0.024584] Modules linked in:
[    0.024708]
[    0.024804] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.9.0-rc7-next-20161128 #473
[    0.025012] Hardware name: Foundation-v8A (DT)
[    0.025162] task: ffff80003d870000 task.stack: ffff80003d844000
[    0.025351] PC is at pcpu_alloc+0x88/0x6c0
[    0.025490] LR is at pcpu_alloc+0x88/0x6c0
[    0.025624] pc : [] lr : []
pstate: 60000045
[    0.025830] sp : ffff80003d847cd0
[    0.025946] x29: ffff80003d847cd0 x28: 0000000000000000
[    0.026147] x27: 0000000000000000 x26: 0000000000000000
[    0.026348] x25: 0000000000000000 x24: 0000000000000000
[    0.026549] x23: 0000000000000000 x22: 00000000024000c0
[    0.026752] x21: ffff000008e97000 x20: 0000000000000000
[    0.026953] x19: 0000000000000030 x18: 0000000000000010
[    0.027155] x17: 0000000000000a3f x16: 00000000deadbeef
[    0.027357] x15: 0000000000000006 x14: ffff000088f79c3f
[    0.027573] x13: ffff000008f79c4d x12: 0000000000000041
[    0.027782] x11: 0000000000000006 x10: 0000000000000042
[    0.027995] x9 : ffff80003d847a40 x8 : 6f697461636f6c6c
[    0.028208] x7 : 6120757063726570 x6 : ffff000008f79c84
[    0.028419] x5 : 0000000000000005 x4 : 0000000000000000
[    0.028628] x3 : 0000000000000000 x2 : 000000000000017f
[    0.028840] x1 : ffff80003d870000 x0 : 0000000000000035
[    0.029056]
[    0.029152] ---[ end trace 0000000000000000 ]---
[    0.029297] Call trace:
[    0.029403] Exception stack(0xffff80003d847b00 to
                               0xffff80003d847c30)
[    0.029621] 7b00: 0000000000000030 0001000000000000
ffff80003d847cd0 ffff00000818e678
[    0.029901] 7b20: 0000000000000002 0000000000000004
ffff000008f7c060 0000000000000035
[    0.030153] 7b40: ffff000008f79000 ffff000008c4cd88
ffff80003d847bf0 ffff000008101778
[    0.030402] 7b60: 0000000000000030 0000000000000000
ffff000008e97000 00000000024000c0
[    0.030647] 7b80: 0000000000000000 0000000000000000
0000000000000000 0000000000000000
[    0.030895] 7ba0: 0000000000000035 ffff80003d870000
000000000000017f 0000000000000000
[    0.031144] 7bc0: 0000000000000000 0000000000000005
ffff000008f79c84 6120757063726570
[    0.031394] 7be0: 6f697461636f6c6c ffff80003d847a40
0000000000000042 0000000000000006
[    0.031643] 7c00: 0000000000000041 ffff000008f79c4d
ffff000088f79c3f 0000000000000006
[    0.031877] 7c20: 00000000deadbeef 0000000000000a3f
[    0.032051] [] pcpu_alloc+0x88/0x6c0
[    0.032229] [] __alloc_percpu+0x18/0x20
[    0.032409] [] xen_guest_init+0x174/0x2f4
[    0.032591] [] do_one_initcall+0x38/0x130
[    0.032783] [] kernel_init_freeable+0xe0/0x248
[    0.032995] [] kernel_init+0x10/0x100
[    0.033172] [] ret_from_fork+0x10/0x50

Reported-by: Wei Chen 
Link: https://lkml.org/lkml/2016/11/28/669
Signed-off-by: Julien Grall 
Signed-off-by: Stefano Stabellini 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Greg Kroah-Hartman

ARM: 8584/1: floppy: avoid gcc-6 warning

2016-11-10T15:36:36+00:00

commit dd665be0e243873343a28e18f9f345927b658daf upstream.

gcc-6.0 warns about comparisons between two identical expressions,
which is what we get in the floppy driver when writing to the FD_DOR
register:

drivers/block/floppy.c: In function 'set_dor':
drivers/block/floppy.c:810:44: error: self-comparison always evaluates to true [-Werror=tautological-compare]
   fd_outb(newdor, FD_DOR);

It would be nice to use a static inline function instead of the
macro, to avoid the warning, but we cannot do that because the
FD_DOR definition is incomplete at this point.

Adding a cast to (u32) is a harmless way to shut up the warning,
just not very nice.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: pxa: pxa_cplds: fix interrupt handling

2016-10-31T10:14:01+00:00

commit 9ba63e3cc849cdaf3b675c47cc51fe35419e5117 upstream.

Since its initial commit, the driver is buggy for multiple interrupts
handling. The translation from the former lubbock.c file was not
complete, and might stall all interrupt handling when multiple
interrupts occur.

This is especially true when inside the interrupt handler and if a new
interrupt comes and is not handled, leaving the output line still held,
and not creating a transition as the GPIO block behind would expect to
trigger another cplds_irq_handler() call.

For the record, the hardware is working as follows.

The interrupt mechanism relies on :
 - one status register
 - one mask register

Let's suppose the input irq lines are called :
 - i_sa1111
 - i_lan91x
 - i_mmc_cd
Let's suppose the status register for each irq line is called :
 - status_sa1111
 - status_lan91x
 - status_mmc_cd
Let's suppose the interrupt mask for each irq line is called :
 - irqen_sa1111
 - irqen_lan91x
 - irqen_mmc_cd
Let's suppose the output irq line, connected to GPIO0 is called :
 - o_gpio0

The behavior is as follows :
 - o_gpio0 = not((status_sa1111 & irqen_sa1111) |
		 (status_lan91x & irqen_lan91x) |
		 (status_mmc_cd & irqen_mmc_cd))
   => this is a N-to-1 NOR gate and multiple AND gates
 - irqen_* is exactly as programmed by a write to the FPGA
 - status_* behavior is governed by a bi-stable D flip-flop
   => on next FPGA clock :
     - if i_xxx is high, status_xxx becomes 1
     - if i_xxx is low, status_xxx remains as it is
     - if software sets status_xxx to 0, the D flip-flop is reset
       => status_xxx becomes 0
       => on next FPGA clock cycle, if i_xxx is high, status_xxx becomes
	  1 again

Fixes: fc9e38c0f4d3 ("ARM: pxa: lubbock: use new pxa_cplds driver")
Reported-by: Russell King 
Signed-off-by: Robert Jarzmik 
Signed-off-by: Greg Kroah-Hartman

crypto: arm/ghash-ce - add missing async import/export

2016-10-31T10:13:59+00:00

commit ed4767d612fd2c39e2c4c69eba484c1219dcddb6 upstream.

Since commit 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero"),
all ahash drivers are required to implement import()/export(), and must have
a non-zero statesize. Fix this for the ARM Crypto Extensions GHASH
implementation.

Fixes: 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero")
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

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