This is a cleanup patch; doesn't change any functionality. Moves
all cpuidle related code from setup.c to a new file.
Signed-off-by: NShreyas B. Prabhu <shreyas@linux.vnet.ibm.com>
Reviewed-by: NPreeti U Murthy <preeti@linux.vnet.ibm.com>
[mpe: Fix the SMP=n build by including asm/smp.h in idle.c]
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

Currently, cpu_online_cores_map returns a mask, which for every core with
at least one online thread, has the bit for thread 0 of the core set to 1,
and the bits for all other threads of the core set to 0. But thread 0 of
the core itself may not be online always. In such cases, if the returned
mask is used for IPI, then it'll cause IPIs to be skipped on cores where
the first thread is offline, because the IPI code refuses to send IPIs to
offline threads.

Fix this by setting the bit of the first online thread in the core.
This is done by fixing this in the underlying function
cpu_thread_mask_to_cores.

The result has the property that for all cores with online threads, there
is one bit set in the returned map. And further, all bits that are set in
the returned map correspond to online threads.
Signed-off-by: NShreyas B. Prabhu <shreyas@linux.vnet.ibm.com>
Reviewed-by: NPreeti U Murthy <preeti@linux.vnet.ibm.com>
[ Changelog from Michael Ellerman <mpe@ellerman.id.au> ]
Reviewed-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

The commit 8170a83f ("powerpc: Wireup the kcmp syscall to sys_ni") has
disabled the kcmp syscall for powerpc.  This has been done due to the use
of unsigned long parameters which may require a dedicated wrapper to handle
32bit process on top of 64bit kernel.  However in the kcmp() case, the 2
unsigned long parameters are currently only used to carry file descriptors
from user space to the kernel.  Since such a parameter is passed through
register, and file descriptor doesn't need to get extended, there is,
today, no need for a wrapper.

In the case there will be a need to pass address in or out of this system
call, then a wrapper could be required, it will then be to care of it.

As today this is not the case, it is safe to enable kcmp() on powerpc.

Tested (by Laurent) on 64-bit, 32-bit, and 32-bit userspace on 64-bit
kernel using tools/testing/selftests/kcmp [mpe].
Signed-off-by: NLaurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

The only little endian configuration we support is ppc64le, all other
configurations are big endian.

So we should only offer a choice of endian if we're building for 64-bit
Book3S, ie. PPC_BOOK3S_64.
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

Currently, the macro IS_BRIDGE is not used any where.
This patch just removes it.
Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
Acked-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

As the comment indicates, powernv_eeh_get_state() will inform EEH core to
delay 1 second. This means the delay doesn't happen when
powernv_eeh_get_state() returns.

This patch moves the delay subtraction just before msleep(), which is the
same logic in pseries_eeh_wait_state().
Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
Acked-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

To retrieve the PCI slot state, EEH driver would set a timeout for that.
While current comment is not aligned to what the code does.

This patch fixes those comments according to the code.
Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
Acked-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

struct pci_io_addr_range{} stores the information of pci resources. It
would be better to keep these related fields have the same type as in
struct resource{}.

This patch fixes the start/end/flags type in struct pci_io_addr_range{} to
have the same type as in struct resource{}.
Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
Acked-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

The patch defines PCI error types and functions in uapi/asm/eeh.h
and exports function eeh_pe_inject_err(), which will be called by
VFIO driver to inject the specified PCI error to the indicated
PE for testing purpose.
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

There are two equivalent sets of PE state constants, defined in
arch/powerpc/include/asm/eeh.h and include/uapi/linux/vfio.h.
Though the names are different, their corresponding values are
exactly same. The former is used by EEH core and the latter is
used by userspace.

The patch moves those constants from arch/powerpc/include/asm/eeh.h
to arch/powerpc/include/uapi/asm/eeh.h, which are expected to be
used by userspace from now on. We can't delete those constants in
vfio.h as it's uncertain that those constants have been or will be
used by userspace.
Suggested-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

OpenPower BMC machines do not place any sysparams in the device tree, so
at every boot we get a warning:

 [    0.437176] SYSPARAM: Opal sysparam node not found

Remove the warning, and reorder the init so we don't peform allocations
when there is no sysparam node in the device tree.
Signed-off-by: NJoel Stanley <joel@jms.id.au>
Acked-by: NNeelesh Gupta <neelegup@linux.vnet.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

The only little endian configuration we support is ppc64le. As such if
we're building little endian we don't need a 32-bit VDSO, because there
is no 32-bit userspace.

This patch is a fairly ugly mess of #ifdefs, but is the minimal logic
required to disable the 32-bit VDSO. We can hopefully clean up the
result in future with some further refactoring.
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

In vdso_fixup_features() we have start64/start32 and size64/size32, but
they have the same types, ie. void * and unsigned long.

They're only used to save the return value from find_sectionXX() for the
subsequent call to do_feature_fixups(), so there's no overlap in their
usage either.

So we can just consolidate them into start/size and avoid the
duplication.
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

It's in the git history if we ever need it back.
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

There is a bug in binutils 2.24 which causes miscompilation if we're
building little endian and using weak symbols (which the kernel does).

It is fixed in binutils commit 57fa7b8c7e59 "Correct elf_merge_st_other
arguments for weak symbols", which is in binutils 2.25 and has been
backported to the binutils 2.24 branch and has been picked up by most
distros it seems.

However if we're running stock 2.24 (no extra version) then the bug is
present, so check for that and bail.
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

We have several checks for bad gcc versions in our Makefile. These don't
apply if we're building with clang, so skip them in that case.

The obvious check would be for ${COMPILER} = "gcc", but because of the
way the logic in the top level Makefile conditionally sets COMPILER,
it's possible that we're building with gcc but COMPILER was not set.

So instead check for ${COMPILER} != "clang", which we know is currently
the only other possibility.
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

Currently we print "Starting Linux PPC64" at boot. But we don't mention
anywhere whether the kernel is big or little endian.

If we print the utsname->machine value instead we get either "ppc64" or
"ppc64le" which is much more informative, eg:

  Starting Linux ppc64le #1 SMP Wed Apr 15 12:12:20 AEST 2015
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

The pasemi MSI code is currently always built when MPIC=y && PCI_MSI=y.
It should not have any effect on other platforms, because it immediately
checks the MPIC's compatible property for "pasemi,pwrficient-openpic".

However it's odd that it's still built even when PASEMI=n. It also
needn't be in sysdev, as it's only used by pasemi. So move it into
platforms/pasemi, whereby it will only be built for PASEMI=y.
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

The STRICT_MM_TYPECHECKS code has bit-rotted over the years. To make it
possible to easily build test it, make it a CONFIG option.
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

Failure return from dlpar_configure_connector when dlpar adding cpus
results in leaking references to the cpus parent device node. Move the
call to of_node_put() prior to checking the result of
dlpar_configure_connector.

Fixes: 8d5ff320 ("powerpc/pseries: Make dlpar_configure_connector parent node aware")
Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

The irq_domain_ops are not modified by the driver and the irqdomain core
code accepts pointer to a const data.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

We cast away the volatile, but really, why make it volatile at all?
We already do a mb() inside the cpumask_empty() loop.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The Marvell mwifiex driver prevents the system to enter into a suspend
state if the card power is not preserved during a suspend/resume cycle.

So Suspend-to-RAM and Suspend-to-idle are failing on Exynos5250 Snow.

Add the keep-power-in-suspend Power Management property to the SDIO/MMC
node so the mwifiex suspend handler doesn't fail and the system is able
to enter into a suspend state.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NKukjin Kim <kgene@kernel.org>

Remove the extra zero in the "cpu-crit-0" trip point for exynos5420
and exynos5440.
Signed-off-by: NAbhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: NKukjin Kim <kgene@kernel.org>

The Exynos4412 SoC has a s3c6410 RTC where the source clock
is now a mandatory property.
This patch fixes probe failure of s3c-rtc on Odroid-X2/U2/U3 boards.
Signed-off-by: NMarkus Reichl <m.reichl@fivetechno.de>
Tested-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Reviewed-by: NChanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NKukjin Kim <kgene@kernel.org>

Commit ea08de16 ("ARM: dts: Add DISP1 power domain for exynos5420")
added a device node for the Exynos5420 DISP1 power domain but dit not
make the DP controller a consumer of that power domain.

This causes an "Unhandled fault: imprecise external abort" error if the
exynos-dp driver tries to access the DP controller registers and the PD
was turned off. This lead to a kernel panic and a complete system hang.

Make the DP controller device node a consumer of the DISP1 power domain
to ensure that the PD is turned on when the exynos-dp driver is probed.

Fixes: ea08de16 ("ARM: dts: Add DISP1 power domain for exynos5420")
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NKukjin Kim <kgene@kernel.org>

Select IMX50, IMX6SX and LS1021A SoC support.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Make sure that xen_swiotlb_init allocates buffers that are DMA capable
when at least one memblock is available below 4G. Otherwise we assume
that all devices on the SoC can cope with >4G addresses. We do this on
ARM and ARM64, where dom0 is mapped 1:1, so pfn == mfn in this case.

No functional changes on x86.

From: Chen Baozi <baozich@gmail.com>
Signed-off-by: NChen Baozi <baozich@gmail.com>
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: NChen Baozi <baozich@gmail.com>
Acked-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>

The following commit:

  f893959b ("x86/fpu: Don't abuse drop_init_fpu() in flush_thread()")

removed drop_init_fpu() usage from flush_thread(). This seems to break
things for me - the Go 1.4 test suite fails all over the place with
floating point comparision errors (offending commit found through
bisection).

The functional change was that flush_thread() after this commit
only calls restore_init_xstate() when both use_eager_fpu() and
!used_math() are true. drop_init_fpu() (now fpu_reset_state()) calls
restore_init_xstate() regardless of whether current used_math() - apply
the same logic here.

Switch used_math() -> tsk_used_math(tsk) to consistently use the grabbed
tsk instead of current, like in the rest of flush_thread().
Tested-by: NDave Hansen <dave.hansen@intel.com>
Signed-off-by: NBobby Powers <bobbypowers@gmail.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Acked-by: NOleg Nesterov <oleg@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pekka Riikonen <priikone@iki.fi>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: f893959b ("x86/fpu: Don't abuse drop_init_fpu() in flush_thread()")
Link: http://lkml.kernel.org/r/1430147441-9820-1-git-send-email-bobbypowers@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

Commit 75182b16 ("x86/asm/entry: Switch all C consumers of
kernel_stack to this_cpu_sp0()") changed current_thread_info
to use this_cpu_sp0, and indirectly made it rely on init_tss
which was exported with EXPORT_PER_CPU_SYMBOL_GPL.
As a result some macros and inline functions such as set/get_fs,
test_thread_flag and variants have been made unusable for
external modules.

Make cpu_tss exported with EXPORT_PER_CPU_SYMBOL so that these
functions are accessible again, as they were previously.
Signed-off-by: NMarc Dionne <marc.dionne@your-file-system.com>
Acked-by: NAndy Lutomirski <luto@amacapital.net>
Link: http://lkml.kernel.org/r/1430763404-21221-1-git-send-email-marc.dionne@your-file-system.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Commit 61f01dd9 ("x86_64, asm: Work around AMD SYSRET SS descriptor
attribute issue") makes AMD processors set SS to __KERNEL_DS in
__switch_to() to deal with cases when SS is NULL.

This breaks Xen PV guests who do not want to load SS with__KERNEL_DS.

Since the problem that the commit is trying to address would have to be
fixed in the hypervisor (if it in fact exists under Xen) there is no
reason to set X86_BUG_SYSRET_SS_ATTRS flag for PV VPCUs here.

This can be easily achieved by adding x86_hyper_xen_hvm.set_cpu_features
op which will clear this flag. (And since this structure is no longer
HVM-specific we should do some renaming).
Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
Reported-by: NSander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>

A spinlock is regarded as contended when there is at least one waiter.
Currently, the code that checks whether there are any waiters rely on
tail value being greater than head. However, this is not true if tail
reaches the max value and wraps back to zero, so arch_spin_is_contended()
incorrectly returns 0 (not contended) when tail is smaller than head.

The original code (before regression) handled this case by casting the
(tail - head) to an unsigned value. This change simply restores that
behavior.

Fixes: d6abfdb2 ("x86/spinlocks/paravirt: Fix memory corruption on unlock")
Signed-off-by: NTahsin Erdogan <tahsin@google.com>
Cc: peterz@infradead.org
Cc: Waiman.Long@hp.com
Cc: borntraeger@de.ibm.com
Cc: oleg@redhat.com
Cc: raghavendra.kt@linux.vnet.ibm.com
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1430799331-20445-1-git-send-email-tahsin@google.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

The L3 Error handling on OMAP5 for the most part is very similar
to that of OMAP4, and had leveraged common data structures and
register layout definitions so far. Upon closer inspection, there
are a few minor differences causing an incorrect decoding and
reporting of the master NIU upon an error:

  1. The L3_TARG_STDERRLOG_MSTADDR.STDERRLOG_MSTADDR occupies
     11 bits on OMAP5 as against 8 bits on OMAP4, with the master
     NIU connID encoded in the 6 MSBs of the STDERRLOG_MSTADDR
     field.
  2. The CLK3 FlagMux component has 1 input source on OMAP4 and 3
     input sources on OMAP5. The common DEBUGSS source is at a
     different input on each SoC.

Fix the above issues by using a OMAP5-specific compatible property
and using SoC-specific data where there are differences.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Acked-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Fix a typo in DRA7 dtsi where 12 bytes are needed for register
description of ABB efuse registers, however only 8 bytes are provided
to map. For some weird reason, this does not generate abort at offset
0x8, probably due to default maps already provided in io.c for the bus
register ranges.
Reported-by: NMatt Gessner <Matt.Gessner@windriver.com>
Reported-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

BeagleBoard-X15 pre-production change includes switching the GPIO fan
gpio over from 1 to 2 to allow for a potential fix at a later point in
time for USB client VBUS detection using PMIC VBUS detect capability.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

BeagleBoard-X15 pre-production change includes switching over to UART
pins that now allow for UART download capability. All original boards
should either have been returned for modifications or already modified
for the required change and maintaining compatibility for older boards
are no longer needed.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The new AM437x SK Beta boards have removed the
large capacitors on the gpio-matrix column lines
which means we can reduce col-scan-delay-us to 5us
without loosing functionality.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

AM437x Starter Kit uses a NewHaven Display module with
a 4.3" display and EDT FT5306 touchscreen

On that module's new revision, NewHave decided to change
the pinout on the 6 pin flat-pcb touchscreen connector so
that instead of having WAKE pin, we now have RESETn.

The new display module is available on AM437x SK Beta and
all new revisions while the older revision is only available
on AM437x SK Alpha which, unfortunately, can't be supported
anymore in mainline without a revert of this patch.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

With commit bc078316 ("ARM: dts: DRA7: Add node for RTC"), we now
have AM57xx RTC register itself as alias 0 even before DS1307 or TPS
rtc drivers are loaded up. However, since neither TPS, nor AM57xx RTC
are capable of being backedup by battery, we would like to maintain
the "primary" rtc as mcp79410 rtc device.

This also generates the following warnings in the bootlog highlighting
the issue:
[    5.895445] rtc-ds1307 2-006f: /aliases ID 0 not available
...
[    6.476285] palmas-rtc 48070000.i2c:tps659038@58:tps659038_rtc: /aliases ID 1 not available

So, add proper aliases to ensure that RTC order is always consistent
to userspace immaterial of probe order.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The interrupt polarity provided in devicetree is used to configure
the interrupt controller(ARM GIC), however, it seems that we have an
inverter at the GIC boundary inside AM57xx which inverts the signal
input from sys_irq external interrupt source.

Further, as per GIC distributor TRM,
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438d/BGBHIACJ.html#BABJFCFB
ARM GIC distributor does not support IRQ trigger type
IRQ_TYPE_LEVEL_LOW, and only rising or level high signals.

However, for some reason, the current configuration(which gets ignored
by GIC driver) functions on some platforms, however, on few platforms
results in infinite interrupts hogging the system down.

Switch over to rising edge for GIC configuration which is also aligned
with trigger point from the RTC chip and the internal inversion.

Fixes: 5a0f93c6 ("ARM: dts: Add am57xx-beagle-x15")
Signed-off-by: NGrygorii Strashko <Grygorii.Strashko@linaro.org>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>