linux-stable.git/arch, branch v3.19.3

ARM: dts: am43xx-clocks: Fix ehrpwm tbclk data on am43xx

2015-03-26T12:59:50+00:00

commit 7d53d25578486d65bd7cd242bc7816b40e55e62b upstream.

ehrpwm tbclk is wrongly modelled as deriving from dpll_per_m2_ck.
The TRM says tbclk is derived from SYSCLKOUT. SYSCLKOUT nothing but the
functional clock of pwmss (l4ls_gclk).
Fix this by changing source of ehrpwmx_tbclk to l4ls_gclk.

Fixes: 4da1c67719f61 ("add tbclk data for ehrpwm")
Signed-off-by: Vignesh R 
Acked-by: Tero Kristo 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: am33xx-clocks: Fix ehrpwm tbclk data on am33xx

2015-03-26T12:59:50+00:00

commit 6e22616eba7e25fac5aa6cb6563471afa1815ec2 upstream.

ehrpwm tbclk is wrongly modelled as deriving from dpll_per_m2_ck.
The TRM says tbclk is derived from SYSCLKOUT. SYSCLKOUT nothing but the
functional clock of pwmss (l4ls_gclk).
Fix this by changing source of ehrpwmx_tbclk to l4ls_gclk.

Fixes: 9e100ebafb91: ("Fix ehrpwm tbclk data")
Signed-off-by: Vignesh R 
Acked-by: Tero Kristo 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: DRA7x: Fix the bypass clock source for dpll_iva and others

2015-03-26T12:59:50+00:00

commit d2192ea09858a8535b056fcede1a41d824e0b3d8 upstream.

Fixes: ee6c750761 (ARM: dts: dra7 clock data)

On DRA7x, For DPLL_IVA, the ref clock(CLKINP) is connected to sys_clk1 and
the bypass input(CLKINPULOW) is connected to iva_dpll_hs_clk_div clock.
But the bypass input is not directly routed to bypass clkout instead
both CLKINP and CLKINPULOW are connected to bypass clkout via a mux.

This mux is controlled by the bit - CM_CLKSEL_DPLL_IVA[23]:DPLL_BYP_CLKSEL
and it's POR value is zero which selects the CLKINP as bypass clkout.
which means iva_dpll_hs_clk_div is not the bypass clock for dpll_iva_ck

Fix this by adding another mux clock as parent in bypass mode.

This design is common to most of the PLLs and the rest have only one bypass
clock. Below is a list of the DPLLs that need this fix:

DPLL_IVA, DPLL_DDR,
DPLL_DSP, DPLL_EVE,
DPLL_GMAC, DPLL_PER,
DPLL_USB and DPLL_CORE

Signed-off-by: Ravikumar Kattekola 
Acked-by: Tero Kristo 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: at91: pm: fix at91rm9200 standby

2015-03-26T12:59:50+00:00

commit 84e871660bebfddb9a62ebd6f19d02536e782f0a upstream.

at91rm9200 standby and suspend to ram has been broken since
00482a4078f4. It is wrongly using AT91_BASE_SYS which is a physical address
and actually doesn't correspond to any register on at91rm9200.

Use the correct at91_ramc_base[0] instead.

Fixes: 00482a4078f4 (ARM: at91: implement the standby function for pm/cpuidle)

Signed-off-by: Alexandre Belloni 
Signed-off-by: Nicolas Ferre 
Signed-off-by: Greg Kroah-Hartman

ARM: imx6qdl-sabresd: set swbst_reg as vbus's parent reg

2015-03-26T12:59:50+00:00

commit 40f737791d4dab26bf23a6331609c604142228bd upstream.

USB vbus 5V is from PMIC SWBST, so set swbst_reg as vbus's
parent reg, it fixed a bug that the voltage of vbus is incorrect
due to swbst_reg is disabled after boots up.

Signed-off-by: Peter Chen 
Signed-off-by: Shawn Guo 
Signed-off-by: Greg Kroah-Hartman

ARM: EXYNOS: Don't use LDREX and STREX after disabling cache coherency

2015-03-26T12:59:50+00:00

commit ca489c58ef0b81cc9c9252fd92e6c9bb38d3c408 upstream.

During CPU shutdown the exynos_cpu_power_down() is called after
disabling cache coherency and it uses LDREX and STREX instructions (by
calling of_machine_is_compatible() -> kobject_get() -> kref_get()).

The LDREX and STREX should not be used after disabling the cache
coherency so just use soc_is_exynos().

Fixes: adc548d77c22 ("ARM: EXYNOS: Use MCPM call-backs to support S2R
on exynos5420")

Reported-by: Stephen Boyd 
Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Stephen Boyd 
Signed-off-by: Kukjin Kim 
Signed-off-by: Greg Kroah-Hartman

ARM: imx6sl-evk: set swbst_reg as vbus's parent reg

2015-03-26T12:59:49+00:00

commit 2de9dd0391a74e80922c1bc95a78cedf85bcdc9e upstream.

USB vbus 5V is from PMIC SWBST, so set swbst_reg as vbus's
parent reg, it fixed a bug that the voltage of vbus is incorrect
due to swbst_reg is disabled after boots up.

Signed-off-by: Peter Chen 
Signed-off-by: Shawn Guo 
Signed-off-by: Greg Kroah-Hartman

powerpc/iommu: Remove IOMMU device references via bus notifier

2015-03-26T12:59:48+00:00

commit 4ad04e5987115ece5fa8a0cf1dc72fcd4707e33e upstream.

After d905c5df9aef ("PPC: POWERNV: move iommu_add_device earlier"), the
refcnt on the kobject backing the IOMMU group for a PCI device is
elevated by each call to pci_dma_dev_setup_pSeriesLP() (via
set_iommu_table_base_and_group). When we go to dlpar a multi-function
PCI device out:

        iommu_reconfig_notifier ->
                iommu_free_table ->
                        iommu_group_put
                        BUG_ON(tbl->it_group)

We trip this BUG_ON, because there are still references on the table, so
it is not freed. Fix this by moving the powernv bus notifier to common
code and calling it for both powernv and pseries.

Fixes: d905c5df9aef ("PPC: POWERNV: move iommu_add_device earlier")
Signed-off-by: Nishanth Aravamudan 
Tested-by: Nishanth Aravamudan 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

powerpc/smp: Wait until secondaries are active & online

2015-03-26T12:59:48+00:00

commit 875ebe940d77a41682c367ad799b4f39f128d3fa upstream.

Anton has a busy ppc64le KVM box where guests sometimes hit the infamous
"kernel BUG at kernel/smpboot.c:134!" issue during boot:

  BUG_ON(td->cpu != smp_processor_id());

Basically a per CPU hotplug thread scheduled on the wrong CPU. The oops
output confirms it:

  CPU: 0
  Comm: watchdog/130

The problem is that we aren't ensuring the CPU active bit is set for the
secondary before allowing the master to continue on. The master unparks
the secondary CPU's kthreads and the scheduler looks for a CPU to run
on. It calls select_task_rq() and realises the suggested CPU is not in
the cpus_allowed mask. It then ends up in select_fallback_rq(), and
since the active bit isnt't set we choose some other CPU to run on.

This seems to have been introduced by 6acbfb96976f "sched: Fix hotplug
vs. set_cpus_allowed_ptr()", which changed from setting active before
online to setting active after online. However that was in turn fixing a
bug where other code assumed an active CPU was also online, so we can't
just revert that fix.

The simplest fix is just to spin waiting for both active & online to be
set. We already have a barrier prior to set_cpu_online() (which also
sets active), to ensure all other setup is completed before online &
active are set.

Fixes: 6acbfb96976f ("sched: Fix hotplug vs. set_cpus_allowed_ptr()")
Signed-off-by: Michael Ellerman 
Signed-off-by: Anton Blanchard 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

x86/apic/numachip: Fix sibling map with NumaChip

2015-03-26T12:59:48+00:00

commit c8a470cab030bae8f9e6e5cfff72b047b7c627a7 upstream.

On NumaChip systems, the physical processor ID assignment wasn't
accounting for the number of nodes in AMD multi-module
processors, giving an incorrect sibling map:

  $ cd /sys/devices/system/cpu/cpu29/topology
  $ grep . *
  core_id:5
  core_siblings:00000000,ff000000
  core_siblings_list:24-31
  physical_package_id:3
  thread_siblings:00000000,30000000
  thread_siblings_list:28-29

This fixes it:

  $ cd /sys/devices/system/cpu/cpu29/topology
  $ grep . *
  core_id:5
  core_siblings:00000000,ffff0000
  core_siblings_list:16-31
  physical_package_id:1
  thread_siblings:00000000,30000000
  thread_siblings_list:28-29

Signed-off-by: Daniel J Blueman 
Signed-off-by: Borislav Petkov 
Cc: H. Peter Anvin 
Cc: Steffen Persvold 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1426135950-10110-1-git-send-email-daniel@numascale.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman