UBUNTU: Start new release

Ignore: yes
UBUNTU: [Config] updateconfigs to balance CONFIG_SCOM_DEBUGFS

Signed-off-by: Andy Whitcroft <apw@canonical.com>
ath3k: Add support of MCI 13d3:3408 bt device

BugLink: http://bugs.launchpad.net/bugs/1395465

Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>

Acked-by: Chris J Arges <chris.j.arges@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
x86: kvm: use alternatives for VMCALL vs. VMMCALL if kernel text is read-only

BugLink: http://bugs.launchpad.net/bugs/1379340

On x86_64, kernel text mappings are mapped read-only with CONFIG_DEBUG_RODATA.
In that case, KVM will fail to patch VMCALL instructions to VMMCALL
as required on AMD processors.

The failure mode is currently a divide-by-zero exception, which obviously
is a KVM bug that has to be fixed.  However, picking the right instruction
between VMCALL and VMMCALL will be faster and will help if you cannot upgrade
the hypervisor.

Reported-by: Chris Webb <chris@arachsys.com>
Tested-by: Chris Webb <chris@arachsys.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(backported from commit c1118b3602c2329671ad5ec8bdf8e374323d6343)
Conflicts:
	arch/x86/include/asm/cpufeature.h
Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Revert "arm64: Make default dma_ops to be noncoherent"

This reverts commit c7a4a7658d689f664050c45493d79adf053f226e.

Conflicts:
	arch/arm64/mm/dma-mapping.c

On ARM64, Utopic kernel ships APM's PCI host controller driver
which isn't upstreamed yet, and APM's ARM64 Soc is a coherent
platform. On the other side, ARM64 maintainer[1] said the
commit c7a4a7658 can be reverted safely if booting with ACPI
which can be supported by APM's own kernel release too.

So please revert the commit c7a4a7658 to avoid breaking
PCI function on APM ARM64.

BugLink: https://bugs.launchpad.net/bugs/1386490

[1] http://marc.info/?l=linux-arm-kernel&m=141708838404470&w=2

Cc: Dann Frazier <dann.frazier@canonical.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
cpufreq: Allow stop CPU callback to be used by all cpufreq drivers

BugLink: http://bugs.launchpad.net/bugs/1397928

Commit 367dc4aa932bfb3 ("cpufreq: Add stop CPU callback to
cpufreq_driver interface") introduced the stop CPU callback for
intel_pstate drivers. During the CPU_DOWN_PREPARE stage, this
callback is invoked so that drivers can take some action on the
pstate of the cpu before it is taken offline. This callback was
assumed to be useful only for those drivers which have implemented
the set_policy CPU callback because they have no other way to take
action about the cpufreq of a CPU which is being hotplugged out
except in the exit callback which is called very late in the offline
process.

The drivers which implement the target/target_index callbacks were
expected to take care of requirements like the ones that commit
367dc4aa addresses in the GOV_STOP notification event. But there
are disadvantages to restricting the usage of stop CPU callback
to cpufreq drivers that implement the set_policy callbacks and who
want to take explicit action on the setting the cpufreq during a
hotplug operation.

1.GOV_STOP gets called for every CPU offline and drivers would usually
want to take action when the last cpu in the policy->cpus mask
is taken offline. As long as there is more than one cpu in the
policy->cpus mask, cpufreq core itself makes sure that the freq
for the other cpus in this mask is set according to the maximum load.
This is sensible and drivers which implement the target_index callback
would mostly not want to modify that. However the cpufreq core leaves a
loose end when the cpu in the policy->cpus mask is the last one to go offline;
it does nothing explicit to the frequency of the core. Drivers may need
a way to take some action here and stop CPU callback mechanism is the
best way to do it today.

2. We cannot implement driver specific actions in the GOV_STOP mechanism.
So we will need another driver callback which is invoked from here which is
unnecessary.

Therefore this patch extends the usage of stop CPU callback to be used
by all cpufreq drivers as long as they have this callback implemented
and irrespective of whether they are set_policy/target_index drivers.
The assumption is if the drivers find the GOV_STOP path to be a suitable
way of implementing what they want to do with the freq of the cpu
going offine,they will not implement the stop CPU callback at all.

Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(backported from commit 789ca243740de236a39146fc3d3bbaeb4d3ae0ba)
Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>

Conflicts:
	drivers/cpufreq/cpufreq.c
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
cpufreq: powernv: Set the pstate of the last hotplugged out cpu in policy->cpus to minimum

BugLink: http://bugs.launchpad.net/bugs/1397928

Its possible today that the pstate of a core is held at a high even after the
entire core is hotplugged out if a load had just run on  the hotplugged cpu. This is
fair, since it is assumed that the pstate does not matter to a cpu in a deep idle
state, which is the expected state of a hotplugged core on powerpc. However on powerpc,
the pstate at a socket level is held at the maximum of the pstates of each core. Even
if the pstates of the active cores on that socket is low, the socket pstate is held
high due to the pstate of the hotplugged core in the above mentioned scenario. This
can cost significant amount of power loss for no good.

Besides, since it is a non active core, nothing can be done from the kernel's end
to set the frequency of the core right. Hence make use of the stop_cpu callback
to explicitly set the pstate of the core to a minimum when the last cpu of the
core gets hotplugged out.

Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit b120339c787b243cdbe3f67401b4aa5625d88ff3)
Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
cpufreq: powernv: Set the cpus to nominal frequency during reboot/kexec

BugLink: http://bugs.launchpad.net/bugs/1397928

This patch ensures the cpus to kexec/reboot at nominal frequency.
Nominal frequency is the highest cpu frequency on PowerPC at
which the cores can run without getting throttled.

If the host kernel had set the cpus to a low pstate and then it
kexecs/reboots to a cpufreq disabled kernel it would cause the target
kernel to perform poorly. It will also increase the boot up time of
the target kernel. So set the cpus to high pstate, in this case to
nominal frequency before rebooting to avoid such scenarios.

The reboot notifier will set the cpus to nominal frequncy.

Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Reviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit cf30af76952b0cb20c4a2cf8db16d69ca59eb652)
Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
UBUNTU: [Config] armhf: VIRTIO_[BALLOON|MMIO]=y

Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Revert "UBUNTU: SAUCE: (no-up) arm64: optimized copy_to_user and copy_from_user assembly code"

This reverts commit fc0e1695548bbd13a2fb12f5de87f23af8ee69de.

BugLink: http://bugs.launchpad.net/bugs/1398596
Acked-by: Chris J Arges <chris.j.arges@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
xen-netfront: Remove BUGs on paged skb data which crosses a page boundary

These BUGs can be erroneously triggered by frags which refer to
tail pages within a compound page. The data in these pages may
overrun the hardware page while still being contained within the
compound page, but since compound_order() evaluates to 0 for tail
pages the assertion fails. The code already iterates through
subsequent pages correctly in this scenario, so the BUGs are
unnecessary and can be removed.

Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit")
Cc: <stable@vger.kernel.org> # 3.7+
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 8d609725d4357f499e2103e46011308b32f53513)
BugLink: http://bugs.launchpad.net/bugs/1275879
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
ACPI / blacklist: blacklist Win8 OSI for Dell Vostro 3546

BugLink: http://bugs.launchpad.net/bugs/1383589

The wireless hotkey of Dell Vostro 3546 does not work with Win8 OSI. Due
to insufficient documentation for the driver implementation, blacklist
it as a workaround.

Signed-off-by: Adam Lee <adam.lee@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 222584647f2821c4d68421c1d07c89b375d501b2)
Signed-off-by: Adam Lee <adam.lee@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Chris J Arges <chris.j.arges@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
iwlwifi: add device / firmware to fw-error-dump file

commit 06ddbf5adac1fd2a031eade8a92239abfa6db93a upstream.

This can be useful later for parsing since the parsing may
differ based on the device's family / bus.
Also add the human readable version of the firmware.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
BugLink: http://bugs.launchpad.net/bugs/1399440
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
iwlwifi: rename iwl_mvm_fw_error_next_data

commit 1fa1605648d15d42f350807279b6c6e8d33b6382 upstream.

This is not related to mvm. Rename to iwl_fw_error_next_data.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
BugLink: http://bugs.launchpad.net/bugs/1399440
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
iwlwifi: pcie: add firmware monitor capabilities

commit c2d202017da18ebd6567862bd9a50392970f048f upstream

This allows to use the firmware monitor. This capability
uses a lot of contiguous memory (up to 64MB), so make its
usage module parameter dependent.

The driver will try to allocate as much contiguous memory
as possible downgrading its requirements until the
allocation succeeds.

Dump this data into the fw-error dump file when an error
happens.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
BugLink: http://bugs.launchpad.net/bugs/1399440
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
iwlwifi: remove wrong comment about alignment in iwl-fw-error-dump.h

commit d4849277f92a0bfa08a988545ea527fc8e0c9571 upstream.

The chunks of data do not need to be multipliers of 4 nor
4-bytes aligned.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
BugLink: http://bugs.launchpad.net/bugs/1399440
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
iwlwifi: mvm: don't collect logs in the interrupt thread

commit 78dae98fab85f4cd2d38cfc3474dea6e87e7b53a upstream.

Instead of reading all the data in the context of the
interrupt thread, collect the data in the restart flow
before the actual restart takes place so that the device
still has all the information.
Remove iwl_mvm_fw_error_sram_dump and move its content to
iwl_mvm_fw_error_dump.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
BugLink: http://bugs.launchpad.net/bugs/1399440
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
iwlwifi: mvm: kill iwl_mvm_fw_error_rxf_dump

commit 655e6d6db21b0c0d411aef9d816816fb68b0496c upstream.

Its content can move to the caller.
While at it, move iwl_mvm_fw_error_rxf_dump to caller.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
BugLink: http://bugs.launchpad.net/bugs/1399440
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
iwlwifi: mvm: update layout of firmware error dump

commit 5bfe6f53283de44855ee45a102210abbfac995f9 upstream.

The memory was not zeroed - fix that. Also update the
iwl_fw_error_dump_info structure.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
BugLink: http://bugs.launchpad.net/bugs/1399440
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
powerpc/pseries: Fix endiannes issue in RTAS call from xmon

BugLink: http://bugs.launchpad.net/bugs/1396235

On pseries system (LPAR) xmon failed to enter when running in LE mode,
system is hunging. Inititating xmon will lead to such an output on the
console:

SysRq : Entering xmon
cpu 0x15: Vector: 0  at [c0000003f39ffb10]
    pc: c00000000007ed7c: sysrq_handle_xmon+0x5c/0x70
    lr: c00000000007ed7c: sysrq_handle_xmon+0x5c/0x70
    sp: c0000003f39ffc70
   msr: 8000000000009033
  current = 0xc0000003fafa7180
  paca    = 0xc000000007d75e80	 softe: 0	 irq_happened: 0x01
    pid   = 14617, comm = bash
Bad kernel stack pointer fafb4b0 at eca7cc4
cpu 0x15: Vector: 300 (Data Access) at [c000000007f07d40]
    pc: 000000000eca7cc4
    lr: 000000000eca7c44
    sp: fafb4b0
   msr: 8000000000001000
   dar: 10000000
 dsisr: 42000000
  current = 0xc0000003fafa7180
  paca    = 0xc000000007d75e80	 softe: 0	 irq_happened: 0x01
    pid   = 14617, comm = bash
cpu 0x15: Exception 300 (Data Access) in xmon, returning to main loop
xmon: WARNING: bad recursive fault on cpu 0x15

The root cause is that xmon is calling RTAS to turn off the surveillance
when entering xmon, and RTAS is requiring big endian parameters.

This patch is byte swapping the RTAS arguments when running in LE mode.

Cc: stable@vger.kernel.org
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 3b8a3c01096925a824ed3272601082289d9c23a5)
Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>