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

lib/decompressors: use real out buf size for gunzip with kernel

2015-09-29T17:33:37+00:00

commit 2d3862d26e67a59340ba1cf1748196c76c5787de upstream.

When loading x86 64bit kernel above 4GiB with patched grub2, got kernel
gunzip error.

| early console in decompress_kernel
| decompress_kernel:
|       input: [0x807f2143b4-0x807ff61aee]
|      output: [0x807cc00000-0x807f3ea29b] 0x027ea29c: output_len
| boot via startup_64
| KASLR using RDTSC...
|  new output: [0x46fe000000-0x470138cfff] 0x0338d000: output_run_size
|  decompress: [0x46fe000000-0x47007ea29b] <=== [0x807f2143b4-0x807ff61aee]
|
| Decompressing Linux... gz...
|
| uncompression error
|
| -- System halted

the new buffer is at 0x46fe000000ULL, decompressor_gzip is using
0xffffffb901ffffff as out_len.  gunzip in lib/zlib_inflate/inflate.c cap
that len to 0x01ffffff and decompress fails later.

We could hit this problem with crashkernel booting that uses kexec loading
kernel above 4GiB.

We have decompress_* support:
    1. inbuf[]/outbuf[] for kernel preboot.
    2. inbuf[]/flush() for initramfs
    3. fill()/flush() for initrd.
This bug only affect kernel preboot path that use outbuf[].

Add __decompress and take real out_buf_len for gunzip instead of guessing
wrong buf size.

Fixes: 1431574a1c4 (lib/decompressors: fix "no limit" output buffer length)
Signed-off-by: Yinghai Lu 
Cc: Alexandre Courbot 
Cc: Jon Medhurst 
Cc: Stephen Warren 
Cc: "H. Peter Anvin" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

arm/arm64: KVM: vgic: Check for !irqchip_in_kernel() when mapping resources

2015-09-29T17:33:20+00:00

commit c2f58514cfb374d5368c9da945f1765cd48eb0da upstream.

Until b26e5fdac43c ("arm/arm64: KVM: introduce per-VM ops"),
kvm_vgic_map_resources() used to include a check on irqchip_in_kernel(),
and vgic_v2_map_resources() still has it.

But now vm_ops are not initialized until we call kvm_vgic_create().
Therefore kvm_vgic_map_resources() can being called without a VGIC,
and we die because vm_ops.map_resources is NULL.

Fixing this restores QEMU's kernel-irqchip=off option to a working state,
allowing to use GIC emulation in userspace.

Fixes: b26e5fdac43c ("arm/arm64: KVM: introduce per-VM ops")
Signed-off-by: Pavel Fedin 
[maz: reworked commit message]
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman

ARM: rockchip: fix broken build

2015-09-21T17:11:00+00:00

commit cb8cc37f4d38d96552f2c52deb15e511cdacf906 upstream.

The following was seen in branch[0] build.

arch/arm/mach-rockchip/platsmp.c:154:23: error:
    'rockchip_secondary_startup' undeclared (first use in this function)

branch[0]:
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
v4.3-armsoc/soc

The broken build is caused by the commit fe4407c0dc58
("ARM: rockchip: fix the CPU soft reset").

Signed-off-by: Caesar Wang 

The breakage was a result of it being wrongly merged in my branch with
the cache invalidation rework from Russell 02b4e2756e01c
("ARM: v7 setup function should invalidate L1 cache").

Signed-off-by: Heiko Stuebner 
Cc: Willy Tarreau 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: rockchip: fix rk3288 watchdog irq

2015-09-21T17:10:58+00:00

commit 1a1b698b115467242303daf5fe1d3c9886c2fa17 upstream.

The watchdog irq is actually SPI 79, which translates to the original
111 in the manual where the SPI irqs start at 32.
The current dw_wdt driver does not use the irq at all, so this issue
never surfaced. Nevertheless fix this for a time we want to use the irq.

Fixes: 2ab557b72d46 ("ARM: dts: rockchip: add core rk3288 dtsi")
Signed-off-by: Heiko Stuebner 
Reviewed-by: Douglas Anderson 
Signed-off-by: Greg Kroah-Hartman

ARM: rockchip: fix the CPU soft reset

2015-09-21T17:10:58+00:00

commit fe4407c0dc58215a7abfb7532740d79ddabe7a7a upstream.

We need different orderings when turning a core on and turning a core
off.  In one case we need to assert reset before turning power off.
In ther other case we need to turn power on and the deassert reset.

In general, the correct flow is:

CPU off:
    reset_control_assert
    regmap_update_bits(pmu, PMU_PWRDN_CON, BIT(pd), BIT(pd))
    wait_for_power_domain_to_turn_off
CPU on:
    regmap_update_bits(pmu, PMU_PWRDN_CON, BIT(pd), 0)
    wait_for_power_domain_to_turn_on
    reset_control_deassert

This is needed for stressing CPU up/down, as per:
    cd /sys/devices/system/cpu/
    for i in $(seq 10000); do
        echo "================= $i ============"
        for j in $(seq 100); do
            while [[ "$(cat cpu1/online)$(cat cpu2/online)$(cat cpu3/online)" != "000"" ]]
                echo 0 > cpu1/online
                echo 0 > cpu2/online
                echo 0 > cpu3/online
            done
            while [[ "$(cat cpu1/online)$(cat cpu2/online)$(cat cpu3/online)" != "111" ]]; do
                echo 1 > cpu1/online
                echo 1 > cpu2/online
                echo 1 > cpu3/online
            done
        done
    done

The following is reproducable log:
    [34466.186812] PM: noirq suspend of devices complete after 0.669 msecs
    [34466.186824] Disabling non-boot CPUs ...
    [34466.187509] CPU1: shutdown
    [34466.188672] CPU2: shutdown
    [34473.736627] Kernel panic - not syncing:Watchdog detected hard LOCKUP on cpu 0
    .......
or others similar log:
    .......
    [ 4072.454453] CPU1: shutdown
    [ 4072.504436] CPU2: shutdown
    [ 4072.554426] CPU3: shutdown
    [ 4072.577827] CPU1: Booted secondary processor
    [ 4072.582611] CPU2: Booted secondary processor
    

    Tested by cpu up/down scripts, the results told us need delay more time
before write the sram. The wait time is affected by many aspects
(e.g: cpu frequency, bootrom frequency, sram frequency, bus speed, ...).

    Although the cpus other than cpu0 will write the sram, the speedy is
no the same as cpu0, if the cpu0 early wake up, perhaps the other cpus
can't startup. As we know, the cpu0 can wake up when the cpu1/2/3 write
the 'sram+4/8' and send the sev.
    Anyway.....
    At the moment, 1ms delay will be happy work for cpu up/down scripts test.

Signed-off-by: Caesar Wang 
Reviewed-by: Doug Anderson 
Reviewed-by: Kever Yang 
Fixes: 3ee851e212d0 ("ARM: rockchip: add basic smp support for rk3288")
Signed-off-by: Heiko Stuebner 
Signed-off-by: Greg Kroah-Hartman

ARM: OMAP2+: DRA7: clockdomain: change l4per2_7xx_clkdm to SW_WKUP

2015-09-21T17:10:58+00:00

commit b9e23f321940d2db2c9def8ff723b8464fb86343 upstream.

Legacy IPs like PWMSS, present under l4per2_7xx_clkdm, cannot support
smart-idle when its clock domain is in HW_AUTO on DRA7 SoCs. Hence,
program clock domain to SW_WKUP.

Signed-off-by: Vignesh R 
Acked-by: Tero Kristo 
Reviewed-by: Paul Walmsley 
Signed-off-by: Paul Walmsley 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: fix clock-frequency of display timing0 for exynos3250-rinato

2015-09-21T17:10:58+00:00

commit 65e3293381e1cf1abcfe1aa22b914650a40e3af4 upstream.

After the commit abc0b1447d49 ("drm: Perform basic sanity checks on
probed modes"), proper clock-frequency becomes mandatory for
validating the mode of panel.  The display does not work if there is
no mode validated. Also, this clock-frequency must be set
appropriately for getting required frame rate.

Fixes: abc0b1447d49 ("drm: Perform basic sanity checks on probed modes")
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Krzysztof Kozlowski 
Sigend-off-by: Kukjin Kim 
Signed-off-by: Greg Kroah-Hartman

ARM: orion5x: fix legacy orion5x IRQ numbers

2015-09-21T17:10:58+00:00

commit 5be9fc23cdb42e1d383ecc8eae8a8ff70a752708 upstream.

Since v3.18, attempts to deliver IRQ0 are rejected, breaking orion5x.
Fix this by increasing all interrupts by one, as did 5d6bed2a9c8b for
dove. Also, force MULTI_IRQ_HANDLER for all orion platforms (including
dove) as the specific handler is needed to shift back IRQ numbers by
one.

[gregory.clement@free-electrons.com]: moved the select
MULTI_IRQ_HANDLER from PLAT_ORION_LEGACY to ARCH_ORION5X as it broke
the build for dove.

Fixes: a71b092a9c68 ("ARM: Convert handle_IRQ to use __handle_domain_irq")
Signed-off-by: Benjamin Cama 
Signed-off-by: Gregory CLEMENT 
Tested-by: Detlef Vollmann 
Signed-off-by: Greg Kroah-Hartman

ARM: BCM63xx: fix parameter to of_get_cpu_node in bcm63138_smp_boot_secondary

2015-09-21T17:10:58+00:00

commit a6b4b25bd15c0a490769422a7eee355e9e91a57b upstream.

of_get_cpu_node provides the device node associated with the given
logical CPU and cpu_logical_map contains the physical id for each CPU
in the logical ordering. Passing cpu_logical_map(cpu) to of_get_cpu_node
is incorrect.

This patch fixes the issue by passing the logical CPU number to
of_get_cpu_node

Fixes: ed5cd8163da8 ("ARM: BCM63xx: Add SMP support for BCM63138")
Cc: Florian Fainelli 
Cc: bcm-kernel-feedback-list@broadcom.com
Signed-off-by: Sudeep Holla 
Signed-off-by: Florian Fainelli 
Signed-off-by: Greg Kroah-Hartman

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

2015-08-22T22:48:04+00:00

Pull ARM fixes from Russell King:
 "Another couple of small ARM fixes.

  A patch from Masahiro Yamada who noticed that "make -jN all zImage"
  would end up generating bad images where N > 1, and a patch from
  Nicolas to fix the Marvell CPU user access optimisation code when page
  faults are disabled"

* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  ARM: 8418/1: add boot image dependencies to not generate invalid images
  ARM: 8414/1: __copy_to_user_memcpy: fix mmap semaphore usage