Commit Graph

136700 Commits

Author SHA1 Message Date
74ad3d28af parisc: Define CONFIG_CPU_BIG_ENDIAN
While working on enabling queued rwlock on SPARC, found this following
code in include/asm-generic/qrwlock.h which uses CONFIG_CPU_BIG_ENDIAN
to clear a byte.

static inline u8 *__qrwlock_write_byte(struct qrwlock *lock)
 {
	return (u8 *)lock + 3 * IS_BUILTIN(CONFIG_CPU_BIG_ENDIAN);
 }

Problem is many of the fixed big endian architectures don't define
CPU_BIG_ENDIAN and clears the wrong byte.

Define CPU_BIG_ENDIAN for parisc architecture to fix it.

Signed-off-by: Babu Moger <babu.moger@oracle.com>
Signed-off-by: Helge Deller <deller@gmx.de>
2017-07-31 17:51:27 +02:00
cc491f1d35 powerpc/64s: Fix stack setup in watchdog soft_nmi_common()
The watchdog soft-NMI exception stack setup loads a stack pointer
twice, which is an obvious error. It ends up using the system reset
interrupt (true-NMI) stack, which is also a bug because the watchdog
could be preempted by a system reset interrupt that overwrites the
NMI stack.

Change the soft-NMI to use the "emergency stack". The current kernel
stack is not used, because of the longer-term goal to prevent
asynchronous stack access using soft-disable.

Fixes: 2104180a53 ("powerpc/64s: implement arch-specific hardlockup watchdog")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-07-31 20:22:37 +10:00
bb272221e9 Merge tag 'v4.13-rc1' into fixes
The fixes branch is based off a random pre-rc1 commit, because we had
some fixes that needed to go in before rc1 was released.

However we now need to fix some code that went in after that point, but
before rc1, so merge rc1 to get that code into fixes so we can fix it!
2017-07-31 20:20:29 +10:00
8f8201dfed parisc: Increase thread and stack size to 32kb
Since kernel 4.11 the thread and irq stacks on parisc randomly overflow
the default size of 16k. The reason why stack usage suddenly grew is yet
unknown.

Signed-off-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org # 4.11+
Signed-off-by: Helge Deller <deller@gmx.de>
2017-07-31 08:41:26 +02:00
13d57093c1 parisc: Handle vma's whose context is not current in flush_cache_range
In testing James' patch to drivers/parisc/pdc_stable.c, I hit the BUG
statement in flush_cache_range() during a system shutdown:

kernel BUG at arch/parisc/kernel/cache.c:595!
CPU: 2 PID: 6532 Comm: kworker/2:0 Not tainted 4.13.0-rc2+ #1
Workqueue: events free_ioctx

 IAOQ[0]: flush_cache_range+0x144/0x148
 IAOQ[1]: flush_cache_page+0x0/0x1a8
 RP(r2): flush_cache_range+0xec/0x148
Backtrace:
 [<00000000402910ac>] unmap_page_range+0x84/0x880
 [<00000000402918f4>] unmap_single_vma+0x4c/0x60
 [<0000000040291a18>] zap_page_range_single+0x110/0x160
 [<0000000040291c34>] unmap_mapping_range+0x174/0x1a8
 [<000000004026ccd8>] truncate_pagecache+0x50/0xa8
 [<000000004026cd84>] truncate_setsize+0x54/0x70
 [<000000004033d534>] put_aio_ring_file+0x44/0xb0
 [<000000004033d5d8>] aio_free_ring+0x38/0x140
 [<000000004033d714>] free_ioctx+0x34/0xa8
 [<00000000401b0028>] process_one_work+0x1b8/0x4d0
 [<00000000401b04f4>] worker_thread+0x1b4/0x648
 [<00000000401b9128>] kthread+0x1b0/0x208
 [<0000000040150020>] end_fault_vector+0x20/0x28
 [<0000000040639518>] nf_ip_reroute+0x50/0xa8
 [<0000000040638ed0>] nf_ip_route+0x10/0x78
 [<0000000040638c90>] xfrm4_mode_tunnel_input+0x180/0x1f8

CPU: 2 PID: 6532 Comm: kworker/2:0 Not tainted 4.13.0-rc2+ #1
Workqueue: events free_ioctx
Backtrace:
 [<0000000040163bf0>] show_stack+0x20/0x38
 [<0000000040688480>] dump_stack+0xa8/0x120
 [<0000000040163dc4>] die_if_kernel+0x19c/0x2b0
 [<0000000040164d0c>] handle_interruption+0xa24/0xa48

This patch modifies flush_cache_range() to handle non current contexts.
In as much as this occurs infrequently, the simplest approach is to
flush the entire cache when this happens.

Signed-off-by: John David Anglin <dave.anglin@bell.net>
Cc: stable@vger.kernel.org # 4.9+
Signed-off-by: Helge Deller <deller@gmx.de>
2017-07-31 08:22:33 +02:00
f137e0b0c5 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Thomas Gleixner:
 "A small set of x86 fixes:

   - prevent the kernel from using the EFI reboot method when EFI is
     disabled.

   - two patches addressing clang issues"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/boot: Disable the address-of-packed-member compiler warning
  x86/efi: Fix reboot_mode when EFI runtime services are disabled
  x86/boot: #undef memcpy() et al in string.c
2017-07-30 12:19:35 -07:00
dbc52a8030 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf fixes from Thomas Gleixner:
 "A couple of fixes for performance counters and kprobes:

   - a series of small patches which make the uncore performance
     counters on Skylake server systems work correctly

   - add a missing instruction slot release to the failure path of
     kprobes"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  kprobes/x86: Release insn_slot in failure path
  perf/x86/intel/uncore: Fix missing marker for skx_uncore_cha_extra_regs
  perf/x86/intel/uncore: Fix SKX CHA event extra regs
  perf/x86/intel/uncore: Remove invalid Skylake server CHA filter field
  perf/x86/intel/uncore: Fix Skylake server CHA LLC_LOOKUP event umask
  perf/x86/intel/uncore: Fix Skylake server PCU PMU event format
  perf/x86/intel/uncore: Fix Skylake UPI PMU event masks
2017-07-30 11:52:15 -07:00
4815d3c56d cpufreq: x86: Make scaling_cur_freq behave more as expected
After commit f8475cef90 "x86: use common aperfmperf_khz_on_cpu() to
calculate KHz using APERF/MPERF" the scaling_cur_freq policy attribute
in sysfs only behaves as expected on x86 with APERF/MPERF registers
available when it is read from at least twice in a row.  The value
returned by the first read may not be meaningful, because the
computations in there use cached values from the previous iteration
of aperfmperf_snapshot_khz() which may be stale.

To prevent that from happening, modify arch_freq_get_on_cpu() to
call aperfmperf_snapshot_khz() twice, with a short delay between
these calls, if the previous invocation of aperfmperf_snapshot_khz()
was too far back in the past (specifically, more that 1s ago).

Also, as pointed out by Doug Smythies, aperf_delta is limited now
and the multiplication of it by cpu_khz won't overflow, so simplify
the s->khz computations too.

Fixes: f8475cef90 "x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF"
Reported-by: Doug Smythies <dsmythies@telus.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-30 14:26:51 +02:00
fce8dc5e50 ARM: shmobile: rcar-gen2: Fix deadlock in regulator quirk
Simon Horman reported that Koelsch and Lager hang during boot, and
bisected this to commit 1c3c5eab17 ("sched/core: Enable
might_sleep() and smp_processor_id() checks early").

The da9063/da9210 regulator quirk for R-Car Gen2 boards uses a bus
notifier, and unregisters the notifier when it is no longer needed.
However, a notifier must not be unregistered from within the call chain.

This bug went unnoticed, as blocking_notifier_chain_unregister() didn't
take the semaphore during early boot.  The aforementioned commit changed
that behavior, leading to a deadlock.

Fix this by removing the call to bus_unregister_notifier(), and keeping
local completion state instead.

Reported-by: Simon Horman <horms+renesas@verge.net.au>
Fixes: 663fbb5215 ("ARM: shmobile: R-Car Gen2: Add da9063/da9210 regulator quirk")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2017-07-29 10:32:52 +02:00
6d0f581d17 xtensa: fix cache aliasing handling code for WT cache
Currently building kernel for xtensa core with aliasing WT cache fails
with the following messages:

  mm/memory.c:2152: undefined reference to `flush_dcache_page'
  mm/memory.c:2332: undefined reference to `local_flush_cache_page'
  mm/memory.c:1919: undefined reference to `local_flush_cache_range'
  mm/memory.c:4179: undefined reference to `copy_to_user_page'
  mm/memory.c:4183: undefined reference to `copy_from_user_page'

This happens because implementation of these functions is only compiled
when data cache is WB, which looks wrong: even when data cache doesn't
need flushing it still needs invalidation. The functions like
__flush_[invalidate_]dcache_* are correctly defined for both WB and WT
caches (and even if they weren't that'd still be ok, just slower).

Fix this by providing the same implementation of the above functions for
both WB and WT cache.

Cc: stable@vger.kernel.org
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2017-07-28 18:35:13 -07:00
8155469341 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull KVM fixes from Paolo Bonzini:
 "s390:
   - SRCU fix

  PPC:
   - host crash fixes

  x86:
   - bugfixes, including making nested posted interrupts really work

  Generic:
   - tweaks to kvm_stat and to uevents"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: LAPIC: Fix reentrancy issues with preempt notifiers
  tools/kvm_stat: add '-f help' to get the available event list
  tools/kvm_stat: use variables instead of hard paths in help output
  KVM: nVMX: Fix loss of L2's NMI blocking state
  KVM: nVMX: Fix posted intr delivery when vcpu is in guest mode
  x86: irq: Define a global vector for nested posted interrupts
  KVM: x86: do mask out upper bits of PAE CR3
  KVM: make pid available for uevents without debugfs
  KVM: s390: take srcu lock when getting/setting storage keys
  KVM: VMX: remove unused field
  KVM: PPC: Book3S HV: Fix host crash on changing HPT size
  KVM: PPC: Book3S HV: Enable TM before accessing TM registers
2017-07-28 13:36:56 -07:00
3d9d7405c0 Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
 "I'd been collecting these whilst we debugged a CPU hotplug failure,
  but we ended up diagnosing that one to tglx, who has taken a fix via
  the -tip tree separately.

  We're seeing some NFS issues that we haven't gotten to the bottom of
  yet, and we've uncovered some issues with our backtracing too so there
  might be another fixes pull before we're done.

  Summary:

   - Ensure we have a guard page after the kernel image in vmalloc

   - Fix incorrect prefetch stride in copy_page

   - Ensure irqs are disabled in die()

   - Fix for event group validation in QCOM L2 PMU driver

   - Fix requesting of PMU IRQs on AMD Seattle

   - Minor cleanups and fixes"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: mmu: Place guard page after mapping of kernel image
  drivers/perf: arm_pmu: Request PMU SPIs with IRQF_PER_CPU
  arm64: sysreg: Fix unprotected macro argmuent in write_sysreg
  perf: qcom_l2: fix column exclusion check
  arm64/lib: copy_page: use consistent prefetch stride
  arm64/numa: Drop duplicate message
  perf: Convert to using %pOF instead of full_name
  arm64: Convert to using %pOF instead of full_name
  arm64: traps: disable irq in die()
  arm64: atomics: Remove '&' from '+&' asm constraint in lse atomics
  arm64: uaccess: Remove redundant __force from addr cast in __range_ok
2017-07-28 13:29:36 -07:00
080012bad6 Merge tag 'powerpc-4.13-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fixes from Michael Ellerman:
 "The highlight is Ben's patch to work around a host killing bug when
  running KVM guests with the Radix MMU on Power9. See the long change
  log of that commit for more detail.

  And then three fairly minor fixes:

   - fix of_node_put() underflow during reconfig remove, using old DLPAR
     tools.

   - fix recently introduced ld version check with 64-bit LE-only
     toolchain.

   - free the subpage_prot_table correctly, avoiding a memory leak.

  Thanks to: Aneesh Kumar K.V, Benjamin Herrenschmidt, Laurent Vivier"

* tag 'powerpc-4.13-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/mm/hash: Free the subpage_prot_table correctly
  powerpc/Makefile: Fix ld version check with 64-bit LE-only toolchain
  powerpc/pseries: Fix of_node_put() underflow during reconfig remove
  powerpc/mm/radix: Workaround prefetch issue with KVM
2017-07-28 13:25:15 -07:00
a2d48756ca Merge tag 'mmc-v4.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
Pull MMC fixes from Ulf Hansson:
 "Here are a couple of mmc fixes intended for v4.13-rc1.

  I have also included a couple of cleanup patches in this pull request
  for OMAP2+, related to the omap_hsmmc driver. The reason is because of
  the changes are also depending on OMAP SoC specific code, so this
  simplifies how to deal with this.

  Summary:

  MMC host:
   - sunxi: Correct time phase settings
   - omap_hsmmc: Clean up some dead code
   - dw_mmc: Fix message printed for deprecated num-slots DT binding
   - dw_mmc: Fix DT documentation"

* tag 'mmc-v4.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
  Documentation: dw-mshc: deprecate num-slots
  mmc: dw_mmc: fix the wrong condition check of getting num-slots from DT
  mmc: host: omap_hsmmc: remove unused platform callbacks
  ARM: OMAP2+: hsmmc.c: Remove dead code
  mmc: sunxi: Keep default timing phase settings for new timing mode
2017-07-28 12:04:36 -07:00
253fd51e2f powerpc/powernv/pci: Return failure for some uses of dma_set_mask()
Commit 8e3f1b1d82 ("powerpc/powernv/pci: Enable 64-bit devices to access
>4GB DMA space") introduced the ability for PCI device drivers to request a
DMA mask between 64 and 32 bits and actually get a mask greater than
32-bits. However currently if certain machine configuration dependent
conditions are not meet the code silently falls back to a 32-bit mask.

This makes it hard for device drivers to detect which mask they actually
got. Instead we should return an error when the request could not be
fulfilled which allows drivers to either fallback or implement other
workarounds as documented in DMA-API-HOWTO.txt.

Signed-off-by: Alistair Popple <alistair@popple.id.au>
Acked-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-07-28 23:02:55 +10:00
65c5ec11c2 powerpc/boot: Fix 64-bit boot wrapper build with non-biarch compiler
Historically the boot wrapper was always built 32-bit big endian, even
for 64-bit kernels. That was because old firmwares didn't necessarily
support booting a 64-bit image. Because of that arch/powerpc/boot/Makefile
uses CROSS32CC for compilation.

However when we added 64-bit little endian support, we also added
support for building the boot wrapper 64-bit. However we kept using
CROSS32CC, because in most cases it is just CC and everything works.

However if the user doesn't specify CROSS32_COMPILE (which no one ever
does AFAIK), and CC is *not* biarch (32/64-bit capable), then CROSS32CC
becomes just "gcc". On native systems that is probably OK, but if we're
cross building it definitely isn't, leading to eg:

  gcc ... -m64 -mlittle-endian -mabi=elfv2 ... arch/powerpc/boot/cpm-serial.c
  gcc: error: unrecognized argument in option ‘-mabi=elfv2’
  gcc: error: unrecognized command line option ‘-mlittle-endian’
  make: *** [zImage] Error 2

To fix it, stop using CROSS32CC, because we may or may not be building
32-bit. Instead setup a BOOTCC, which defaults to CC, and only use
CROSS32_COMPILE if it's set and we're building for 32-bit.

Fixes: 147c05168f ("powerpc/boot: Add support for 64bit little endian wrapper")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Cyril Bur <cyrilbur@gmail.com>
2017-07-28 19:35:46 +10:00
7b7622bb95 powerpc/smp: Call smp_ops->setup_cpu() directly on the boot CPU
In smp_cpus_done() we need to call smp_ops->setup_cpu() for the boot
CPU, which means it has to run *on* the boot CPU.

In the past we ensured it ran on the boot CPU by changing the CPU
affinity mask of current directly. That was removed in commit
6d11b87d55 ("powerpc/smp: Replace open coded task affinity logic"),
and replaced with a work queue call.

Unfortunately using a work queue leads to a lockdep warning, now that
the CPU hotplug lock is a regular semaphore:

  ======================================================
  WARNING: possible circular locking dependency detected
  ...
  kworker/0:1/971 is trying to acquire lock:
   (cpu_hotplug_lock.rw_sem){++++++}, at: [<c000000000100974>] apply_workqueue_attrs+0x34/0xa0

  but task is already holding lock:
   ((&wfc.work)){+.+.+.}, at: [<c0000000000fdb2c>] process_one_work+0x25c/0x800
  ...
       CPU0                    CPU1
       ----                    ----
  lock((&wfc.work));
                               lock(cpu_hotplug_lock.rw_sem);
                               lock((&wfc.work));
  lock(cpu_hotplug_lock.rw_sem);

Although the deadlock can't happen in practice, because
smp_cpus_done() only runs in early boot before CPU hotplug is allowed,
lockdep can't tell that.

Luckily in commit 8fb12156b8 ("init: Pin init task to the boot CPU,
initially") tglx changed the generic code to pin init to the boot CPU
to begin with. The unpinning of init from the boot CPU happens in
sched_init_smp(), which is called after smp_cpus_done().

So smp_cpus_done() is always called on the boot CPU, which means we
don't need the work queue call at all - and the lockdep warning goes
away.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
2017-07-28 19:35:45 +10:00
92bbd16e50 arm64: mmu: Place guard page after mapping of kernel image
The vast majority of virtual allocations in the vmalloc region are followed
by a guard page, which can help to avoid overruning on vma into another,
which may map a read-sensitive device.

This patch adds a guard page to the end of the kernel image mapping (i.e.
following the data/bss segments).

Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2017-07-28 10:32:14 +01:00
20c6c18904 x86/boot: Disable the address-of-packed-member compiler warning
The clang warning 'address-of-packed-member' is disabled for the general
kernel code, also disable it for the x86 boot code.

This suppresses a bunch of warnings like this when building with clang:

./arch/x86/include/asm/processor.h:535:30: warning: taking address of
  packed member 'sp0' of class or structure 'x86_hw_tss' may result in an
  unaligned pointer value [-Waddress-of-packed-member]
    return this_cpu_read_stable(cpu_tss.x86_tss.sp0);
                                ^~~~~~~~~~~~~~~~~~~
./arch/x86/include/asm/percpu.h:391:59: note: expanded from macro
  'this_cpu_read_stable'
    #define this_cpu_read_stable(var)       percpu_stable_op("mov", var)
                                                                    ^~~
./arch/x86/include/asm/percpu.h:228:16: note: expanded from macro
  'percpu_stable_op'
    : "p" (&(var)));
             ^~~

Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20170725215053.135586-1-mka@chromium.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-28 08:39:08 +02:00
cd63f3cf1d powerpc/tm: Fix saving of TM SPRs in core dump
Currently flush_tmregs_to_thread() does not save the TM SPRs (TFHAR,
TFIAR, TEXASR) to the thread struct, unless the process is currently
inside a suspended transaction.

If the process is core dumping, and the TM SPRs have changed since the
last time the process was context switched, then we will save stale
values of the TM SPRs to the core dump.

Fix it by saving the live register state to the thread struct in that
case.

Fixes: 08e1c01d6a ("powerpc/ptrace: Enable support for TM SPR state")
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Gustavo Romero <gromero@linux.vnet.ibm.com>
Reviewed-by: Cyril Bur <cyrilbur@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-07-28 15:56:06 +10:00
c9c98bc5cc powerpc/mm: Fix pmd/pte_devmap() on non-leaf entries
The Radix MMU translation tree as defined in ISA v3.0 contains two
different types of entry, directories and leaves. Leaves are
identified by _PAGE_PTE being set.

The formats of the two entries are different, with the directory
entries containing no spare bits for use by software. In particular
the bit we use for _PAGE_DEVMAP is not reserved for software, and is
part of the NLB (Next Level Base) field, essentially the address of
the next level in the tree.

Note that the Linux pte_t is not == _PAGE_PTE. A huge page pmd
entry (or devmap!) is also a leaf and so has _PAGE_PTE set, even
though we use a pmd_t for it in Linux.

The fix is to ensure that the pmd/pte_devmap() confirm they are
looking at a leaf entry (_PAGE_PTE) as well as checking _PAGE_DEVMAP.

Fixes: ebd3119793 ("powerpc/mm: Add devmap support for ppc64")
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Tested-by: Laurent Vivier <lvivier@redhat.com>
Tested-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
[mpe: Add a comment in the code and flesh out change log]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-07-28 15:55:30 +10:00
3ac8093cf5 arm64: defconfig: enable missing HWSPINLOCK
The hardware spinlock drivers now depend on HWSPINLOCK (instead of
selecting it), so we need to explicitly enable it after commit
35fc8a07d7 ("Make HWSPINLOCK a menuconfig to ease disabling")

Without HWSPINLOCK, various drivers are left with unsatisfied
dependencies and Qcom boards using shared memory based communication
to request regulators are failing to boot and mount rootfs.

Fix this by explicitly enabling HWSPINLOCK in defconfig.

Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
2017-07-27 23:09:54 -05:00
1d20d8a9fc ARM: pxa: select both FB and FB_W100 for eseries
We get a link error trying to access the w100fb_gpio_read/write
functions from the platform when the driver is a loadable module
or not built-in, so the platform already uses 'select' to hard-enable
the driver.

However, that fails if the framebuffer subsystem is disabled
altogether.

I've considered various ways to fix this properly, but they
all seem like too much work or too risky, so this simply
adds another 'select' to force the subsystem on as well.

Fixes: 82427de2c7 ("ARM: pxa: PXA_ESERIES depends on FB_W100.")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-07-27 22:57:55 +02:00
c4caa8db4c ARM: ixp4xx: fix ioport_unmap definition
An empty macro definition can cause unexpected behavior, in
case of the ixp4xx ioport_unmap, we get two warnings:

drivers/net/wireless/marvell/libertas/if_cs.c: In function 'if_cs_release':
drivers/net/wireless/marvell/libertas/if_cs.c:826:3: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body]
   ioport_unmap(card->iobase);
drivers/vfio/pci/vfio_pci_rdwr.c: In function 'vfio_pci_vga_rw':
drivers/vfio/pci/vfio_pci_rdwr.c:230:15: error: the omitted middle operand in ?: will always be 'true', suggest explicit middle operand [-Werror=parentheses]
   is_ioport ? ioport_unmap(iomem) : iounmap(iomem);

This uses an inline function to define the macro in a safer way.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Krzysztof Halasa <khalasa@piap.pl>
2017-07-27 22:57:53 +02:00
cd5bad4135 ARM: ep93xx: use ARM_PATCH_PHYS_VIRT correctly
Just like ARCH_MULTIPLATFORM, we want to use ARM_PATCH_PHYS_VIRT
when possible, but that fails for NOMMU or XIP_KERNEL configurations.
Using 'imply' instead of 'select' gets this right and only uses
the symbol when we don't have to hardcode the address anyway.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
2017-07-27 22:57:51 +02:00
1c1953f351 ARM: mmp: mark usb_dma_mask as __maybe_unused
This variable may be used by some devices that each have their
on Kconfig symbol, or by none of them, and that causes a build
warning:

arch/arm/mach-mmp/devices.c:241:12: error: 'usb_dma_mask' defined but not used [-Werror=unused-variable]

Marking it __maybe_unused avoids the warning.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-07-27 22:57:49 +02:00
293ea3d0ab ARM: omap2: mark unused functions as __maybe_unused
The omap_generic_init() and omap_hwmod_init_postsetup() functions are
used in the initialization for all OMAP2+ SoC types, but in the
extreme case that those are all disabled, we get a warning about
unused code:

arch/arm/mach-omap2/io.c:412:123: error: 'omap_hwmod_init_postsetup' defined but not used [-Werror=unused-function]
arch/arm/mach-omap2/board-generic.c:30:123: error: 'omap_generic_init' defined but not used [-Werror=unused-function]

This annotates both as __maybe_unused to shut up that warning.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2017-07-27 22:57:48 +02:00
d1c888878c ARM: omap1: avoid unused variable warning
The osk_mistral_init() contains code that is only compiled when
CONFIG_PM is set, but it uses a variable that is declared outside
of the #ifdef:

arch/arm/mach-omap1/board-osk.c: In function 'osk_mistral_init':
arch/arm/mach-omap1/board-osk.c:513:7: warning: unused variable 'ret' [-Wunused-variable]

This removes the #ifdef around the user of the variable,
make it always used.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tony Lindgren <tony@atomide.com>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
2017-07-27 22:57:46 +02:00
c1ae3f7c4b ARM: sirf: mark sirfsoc_init_late as __maybe_unused
sirfsoc_init_late is called by each of the three individual
SoC definitions, but in a randconfig build, we can encounter
a situation where they are all disabled:

arch/arm/mach-prima2/common.c:18:123: warning: 'sirfsoc_init_late' defined but not used [-Wunused-function]

While that is not a useful configuration, the warning also
doesn't help, so this patch marks the function as __maybe_unused
to let the compiler know it is there intentionally.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-07-27 22:57:44 +02:00
1f3b4d8fcc ARM: ixp4xx: use normal prototype for {read,write}s{b,w,l}
ixp4xx defines the arguments to its __indirect_writesb() and other
functions as pointers to fixed-size data. This is not necessarily
wrong, and it works most of the time, but it causes warnings in
at least one driver:

drivers/net/ethernet/smsc/smc91x.c: In function 'smc_rcv':
drivers/net/ethernet/smsc/smc91x.c:495:21: error: passing argument 2 of '__indirect_readsw' from incompatible pointer type [-Werror=incompatible-pointer-types]
   SMC_PULL_DATA(lp, data, packet_len - 4);

All other definitions of the same functions pass void pointers,
so doing the same here avoids the warnings.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Krzysztof Halasa <khalasa@piap.pl>
2017-07-27 22:57:42 +02:00
595a9f9a57 ARM: omap1/ams-delta: warn about failed regulator enable
The modem pm handler in the ams-delta board uses regulator_enable()
but does not check for a successful return code:

board-ams-delta.c:521:3: error: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result [-Werror=unused-result]

It is not easy to propagate that return code to the callers in
uart_configure_port/uart_suspend_port/uart_resume_port, unless
we change all UART drivers, and it is unclear what those would
do with the return code.

Instead, this patch uses a runtime warning to replace the
compiletime warning. I have checked that the regulator in question
is hardcoded to a fixed-voltage GPIO regulator, and that should
never fail to get enabled if I understand the code right.

Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Link: https://patchwork.kernel.org/patch/8391981/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-07-27 22:57:40 +02:00
47589c4af9 ARM: rpc: rename RAM_SIZE macro
The RAM_SIZE macro in mach/hardware.h conflicts with macros of
the same name in multiple drivers, leading to annoying build warnings:

In file included from drivers/net/ethernet/cirrus/cs89x0.c:79:0:
drivers/net/ethernet/cirrus/cs89x0.h:324:0: error: "RAM_SIZE" redefined [-Werror]
 #define RAM_SIZE 0x1000       /*  The card has 4k bytes or RAM */
 ^
In file included from /git/arm-soc/arch/arm/mach-rpc/include/mach/io.h:16:0,
                 from /git/arm-soc/arch/arm/include/asm/io.h:194,
                 from /git/arm-soc/include/linux/scatterlist.h:8,
                 from /git/arm-soc/include/linux/dmaengine.h:24,
                 from /git/arm-soc/include/linux/netdevice.h:38,
                 from /git/arm-soc/drivers/net/ethernet/cirrus/cs89x0.c:54:
arch/arm/mach-rpc/include/mach/hardware.h:28:0: note: this is the location of the previous definition
 #define RAM_SIZE  0x10000000

We don't use RAM_SIZE/RAM_START at all, so we could just remove
them, but it might be nice to leave them for documentation purposes,
so this renames them to RPC_RAM_SIZE/RPC_RAM_START in order to
avoid the build warnings

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-07-27 22:57:38 +02:00
bd7fefe1f0 ARM: w90x900: normalize clk API
w90x900 still provides its own variant of the clk API rather than using
the generic COMMON_CLK API. This generally works, but it causes some link
errors with drivers using the clk_set_rate, clk_get_parent, clk_set_parent
or clk_round_rate functions when a platform lacks those interfaces.

This adds empty stub implementations for each of them, and I don't even
try to do something useful here but instead just print a WARN() message
to make it obvious what is going on if they ever end up being called.

The drivers that call these won't be used on these platforms (otherwise
we'd get a link error today), so the added code is harmless bloat and
will warn about accidental use.

A while ago there was a proposal to change w90x900 to use the common-clk
implementation, which would be the way it should be handled properly.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-07-27 22:57:36 +02:00
ef8aa4e0a0 ARM: ep93xx: normalize clk API
It's a combination of the patch from Arnd Bergmann, which added empty stubs
for clk_round_rate() and clk_set_parent() and a working trivial
implementation of clk_get_parent(). The later is required for ADC driver.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-07-27 22:57:24 +02:00
36cb531d86 Merge branch 'parisc-4.13-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
Pull parisc fixes from Helge Deller:

 - The majority of lines changed are due to regenerated defconfig files.

 - The support for the Page Deallocation Table (PDT) which was merged in
   the merge window for 4.13 contained a bug which crashes the kernel if
   a bad page is reported by firmware. This is now fixed and the kernel
   messages will show which memory slot holds the broken DIMM.

 - Commit 3a166fc2d4 ("kbuild: handle libs-y archives separately from
   built-in.o archives") broke linking the parisc kernel due to
   millicode symbols which can't be reached then any longer. This was
   fixed by modifying the parisc vmlinux.lds linker script.

 - If the stack checker panics on stack overflow, avoid recursive
   panics.

 - Some parisc machines can't physically power off and thus instead
   start after some time to flood the console by presumably detected
   soft lockups. Avoid this by disabling the lockup detectors before
   entering the endless for-next loop.

 - Dave Anglin provided fixes which prevents TLB speculation on flushed
   pages on PA8800/PA9000 CPUs.

 - Arvind Yadav sent a trivial patch to constify the attribute_group
   structure in our firmware on-board-flash storage driver
   (pdc_stable.c)

* 'parisc-4.13-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: Extend disabled preemption in copy_user_page
  parisc: Prevent TLB speculation on flushed pages on CPUs that only support equivalent aliases
  parisc: Suspend lockup detectors before system halt
  parisc: Show DIMM slot number which holds broken memory module
  parisc: Add function to return DIMM slot of physical address
  parisc: Fix crash when calling PDC_PAT_MEM PDT firmware function
  parisc: regenerate defconfig files
  parisc: pdc_stable: constify attribute_group structures.
  parisc: Merge millicode routines via linker script
  parisc: Disable further stack checks when panic occurs during stack check
2017-07-27 12:44:05 -07:00
60187bd4fd Merge branch 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm
Pull ARM fixes from Russell King:
 "Two areas addressed by these fixes:

   - Fixes from Dave Martin for the signal frames that were broken with
     certain configurations. No one noticed until recently.

   - More kexec fixes to ensure that the crashkernel region is correctly
     allocated, and a fix for the location of the device tree when
     several kexec kernels are loaded"

* 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm:
  ARM: 8687/1: signal: Fix unparseable iwmmxt_sigframe in uc_regspace[]
  ARM: 8686/1: iwmmxt: Add missing __user annotations to sigframe accessors
  ARM: kexec: fix failure to boot crash kernel
  ARM: kexec: avoid allocating crashkernel region outside lowmem
2017-07-27 10:35:07 -07:00
c50f9fb6c5 ARM: dts: sun8i: a83t: Switch to CCU device tree binding macros
Now that the CCU device tree binding headers have been merged, we can
use the properly named macros in the device tree, instead of raw
numbers.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-07-27 21:18:48 +08:00
3a4bae5fd4 arm64: allwinner: sun50i-a64: Correct emac register size
The datasheet said that emac register size is 0x10000 not 0x100

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
[wens@csie.org: Fixed commit subject prefix]
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2017-07-27 21:18:43 +08:00
072b6e3692 ARM: dts: sunxi: h3/h5: Correct emac register size
The datasheet said that emac register size is 0x10000 not 0x104

Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
[wens@csie.org: Fixed commit subject prefix]
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2017-07-27 21:10:32 +08:00
a3287c41ff drivers/perf: arm_pmu: Request PMU SPIs with IRQF_PER_CPU
Since the PMU register interface is banked per CPU, CPU PMU interrrupts
cannot be handled by a CPU other than the one with the PMU asserting the
interrupt. This means that migrating PMU SPIs, as we do during a CPU
hotplug operation doesn't make any sense and can lead to the IRQ being
disabled entirely if we route a spurious IRQ to the new affinity target.

This has been observed in practice on AMD Seattle, where CPUs on the
non-boot cluster appear to take a spurious PMU IRQ when coming online,
which is routed to CPU0 where it cannot be handled.

This patch passes IRQF_PERCPU for PMU SPIs and forcefully sets their
affinity prior to requesting them, ensuring that they cannot
be migrated during hotplug events. This interacts badly with the DB8500
erratum workaround that ping-pongs the interrupt affinity from the handler,
so we avoid passing IRQF_PERCPU in that case by allowing the IRQ flags
to be overridden in the platdata.

Fixes: 3cf7ee98b8 ("drivers/perf: arm_pmu: move irq request/free into probe")
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2017-07-27 13:43:22 +01:00
77a374c299 ARM: sa1100: normalize clk API
sa1100 provides its own variant of the clk API rather than using the
generic COMMON_CLK API. This generally works, but it causes some link
errors with drivers using the clk_set_rate, clk_get_parent, clk_set_parent
or clk_round_rate functions when a platform lacks those interfaces.

This adds trivial stub implementations for each of them, based on
the behavior of the COMMON_CLK implementation:

- set_rate() and set_parent() report success without doing anything
- round_rate() returns the clk rate
- get_parent() returns NULL.

This adds the minimal bloat and should do the right thing for
the simple clock hardware in this SoC.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-07-27 13:15:50 +02:00
31d5cf1476 ARM: davinci: normalize clk API
davinci still has its own clk implementation, but lacks
a clk_get_parent() helper, which can lead to link errors
in randconfig builds.

This adds the usual implementation.

Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-07-27 13:15:29 +02:00
d997211e1e ARM: sa1100/pxa: fix MTD_XIP build
In commit 3169663ac5 "ARM: sa11x0/pxa: convert OS timer registers
to IOMEM", the definition of the OSCR macro was changed to be an
__iomem pointer, but the same register is also used by the XIP
code. This patch does the corresponding change here as well.

On PXA, the IRQ register definitions were removed even earlier, in
commit 5d284e353e ("ARM: pxa: avoid accessing interrupt registers
directly"). This patch unfortunately brings some of that back. An
earlier version of my patch moved the code into an external function,
which could not work for CONFIG_XIP_KERNEL+CONFIG_MTD_XIP, so this
restores something close to the original code.

Link: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/241716.html
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-07-27 13:14:41 +02:00
8b9740178f ARM: davinci: don't mark vpif_input structures as 'const'
A change to the platform data definitions caused a warning in the board code:

arch/arm/mach-davinci/board-da850-evm.c:1221:13: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
arch/arm/mach-davinci/board-da850-evm.c:1231:13: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]

This is a bit unfortunate, since we generally like structure definitions to
be const, but as this is legacy code, the easiest way out is still to
remove the 'const' annotation here.

Fixes: 4a5f8ae50b ("[media] davinci: vpif_capture: get subdevs from DT when available")
Fixes: 231ce279e6 ("ARM: davinci: fix const warnings")
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-07-27 13:13:26 +02:00
6ea57ad6b9 ARM: dts: da850-lcdk: drop unused VPIF endpoints
Drop the unused endpoints.  They should only be used when there is an
actual remote-endpoint connected.

Cc: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2017-07-27 16:29:44 +05:30
0b048ff2cf ARM: dts: da850-evm: drop unused VPIF endpoints
Drop the unused endpoints.  They should only be used when there is
an actual remote-endpoint connected.

Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2017-07-27 16:29:43 +05:30
75f4e38131 Merge tag 'mvebu-fixes-4.13-1' of git://git.infradead.org/linux-mvebu into fixes
Pull "mvebu fixes for 4.13 (part 1)" from Gregory CLEMENT:

- Fix wrong irq type for gpio expeander on Armada 388 GP
- Use __pa_symbol instead of virt_to_phys in the mv98dx3236 platform
  SMP code

* tag 'mvebu-fixes-4.13-1' of git://git.infradead.org/linux-mvebu:
  ARM: dts: armada-38x: Fix irq type for pca955
  ARM: mvebu: use __pa_symbol in the mv98dx3236 platform SMP code
2017-07-27 12:54:35 +02:00
a3c0d2fb08 ARM: dts: exynos: Add clocks to audss block to fix silent hang on Exynos4412
Add necessary parent clocks for audss (Audio SubSystem, MAUDIO) clock
controller block.

This allows driver to keep EPLL enabled before accessing any MAUDIO
registers thus fixing silent hang.  This silent hang appeared with
commit 6edfa11cb3 ("clk: samsung: Add enable/disable operation for
PLL36XX clocks"), e.g. on Odroid U3 usually with last (but unrelated)
messages:

	[    2.382741] input: gpio_keys as /devices/platform/gpio_keys/input/input0
	[    2.405686] usb 1-3: new high-speed USB device number 3 using exynos-ehci
	[    2.419843] max77686-rtc max77686-rtc: setting system clock to 2017-06-21 17:04:13 UTC (1498064653)

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-07-27 12:53:15 +02:00
b2e58cbee3 Merge tag 'renesas-fixes2-for-v4.13' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes
Pull "Second Round of Renesas ARM Based SoC Fixes for v4.13" from Simon Horman:

Correct order of sound clock frequencies for ULCB boards
used by r8a7795 and r8a7796 SoCs.

These sounds clock frequencies are used as the ADG clock (output clocks
for audio module) initial setting and sound codec's initial system clock
which needs the maximum clock frequency. Thus, descending order is
required.

* tag 'renesas-fixes2-for-v4.13' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
  arm64: dts: renesas: ulcb: sound clock-frequency needs descending order
2017-07-27 12:51:28 +02:00
d4e740053a Merge tag 'omap-for-v4.13/fixes-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
Pull "Few fixes for omaps for issues found recently" from Tony Lindgren:

- Fix disable_irq related shared IRQ warnings for omap3 PRM

- Fix omap4 legacy code regression that accidentally removed code that
  we still need for PRM interrupts

- Fix dm8168-evm NAND pins and MMC write protect pin direction

- Fix dra71-evm mdio impedance values

* tag 'omap-for-v4.13/fixes-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: dts: dra71-evm: mdio: Fix impedance values
  ARM: dts: dm816x: Correct the state of the write protect pin
  ARM: dts: dm816x: Correct NAND support nodes
  ARM: OMAP4: Fix legacy code clean-up regression
  ARM: OMAP2+: Fix omap3 prm shared irq
2017-07-27 12:50:35 +02:00