linux.git/arch, branch v4.1.8

ARM: rockchip: fix broken build

2015-09-21T17:05:45+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

ACPI, PCI: Penalize legacy IRQ used by ACPI SCI

2015-09-21T17:05:44+00:00

commit 5d0ddfebb93069061880fc57ee4ba7246bd1e1ee upstream.

Nick Meier reported a regression with HyperV that "
  After rebooting the VM, the following messages are logged in syslog
  when trying to load the tulip driver:
    tulip: Linux Tulip drivers version 1.1.15 (Feb 27, 2007)
    tulip: 0000:00:0a.0: PCI INT A: failed to register GSI
    tulip: Cannot enable tulip board #0, aborting
    tulip: probe of 0000:00:0a.0 failed with error -16
  Errors occur in 3.19.0 kernel
  Works in 3.17 kernel.
"

According to the ACPI dump file posted by Nick at
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1440072

The ACPI MADT table includes an interrupt source overridden entry for
ACPI SCI:
[236h 0566  1]                Subtable Type : 02 
[237h 0567  1]                       Length : 0A
[238h 0568  1]                          Bus : 00
[239h 0569  1]                       Source : 09
[23Ah 0570  4]                    Interrupt : 00000009
[23Eh 0574  2]        Flags (decoded below) : 000D
                                   Polarity : 1
                               Trigger Mode : 3

And in DSDT table, we have _PRT method to define PCI interrupts, which
eventually goes to:
        Name (PRSA, ResourceTemplate ()
        {
            IRQ (Level, ActiveLow, Shared, )
                {3,4,5,7,9,10,11,12,14,15}
        })
        Name (PRSB, ResourceTemplate ()
        {
            IRQ (Level, ActiveLow, Shared, )
                {3,4,5,7,9,10,11,12,14,15}
        })
        Name (PRSC, ResourceTemplate ()
        {
            IRQ (Level, ActiveLow, Shared, )
                {3,4,5,7,9,10,11,12,14,15}
        })
        Name (PRSD, ResourceTemplate ()
        {
            IRQ (Level, ActiveLow, Shared, )
                {3,4,5,7,9,10,11,12,14,15}
        })

According to the MADT and DSDT tables, IRQ 9 may be used for:
 1) ACPI SCI in level, high mode
 2) PCI legacy IRQ in level, low mode
So there's a conflict in polarity setting for IRQ 9.

Prior to commit cd68f6bd53cf ("x86, irq, acpi: Get rid of special
handling of GSI for ACPI SCI"), ACPI SCI is handled specially and
there's no check for conflicts between ACPI SCI and PCI legagy IRQ.
And it seems that the HyperV hypervisor doesn't make use of the
polarity configuration in IOAPIC entry, so it just works.

Commit cd68f6bd53cf gets rid of the specially handling of ACPI SCI,
and then the pin attribute checking code discloses the conflicts
between ACPI SCI and PCI legacy IRQ on HyperV virtual machine,
and rejects the request to assign IRQ9 to PCI devices.

So penalize legacy IRQ used by ACPI SCI and mark it unusable if ACPI
SCI attributes conflict with PCI IRQ attributes.

Please refer to following links for more information:
https://bugzilla.kernel.org/show_bug.cgi?id=101301
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1440072

Fixes: cd68f6bd53cf ("x86, irq, acpi: Get rid of special handling of GSI for ACPI SCI")
Reported-and-tested-by: Nick Meier 
Acked-by: Thomas Gleixner 
Signed-off-by: Jiang Liu 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: rockchip: fix rk3288 watchdog irq

2015-09-21T17:05:44+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:05:43+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:05:43+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:05:43+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:05:43+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

x86/mce: Reenable CMCI banks when swiching back to interrupt mode

2015-09-21T17:05:43+00:00

commit 1b48465500611a2dc5e75800c61ac352e22d41c3 upstream.

Zhang Liguang reported the following issue:

1) System detects a CMCI storm on the current CPU.

2) Kernel disables the CMCI interrupt on banks owned by the
   current CPU and switches to poll mode

3) After the CMCI storm subsides, kernel switches back to
   interrupt mode

4) We expect the system to reenable the CMCI interrupt on banks
   owned by the current CPU

   mce_intel_adjust_timer
   |-> cmci_reenable
       |-> cmci_discover     # owned banks are ignored here

  static void cmci_discover(int banks)
	...
	for (i = 0; i < banks; i++) {
		...
		if (test_bit(i, owned))	# ownd banks is ignore here
			continue;

So convert cmci_storm_disable_banks() to
cmci_toggle_interrupt_mode() which controls whether to enable or
disable CMCI interrupts with its argument.

NB: We cannot clear the owned bit because the banks won't be
polled, otherwise. See:

  27f6c573e0f7 ("x86, CMCI: Add proper detection of end of CMCI storms")

for more info.

Reported-by: Zhang Liguang 
Signed-off-by: Xie XiuQi 
Signed-off-by: Borislav Petkov 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: huawei.libin@huawei.com
Cc: linux-edac 
Cc: rui.xiang@huawei.com
Link: http://lkml.kernel.org/r/1439396985-12812-10-git-send-email-bp@alien8.de
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

xtensa: fix kernel register spilling

2015-09-21T17:05:42+00:00

commit 77d6273e79e3a86552fcf10cdd31a69b46ed2ce6 upstream.

call12 can't be safely used as the first call in the inline function,
because the compiler does not extend the stack frame of the bounding
function accordingly, which may result in corruption of local variables.

If a call needs to be done, do call8 first followed by call12.

For pure assembly code in _switch_to increase stack frame size of the
bounding function.

Signed-off-by: Max Filippov 
Signed-off-by: Greg Kroah-Hartman

xtensa: fix threadptr reload on return to userspace

2015-09-21T17:05:41+00:00

commit 4229fb12a03e5da5882b420b0aa4a02e77447b86 upstream.

Userspace return code may skip restoring THREADPTR register if there are
no registers that need to be zeroed. This leads to spurious failures in
libc NPTL tests.

Always restore THREADPTR on return to userspace.

Signed-off-by: Max Filippov 
Signed-off-by: Greg Kroah-Hartman