129978 Commits

Author SHA1 Message Date
Steven Rostedt (Red Hat)
8cf868affd tracing: Have the reg function allow to fail
Some tracepoints have a registration function that gets enabled when the
tracepoint is enabled. There may be cases that the registraction function
must fail (for example, can't allocate enough memory). In this case, the
tracepoint should also fail to register, otherwise the user would not know
why the tracepoint is not working.

Cc: David Howells <dhowells@redhat.com>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Cc: Anton Blanchard <anton@samba.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2016-12-09 09:13:30 -05:00
Shaohua Li
76ae054c69 x86/intel_rdt: Implement show_options() for resctrlfs
Implement show_options() callback for intel resource control filesystem
to expose the active mount options in /proc/

Signed-off-by: Shaohua Li <shli@fb.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Link: http://lkml.kernel.org/r/7dce7c1886ac9289442d254ea18322c92bd968da.1480717072.git.shli@fb.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2016-12-09 14:12:18 +01:00
Alex Thorlton
738662c35c xen/x86: Increase xen_e820_map to E820_X_MAX possible entries
On systems with sufficiently large e820 tables, and several IOAPICs, it
is possible for the XENMEM_machine_memory_map callback (and its
counterpart, XENMEM_memory_map) to attempt to return an e820 table with
more than 128 entries.  This callback adds entries to the BIOS-provided
e820 table to account for IOAPIC registers, which, on sufficiently large
systems, can result in an e820 table that is too large to copy back into
xen_e820_map.

This change simply increases the size of xen_e820_map to E820_X_MAX to
ensure that there is enough room to store the entire e820 map returned
from this callback.

Signed-off-by: Alex Thorlton <athorlton@sgi.com>
Suggested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Juergen Gross <jgross@suse.com>
2016-12-09 10:59:08 +01:00
Alex Thorlton
9d2f86c6ca x86: Make E820_X_MAX unconditionally larger than E820MAX
It's really not necessary to limit E820_X_MAX to 128 in the non-EFI
case.  This commit drops E820_X_MAX's dependency on CONFIG_EFI, so that
E820_X_MAX is always at least slightly larger than E820MAX.

The real motivation behind this is actually to prevent some issues in
the Xen kernel, where the XENMEM_machine_memory_map hypercall can
produce an e820 map larger than 128 entries, even on systems where the
original e820 table was quite a bit smaller than that, depending on how
many IOAPICs are installed on the system.

Signed-off-by: Alex Thorlton <athorlton@sgi.com>
Suggested-by: Ingo Molnar <mingo@redhat.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Juergen Gross <jgross@suse.com>
2016-12-09 10:59:04 +01:00
Markus Elfring
ad595b77c4 m68k/atari: Use seq_puts() in atari_get_hardware_list()
A string which did not contain a data format specification should be put
into a sequence. Thus use the corresponding function "seq_puts".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2016-12-09 08:52:29 +01:00
Markus Elfring
f2a0c53402 m68k/amiga: Use seq_puts() in amiga_get_hardware_list()
A string which did not contain a data format specification should be put
into a sequence. Thus use the corresponding function "seq_puts".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2016-12-09 08:52:29 +01:00
Linus Torvalds
a37102dcd7 Merge branch 'parisc-4.9-5' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
Pull parisc fixes from Helge Deller:
 "Three important fixes for the parisc architecture.

  Dave provided two patches: One which purges the TLB before setting a
  PTE entry and a second one which drops unnecessary TLB flushes. Both
  patches have been tested for one week on the debian buildd servers and
  prevent random segmentation faults.

  The patch from me fixes a crash at boot inside the TLB measuring code
  on SMP machines with PA8000-PA8700 CPUs (specifically A500-44 and
  J5000 servers)"

* 'parisc-4.9-5' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: Fix TLB related boot crash on SMP machines
  parisc: Remove unnecessary TLB purges from flush_dcache_page_asm and flush_icache_page_asm
  parisc: Purge TLB before setting PTE
2016-12-08 15:40:15 -08:00
Helge Deller
24d0492b7d parisc: Fix TLB related boot crash on SMP machines
At bootup we run measurements to calculate the best threshold for when we
should be using full TLB flushes instead of just flushing a specific amount of
TLB entries.  This performance test is run over the kernel text segment.

But running this TLB performance test on the kernel text segment turned out to
crash some SMP machines when the kernel text pages were mapped as huge pages.

To avoid those crashes this patch simply skips this test on some SMP machines
and calculates an optimal threshold based on the maximum number of available
TLB entries and number of online CPUs.

On a technical side, this seems to happen:
The TLB measurement code uses flush_tlb_kernel_range() to flush specific TLB
entries with a page size of 4k (pdtlb 0(sr1,addr)). On UP systems this purge
instruction seems to work without problems even if the pages were mapped as
huge pages.  But on SMP systems the TLB purge instruction is broadcasted to
other CPUs. Those CPUs then crash the machine because the page size is not as
expected.  C8000 machines with PA8800/PA8900 CPUs were not affected by this
problem, because the required cache coherency prohibits to use huge pages at
all.  Sadly I didn't found any documentation about this behaviour, so this
finding is purely based on testing with phyiscal SMP machines (A500-44 and
J5000, both were 2-way boxes).

Cc: <stable@vger.kernel.org> # v3.18+
Signed-off-by: Helge Deller <deller@gmx.de>
2016-12-08 21:27:18 +01:00
Martin KaFai Lau
17bedab272 bpf: xdp: Allow head adjustment in XDP prog
This patch allows XDP prog to extend/remove the packet
data at the head (like adding or removing header).  It is
done by adding a new XDP helper bpf_xdp_adjust_head().

It also renames bpf_helper_changes_skb_data() to
bpf_helper_changes_pkt_data() to better reflect
that XDP prog does not work on skb.

This patch adds one "xdp_adjust_head" bit to bpf_prog for the
XDP-capable driver to check if the XDP prog requires
bpf_xdp_adjust_head() support.  The driver can then decide
to error out during XDP_SETUP_PROG.

Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: John Fastabend <john.r.fastabend@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-08 14:25:13 -05:00
Roger Shimizu
038ccb3e8c ARM: dts: orion5x: fix number of sata port for linkstation ls-gl
Bug report from Debian [0] shows there's minor changed model of
Linkstation LS-GL that uses the 2nd SATA port of the SoC.
So it's necessary to enable two SATA ports, though for that specific
model only the 2nd one is used.

[0] https://bugs.debian.org/845611

Fixes: b1742ffa9ddb ("ARM: dts: orion5x: add device tree for buffalo linkstation ls-gl")
Reported-by: Ryan Tandy <ryan@nardis.ca>
Tested-by: Ryan Tandy <ryan@nardis.ca>
Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2016-12-08 10:19:24 -08:00
Petr Mladek
36da91bdf5 KVM: x86: Handle the kthread worker using the new API
Use the new API to create and destroy the "kvm-pit" kthread
worker. The API hides some implementation details.

In particular, kthread_create_worker() allocates and initializes
struct kthread_worker. It runs the kthread the right way
and stores task_struct into the worker structure.

kthread_destroy_worker() flushes all pending works, stops
the kthread and frees the structure.

This patch does not change the existing behavior except for
dynamically allocating struct kthread_worker and storing
only the pointer of this structure.

It is compile tested only because I did not find an easy
way how to run the code. Well, it should be pretty safe
given the nature of the change.

Signed-off-by: Petr Mladek <pmladek@suse.com>
Message-Id: <1476877847-11217-1-git-send-email-pmladek@suse.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-12-08 15:31:11 +01:00
Jan Dakinevich
16c2aec6a2 KVM: nVMX: invvpid handling improvements
- Expose all invalidation types to the L1

 - Reject invvpid instruction, if L1 passed zero vpid value to single
   context invalidations

Signed-off-by: Jan Dakinevich <jan.dakinevich@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-12-08 15:31:11 +01:00
Ladi Prosek
1dc35dacc1 KVM: nVMX: check host CR3 on vmentry and vmexit
This commit adds missing host CR3 checks. Before entering guest mode, the value
of CR3 is checked for reserved bits. After returning, nested_vmx_load_cr3 is
called to set the new CR3 value and check and load PDPTRs.

Signed-off-by: Ladi Prosek <lprosek@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2016-12-08 15:31:10 +01:00
Ladi Prosek
9ed38ffad4 KVM: nVMX: introduce nested_vmx_load_cr3 and call it on vmentry
Loading CR3 as part of emulating vmentry is different from regular CR3 loads,
as implemented in kvm_set_cr3, in several ways.

* different rules are followed to check CR3 and it is desirable for the caller
to distinguish between the possible failures
* PDPTRs are not loaded if PAE paging and nested EPT are both enabled
* many MMU operations are not necessary

This patch introduces nested_vmx_load_cr3 suitable for CR3 loads as part of
nested vmentry and vmexit, and makes use of it on the nested vmentry path.

Signed-off-by: Ladi Prosek <lprosek@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2016-12-08 15:31:10 +01:00
Ladi Prosek
ee146c1c10 KVM: nVMX: propagate errors from prepare_vmcs02
It is possible that prepare_vmcs02 fails to load the guest state. This
patch adds the proper error handling for such a case. L1 will receive
an INVALID_STATE vmexit with the appropriate exit qualification if it
happens.

A failure to set guest CR3 is the only error propagated from prepare_vmcs02
at the moment.

Signed-off-by: Ladi Prosek <lprosek@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2016-12-08 15:31:09 +01:00
Ladi Prosek
7ca29de213 KVM: nVMX: fix CR3 load if L2 uses PAE paging and EPT
KVM does not correctly handle L1 hypervisors that emulate L2 real mode with
PAE and EPT, such as Hyper-V. In this mode, the L1 hypervisor populates guest
PDPTE VMCS fields and leaves guest CR3 uninitialized because it is not used
(see 26.3.2.4 Loading Page-Directory-Pointer-Table Entries). KVM always
dereferences CR3 and tries to load PDPTEs if PAE is on. This leads to two
related issues:

1) On the first nested vmentry, the guest PDPTEs, as populated by L1, are
overwritten in ept_load_pdptrs because the registers are believed to have
been loaded in load_pdptrs as part of kvm_set_cr3. This is incorrect. L2 is
running with PAE enabled but PDPTRs have been set up by L1.

2) When L2 is about to enable paging and loads its CR3, we, again, attempt
to load PDPTEs in load_pdptrs called from kvm_set_cr3. There are no guarantees
that this will succeed (it's just a CR3 load, paging is not enabled yet) and
if it doesn't, kvm_set_cr3 returns early without persisting the CR3 which is
then lost and L2 crashes right after it enables paging.

This patch replaces the kvm_set_cr3 call with a simple register write if PAE
and EPT are both on. CR3 is not to be interpreted in this case.

Signed-off-by: Ladi Prosek <lprosek@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2016-12-08 15:31:09 +01:00
David Matlack
5a6a9748b4 KVM: nVMX: load GUEST_EFER after GUEST_CR0 during emulated VM-entry
vmx_set_cr0() modifies GUEST_EFER and "IA-32e mode guest" in the current
VMCS. Call vmx_set_efer() after vmx_set_cr0() so that emulated VM-entry
is more faithful to VMCS12.

This patch correctly causes VM-entry to fail when "IA-32e mode guest" is
1 and GUEST_CR0.PG is 0. Previously this configuration would succeed and
"IA-32e mode guest" would silently be disabled by KVM.

Signed-off-by: David Matlack <dmatlack@google.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2016-12-08 15:31:08 +01:00
David Matlack
8322ebbb24 KVM: nVMX: generate MSR_IA32_CR{0,4}_FIXED1 from guest CPUID
MSR_IA32_CR{0,4}_FIXED1 define which bits in CR0 and CR4 are allowed to
be 1 during VMX operation. Since the set of allowed-1 bits is the same
in and out of VMX operation, we can generate these MSRs entirely from
the guest's CPUID. This lets userspace avoiding having to save/restore
these MSRs.

This patch also initializes MSR_IA32_CR{0,4}_FIXED1 from the CPU's MSRs
by default. This is a saner than the current default of -1ull, which
includes bits that the host CPU does not support.

Signed-off-by: David Matlack <dmatlack@google.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2016-12-08 15:31:08 +01:00
David Matlack
3899152ccb KVM: nVMX: fix checks on CR{0,4} during virtual VMX operation
KVM emulates MSR_IA32_VMX_CR{0,4}_FIXED1 with the value -1ULL, meaning
all CR0 and CR4 bits are allowed to be 1 during VMX operation.

This does not match real hardware, which disallows the high 32 bits of
CR0 to be 1, and disallows reserved bits of CR4 to be 1 (including bits
which are defined in the SDM but missing according to CPUID). A guest
can induce a VM-entry failure by setting these bits in GUEST_CR0 and
GUEST_CR4, despite MSR_IA32_VMX_CR{0,4}_FIXED1 indicating they are
valid.

Since KVM has allowed all bits to be 1 in CR0 and CR4, the existing
checks on these registers do not verify must-be-0 bits. Fix these checks
to identify must-be-0 bits according to MSR_IA32_VMX_CR{0,4}_FIXED1.

This patch should introduce no change in behavior in KVM, since these
MSRs are still -1ULL.

Signed-off-by: David Matlack <dmatlack@google.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2016-12-08 15:31:07 +01:00
David Matlack
62cc6b9dc6 KVM: nVMX: support restore of VMX capability MSRs
The VMX capability MSRs advertise the set of features the KVM virtual
CPU can support. This set of features varies across different host CPUs
and KVM versions. This patch aims to addresses both sources of
differences, allowing VMs to be migrated across CPUs and KVM versions
without guest-visible changes to these MSRs. Note that cross-KVM-
version migration is only supported from this point forward.

When the VMX capability MSRs are restored, they are audited to check
that the set of features advertised are a subset of what KVM and the
CPU support.

Since the VMX capability MSRs are read-only, they do not need to be on
the default MSR save/restore lists. The userspace hypervisor can set
the values of these MSRs or read them from KVM at VCPU creation time,
and restore the same value after every save/restore.

Signed-off-by: David Matlack <dmatlack@google.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2016-12-08 15:31:07 +01:00
David Matlack
0115f9cbac KVM: nVMX: generate non-true VMX MSRs based on true versions
The "non-true" VMX capability MSRs can be generated from their "true"
counterparts, by OR-ing the default1 bits. The default1 bits are fixed
and defined in the SDM.

Since we can generate the non-true VMX MSRs from the true versions,
there's no need to store both in struct nested_vmx. This also lets
userspace avoid having to restore the non-true MSRs.

Note this does not preclude emulating MSR_IA32_VMX_BASIC[55]=0. To do so,
we simply need to set all the default1 bits in the true MSRs (such that
the true MSRs and the generated non-true MSRs are equal).

Signed-off-by: David Matlack <dmatlack@google.com>
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2016-12-08 15:31:06 +01:00
Kyle Huey
ea07e42dec KVM: x86: Do not clear RFLAGS.TF when a singlestep trap occurs.
The trap flag stays set until software clears it.

Signed-off-by: Kyle Huey <khuey@kylehuey.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2016-12-08 15:31:06 +01:00
Kyle Huey
6affcbedca KVM: x86: Add kvm_skip_emulated_instruction and use it.
kvm_skip_emulated_instruction calls both
kvm_x86_ops->skip_emulated_instruction and kvm_vcpu_check_singlestep,
skipping the emulated instruction and generating a trap if necessary.

Replacing skip_emulated_instruction calls with
kvm_skip_emulated_instruction is straightforward, except for:

- ICEBP, which is already inside a trap, so avoid triggering another trap.
- Instructions that can trigger exits to userspace, such as the IO insns,
  MOVs to CR8, and HALT. If kvm_skip_emulated_instruction does trigger a
  KVM_GUESTDBG_SINGLESTEP exit, and the handling code for
  IN/OUT/MOV CR8/HALT also triggers an exit to userspace, the latter will
  take precedence. The singlestep will be triggered again on the next
  instruction, which is the current behavior.
- Task switch instructions which would require additional handling (e.g.
  the task switch bit) and are instead left alone.
- Cases where VMLAUNCH/VMRESUME do not proceed to the next instruction,
  which do not trigger singlestep traps as mentioned previously.

Signed-off-by: Kyle Huey <khuey@kylehuey.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2016-12-08 15:31:05 +01:00
Kyle Huey
eb27756217 KVM: VMX: Move skip_emulated_instruction out of nested_vmx_check_vmcs12
We can't return both the pass/fail boolean for the vmcs and the upcoming
continue/exit-to-userspace boolean for skip_emulated_instruction out of
nested_vmx_check_vmcs, so move skip_emulated_instruction out of it instead.

Additionally, VMENTER/VMRESUME only trigger singlestep exceptions when
they advance the IP to the following instruction, not when they a) succeed,
b) fail MSR validation or c) throw an exception. Add a separate call to
skip_emulated_instruction that will later not be converted to the variant
that checks the singlestep flag.

Signed-off-by: Kyle Huey <khuey@kylehuey.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2016-12-08 15:31:04 +01:00
Kyle Huey
09ca3f2049 KVM: VMX: Reorder some skip_emulated_instruction calls
The functions being moved ahead of skip_emulated_instruction here don't
need updated IPs, and skipping the emulated instruction at the end will
make it easier to return its value.

Signed-off-by: Kyle Huey <khuey@kylehuey.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2016-12-08 15:31:04 +01:00
Kyle Huey
6a908b628c KVM: x86: Add a return value to kvm_emulate_cpuid
Once skipping the emulated instruction can potentially trigger an exit to
userspace (via KVM_GUESTDBG_SINGLESTEP) kvm_emulate_cpuid will need to
propagate a return value.

Signed-off-by: Kyle Huey <khuey@kylehuey.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2016-12-08 15:31:03 +01:00
Simon Horman
8ebcb400af arm64: dts: h3ulcb: Provide sd0_uhs node
Provide separaate sd0 and sd0_uhs nodes rather than duplicate sd0 nodes.

Cc: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Fixes: 93373c309a70 ("arm64: dts: h3ulcb: rename SDHI0 pins")
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2016-12-08 14:29:17 +01:00
Paul Bolle
8f50f2a1b4 cris: No need to append -O2 and $(LINUXINCLUDE)
The make variables asflags-y and ccflags-y are appended with -O2 and
$(LINUXINCLUDE). But the build already picks up -O2 from the top Makefile
and $(LINUXINCLUDE) from scripts/Makefile.lib. The net effect is that -O2
and the (long) list of include directories are used twice.

This is harmless but pointless. So stop appending to these flags.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Jesper Nilsson <jespern@axis.com>
2016-12-08 10:56:40 +01:00
Konrad Rzeszutek Wilk
577f79e411 xen/pci: Bubble up error and fix description.
The function is never called under PV guests, and only shows up
when MSI (or MSI-X) cannot be allocated. Convert the message
to include the error value.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
2016-12-08 07:54:04 +01:00
Alexandre Courbot
816c60c131 arm64: tegra: Add missing Smaug revision
The "google,smaug-rev2" string is missing from the compatible list of
Smaug's DT. The differences of rev2 are not relevant at our current
level of support and it boots just fine, so add it.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2016-12-08 00:23:34 +01:00
Alexandre Courbot
5e6b9a89af arm64: tegra: Add VDD_GPU regulator to Jetson TX1
Add the VDD_GPU regulator (a GPIO-enabled PWM regulator) to the Jetson
TX1 board. This addition allows the GPU to be used provided the
bootloader properly enabled the GPU node.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
[as pointed out by Thierry on IRC, nobody has reported a bug
 in the field, but using a new bootloader with a .dtb that
 has the incorrect data, it will crash on boot]
Fixes: 336f79c7b6d7 ("arm64: tegra: Add NVIDIA Jetson TX1 Developer Kit support")
Cc: stable@vger.kernel.org #v4.5+
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2016-12-08 00:23:33 +01:00
Julien Grall
24d5373dda arm/xen: Use alloc_percpu rather than __alloc_percpu
The function xen_guest_init is using __alloc_percpu with an alignment
which are not power of two.

However, the percpu allocator never supported alignments which are not power
of two and has always behaved incorectly in thise case.

Commit 3ca45a4 "percpu: ensure requested alignment is power of two"
introduced a check which trigger a warning [1] when booting linux-next
on Xen. But in reality this bug was always present.

This can be fixed by replacing the call to __alloc_percpu with
alloc_percpu. The latter will use an alignment which are a power of two.

[1]

[    0.023921] illegal size (48) or align (48) for percpu allocation
[    0.024167] ------------[ cut here ]------------
[    0.024344] WARNING: CPU: 0 PID: 1 at linux/mm/percpu.c:892 pcpu_alloc+0x88/0x6c0
[    0.024584] Modules linked in:
[    0.024708]
[    0.024804] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.9.0-rc7-next-20161128 #473
[    0.025012] Hardware name: Foundation-v8A (DT)
[    0.025162] task: ffff80003d870000 task.stack: ffff80003d844000
[    0.025351] PC is at pcpu_alloc+0x88/0x6c0
[    0.025490] LR is at pcpu_alloc+0x88/0x6c0
[    0.025624] pc : [<ffff00000818e678>] lr : [<ffff00000818e678>]
pstate: 60000045
[    0.025830] sp : ffff80003d847cd0
[    0.025946] x29: ffff80003d847cd0 x28: 0000000000000000
[    0.026147] x27: 0000000000000000 x26: 0000000000000000
[    0.026348] x25: 0000000000000000 x24: 0000000000000000
[    0.026549] x23: 0000000000000000 x22: 00000000024000c0
[    0.026752] x21: ffff000008e97000 x20: 0000000000000000
[    0.026953] x19: 0000000000000030 x18: 0000000000000010
[    0.027155] x17: 0000000000000a3f x16: 00000000deadbeef
[    0.027357] x15: 0000000000000006 x14: ffff000088f79c3f
[    0.027573] x13: ffff000008f79c4d x12: 0000000000000041
[    0.027782] x11: 0000000000000006 x10: 0000000000000042
[    0.027995] x9 : ffff80003d847a40 x8 : 6f697461636f6c6c
[    0.028208] x7 : 6120757063726570 x6 : ffff000008f79c84
[    0.028419] x5 : 0000000000000005 x4 : 0000000000000000
[    0.028628] x3 : 0000000000000000 x2 : 000000000000017f
[    0.028840] x1 : ffff80003d870000 x0 : 0000000000000035
[    0.029056]
[    0.029152] ---[ end trace 0000000000000000 ]---
[    0.029297] Call trace:
[    0.029403] Exception stack(0xffff80003d847b00 to
                               0xffff80003d847c30)
[    0.029621] 7b00: 0000000000000030 0001000000000000
ffff80003d847cd0 ffff00000818e678
[    0.029901] 7b20: 0000000000000002 0000000000000004
ffff000008f7c060 0000000000000035
[    0.030153] 7b40: ffff000008f79000 ffff000008c4cd88
ffff80003d847bf0 ffff000008101778
[    0.030402] 7b60: 0000000000000030 0000000000000000
ffff000008e97000 00000000024000c0
[    0.030647] 7b80: 0000000000000000 0000000000000000
0000000000000000 0000000000000000
[    0.030895] 7ba0: 0000000000000035 ffff80003d870000
000000000000017f 0000000000000000
[    0.031144] 7bc0: 0000000000000000 0000000000000005
ffff000008f79c84 6120757063726570
[    0.031394] 7be0: 6f697461636f6c6c ffff80003d847a40
0000000000000042 0000000000000006
[    0.031643] 7c00: 0000000000000041 ffff000008f79c4d
ffff000088f79c3f 0000000000000006
[    0.031877] 7c20: 00000000deadbeef 0000000000000a3f
[    0.032051] [<ffff00000818e678>] pcpu_alloc+0x88/0x6c0
[    0.032229] [<ffff00000818ece8>] __alloc_percpu+0x18/0x20
[    0.032409] [<ffff000008d9606c>] xen_guest_init+0x174/0x2f4
[    0.032591] [<ffff0000080830f8>] do_one_initcall+0x38/0x130
[    0.032783] [<ffff000008d90c34>] kernel_init_freeable+0xe0/0x248
[    0.032995] [<ffff00000899a890>] kernel_init+0x10/0x100
[    0.033172] [<ffff000008082ec0>] ret_from_fork+0x10/0x50

Reported-by: Wei Chen <wei.chen@arm.com>
Link: https://lkml.org/lkml/2016/11/28/669
Signed-off-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Cc: stable@vger.kernel.org
2016-12-07 13:23:15 -08:00
Stefan Agner
4b707fa00a ARM: dts: imx7d: fix LCDIF clock assignment
The eLCDIF IP of the i.MX 7 SoC knows multiple clocks and lists them
separately:

Clock      Clock Root              Description
apb_clk    MAIN_AXI_CLK_ROOT       AXI clock
pix_clk    LCDIF_PIXEL_CLK_ROOT    Pixel clock
ipg_clk_s  MAIN_AXI_CLK_ROOT       Peripheral access clock

All of them are switched by a single gate, which is part of the
IMX7D_LCDIF_PIXEL_ROOT_CLK clock. Hence using that clock also for
the AXI bus clock (clock-name "axi") makes sure the gate gets
enabled when accessing registers.

There seem to be no separate AXI display clock, and the clock is
optional. Hence remove the dummy clock.

This fixes kernel freezes when starting the X-Server (which
disables/re-enables the display controller).

Fixes: e8ed73f691bd ("ARM: dts: imx7d: add lcdif support")
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
2016-12-07 12:52:07 -08:00
Jorik Jonker
4367c1d846 dts: sun8i-h3: correct UART3 pin definitions
In a previous commit, I made a copy/paste error in the pinmux
definitions of UART3: PG{13,14} instead of PA{13,14}. This commit takes
care of that. I have tested this commit on Orange Pi PC and Orange Pi
Plus, and it works for these boards.

Fixes: e3d11d3c45c5 ("dts: sun8i-h3: add pinmux definitions for
UART2-3")

Signed-off-by: Jorik Jonker <jorik@kippendief.biz>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
2016-12-07 12:40:32 -08:00
Olof Johansson
8237c0b957 arm: Xilinx Zynq dt patches for v4.10
- Remove skeleton.dtsi
 - Fix DTC warnings
 - Coding style changes
 - Microzed support
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iEYEABECAAYFAlhGs0YACgkQykllyylKDCFxKQCfb0fzHzG4hUPQrByM0lk8CYJy
 5AMAniRgQNDaVFds5SCGXhFzNqS90PMa
 =RK/x
 -----END PGP SIGNATURE-----

Merge tag 'zynq-dt-for-4.10' of https://github.com/Xilinx/linux-xlnx into next/dt

arm: Xilinx Zynq dt patches for v4.10

- Remove skeleton.dtsi
- Fix DTC warnings
- Coding style changes
- Microzed support

* tag 'zynq-dt-for-4.10' of https://github.com/Xilinx/linux-xlnx:
  arm: dts: zynq: Add MicroZed board support
  ARM: zynq: Fix pmu register description coding style
  ARM: zynq: Fix W=1 dtc 1.4 warnings
  ARM: zynq: Remove skeleton.dtsi

Signed-off-by: Olof Johansson <olof@lixom.net>
2016-12-07 12:38:43 -08:00
Olof Johansson
44c29b83de arm: Xilinx Zynq patches for v4.10
- Fix dma issue
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iEYEABECAAYFAlhGsk8ACgkQykllyylKDCFJlQCeKhBp/gd/4EEuxT0ovvcWqeoS
 W30An2dhQX9/6MpJT+sLiR09RUzngdFI
 =PvhL
 -----END PGP SIGNATURE-----

Merge tag 'zynq-soc-for-4.10' of https://github.com/Xilinx/linux-xlnx into next/soc

arm: Xilinx Zynq patches for v4.10

- Fix dma issue

* tag 'zynq-soc-for-4.10' of https://github.com/Xilinx/linux-xlnx:
  ARM: zynq: Reserve correct amount of non-DMA RAM

Signed-off-by: Olof Johansson <olof@lixom.net>
2016-12-07 12:35:46 -08:00
Olof Johansson
9f793ef32f Enable support for MUSB based USB OTG on DA850.
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJYRTpjAAoJEGFBu2jqvgRN7dUP/2iS6bTJcVAEMxlJexIHI/bQ
 8jH5WoltdAqAIFfyZ++6y+W3VhEev4Lu5VP5e2kLG2lYpPurlv1nXrNatT67pyW8
 DOMiekzAvSsI1PGYzLq5WV/+dDzTYO/hAPY+JqzZhgYMJtBQJxLINCdRkilnHW7C
 2a5cElnpy4ADCjyVLOCAXe4D0SPpMqEEQBefVAbFGquKjwwl07tY06ATD0uMcKX7
 L0lyYPKVX9802UQDA/pp6ahJbaXZtfi2rOqVvIYh6qv28qdx97RbCshrVkeYRKa9
 Jm/4kWuUZ6mkZzWASXd4dS11XQheHdZCJr8d3DvsYgebcRBq+RKN/kVMkkilE42X
 IvrqfMGJXJRdx1C9DxAjVOMIqfLjO1wfEj3gZFtmGUZEPUKkGUqkdYfa/O1yxxzm
 DfJCoMNwEy4SQHhIf4uY2kPR0vhUcnTNeYIJl/9SCvXOyOXPWdBCh00ggTUJZkWB
 pv7Y/gcCj8E1kNF1rc9nBnFehAhR97cDw2/ZOC+8oMCkenpu/zN2Gm8UZigTyvkm
 Jw2tpbeaKYUPLyjtZMKuflnO4vy1RlW8CKLN8wwa3Saqf6YfPDamqsY/XFt53dV7
 QlF6wOjbMTTg6ZbxQWybiObDn+qcQurCuq6+Echwg1iPeNcU6TNxoEcQbgqpAnEv
 g8YUoh94v1kihLKK8wg8
 =SQob
 -----END PGP SIGNATURE-----

Merge tag 'davinci-for-v4.10/defconfig-4' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into next/defconfig

Enable support for MUSB based USB OTG on DA850.

* tag 'davinci-for-v4.10/defconfig-4' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci:
  ARM: davinci_all_defconfig: Enable da8xx usb otg

Signed-off-by: Olof Johansson <olof@lixom.net>
2016-12-07 12:35:06 -08:00
Olof Johansson
dd1551b650 - Add device tree nodes for pin pull-up/pull-down
bias control on DA850.
 
 - Enable high speed support on DA850 MMC/SD
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJYRTrHAAoJEGFBu2jqvgRNsk8P/1YZzdGQFXS/JU/09IczFulP
 ipYIhV6PdWzYY+yI4L/lFVUqQ9U7ty8CFPDyQuamgp/UpeFqocbVdWY91/kMi0Jr
 q3dmNtCC/UM3VeATEli66BiW28MfouW02ZBZWF533gTHb0VoJLaBZLitQzXlJlWg
 7cIr73BvyYpSvsSos4yXN94qPYpmjt0OIZtZdfJCLDqS91hTNrNNHtktIUn9U2qB
 SlnxIJ4Cfs0hG+cUCJD7u4HkA7XbUkx3Z9UBcbVsGJVQ/6E8x6pbam1vBvUJvp81
 aAMw5nmeMBK2xzI2AYjti64gMZTEnAKdYXwvQFuvCJ+i1oSvm5Sv2v0X4fJW5AVF
 iTW21sxruUHfYpbTn/NSQ2pAbMtgl23ythm5Utuhq52shfU1/Vtra6NDAPLsbR9H
 CvCd2Ao8NgQAcORSyEIKctcVflGjfcUhthVzR/K1TfGm5Y01yj7UvHQ6oXb0PDr0
 XW57XFPmYz0/c814Knb7zAKlMQG8dXqmbXWHjybyckxcl4f16055ZMo0crrus1lx
 kS5+ju3A+ZPcVcIbrkVEwKbCno06YpoTf1zxQOvhsCBrs1R6rXg8kMysABN4FvoA
 9BYEbZA15YiJHqG7AuoBFQ9kejVJgO+YFp20mc3dygVd6w1LgH7gNaCuqSyFPIqx
 axucAULZwTlhPcAFEfpr
 =w2Ug
 -----END PGP SIGNATURE-----

Merge tag 'davinci-for-v4.10/dt-4' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into next/dt

- Add device tree nodes for pin pull-up/pull-down
bias control on DA850.

- Enable high speed support on DA850 MMC/SD

* tag 'davinci-for-v4.10/dt-4' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci:
  ARM: dts: da850: enable high speed for mmc
  ARM: dts: da850: Add node for pullup/pulldown pinconf

Signed-off-by: Olof Johansson <olof@lixom.net>
2016-12-07 12:34:30 -08:00
Shawn Guo
253e80651e arm64: dts: zte: clean up gic-v3 redistributor properties
The gic-v3 property redistributor-stride is only meant as a workaround
for broken platforms that have a redistributor stride deviating what the
architecture defines, i.e. 128KiB for GICv3, 256KiB for GICv4.  This is
not the case for ZX296718, and redistributor-stride is not really
necessary.  Let's drop it.

Also, #redistributor-regions is only required when there is more than
one such region is present.  Let's remove it as well.

Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
2016-12-07 12:33:16 -08:00
Jun Nie
fe901d3578 arm64: dts: zx: Fix gic GICR property
GICR for multiple CPU can be described with start address and stride,
or with multiple address. Current multiple address and stride are
both used. Fix it.

vmalloc patch 727a7f5a9 triggered this bug:
[    0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
[    0.097150] pgd = ffff000008602000
[    0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
[    0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
[    0.097170] Modules linked in:
[    0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
[    0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
[    0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
[    0.097197] PC is at gic_populate_rdist+0x74/0x15c
[    0.097202] LR is at gic_starting_cpu+0xc/0x20
[    0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5

Signed-off-by: Jun Nie <jun.nie@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
2016-12-07 12:32:55 -08:00
Linus Torvalds
ea5a9eff96 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Ingo Molnar:
 "Misc fixes: a core dumping crash fix, a guess-unwinder regression fix,
  plus three build warning fixes"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/unwind: Fix guess-unwinder regression
  x86/build: Annotate die() with noreturn to fix build warning on clang
  x86/platform/olpc: Fix resume handler build warning
  x86/apic/uv: Silence a shift wrapping warning
  x86/coredump: Always use user_regs_struct for compat_elf_gregset_t
2016-12-07 11:39:27 -08:00
Thierry Reding
af099eab35 arm64: tegra: Enable PCIe on Jetson TX1
Enable the x4 PCIe and M.2 Key E slots on Jetson TX1. The Key E slot is
currently untested due to lack of hardware.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
2016-12-07 12:07:23 -06:00
Thierry Reding
589a2d3f18 arm64: tegra: Add PCIe host bridge on Tegra210
Add the PCIe host bridge found on Tegra X1. It implements two root ports
that support x4 and x1 configurations, respectively.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
2016-12-07 12:07:15 -06:00
Krzysztof Kozlowski
da6b21e97e ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
All Samsung platforms, including the Exynos, are selecting HZ_FIXED with
200 Hz.  Unfortunately in case of multiplatform image this affects also
other platforms when Exynos is enabled.

This looks like an very old legacy code, dating back to initial
upstreaming of S3C24xx.  Probably it was required for s3c24xx timer
driver, which was removed in commit ad38bdd15d5b ("ARM: SAMSUNG: Remove
unused plat-samsung/time.c").

Since then, this fixed 200 Hz spread everywhere, including out-of-tree
Samsung kernels (SoC vendor's and Tizen's).  I believe this choice
was rather an effect of coincidence instead of conscious choice.

On S3C24xx, the PWM counter is only 16 bit wide, and with the
typical 12MHz input clock that overflows every 5.5ms.  This works
with HZ=200 or higher but not with HZ=100 which needs a 10ms
interval between ticks.  On Later chips (S3C64xx, S5P and EXYNOS),
the counter is 32 bits and does not have this problem.

The new samsung_pwm_timer driver solves the problem by scaling the input
clock by a factor of 50 on S3C24xx, which makes it less accurate but
allows HZ=100 as well as CONFIG_NO_HZ with fewer wakeups.

Few perf mem and sched tests on Odroid XU3 board (Exynos5422, 4x Cortex
A7, 4x Cortex A15) show no regressions when switching from 200 Hz to
other values.

Reported-by: Lee Jones <lee.jones@linaro.org>
[Dropping of 200_HZ from S3C/S5P was suggested by Arnd]
Reported-by: Arnd Bergmann <arnd@arndb.de>
Cc: Kukjin Kim <kgene@kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
[Tested on Exynos5800]
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Kukjin Kim <kgene@kernel.org>
[Tested on S3C2440]
Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
2016-12-07 18:42:11 +02:00
Linus Walleij
eb485c7d9e Merge branch 'pl061' into devel 2016-12-07 15:23:45 +01:00
Linus Walleij
562b488443 gpio: pl061: move platform data into driver
No boardfile defines any PL061 platform data anymore: the
Integrator IM/PD-1 includes the file but is not making use
of the struct. Let's delete the include and all references,
then move the platform data into the driver for later
consolidation into the driver state container.

The only resource defined by the IM/PD-1 is the IRQ which
is passed through the AMBA PrimeCell bus abstraction
struct amba_device.

Cc: arm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-12-07 15:22:50 +01:00
Ard Biesheuvel
d0a3431a7b crypto: arm/crc32 - accelerated support based on x86 SSE implementation
This is a combination of the the Intel algorithm implemented using SSE
and PCLMULQDQ instructions from arch/x86/crypto/crc32-pclmul_asm.S, and
the new CRC32 extensions introduced for both 32-bit and 64-bit ARM in
version 8 of the architecture. Two versions of the above combo are
provided, one for CRC32 and one for CRC32C.

The PMULL/NEON algorithm is faster, but operates on blocks of at least
64 bytes, and on multiples of 16 bytes only. For the remaining input,
or for all input on systems that lack the PMULL 64x64->128 instructions,
the CRC32 instructions will be used.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-12-07 20:01:24 +08:00
Ard Biesheuvel
8fefde90e9 crypto: arm64/crc32 - accelerated support based on x86 SSE implementation
This is a combination of the the Intel algorithm implemented using SSE
and PCLMULQDQ instructions from arch/x86/crypto/crc32-pclmul_asm.S, and
the new CRC32 extensions introduced for both 32-bit and 64-bit ARM in
version 8 of the architecture. Two versions of the above combo are
provided, one for CRC32 and one for CRC32C.

The PMULL/NEON algorithm is faster, but operates on blocks of at least
64 bytes, and on multiples of 16 bytes only. For the remaining input,
or for all input on systems that lack the PMULL 64x64->128 instructions,
the CRC32 instructions will be used.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-12-07 20:01:22 +08:00
Ard Biesheuvel
1d481f1cd8 crypto: arm/crct10dif - port x86 SSE implementation to ARM
This is a transliteration of the Intel algorithm implemented
using SSE and PCLMULQDQ instructions that resides in the file
arch/x86/crypto/crct10dif-pcl-asm_64.S, but simplified to only
operate on buffers that are 16 byte aligned (but of any size)

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-12-07 20:01:21 +08:00
Ard Biesheuvel
6ef5737f39 crypto: arm64/crct10dif - port x86 SSE implementation to arm64
This is a transliteration of the Intel algorithm implemented
using SSE and PCLMULQDQ instructions that resides in the file
arch/x86/crypto/crct10dif-pcl-asm_64.S, but simplified to only
operate on buffers that are 16 byte aligned (but of any size)

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-12-07 20:01:17 +08:00