arm64: Add support for CLOCK_MONOTONIC_RAW in clock_gettime() vDSO

So far the arm64 clock_gettime() vDSO implementation only supported
the following clocks, falling back to the syscall for the others:
- CLOCK_REALTIME{,_COARSE}
- CLOCK_MONOTONIC{,_COARSE}

This patch adds support for the CLOCK_MONOTONIC_RAW clock, taking
advantage of the recent refactoring of the vDSO time functions. Like
the non-_COARSE clocks, this only works when the "arch_sys_counter"
clocksource is in use (allowing us to read the current time from the
virtual counter register), otherwise we also have to fall back to the
syscall.

Most of the data is shared with CLOCK_MONOTONIC, and the algorithm is
similar. The reference implementation in kernel/time/timekeeping.c
shows that:
- CLOCK_MONOTONIC = tk->wall_to_monotonic + tk->xtime_sec +
  timekeeping_get_ns(&tk->tkr_mono)
- CLOCK_MONOTONIC_RAW = tk->raw_time + timekeeping_get_ns(&tk->tkr_raw)
- tkr_mono and tkr_raw are identical (in particular, same
  clocksource), except these members:
  * mult (only mono's multiplier is NTP-adjusted)
  * xtime_nsec (always 0 for raw)

Therefore, tk->raw_time and tkr_raw->mult are now also stored in the
vDSO data page.

Cc: Ali Saidi <ali.saidi@arm.com>
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: Refactor vDSO time functions

Time functions are directly implemented in assembly in arm64, and it
is desirable to keep it this way for performance reasons (everything
fits in registers, so that the stack is not used at all). However, the
current implementation is quite difficult to read and understand (even
considering it's assembly).  Additionally, due to the structure of
__kernel_clock_gettime, which heavily uses conditional branches to
share code between the different clocks, it is difficult to support a
new clock without making the branches even harder to follow.

This commit completely refactors the structure of clock_gettime (and
gettimeofday along the way) while keeping exactly the same algorithms.
We no longer try to share code; instead, macros provide common
operations. This new approach comes with a number of advantages:
- In clock_gettime, clock implementations are no longer interspersed,
  making them much more readable. Additionally, macros only use
  registers passed as arguments or reserved with .req, this way it is
  easy to make sure that registers are properly allocated. To avoid a
  large number of branches in a given execution path, a jump table is
  used; a normal execution uses 3 unconditional branches.
- __do_get_tspec has been replaced with 2 macros (get_ts_clock_mono,
  get_clock_shifted_nsec) and explicit loading of data from the vDSO
  page. Consequently, clock_gettime and gettimeofday are now leaf
  functions, and saving x30 (lr) is no longer necessary.
- Variables protected by tb_seq_count are now loaded all at once,
  allowing to merge the seqcnt_read macro into seqcnt_check.
- For CLOCK_REALTIME_COARSE, removed an unused load of the wall to
  monotonic timespec.
- For CLOCK_MONOTONIC_COARSE, removed a few shift instructions.

Obviously, the downside of sharing less code is an increase in code
size. However since the vDSO has its own code page, this does not
really matter, as long as the size of the DSO remains below 4 kB. For
now this should be all right:
                    Before  After
  vdso.so size (B)  2776    3000

Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: fix vdso-offsets.h dependency

arm64/kernel/{vdso,signal}.c include vdso-offsets.h, as well as any
file that includes asm/vdso.h. Therefore, vdso-offsets.h must be
generated before these files are compiled.

The current rules in arm64/kernel/Makefile do not actually enforce
this, because even though $(obj)/vdso is listed as a prerequisite for
vdso-offsets.h, this does not result in the intended effect of
building the vdso subdirectory (before all the other objects). As a
consequence, depending on the order in which the rules are followed,
vdso-offsets.h is updated or not before arm64/kernel/{vdso,signal}.o
are built. The current rules also impose an unnecessary dependency on
vdso-offsets.h for all arm64/kernel/*.o, resulting in unnecessary
rebuilds. This is made obvious when using make -j:

  touch arch/arm64/kernel/vdso/gettimeofday.S && make -j$NCPUS arch/arm64/kernel

will sometimes result in none of arm64/kernel/*.o being
rebuilt, sometimes all of them, or even just some of them.

It is quite difficult to ensure that a header is generated before it
is used with recursive Makefiles by using normal rules.  Instead,
arch-specific generated headers are normally built in the archprepare
recipe in the arch Makefile (see for instance arch/ia64/Makefile).
Unfortunately, asm-offsets.h is included in gettimeofday.S, and must
therefore be generated before vdso-offsets.h, which is not the case if
archprepare is used. For this reason, a rule run after archprepare has
to be used.

This commit adds rules in arm64/Makefile to build vdso-offsets.h
during the prepare step, ensuring that vdso-offsets.h is generated
before building anything. It also removes the now-unnecessary
dependencies on vdso-offsets.h in arm64/kernel/Makefile. Finally, it
removes the duplication of asm-offsets.h between arm64/kernel/vdso/
and include/generated/ and makes include/generated/vdso-offsets.h a
target in arm64/kernel/vdso/Makefile.

Cc: Will Deacon <will.deacon@arm.com>
Cc: Michal Marek <mmarek@suse.com>
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

Revert "arm64: Fix vdso-offsets.h dependency"

This reverts commit 90f777beb788d08300f4a1482cb4fd37a401b472.

While this commit was aimed at fixing the dependencies, with a large
make -j the vdso-offsets.h file is not generated, leading to build
failures.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: mm: change IOMMU notifier action to attach DMA ops

Current bus notifier in ARM64 (__iommu_attach_notifier)
attempts to attach dma_ops to a device on BUS_NOTIFY_ADD_DEVICE
action notification.

This will cause issues on ACPI based systems, where PCI devices
can be added before the IOMMUs the devices are attached to
had a chance to be probed, causing failures on attempts to
attach dma_ops in that the domain for the respective IOMMU
may not be set-up yet by the time the bus notifier is run.

Devices dma_ops do not require to be set-up till the matching
device drivers are probed. This means that instead of running
the notifier attaching dma_ops to devices (__iommu_attach_notifier)
on BUS_NOTIFY_ADD_DEVICE action, it can be run just before the
device driver is bound to the device in question (on action
BUS_NOTIFY_BIND_DRIVER) so that it is certain that its IOMMU
group and domain are set-up accordingly at the time the
notifier is triggered.

This patch changes the notifier action upon which dma_ops
are attached to devices and defer it to driver binding time,
so that IOMMU devices have a chance to be probed and to register
their bus notifiers before the dma_ops attach sequence for a
device is actually carried out.

As a result we also no longer need worry about racing with
iommu_bus_notifier(), or about retrying the queue in case devices
were added too early on DT-based systems, so clean up the notifier
itself plus the additional workaround from 722ec35f7fae ("arm64:
dma-mapping: fix handling of devices registered before arch_initcall")

Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
[rm: get rid of other now-redundant bits]
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

drivers/perf: arm-pmu: Handle per-interrupt affinity mask

On a big-little system, PMUs can be wired to CPUs using per CPU
interrups (PPI). In this case, it is important to make sure that
the enable/disable do happen on the right set of CPUs.

So instead of relying on the interrupt-affinity property, we can
use the actual percpu affinity that DT exposes as part of the
interrupt specifier. The DT binding is also updated to reflect
the fact that the interrupt-affinity property shouldn't be used
in that case.

Acked-by: Rob Herring <robh@kernel.org>
Tested-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: Fix vdso-offsets.h dependency

arch/arm64/kernel/{vdso,signal}.c include generated/vdso-offsets.h, and
therefore the symbol offsets must be generated before these files are
compiled.

The current rules in arm64/kernel/Makefile do not actually enforce
this, because even though $(obj)/vdso is listed as a prerequisite for
vdso-offsets.h, this does not result in the intended effect of
building the vdso subdirectory (before all the other objects). As a
consequence, depending on the order in which the rules are followed,
vdso-offsets.h is updated or not before arm64/kernel/{vdso,signal}.o
are built. The current rules also impose an unnecessary dependency on
vdso-offsets.h for all arm64/kernel/*.o, resulting in unnecessary
rebuilds.

This patch removes the arch/arm64/kernel/vdso/vdso-offsets.h file
generation, leaving only the include/generated/vdso-offsets.h one. It
adds a forced dependency check of the vdso-offsets.h file in
arch/arm64/kernel/Makefile which, if not up to date according to the
arch/arm64/kernel/vdso/Makefile rules (depending on vdso.so.dbg), will
trigger the vdso/ subdirectory build and vdso-offsets.h re-generation.
Automatic kbuild dependency rules between kernel/{vdso,signal}.c rules
and vdso-offsets.h will guarantee that the vDSO object is built first,
followed by the generated symbol offsets header file.

Reported-by: Kevin Brodsky <kevin.brodsky@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: mm: fold init_pgd() into __create_pgd_mapping()

The routine __create_pgd_mapping() does nothing except calling init_pgd(),
which has no other callers. So fold the latter into the former. Also, drop
a comment that has gone stale.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: mm: Remove split_p*d() functions

Since the efi_create_mapping() no longer generates block mappings
and being the last user of the split_p*d code, remove these functions
and the corresponding TLBI.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[ardb: replace 'overlapping regions' with 'block mappings' in commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: efi: avoid block mappings for unaligned UEFI memory regions

When running the OS with a page size > 4 KB, we need to round up mappings
for regions that are not aligned to the OS's page size. We already avoid
block mappings for EfiRuntimeServicesCode/Data regions for other reasons,
but in the unlikely event that other unaliged regions exists that have the
EFI_MEMORY_RUNTIME attribute set, ensure that unaligned regions are always
mapped down to pages. This way, the overlapping page is guaranteed not to
be covered by a block mapping that needs to be split.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: efi: always map runtime services code and data regions down to pages

To avoid triggering diagnostics in the MMU code that are finicky about
splitting block mappings into more granular mappings, ensure that regions
that are likely to appear in the Memory Attributes table as well as the
UEFI memory map are always mapped down to pages. This way, we can use
apply_to_page_range() instead of create_pgd_mapping() for the second pass,
which cannot split or merge block entries, and operates strictly on PTEs.

Note that this aligns the arm64 Memory Attributes table handling code with
the ARM code, which already uses apply_to_page_range() to set the strict
permissions.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: mm: add param to force create_pgd_mapping() to use page mappings

Add a bool parameter 'allow_block_mappings' to create_pgd_mapping() and
the various helper functions that it descends into, to give the caller
control over whether block entries may be used to create the mapping.

The UEFI runtime mapping routines will use this to avoid creating block
entries that would need to split up into page entries when applying the
permissions listed in the Memory Attributes firmware table.

This also replaces the block_mappings_allowed() helper function that was
added for DEBUG_PAGEALLOC functionality, but the resulting code is
functionally equivalent (given that debug_page_alloc does not operate on
EFI page table entries anyway)

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: trap userspace "dc cvau" cache operation on errata-affected core

The ARM errata 819472, 826319, 827319 and 824069 for affected
Cortex-A53 cores demand to promote "dc cvau" instructions to
"dc civac". Since we allow userspace to also emit those instructions,
we should make sure that "dc cvau" gets promoted there too.
So lets grasp the nettle here and actually trap every userland cache
maintenance instruction once we detect at least one affected core in
the system.
We then emulate the instruction by executing it on behalf of userland,
promoting "dc cvau" to "dc civac" on the way and injecting access
fault back into userspace.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[catalin.marinas@arm.com: s/set_segfault/arm64_notify_segfault/]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: consolidate signal injection on emulation errors

The code for injecting a signal into userland if a trapped instruction
fails emulation due to a _userland_ error (like an illegal address)
will be used more often with the next patch.
Factor out the core functionality into a separate function and use
that both for the existing trap handler and for the deprecated
instructions emulation.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[catalin.marinas@arm.com: s/set_segfault/arm64_notify_segfault/]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: errata: Calling enable functions for CPU errata too

Currently we call the (optional) enable function for CPU _features_
only. As CPU _errata_ descriptions share the same data structure and
having an enable function is useful for errata as well (for instance
to set bits in SCTLR), lets call it when enumerating erratas too.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: include alternative handling in dcache_by_line_op

The newly introduced dcache_by_line_op macro is used at least in
one occassion at the moment to issue a "dc cvau" instruction,
which is affected by ARM errata 819472, 826319, 827319 and 824069.
Change the macro to allow for alternative patching in there to
protect affected Cortex-A53 cores.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[catalin.marinas@arm.com: indentation fixups]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: fix "dc cvau" cache operation on errata-affected core

The ARM errata 819472, 826319, 827319 and 824069 for affected
Cortex-A53 cores demand to promote "dc cvau" instructions to
"dc civac" as well.
Attribute the usage of the instruction in __flush_cache_user_range
to also be covered by our alternative patching efforts.
For that we introduce an assembly macro which both deals with
alternatives while still tagging the instructions as USER.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

Revert "arm64: alternatives: add enable parameter to conditional asm macros"

Commit 77ee306c0aea9 ("arm64: alternatives: add enable parameter to
conditional asm macros") extended the alternative assembly macros.
Unfortunately this does not really work as one would expect, as the
enable parameter in fact correctly protects the alternative section
magic, but not the actual code sequences.
This results in having both the original instruction(s) _and_  the
alternative ones, if enable if false.
Since there is no user of this macros anyway, just revert it.

This reverts commit 77ee306c0aea9a219daec256ad25982944affef8.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: mm: remove unnecessary BUG_ON

The memblock_alloc() and memblock_alloc_base() will panic on their own
if no free memory, remove pointless BUG_ON.

Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: mm: fix location of _etext

As Kees Cook notes in the ARM counterpart of this patch [0]:

  The _etext position is defined to be the end of the kernel text code,
  and should not include any part of the data segments. This interferes
  with things that might check memory ranges and expect executable code
  up to _etext.

In particular, Kees is referring to the HARDENED_USERCOPY patch set [1],
which rejects attempts to call copy_to_user() on kernel ranges containing
executable code, but does allow access to the .rodata segment. Regardless
of whether one may or may not agree with the distinction, it makes sense
for _etext to have the same meaning across architectures.

So let's put _etext where it belongs, between .text and .rodata, and fix
up existing references to use __init_begin instead, which unlike _end_rodata
includes the exception and notes sections as well.

The _etext references in kaslr.c are left untouched, since its references
to [_stext, _etext) are meant to capture potential jump instruction targets,
and so disregarding .rodata is actually an improvement here.

[0] http://article.gmane.org/gmane.linux.kernel/2245084
[1] http://thread.gmane.org/gmane.linux.kernel.hardened.devel/2502

Reported-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: mm: simplify memblock numa node extraction

We currently open-code extracting the NUMA node of a memblock region,
which requires an ifdef to cater for !CONFIG_NUMA builds where the
memblock_region::nid field does not exist.

The generic memblock_get_region_node helper is intended to cater for
this. For CONFIG_HAVE_MEMBLOCK_NODE_MAP, builds this returns reg->nid,
and for for !CONFIG_HAVE_MEMBLOCK_NODE_MAP builds this is a static
inline that returns 0. Note that for arm64,
CONFIG_HAVE_MEMBLOCK_NODE_MAP is selected iff CONFIG_NUMA is.

This patch makes use of memblock_get_region_node to simplify the arm64
code. At the same time, we can move the nid variable definition into the
loop, as this is the only place it is used.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Steve Capper <steve.capper@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64/kexec: Add pr_debug output

To aid in debugging kexec problems or when adding new functionality to
kexec add a new routine kexec_image_info() and several inline pr_debug
statements.

Signed-off-by: Geoff Levand <geoff@infradead.org>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64/kexec: Enable kexec in the arm64 defconfig

Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64/kexec: Add core kexec support

Add three new files, kexec.h, machine_kexec.c and relocate_kernel.S to the
arm64 architecture that add support for the kexec re-boot mechanism
(CONFIG_KEXEC) on arm64 platforms.

Signed-off-by: Geoff Levand <geoff@infradead.org>
Reviewed-by: James Morse <james.morse@arm.com>
[catalin.marinas@arm.com: removed dead code following James Morse's comments]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: Add back cpu reset routines

Commit 68234df4ea79 ("arm64: kill flush_cache_all()") removed the global
arm64 routines cpu_reset() and cpu_soft_restart() needed by the arm64
kexec and kdump support.  Add back a simplified version of
cpu_soft_restart() with some changes needed for kexec in the new files
cpu_reset.S, and cpu_reset.h.

When a CPU is reset it needs to be put into the exception level it had when
it entered the kernel. Update cpu_soft_restart() to accept an argument
which signals if the reset address should be entered at EL1 or EL2, and
add a new hypercall HVC_SOFT_RESTART which is used for the EL2 switch.

Signed-off-by: Geoff Levand <geoff@infradead.org>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: smp: Add function to determine if cpus are stuck in the kernel

kernel/smp.c has a fancy counter that keeps track of the number of CPUs
it marked as not-present and left in cpu_park_loop(). If there are any
CPUs spinning in here, features like kexec or hibernate may release them
by overwriting this memory.

This problem also occurs on machines using spin-tables to release
secondary cores.
After commit 44dbcc93ab67 ("arm64: Fix behavior of maxcpus=N")
we bring all known cpus into the secondary holding pen, meaning this
memory can't be re-used by kexec or hibernate.

Add a function cpus_are_stuck_in_kernel() to determine if either of these
cases have occurred.

Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
[catalin.marinas@arm.com: cherry-picked from mainline for kexec dependency]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

Revert "arm64: Add support ARCH_SUPPORTS_INT128"

This reverts commit 6b14c517a2a866c8407e9864c1cd3fcc6fed55ab.

The original patch and UBSAN+KASAN enabled causes Linux to fail to link
with:

lib/built-in.o: In function `get_signed_val':
lib/ubsan.c:93: undefined reference to `__ashlti3'
lib/ubsan.c:93: undefined reference to `__ashrti3'

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: kill ESR_LNX_EXEC

Currently we treat ESR_EL1 bit 24 as software-defined for distinguishing
instruction aborts from data aborts, but this bit is architecturally
RES0 for instruction aborts, and could be allocated for an arbitrary
purpose in future. Additionally, we hard-code the value in entry.S
without the mnemonic, making the code difficult to understand.

Instead, remove ESR_LNX_EXEC, and distinguish aborts based on the esr,
which we already pass to the sole use of ESR_LNX_EXEC. A new helper,
is_el0_instruction_abort() is added to make the logic clear. Any
instruction aborts taken from EL1 will already have been handled by
bad_mode, so we need not handle that case in the helper.

For consistency, the existing permission_fault helper is renamed to
is_permission_fault, and the return type is changed to bool. There
should be no functional changes as the return value was a boolean
expression, and the result is only used in another boolean expression.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Dave P Martin <dave.martin@arm.com>
Cc: Huang Shijie <shijie.huang@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64/kvm: use ESR_ELx_EC to extract EC

Now that we have a helper to extract the EC from an ESR_ELx value, make
use of this in the arm64 KVM code for simplicity and consistency. There
should be no functional changes as a result of this patch.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Dave P Martin <dave.martin@arm.com>
Cc: Huang Shijie <shijie.huang@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: kvmarm@lists.cs.columbia.edu
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: add macro to extract ESR_ELx.EC

Several places open-code extraction of the EC field from an ESR_ELx
value, in subtly different ways. This is unfortunate duplication and
variation, and the precise logic used to extract the field is a
distraction.

This patch adds a new macro, ESR_ELx_EC(), to extract the EC field from
an ESR_ELx value in a consistent fashion.

Existing open-coded extractions in core arm64 code are moved over to the
new helper. KVM code is left as-is for the moment.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Huang Shijie <shijie.huang@arm.com>
Cc: Dave P Martin <dave.martin@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: mm: only initialize swiotlb when necessary

we only initialize swiotlb when swiotlb_force is true or not all system
memory is DMA-able, this trivial optimization saves us 64MB when
swiotlb is not necessary.

Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

ARM64: ACPI: Update documentation for latest specification version

The ACPI 6.1 specification was recently released at the end of January
2016, but the arm64 kernel documentation for the use of ACPI was written
for the 5.1 version of the spec.  There were significant additions to the
spec that had not yet been mentioned -- for example, the 6.0 mechanisms
added to make it easier to define processors and low power idle states,
as well as the 6.1 addition allowing regular interrupts (not just from
GPIO) be used to signal ACPI general purpose events.

This patch reflects going back through and examining the specs in detail
and updating content appropriately.  Whilst there, a few odds and ends of
typos were caught as well.  This brings the documentation up to date with
ACPI 6.1 for arm64.

Signed-off-by: Al Stone <al.stone@linaro.org>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Roy Franz <roy.franz@hpe.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: allow building with kcov coverage on ARM64

Add ARCH_HAS_KCOV to ARM64 config. To avoid potential crashes, disable
instrumentation of the files in arch/arm64/kvm/hyp/*.

Signed-off-by: Alexander Potapenko <glider@google.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Tested-by: James Morse <james.morse@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: Add support ARCH_SUPPORTS_INT128

The gcc support __SIZEOF_INT128__ and __int128 in arm64, thus,
enable ARCH_SUPPORTS_INT128 to make mul_u64_u32_shr() a bit
more efficient in scheduler.

Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: simplify dump_mem

Currently dump_mem attempts to dump memory in 64-bit chunks when
reporting a failure in 64-bit code, or 32-bit chunks when reporting a
failure in 32-bit code. We added code to handle these two cases
separately in commit e147ae6d7f908412 ("arm64: modify the dump mem for
64 bit addresses").

However, in all cases dump_mem is called, the failing context is a
kernel rather than user context. Additionally dump_mem is assumed to
only be used for kernel contexts, as internally it switches to
KERNEL_DS, and its callers pass kernel stack bounds.

This patch removes the redundant 32-bit chunk logic and associated
compat parameter, largely reverting the aforementioned commit. For the
call in __die(), the check of in_interrupt() is removed also, as __die()
is only called in response to faults from the kernel's exception level,
and thus the !user_mode(regs) check is sufficient. Were this not the
case, the used of task_stack_page(tsk) to generate the stack bounds
would be erroneous.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: kasan: instrument user memory access API

The upstream commit 1771c6e1a567ea0ba2cccc0a4ffe68a1419fd8ef
("x86/kasan: instrument user memory access API") added KASAN instrument to
x86 user memory access API, so added such instrument to ARM64 too.

Define __copy_to/from_user in C in order to add kasan_check_read/write call,
rename assembly implementation to __arch_copy_to/from_user.

Tested by test_kasan module.

Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Yang Shi <yang.shi@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: mm: dump: make page table dumping reusable

For debugging purposes, it would be nice if we could export page tables
other than the swapper_pg_dir to userspace. To enable this, this patch
refactors the arm64 page table dumping code such that multiple tables
may be registered with the framework, and exported under debugfs.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Laura Abbott <labbott@fedoraproject.org>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: Implement optimised IP checksum helpers

AArch64 is capable of 128-bit memory accesses without alignment
restrictions, which makes it both possible and highly practical to slurp
up a typical 20-byte IP header in just 2 loads. Implement our own
version of ip_fast_checksum() to take advantage of that, resulting in
considerably fewer instructions and memory accesses than the generic
version. We can also get more optimal code generation for csum_fold() by
defining it a slightly different way round from the generic version, so
throw that into the mix too.

Suggested-by: Luke Starrett <luke.starrett@broadcom.com>
Acked-by: Luke Starrett <luke.starrett@broadcom.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

Linux 4.7-rc4

Merge branch 'for_linus' of git://git./linux/kernel/git/jack/linux-fs

Pull UDF fixes and a reiserfs fix from Jan Kara:
 "A couple of udf fixes (most notably a bug in parsing UDF partitions
  which led to inability to mount recent Windows installation media) and
  a reiserfs fix for handling kstrdup failure"

* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
  reiserfs: check kstrdup failure
  udf: Use correct partition reference number for metadata
  udf: Use IS_ERR when loading metadata mirror file entry
  udf: Don't BUG on missing metadata partition descriptor

Merge tag 'dmaengine-fix-4.7-rc4' of git://git.infradead.org/users/vkoul/slave-dma

Pull dmaengine fixes from Vinod Koul:
 "Some fixes has piled up, so time to send them upstream.

  These fixes include:
   - at_xdmac fixes for residue and other stuff
   - update MAINTAINERS for dma dt bindings
   - mv_xor fix for incorrect offset"

* tag 'dmaengine-fix-4.7-rc4' of git://git.infradead.org/users/vkoul/slave-dma:
  dmaengine: mv_xor: Fix incorrect offset in dma_map_page()
  dmaengine: at_xdmac: double FIFO flush needed to compute residue
  dmaengine: at_xdmac: fix residue corruption
  dmaengine: at_xdmac: align descriptors on 64 bits
  MAINTAINERS: Add file patterns for dma device tree bindings

Merge tag 'armsoc-fixes' of git://git./linux/kernel/git/arm/arm-soc

Pull ARM SoC fixes from Olof Johansson:
 "Another batch of fixes for ARM SoC platforms.  Most are smaller fixes.

  Two areas that are worth pointing out are:

   - OMAP had a handful of changes to voltage specs that caused a bit of
     churn, most of volume of change in this branch is due to this.

   - There are a couple of _rcuidle fixes from Paul that touch common
     code and came in through the OMAP tree since they were the ones who
     saw the problems.

 The rest is smaller changes across a handful of platforms"

* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (36 commits)
  ARM: dts: STi: stih407-family: Disable reserved-memory co-processor nodes
  ARM: dts: am437x-sk-evm: Reduce i2c0 bus speed for tps65218
  ARM: OMAP2+: timer: add probe for clocksources
  ARM: OMAP1: fix ams-delta FIQ handler to work with sparse IRQ
  memory: omap-gpmc: Fix omap gpmc EXTRADELAY timing
  arm: Use _rcuidle for smp_cross_call() tracepoints
  MAINTAINERS: Add myself as reviewer of ARM FSL/NXP
  ARM: OMAP: DRA7: powerdomain data: Remove unused pwrsts_mem_ret
  ARM: OMAP: DRA7: powerdomain data: Remove unused pwrsts_logic_ret
  ARM: OMAP: DRA7: powerdomain data: Set L3init and L4per to ON
  ARM: imx6ul: Fix Micrel PHY mask
  ARM: OMAP2+: Select OMAP_INTERCONNECT for SOC_AM43XX
  ARM: dts: DRA74x: fix DSS PLL2 addresses
  ARM: OMAP2: Enable Errata 430973 for OMAP3
  ARM: dts: socfpga: Add missing PHY phandle
  ARM: dts: exynos: Fix port nodes names for Exynos5420 Peach Pit board
  ARM: dts: exynos: Fix port nodes names for Exynos5250 Snow board
  ARM: dts: sun6i: yones-toptech-bs1078-v2: Drop constraints on dc1sw regulator
  ARM: dts: sun6i: primo81: Drop constraints on dc1sw regulator
  ARM: dts: sunxi: Add OLinuXino Lime2 eMMC to the Makefile
  ...

Merge tag 'gpmc-omap-fixes-for-v4.7' of https://github.com/rogerq/linux into fixes

OMAP-GPMC: Fixes for for v4.7-rc cycle:

- Fix omap gpmc EXTRADELAY timing. The DT provided timings
were wrongly used causing devices requiring extra delay timing
to fail.

* tag 'gpmc-omap-fixes-for-v4.7' of https://github.com/rogerq/linux:
  memory: omap-gpmc: Fix omap gpmc EXTRADELAY timing
  + Linux 4.7-rc3

Signed-off-by: Olof Johansson <olof@lixom.net>

Merge tag 'omap-for-v4.7/fixes-powedomain' of git://git./linux/kernel/git/tmlind/linux-omap into fixes

Fixes for omaps for v4.7-rc cycle:

- Fix dra7 for hardware issues limiting L4Per and L3init power domains
  to on state. Without this the devices may not work correctly after
  some time of use because of asymmetric aging. And related to this,
  let's also remove the unusable states.

- Always select omap interconnect for am43x as otherwise the am43x
  only configurations will not boot properly. This can happen easily
  for any product kernels that leave out other SoCs to save memory.

- Fix DSS PLL2 addresses that have gone unused for now

- Select erratum 430973 for omap3, this is now safe to do and can
  save quite a bit of debugging time for people who may have left
  it out.

* tag 'omap-for-v4.7/fixes-powedomain' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: OMAP: DRA7: powerdomain data: Remove unused pwrsts_mem_ret
  ARM: OMAP: DRA7: powerdomain data: Remove unused pwrsts_logic_ret
  ARM: OMAP: DRA7: powerdomain data: Set L3init and L4per to ON
  ARM: OMAP2+: Select OMAP_INTERCONNECT for SOC_AM43XX
  ARM: dts: DRA74x: fix DSS PLL2 addresses
  ARM: OMAP2: Enable Errata 430973 for OMAP3
  + Linux 4.7-rc2

Signed-off-by: Olof Johansson <olof@lixom.net>

Merge tag 'fixes-rcu-fiq-signed' of git://git./linux/kernel/git/tmlind/linux-omap into fixes

Fixes for omaps for v4.7-rc cycle:

- Two boot warning fixes from the RCU tree that should have gotten
  merged several weeks ago already but did not because of issues
  with who merges them. Paul has now split the RCU warning fixes into
  sets for various maintainers.

- Fix ams-delta FIQ regression caused by omap1 sparse IRQ changes

- Fix PM for omap3 boards using timer12 and gptimer, like the
  original beagleboard

- Fix hangs on am437x-sk-evm by lowering the I2C bus speed

* tag 'fixes-rcu-fiq-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: dts: am437x-sk-evm: Reduce i2c0 bus speed for tps65218
  ARM: OMAP2+: timer: add probe for clocksources
  ARM: OMAP1: fix ams-delta FIQ handler to work with sparse IRQ
  arm: Use _rcuidle for smp_cross_call() tracepoints
  arm: Use _rcuidle tracepoint to allow use from idle

Signed-off-by: Olof Johansson <olof@lixom.net>

ARM: dts: STi: stih407-family: Disable reserved-memory co-processor nodes

This patch fixes a non-booting issue in Mainline.

When booting with a compressed kernel, we need to be careful how we
populate memory close to DDR start.  AUTO_ZRELADDR is enabled by default
in multi-arch enabled configurations, which place some restrictions on
where the kernel is placed and where it will be uncompressed to on boot.

AUTO_ZRELADDR takes the decompressor code's start address and masks out
the bottom 28 bits to obtain an address to uncompress the kernel to
(thus a load address of 0x42000000 means that the kernel will be
uncompressed to 0x40000000 i.e. DDR START on this platform).

Even changing the load address to after the co-processor's shared memory
won't render a booting platform, since the AUTO_ZRELADDR algorithm still
ensures the kernel is uncompressed into memory shared with the first
co-processor (0x40000000).

Another option would be to move loading to 0x4A000000, since this will
mean the decompressor will decompress the kernel to 0x48000000. However,
this would mean a large chunk (0x44000000 => 0x48000000 (64MB)) of
memory would essentially be wasted for no good reason.

Until we can work with ST to find a suitable memory location to
relocate co-processor shared memory, let's disable the shared memory
nodes.  This will ensure a working platform in the mean time.

NB: The more observant of you will notice that we're leaving the DMU
shared memory node enabled; this is because a) it is the only one in
active use at the time of this writing and b) it is not affected by
the current default behaviour which is causing issues.

Fixes: fe135c6 (ARM: dts: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory)
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

Merge tag 'imx-fixes-4.7' of git://git./linux/kernel/git/shawnguo/linux into fixes

The i.MX fixes for 4.7:
 - Correct Micrel PHY mask to fix the issue that i.MX6UL ethernet works
   in U-Boot but not in kernel.

* tag 'imx-fixes-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
  ARM: imx6ul: Fix Micrel PHY mask

Signed-off-by: Olof Johansson <olof@lixom.net>

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

Pull ARM fixes from Russell King:
 "A couple of fixes for pmd_mknotpresent()/pmd_present() for LPAE
  systems"

* 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm:
  ARM: 8579/1: mm: Fix definition of pmd_mknotpresent
  ARM: 8578/1: mm: ensure pmd_present only checks the valid bit

Merge tag 'usb-4.7-rc4' of git://git./linux/kernel/git/gregkh/usb

Pull USB fixes from Greg KH:
 "Here are a bunch (65) of USB fixes for 4.7-rc4.  Sorry about the
  quantity, I've been slow in getting these out.

  The majority are the "normal" gadget, musb, and xhci fixes, that we
  all are used to.  There are also a few other tiny fixes resolving a
  number of reported issues that showed up in 4.7-rc1.

  All of these have been in linux-next"

* tag 'usb-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (65 commits)
  usbip: rate limit get_frame_number message
  usb: musb: sunxi: Remove bogus "Frees glue" comment
  usb: musb: sunxi: Fix NULL ptr deref when gadget is registered before musb
  usb: echi-hcd: Add ehci_setup check before echi_shutdown
  usb: host: ehci-msm: Conditionally call ehci suspend/resume
  MAINTAINERS: Add file patterns for usb device tree bindings
  usb: host: ehci-tegra: Avoid getting the same reset twice
  usb: host: ehci-tegra: Grab the correct UTMI pads reset
  USB: mos7720: delete parport
  USB: OHCI: Don't mark EDs as ED_OPER if scheduling fails
  phy: ti-pipe3: Program the DPLL even if it was already locked
  usb: musb: Stop bulk endpoint while queue is rotated
  usb: musb: Ensure rx reinit occurs for shared_fifo endpoints
  usb: musb: host: correct cppi dma channel for isoch transfer
  usb: musb: only restore devctl when session was set in backup
  usb: phy: Check initial state for twl6030
  usb: musb: Use normal module_init for 2430 glue
  usb: musb: Remove pm_runtime_set_irq_safe
  usb: musb: Remove extra PM runtime calls from 2430 glue layer
  usb: musb: Return error value from musb_mailbox
  ...

Merge tag 'staging-4.7-rc4' of git://git./linux/kernel/git/gregkh/staging

Pull IIO and staging fixes from Greg KH:
 "Here are a number of IIO and staging bugfixes for 4.7-rc4.

  Nothing huge, the normal amount of iio driver fixes, and some small
  staging driver bugfixes for some reported problems (2 are reverts of
  patches that went into 4.7-rc1).  All have been in linux-next with no
  reported issues"

* tag 'staging-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (24 commits)
  Revert "Staging: rtl8188eu: rtw_efuse: Use sizeof type *pointer instead of sizeof type."
  Revert "Staging: drivers: rtl8188eu: use sizeof(*ptr) instead of sizeof(struct)"
  staging: lustre: lnet: Don't access NULL NI on failure path
  iio: hudmidity: hdc100x: fix incorrect shifting and scaling
  iio: light apds9960: Add the missing dev.parent
  iio: Fix error handling in iio_trigger_attach_poll_func
  iio: st_sensors: Disable DRDY at init time
  iio: st_sensors: Init trigger before irq request
  iio: st_sensors: switch to a threaded interrupt
  iio: light: bh1780: assign a static name
  iio: bh1780: dereference the client properly
  iio: humidity: hdc100x: fix IIO_TEMP channel reporting
  iio:st_pressure: fix sampling gains (bring inline with ABI)
  iio: proximity: as3935: fix buffer stack trashing
  iio: proximity: as3935: remove triggered buffer processing
  iio: proximity: as3935: correct IIO_CHAN_INFO_RAW output
  max44000: Remove scale from proximity
  iio: humidity: am2315: Remove a stray unlock
  iio: humidity: hdc100x: correct humidity integration time mask
  iio: pressure: bmp280: fix error message for wrong chip id
  ...

Merge tag 'driver-core-4.7-rc4' of git://git./linux/kernel/git/gregkh/driver-core

Pull driver core fixes from Greg KH:
 "Here are a small number of debugfs, ISA, and one driver core fix for
  4.7-rc4.

  All of these resolve reported issues.  The ISA ones have spent the
  least amount of time in linux-next, sorry about that, I didn't realize
  they were regressions that needed to get in now (thanks to Thorsten
  for the prodding!) but they do all pass the 0-day bot tests.  The
  others have been in linux-next for a while now.

  Full details about them are in the shortlog below"

* tag 'driver-core-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  isa: Dummy isa_register_driver should return error code
  isa: Call isa_bus_init before dependent ISA bus drivers register
  watchdog: ebc-c384_wdt: Allow build for X86_64
  iio: stx104: Allow build for X86_64
  gpio: Allow PC/104 devices on X86_64
  isa: Allow ISA-style drivers on modern systems
  base: make module_create_drivers_dir race-free
  debugfs: open_proxy_open(): avoid double fops release
  debugfs: full_proxy_open(): free proxy on ->open() failure
  kernel/kcov: unproxify debugfs file's fops

Merge tag 'char-misc-4.7-rc4' of git://git./linux/kernel/git/gregkh/char-misc

Pull char/misc driver fixes from Greg KH:
 "Here are a small number of char and misc driver fixes for 4.7-rc4.

  They resolve some minor issues that have been reported, and have all
  been in linux-next"

* tag 'char-misc-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  coresight: Handle build path error
  coresight: Fix erroneous memset in tmc_read_unprepare_etr
  coresight: Fix tmc_read_unprepare_etr
  coresight: Fix NULL pointer dereference in _coresight_build_path
  extcon: palmas: Fix boot up state of VBUS when using GPIO detection
  mcb: Acquire reference to carrier module in core
  mcb: Acquire reference to device in probe
  mei: don't use wake_up_interruptible for wr_ctrl

Merge branch 'for-linus-4.7' of git://git./linux/kernel/git/mason/linux-btrfs

Pull btrfs fixes from Chris Mason:
 "The most user visible change here is a fix for our recent superblock
  validation checks that were causing problems on non-4k pagesized
  systems"

* 'for-linus-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  Btrfs: btrfs_check_super_valid: Allow 4096 as stripesize
  btrfs: remove build fixup for qgroup_account_snapshot
  btrfs: use new error message helper in qgroup_account_snapshot
  btrfs: avoid blocking open_ctree from cleaner_kthread
  Btrfs: don't BUG_ON() in btrfs_orphan_add
  btrfs: account for non-CoW'd blocks in btrfs_abort_transaction
  Btrfs: check if extent buffer is aligned to sectorsize
  btrfs: Use correct format specifier

Merge tag 'acpi-4.7-rc4' of git://git./linux/kernel/git/rafael/linux-pm

Pull ACPI fix from Rafael Wysocki:
 "Revert a recent ACPICA commit that introduced a suspend-to-RAM
  regression on one system due to incorrect information in its ACPI
  tables that had not been taken into consideration at all before (and
  everything worked), but the commit in question started to use it"

* tag 'acpi-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  Revert "ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_hw_write()"

Merge tag 'pm-4.7-rc4' of git://git./linux/kernel/git/rafael/linux-pm

Pull power management fixes from Rafael Wysocki:
 "Fixes for two recent regressions that may lead to degraded performance
  (operating performance points framework, intel_pstate).

  Specifics:

   - Fix a recent regression in the intel_pstate driver that may lead to
     degraded performance on some systems due to missing turbo state
     entry in the table returned by the ACPI _PSS object (Srinivas
     Pandruvada).

   - Fix a recent regression in the OPP (operating performance points)
     framework that may lead to degraded performance on some systems
     where the OPP table is created too early (Viresh Kumar)"

* tag 'pm-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  PM / OPP: Add 'UNKNOWN' status for shared_opp in struct opp_table
  cpufreq: intel_pstate: Adjust _PSS[0] freqeuency if needed

Merge branch 'for-linus' of git://git./linux/kernel/git/jikos/hid

Pull HID subsystem fixes from Jiri Kosina:

 - kernel panic fix in hid-elo from Oliver Neukum

 - Surface Pro 3 device quirk from Benjamin Tissoires

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
  HID: multitouch: Add MT_QUIRK_NOT_SEEN_MEANS_UP to Surface Pro 3
  HID: elo: kill not flush the work

isa: Dummy isa_register_driver should return error code

The inline isa_register_driver stub simply allows compilation on systems
with CONFIG_ISA disabled; the dummy isa_register_driver does not
register an isa_driver at all. The inline isa_register_driver should
return -ENODEV to indicate lack of support when attempting to register
an isa_driver on such a system with CONFIG_ISA disabled.

Cc: Matthew Wilcox <matthew@wil.cx>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Tested-by: Ye Xiaolong
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

isa: Call isa_bus_init before dependent ISA bus drivers register

The isa_bus_init function must be called before drivers which utilize
the ISA bus driver are registered. A race condition for initilization
exists if device_initcall is used (the isa_bus_init callback is placed
in the same initcall level as dependent drivers which use module_init).
This patch ensures that isa_bus_init is called first by utilizing
postcore_initcall in favor of device_initcall.

Fixes: a5117ba7da37 ("[PATCH] Driver model: add ISA bus")
Cc: Rene Herman <rene.herman@keyaccess.nl>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

watchdog: ebc-c384_wdt: Allow build for X86_64

With the introduction of the ISA_BUS_API Kconfig option, ISA-style
drivers may be built for X86_64 architectures. This patch changes the
ISA Kconfig option dependency of the WinSystems EBC-C384 watchdog timer
driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is
expected to.

Cc: Wim Van Sebroeck <wim@iguana.be>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: stx104: Allow build for X86_64

With the introduction of the ISA_BUS_API Kconfig option, ISA-style
drivers may be built for X86_64 architectures. This patch changes the
ISA Kconfig option dependency of the Apex Embedded Systems STX104 DAC
driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is
expected to.

Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

gpio: Allow PC/104 devices on X86_64

With the introduction of the ISA_BUS_API Kconfig option, ISA-style
drivers may be built for X86_64 architectures. This patch changes the
ISA Kconfig option dependency of the PC/104 drivers to ISA_BUS_API, thus
allowing them to build for X86_64 as they are expected to.

Cc: Alexandre Courbot <gnurou@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

isa: Allow ISA-style drivers on modern systems

Several modern devices, such as PC/104 cards, are expected to run on
modern systems via an ISA bus interface. Since ISA is a legacy interface
for most modern architectures, ISA support should remain disabled in
general. Support for ISA-style drivers should be enabled on a per driver
basis.

To allow ISA-style drivers on modern systems, this patch introduces the
ISA_BUS_API and ISA_BUS Kconfig options. The ISA bus driver will now
build conditionally on the ISA_BUS_API Kconfig option, which defaults to
the legacy ISA Kconfig option. The ISA_BUS Kconfig option allows the
ISA_BUS_API Kconfig option to be selected on architectures which do not
enable ISA (e.g. X86_64).

The ISA_BUS Kconfig option is currently only implemented for X86
architectures. Other architectures may have their own ISA_BUS Kconfig
options added as required.

Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usbip: rate limit get_frame_number message

It's annoying to constantly see the same "Not yet implemented" message
over and over with nothing able to be done about it, so rate limit it
for now to keep user's logs "clean".

Reported-by: Lars Täuber <lars.taeuber@web.de>
Tested-by: Lars Täuber <lars.taeuber@web.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge branch 'acpica-fixes'

* acpica-fixes:
  Revert "ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_hw_write()"

Merge branches 'pm-opp' and 'pm-cpufreq-fixes'

* pm-opp:
  PM / OPP: Add 'UNKNOWN' status for shared_opp in struct opp_table

* pm-cpufreq-fixes:
  cpufreq: intel_pstate: Adjust _PSS[0] freqeuency if needed

Revert "Staging: rtl8188eu: rtw_efuse: Use sizeof type *pointer instead of sizeof type."

This reverts commit b5e12ec38331 ("Staging: rtl8188eu: rtw_efuse: Use
sizeof type *pointer instead of sizeof type.").

This commit is wrong, the rtw_malloc2d helper function takes the size of
the array elements as its 3th argument, whereas sizeof(*eFuseWord)
gives the size of a pointer instead of the size of a u16.

Since sizeof(void *) > sizeof(u16) this has no adverse effects, but it
is still wrong.

Cc: Sandhya Bankar <bankarsandhya512@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "Staging: drivers: rtl8188eu: use sizeof(*ptr) instead of sizeof(struct)"

This reverts commit 99aded71b52c ("Staging: drivers: rtl8188eu: use
sizeof(*ptr) instead of sizeof(struct)").

This commit is wrong, as adapt->HalData has a type of "void *", so
now we are allocating a much to small struct, which causes the driver
to overwrite random memory which leads to a non working driver and
various system crashes.

Cc: Jacky Boen <aqiank@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'arm64-fixes' of git://git./linux/kernel/git/arm64/linux

Pull arm64 fixes from Will Deacon:
 "The main things are getting kgdb up and running with upstream GDB
  after a protocol change was reverted and fixing our spin_unlock_wait
  and spin_is_locked implementations after doing some similar work with
  PeterZ on the qspinlock code last week.  Whilst we haven't seen any
  failures in practice, it's still worth getting this fixed.

  Summary:

   - Plug the ongoing spin_unlock_wait/spin_is_locked mess
   - KGDB protocol fix to sync w/ GDB
   - Fix MIDR-based PMU probing for old 32-bit SMP systems
     (OMAP4/Realview)
   - Minor tweaks to the fault handling path"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: kgdb: Match pstate size with gdbserver protocol
  arm64: spinlock: Ensure forward-progress in spin_unlock_wait
  arm64: spinlock: fix spin_unlock_wait for LSE atomics
  arm64: spinlock: order spin_{is_locked,unlock_wait} against local locks
  arm: pmu: Fix non-devicetree probing
  arm64: mm: mark fault_info table const
  arm64: fix dump_instr when PAN and UAO are in use

Merge tag 'iommu-fixes-v4.7-rc3' of git://git./linux/kernel/git/joro/iommu

Pull IOMMU fixes from Joerg Roedel:
 "Three patches queued up:

   - Fix for ARM-SMMU to add a missing iommu-ops callback which is
     required by common iommu code

   - Fix for the rockchip iommu where the wrong MMUs got the commands

   - A regression fix for the Intel VT-d driver.  The regression only
     showed up on X58 chipsets with more than one iommu.  These chipsets
     seem to require that QI is enabled on all IOMMUs before it can be
     used"

* tag 'iommu-fixes-v4.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
  iommu/vt-d: Enable QI on all IOMMUs before setting root entry
  iommu/rockchip: Fix zap cache during device attach
  iommu/arm-smmu: Wire up map_sg for arm-smmu-v3

Merge tag 'for-4.7-rc4' of git://git./linux/kernel/git/j.anaszewski/linux-leds

Pull LED fixes from Jacek Anaszewski:

 - Fix brightness setting upon hardware blinking enabled

 - Handle suspend/resume in heartbeat trigger

* tag 'for-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds:
  leds: handle suspend/resume in heartbeat trigger
  leds: core: Fix brightness setting upon hardware blinking enabled

Merge branch 'for-chris' of git://git./linux/kernel/git/kdave/linux into for-linus-4.7

Btrfs: btrfs_check_super_valid: Allow 4096 as stripesize

Older btrfs-progs/mkfs.btrfs sets 4096 as the stripesize. Hence
restricting stripesize to be equal to sectorsize would cause super block
validation to return an error on architectures where PAGE_SIZE is not
equal to 4096.

Hence as a workaround, this commit allows stripesize to be set to 4096
bytes.

Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Signed-off-by: David Sterba <dsterba@suse.com>

btrfs: remove build fixup for qgroup_account_snapshot

Introduced in 2c1984f244838477aab ("btrfs: build fixup for
qgroup_account_snapshot") as temporary bisectability build fixup.

Signed-off-by: David Sterba <dsterba@suse.com>

btrfs: use new error message helper in qgroup_account_snapshot

We've renamed btrfs_std_error, this one is left from last merge.

Signed-off-by: David Sterba <dsterba@suse.com>

btrfs: avoid blocking open_ctree from cleaner_kthread

This fixes a problem introduced in commit 2f3165ecf103599f82bf0ea254039db335fb5005
"btrfs: don't force mounts to wait for cleaner_kthread to delete one or more subvolumes".

open_ctree eventually calls btrfs_replay_log which in turn calls
btrfs_commit_super which tries to lock the cleaner_mutex, causing a
recursive mutex deadlock during mount.

Instead of playing whack-a-mole trying to keep up with all the
functions that may want to lock cleaner_mutex, put all the cleaner_mutex
lockers back where they were, and attack the problem more directly:
keep cleaner_kthread asleep until the filesystem is mounted.

When filesystems are mounted read-only and later remounted read-write,
open_ctree did not set fs_info->open and neither does anything else.
Set this flag in btrfs_remount so that neither btrfs_delete_unused_bgs
nor cleaner_kthread get confused by the common case of "/" filesystem
read-only mount followed by read-write remount.

Signed-off-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>

Btrfs: don't BUG_ON() in btrfs_orphan_add

This is just a screwup for developers, so change it to an ASSERT() so developers
notice when things go wrong and deal with the error appropriately if ASSERT()
isn't enabled.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>

btrfs: account for non-CoW'd blocks in btrfs_abort_transaction

The test for !trans->blocks_used in btrfs_abort_transaction is
insufficient to determine whether it's safe to drop the transaction
handle on the floor.  btrfs_cow_block, informed by should_cow_block,
can return blocks that have already been CoW'd in the current
transaction.  trans->blocks_used is only incremented for new block
allocations. If an operation overlaps the blocks in the current
transaction entirely and must abort the transaction, we'll happily
let it clean up the trans handle even though it may have modified
the blocks and will commit an incomplete operation.

In the long-term, I'd like to do closer tracking of when the fs
is actually modified so we can still recover as gracefully as possible,
but that approach will need some discussion.  In the short term,
since this is the only code using trans->blocks_used, let's just
switch it to a bool indicating whether any blocks were used and set
it when should_cow_block returns false.

Cc: stable@vger.kernel.org # 3.4+
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>

Btrfs: check if extent buffer is aligned to sectorsize

Thanks to fuzz testing, we can pass an invalid bytenr to extent buffer
via alloc_extent_buffer().  An unaligned eb can have more pages than it
should have, which ends up extent buffer's leak or some corrupted content
in extent buffer.

This adds a warning to let us quickly know what was happening.

Now that alloc_extent_buffer() no more returns NULL, this changes its
caller and callers of its caller to match with the new error
handling.

Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>

btrfs: Use correct format specifier

Component mirror_num of struct btrfsic_block is defined
as unsigned int. Use %u as format specifier.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>

ARM: dts: am437x-sk-evm: Reduce i2c0 bus speed for tps65218

Based on the latest timing specifications for the TPS65218 from the data
sheet, http://www.ti.com/lit/ds/symlink/tps65218.pdf, document SLDS206
from November 2014, we must change the i2c bus speed to better fit within
the minimum high SCL time required for proper i2c transfer.

When running at 400khz, measurements show that SCL spends
0.8125 uS/1.666 uS high/low which violates the requirement for minimum
high period of SCL provided in datasheet Table 7.6 which is 1 uS.
Switching to 100khz gives us 5 uS/5 uS high/low which both fall above
the minimum given values for 100 khz, 4.0 uS/4.7 uS high/low.

Without this patch occasionally a voltage set operation from the kernel
will appear to have worked but the actual voltage reflected on the PMIC
will not have updated, causing problems especially with cpufreq that may
update to a higher OPP without actually raising the voltage on DCDC2,
leading to a hang.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Aparna Balasubramanian <aparnab@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP2+: timer: add probe for clocksources

A few platforms are currently missing clocksource_probe() completely
in their time_init functionality. On OMAP3430 for example, this is
causing cpuidle to be pretty much dead, as the counter32k is not
going to be registered and instead a gptimer is used as a clocksource.
This will tick in periodic mode, preventing any deeper idle states.

While here, also drop one unnecessary check for populated DT before
existing clocksource_probe() call.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP1: fix ams-delta FIQ handler to work with sparse IRQ

After OMAP1 IRQ definitions have been changed by commit 685e2d08c54b
("ARM: OMAP1: Change interrupt numbering for sparse IRQ") introduced
in v4.2, ams-delta FIQ handler which depends on them no longer works
as expected. Fix it.

Created and tested on Amstrad Delta against Linux-4.7-rc3

Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

iommu/vt-d: Enable QI on all IOMMUs before setting root entry

This seems to be required on some X58 chipsets on systems
with more than one IOMMU. QI does not work until it is
enabled on all IOMMUs in the system.

Reported-by: Dheeraj CVR <cvr.dheeraj@gmail.com>
Tested-by: Dheeraj CVR <cvr.dheeraj@gmail.com>
Fixes: 5f0a7f7614a9 ('iommu/vt-d: Make root entry visible for hardware right after allocation')
Cc: stable@vger.kernel.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>

Merge tag 'pwm/for-4.7-rc4' of git://git./linux/kernel/git/thierry.reding/linux-pwm

Pull pwm fixes from Thierry Reding:
 "These changes fix a bit of fallout from the introduction of the atomic
  API"

* tag 'pwm/for-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
  pwm: atmel-hlcdc: Fix default PWM polarity
  pwm: sysfs: Get return value from pwm_apply_state()
  pwm: Improve args checking in pwm_apply_state()

Merge tag 'for-linus' of git://git./virt/kvm/kvm

Pull KVM fixes from Paolo Bonzini:

 - miscellaneous fixes for MIPS and s390

 - one new kvm_stat for s390

 - correctly disable VT-d posted interrupts with the rest of posted
   interrupts

 - "make randconfig" fix for x86 AMD

 - off-by-one in irq route check (the "good" kind that errors out a bit
   too early!)

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  kvm: vmx: check apicv is active before using VT-d posted interrupt
  kvm: Fix irq route entries exceeding KVM_MAX_IRQ_ROUTES
  kvm: svm: Do not support AVIC if not CONFIG_X86_LOCAL_APIC
  kvm: svm: Fix implicit declaration for __default_cpu_present_to_apicid()
  MIPS: KVM: Fix CACHE triggered exception emulation
  MIPS: KVM: Don't unwind PC when emulating CACHE
  MIPS: KVM: Include bit 31 in segment matches
  MIPS: KVM: Fix modular KVM under QEMU
  KVM: s390: Add stats for PEI events
  KVM: s390: ignore IBC if zero

Merge tag 'nfsd-4.7-1' of git://linux-nfs.org/~bfields/linux

Pull nfsd bugfixes from Bruce Fields:
 "Oleg Drokin found and fixed races in the nfsd4 state code that go back
  to the big nfs4_lock_state removal around 3.17 (but that were also
  probably hard to reproduce before client changes in 3.20 allowed the
  client to perform parallel opens).

  Also fix a 4.1 backchannel crash due to rpc multipath changes in 4.6.
  Trond acked the client-side rpc fixes going through my tree"

* tag 'nfsd-4.7-1' of git://linux-nfs.org/~bfields/linux:
  nfsd: Make init_open_stateid() a bit more whole
  nfsd: Extend the mutex holding region around in nfsd4_process_open2()
  nfsd: Always lock state exclusively.
  rpc: share one xps between all backchannels
  nfsd4/rpc: move backchannel create logic into rpc code
  SUNRPC: fix xprt leak on xps allocation failure
  nfsd: Fix NFSD_MDS_PR_KEY on 32-bit by adding ULL postfix

Merge branch 'overlayfs-linus' of git://git./linux/kernel/git/mszeredi/vfs

Pull overlayfs fixes from Miklos Szeredi:
 "This contains two regression fixes: one for the xattr API update and
  one for using the mounter's creds in file creation in overlayfs.

  There's also a fix for a bug in handling hard linked AF_UNIX sockets
  that's been there from day one.  This fix is overlayfs only despite
  the fact that it touches code outside the overlay filesystem: d_real()
  is an identity function for all except overlay dentries"

* 'overlayfs-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs:
  ovl: fix uid/gid when creating over whiteout
  ovl: xattr filter fix
  af_unix: fix hard linked sockets on overlay
  vfs: add d_real_inode() helper

KEYS: potential uninitialized variable

If __key_link_begin() failed then "edit" would be uninitialized.  I've
added a check to fix that.

This allows a random user to crash the kernel, though it's quite
difficult to achieve.  There are three ways it can be done as the user
would have to cause an error to occur in __key_link():

 (1) Cause the kernel to run out of memory.  In practice, this is difficult
     to achieve without ENOMEM cropping up elsewhere and aborting the
     attempt.

 (2) Revoke the destination keyring between the keyring ID being looked up
     and it being tested for revocation.  In practice, this is difficult to
     time correctly because the KEYCTL_REJECT function can only be used
     from the request-key upcall process.  Further, users can only make use
     of what's in /sbin/request-key.conf, though this does including a
     rejection debugging test - which means that the destination keyring
     has to be the caller's session keyring in practice.

 (3) Have just enough key quota available to create a key, a new session
     keyring for the upcall and a link in the session keyring, but not then
     sufficient quota to create a link in the nominated destination keyring
     so that it fails with EDQUOT.

The bug can be triggered using option (3) above using something like the
following:

echo 80 >/proc/sys/kernel/keys/root_maxbytes
keyctl request2 user debug:fred negate @t

The above sets the quota to something much lower (80) to make the bug
easier to trigger, but this is dependent on the system.  Note also that
the name of the keyring created contains a random number that may be
between 1 and 10 characters in size, so may throw the test off by
changing the amount of quota used.

Assuming the failure occurs, something like the following will be seen:

kfree_debugcheck: out of range ptr 6b6b6b6b6b6b6b68h
------------[ cut here ]------------
kernel BUG at ../mm/slab.c:2821!
...
RIP: 0010:[<ffffffff811600f9>] kfree_debugcheck+0x20/0x25
RSP: 0018:ffff8804014a7de8  EFLAGS: 00010092
RAX: 0000000000000034 RBX: 6b6b6b6b6b6b6b68 RCX: 0000000000000000
RDX: 0000000000040001 RSI: 00000000000000f6 RDI: 0000000000000300
RBP: ffff8804014a7df0 R08: 0000000000000001 R09: 0000000000000000
R10: ffff8804014a7e68 R11: 0000000000000054 R12: 0000000000000202
R13: ffffffff81318a66 R14: 0000000000000000 R15: 0000000000000001
...
Call Trace:
  kfree+0xde/0x1bc
  assoc_array_cancel_edit+0x1f/0x36
  __key_link_end+0x55/0x63
  key_reject_and_link+0x124/0x155
  keyctl_reject_key+0xb6/0xe0
  keyctl_negate_key+0x10/0x12
  SyS_keyctl+0x9f/0xe7
  do_syscall_64+0x63/0x13a
  entry_SYSCALL64_slow_path+0x25/0x25

Fixes: f70e2e06196a ('KEYS: Do preallocation for __key_link()')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

arm64: kgdb: Match pstate size with gdbserver protocol

Current versions of gdb do not interoperate cleanly with kgdb on arm64
systems because gdb and kgdb do not use the same register description.
This patch modifies kgdb to work with recent releases of gdb (>= 7.8.1).

Compatibility with gdb (after the patch is applied) is as follows:

  gdb-7.6 and earlier  Ok
  gdb-7.7 series       Works if user provides custom target description
  gdb-7.8(.0)          Works if user provides custom target description
  gdb-7.8.1 and later  Ok

When commit 44679a4f142b ("arm64: KGDB: Add step debugging support") was
introduced it was paired with a gdb patch that made an incompatible
change to the gdbserver protocol. This patch was eventually merged into
the gdb sources:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=a4d9ba85ec5597a6a556afe26b712e878374b9dd

The change to the protocol was mostly made to simplify big-endian support
inside the kernel gdb stub. Unfortunately the gdb project released
gdb-7.7.x and gdb-7.8.0 before the protocol incompatibility was identified
and reversed:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bdc144174bcb11e808b4e73089b850cf9620a7ee

This leaves us in a position where kgdb still uses the no-longer-used
protocol; gdb-7.8.1, which restored the original behaviour, was
released on 2014-10-29.

I don't believe it is possible to detect/correct the protocol
incompatiblity which means the kernel must take a view about which
version of the gdb remote protocol is "correct". This patch takes the
view that the original/current version of the protocol is correct
and that version found in gdb-7.7.x and gdb-7.8.0 is anomalous.

Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>

PM / OPP: Add 'UNKNOWN' status for shared_opp in struct opp_table

dev_pm_opp_get_sharing_cpus() returns 0 even in the case when the OPP
core doesn't know whether or not the table is shared. It works on the
majority of platforms, where the OPP table is never created before
invoking the function and then -ENODEV is returned by it.

But in the case of one platform (Jetson TK1) at least, the situation
is a bit different. The OPP table has been created (somehow) before
dev_pm_opp_get_sharing_cpus() is called and it returns 0. Its caller
treats that as 'the CPUs don't share OPPs' and that leads to degraded
performance.

Fix this by converting 'shared_opp' in struct opp_table to an enum
and making dev_pm_opp_get_sharing_cpus() return -EINVAL in case when
the value of that field is "access unknown", so that the caller can
handle it accordingly (cpufreq-dt considers that as 'all CPUs share
the table', for example).

Fixes: 6f707daa3833 "PM / OPP: Add dev_pm_opp_get_sharing_cpus()"
Reported-and-tested-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
[ rjw : Subject & changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

memory: omap-gpmc: Fix omap gpmc EXTRADELAY timing

In the omap gpmc driver it can be noticed that GPMC_CONFIG4_OEEXTRADELAY
is overwritten by the WEEXTRADELAY value from the device tree and
GPMC_CONFIG4_WEEXTRADELAY is not updated by the value from the device
tree.

As a consequence, the memory accesses cannot be configured properly when
the extra delay are needed for OE and WE.

Fix the update of GPMC_CONFIG4_WEEXTRADELAY with the value from the
device tree file and prevents GPMC_CONFIG4_OEXTRADELAY
being overwritten by the WEXTRADELAY value from the device tree.

Cc: stable@vger.kernel.org
Signed-off-by: Ocquidant, Sebastien <sebastienocquidant@eaton.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>

kvm: vmx: check apicv is active before using VT-d posted interrupt

VT-d posted interrupt is relying on the CPU side's posted interrupt.
Need to check whether VCPU's APICv is active before enabing VT-d
posted interrupt.

Fixes: d62caabb41f33d96333f9ef15e09cd26e1c12760
Cc: stable@vger.kernel.org
Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com>
Signed-off-by: Shengge Ding <shengge.dsg@alibaba-inc.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

kvm: Fix irq route entries exceeding KVM_MAX_IRQ_ROUTES

These days, we experienced one guest crash with 8 cores and 3 disks,
with qemu error logs as bellow:

qemu-system-x86_64: /build/qemu-2.0.0/kvm-all.c:984:
kvm_irqchip_commit_routes: Assertion `ret == 0' failed.

And then we found one patch(bdf026317d) in qemu tree, which said
could fix this bug.

Execute the following script will reproduce the BUG quickly:

irq_affinity.sh
========================================================================

vda_irq_num=25
vdb_irq_num=27
while [ 1 ]
do
    for irq in {1,2,4,8,10,20,40,80}
        do
            echo $irq > /proc/irq/$vda_irq_num/smp_affinity
            echo $irq > /proc/irq/$vdb_irq_num/smp_affinity
            dd if=/dev/vda of=/dev/zero bs=4K count=100 iflag=direct
            dd if=/dev/vdb of=/dev/zero bs=4K count=100 iflag=direct
        done
done
========================================================================

The following qemu log is added in the qemu code and is displayed when
this bug reproduced:

kvm_irqchip_commit_routes: max gsi: 1008, nr_allocated_irq_routes: 1024,
irq_routes->nr: 1024, gsi_count: 1024.

That's to say when irq_routes->nr == 1024, there are 1024 routing entries,
but in the kernel code when routes->nr >= 1024, will just return -EINVAL;

The nr is the number of the routing entries which is in of
[1 ~ KVM_MAX_IRQ_ROUTES], not the index in [0 ~ KVM_MAX_IRQ_ROUTES - 1].

This patch fix the BUG above.

Cc: stable@vger.kernel.org
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: Wei Tang <tangwei@cmss.chinamobile.com>
Signed-off-by: Zhang Zhuoyu <zhangzhuoyu@cmss.chinamobile.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

coresight: Handle build path error

Enabling a component via sysfs (echo 1 > enable_source), would
trigger building a path from the enabled sources to the sink.
If there is an error in the process (e.g, sink not enabled or
the device (CPU corresponding to ETM) is not online), we never report
failure, except for leaving a message in the dmesg.

Do proper error checking for the build path and return the error.

Before:
 $ echo 0 > /sys/devices/system/cpu/cpu2/online
 $ echo 1 > /sys/devices/cs_etm/cpu2/enable_source
 $ echo $?
 0

After:
 $ echo 0 > /sys/devices/system/cpu/cpu2/online
 $ echo 1 > /sys/devices/cs_etm/cpu2/enable_source
 -bash: echo: write error: No such device or address

Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

coresight: Fix erroneous memset in tmc_read_unprepare_etr

At the end of a trace collection, we try to clear the entire buffer
and enable the ETR back if it was already enabled. But, we would have
adjusted the drvdata->buf to point to the beginning of the trace data
in the trace buffer @drvdata->vaddr. So, the following code which
clears the buffer is dangerous and can cause crashes, like below :

memset(drvdata->buf, 0, drvdata->size);

 Unable to handle kernel paging request at virtual address ffffff800a145000
 pgd = ffffffc974726000
 *pgd=00000009f3e91003, *pud=00000009f3e91003, *pmd=0000000000000000
 PREEMPT SMP
 Modules linked in:
 CPU: 4 PID: 1692 Comm: dd Not tainted 4.7.0-rc2+ #1721
 Hardware name: ARM Juno development board (r0) (DT)
 task: ffffffc9734a0080 ti: ffffffc974460000 task.ti: ffffffc974460000
 PC is at __memset+0x1ac/0x200
 LR is at tmc_read_unprepare_etr+0x144/0x1bc
 pc : [<ffffff80083a05ac>] lr : [<ffffff800859c984>] pstate: 200001c5
 ...
 [<ffffff80083a05ac>] __memset+0x1ac/0x200
 [<ffffff800859b2e4>] tmc_release+0x90/0x94
 [<ffffff8008202f58>] __fput+0xa8/0x1ec
 [<ffffff80082030f4>] ____fput+0xc/0x14
 [<ffffff80080c3ef8>] task_work_run+0xb0/0xe4
 [<ffffff8008088bf4>] do_notify_resume+0x64/0x6c
 [<ffffff8008084d5c>] work_pending+0x10/0x14
 Code: 91010108 54ffff4a 8b040108 cb050042 (d50b7428)

Since we clear the buffer anyway in the following call to
tmc_etr_enable_hw(), remove the erroneous memset().

Fixes: commit de5461970b3e9e1 ("coresight: tmc: allocating memory when needed")
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

coresight: Fix tmc_read_unprepare_etr

At the end of the trace capture, we free the allocated memory,
resetting the drvdata->buf to NULL, to indicate that trace data
was collected and the next trace session should allocate the
memory in tmc_enable_etr_sink_sysfs.

The tmc_enable_etr_sink_sysfs, we only allocate memory if drvdata->vaddr
is not NULL (which is not performed at the end of previous session).
This can cause, drvdata->vaddr getting assigned NULL and later we do
memset() which causes a crash as below :

Unable to handle kernel NULL pointer dereference at virtual
 address  00000000
pgd = ffffffc9747f0000
[00000000] *pgd=00000009f402e003, *pud=00000009f402e003,
 *pmd=0000000000000000
Internal error: Oops: 96000046 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 1592 Comm: bash Not tainted 4.7.0-rc1+ #1712
Hardware name: ARM Juno development board (r0) (DT)
task: ffffffc078fe0080 ti: ffffffc974178000 task.ti: ffffffc974178000
PC is at __memset+0x1ac/0x200
LR is at tmc_enable_etr_sink+0xf8/0x304
pc : [<ffffff80083a002c>] lr : [<ffffff800859be44>] pstate: 400001c5
sp : ffffffc97417bc00
x29: ffffffc97417bc00 x28: ffffffc974178000

Call trace:
Exception stack(0xffffffc97417ba40 to 0xffffffc97417bb60)
ba40: 0000000000000001 ffffffc974a5d098 ffffffc97417bc00 ffffff80083a002c
ba60: ffffffc974a5d118 0000000000000000 0000000000000000 0000000000000000
ba80: 0000000000000001 0000000000000000 ffffff800859bdec 0000000000000040
baa0: ffffff8008b45b58 00000000000001c0 ffffffc97417baf0 ffffff80080eddb4
bac0: 0000000000000003 ffffffc078fe0080 ffffffc078fe0960 ffffffc078fe0940
bae0: 0000000000000000 0000000000000000 00000000007fffc0 0000000000000004
bb00: 0000000000000000 0000000000000040 000000000000003f 0000000000000000
bb20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
bb40: ffffffc078fe0960 0000000000000018 ffffffffffffffff 0008669628000000
[<ffffff80083a002c>] __memset+0x1ac/0x200
[<ffffff8008599814>] coresight_enable_path+0xa8/0x1dc
[<ffffff8008599b10>] coresight_enable+0x88/0x1b8
[<ffffff8008599d88>] enable_source_store+0x3c/0x6c
[<ffffff800845eaf4>] dev_attr_store+0x18/0x28
[<ffffff80082829e8>] sysfs_kf_write+0x54/0x64
[<ffffff8008281c30>] kernfs_fop_write+0x148/0x1d8
[<ffffff8008200128>] __vfs_write+0x28/0x110
[<ffffff8008200e88>] vfs_write+0xa0/0x198
[<ffffff80082021b0>] SyS_write+0x44/0xa0
[<ffffff8008084e70>] el0_svc_naked+0x24/0x28
Code: 91010108 54ffff4a 8b040108 cb050042 (d50b7428)

This patch fixes the issue by clearing the drvdata->vaddr while we free
the allocated buffer at the end of a session, so that we allocate the
memory again.

Cc: mathieu.poirier@linaro.org
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

coresight: Fix NULL pointer dereference in _coresight_build_path

_coresight_build_path assumes that all the connections of a csdev
has the child_dev initialised. This may not be true if the particular
component is not supported by the kernel config(e.g TPIU) but is
present in the DT. In which case, building a path can cause a crash like this :

  Unable to handle kernel NULL pointer dereference at virtual address 00000010
  pgd = ffffffc9750dd000
  [00000010] *pgd=00000009f5e90003, *pud=00000009f5e90003, *pmd=0000000000000000
  Internal error: Oops: 96000006 [#1] PREEMPT SMP
  Modules linked in:
  CPU: 4 PID: 1348 Comm: bash Not tainted 4.6.0-next-20160517 #1646
  Hardware name: ARM Juno development board (r0) (DT)
  task: ffffffc97517a280 ti: ffffffc9762c4000 task.ti: ffffffc9762c4000
  PC is at _coresight_build_path+0x18/0xe4
  LR is at _coresight_build_path+0xc0/0xe4
  pc : [<ffffff80083d5130>] lr : [<ffffff80083d51d8>] pstate: 20000145
  sp : ffffffc9762c7ba0

  [<ffffff80083d5130>] _coresight_build_path+0x18/0xe4
  [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4
  [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4
  [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4
  [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4
  [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4
  [<ffffff80083d5cdc>] coresight_build_path+0x40/0x68
  [<ffffff80083d5e14>] coresight_enable+0x74/0x1bc
  [<ffffff80083d60a0>] enable_source_store+0x3c/0x6c
  [<ffffff800830b17c>] dev_attr_store+0x18/0x28
  [<ffffff80081ca9c4>] sysfs_kf_write+0x40/0x50
  [<ffffff80081c9e38>] kernfs_fop_write+0x140/0x1cc
  [<ffffff8008163ec8>] __vfs_write+0x28/0x110
  [<ffffff8008164bf0>] vfs_write+0xa0/0x174
  [<ffffff8008165d18>] SyS_write+0x44/0xa0
  [<ffffff8008084e70>] el0_svc_naked+0x24/0x28

Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'extcon-fixes-for-4.7-rc4' of git://git./linux/kernel/git/chanwoo/extcon into char-misc-linus

Chanwoo writes:

Update extcon for v4.7-rc4

This patch fixes the following issue:
- In the extcon-palmas.c, fix the state of VBUS when using GPIO detection.
If probe funticon don't check the state during probe, the extcon client
driver cannot get the state of VBUS gpio until the user detach the connector
and attach the connector again.

Merge tag 'drm-fixes-for-v4.7-rc4' of git://people.freedesktop.org/~airlied/linux

Pull drm fixes from Dave Airlie:
 "The main drm fixes pull for rc4: one regression fix in the connector
  refcounting, and an MST fix.

  There rest is nouveau, amdkfd, i915, etnaviv, and radeon/amdgpu fixes,
  mostly regression or black screen fixes"

* tag 'drm-fixes-for-v4.7-rc4' of git://people.freedesktop.org/~airlied/linux: (23 commits)
  drm/etnaviv: initialize iommu domain page size
  drm/nouveau/iccsense: fix memory leak
  drm/nouveau/Revert "drm/nouveau/device/pci: set as non-CPU-coherent on ARM64"
  drm/amd/powerplay: select samu dpm 0 as boot level on polaris.
  drm/amd/powerplay: update powerplay table parsing
  drm/dp/mst: Always clear proposed vcpi table for port.
  drm/crtc: only store the necessary data for set_config rollback
  drm/crtc: fix connector reference counting mismatch in drm_crtc_helper_set_config
  drm/i915/ilk: Don't disable SSC source if it's in use
  Revert "drm/amdgpu: add pipeline sync while vmid switch in same ctx"
  drm/amdgpu/gfx7: fix broken condition check
  drm/radeon: fix asic initialization for virtualized environments
  amdgpu: fix asic initialization for virtualized environments (v2)
  drm/radeon: don't use fractional dividers on RS[78]80 if SS is enabled
  drm/radeon: do not hard reset GPU while freezing on r600/r700 family
  drm/i915: Extract physical display dimensions from VBT
  drm/i915: Check VBT for port presence in addition to the strap on VLV/CHV
  drm/i915: Only ignore eDP ports that are connected
  drm/i915: Silence "unexpected child device config size" for VBT on 845g
  drm/i915: Fix NULL pointer deference when out of PLLs in IVB
  ...

Merge tag 'platform-drivers-x86-v4.7-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86

Pull x86 platform driver fixes from Darren Hart:
 "Minor kconfig dependency cleanup, trivial mic mute hotkey for ideapad,
  and a needed improvement in adaptive keyboard detection for thinkpad:

  platform/x86:
   - Drop duplicate dependencies on X86

  thinkpad_acpi:
   - Add support for HKEY version 0x200

  ideapad_laptop:
   - Add an event for mic mute hotkey"

* tag 'platform-drivers-x86-v4.7-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86:
  platform/x86: Drop duplicate dependencies on X86
  thinkpad_acpi: Add support for HKEY version 0x200
  ideapad_laptop: Add an event for mic mute hotkey