Squash 'enhance power efficiency' patches

Series of patches from NVIDIA on some critical blocking
code paths to allow the CPU to relax instead of busy spinning
thus lowering the load_average and lowering power consumption.

Signed-off-by: Sumit Singh <sumsingh@nvidia.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
USB: storage: ene_ub6250: fix warning for the frame size

[-Wframe-larger-than=]

Change-Id: I19f9a88cfa151e932dab30ed6dd34f452340cb5b
USB: serial: fix potential stack buffer overflow

commit d979e9f9ecab04c1ecca741370e30a8a498893f5 upstream.

Make sure to verify the maximum number of endpoints per type to avoid
writing beyond the end of a stack-allocated array.

The current usb-serial implementation is limited to eight ports per
interface but failed to verify that the number of endpoints of a certain
type reported by a device did not exceed this limit.

Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
USB: serial: fix potential heap buffer overflow

commit 5654699fb38512bdbfc0f892ce54fce75bdc2bab upstream.

Make sure to verify the number of ports requested by subdriver to avoid
writing beyond the end of fixed-size array in interface data.

The current usb-serial implementation is limited to eight ports per
interface but failed to verify that the number of ports requested by a
subdriver (which could have been determined from device descriptors) did
not exceed this limit.

Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[lizf: Backported to 3.4: s/ddev/\&interface->dev/]
Signed-off-by: Zefan Li <lizefan@huawei.com>
USB: whiteheat: Added bounds checking for bulk command response

commit 6817ae225cd650fb1c3295d769298c38b1eba818 upstream.

This patch fixes a potential security issue in the whiteheat USB driver
which might allow a local attacker to cause kernel memory corrpution. This
is due to an unchecked memcpy into a fixed size buffer (of 64 bytes). On
EHCI and XHCI busses it's possible to craft responses greater than 64
bytes leading a buffer overflow.

Signed-off-by: James Forshaw <forshaw@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
Implement kexec-hardboot

"Allows hard booting (i.e., with a full hardware reboot) to a kernel
previously loaded in memory by kexec.  This works around the problem of
soft-booted kernel hangs due to improper device shutdown and/or
reinitialization."
More info in /arch/arm/Kconfig.

Original author: Mike Kasick <mike@kasick.org>

Vojtech Bocek <vbocek@gmail.com>:
  I've ported it to hammerhead, it is based of my mako/grouper port, which is
  based of Asus TF201 patch ported by Jens Andersen <jens.andersen@gmail.com>

  Hammerhead is the first device I've ported this patch to which uses
  device tree binary instead of atags. It is also rather picky - its
  bootloader erases first 128MB of RAM on reboot, so following hacks had
  to be applied:
  * Copy dtb to location passed in r2 before jumping to kexecd' kernel,
    the kernel would just freeze when I left dtb above 128MB of RAM.
  * Copy kexecd' kernel to location in the first 128MB before jumping to it,
    the decompressor operates very slowly if the kernel is above the cached
    area, copying it lower and decompressing it afterwards is much faster.

  Same as my mako/flo patches, the guest kernel does not require any
  modifications, kexec-hardboot is equivalent to standard kexec.

  To support dtb, following commit was backported from the mainline:
    commit 4cabd1d9625c7d88acd143f4021fbef75394f154
    Author: Matthew Leach <matthew.leach@arm.com>
    Date:   Fri Sep 21 18:56:02 2012 +0100

      ARM: 7539/1: kexec: scan for dtb magic in segments

      This patch allows a dtb to be passed to a new kernel using the kexec
      mechinism.

      When loading segments from userspace, scan each segment's first four
      bytes for the dtb magic. If this is found set the kexec_boot_atags
      parameter to the relocate_kernel code to the phyical address of this
      segment.

Davide Pianca <kingbabasula@gmail.com>:
  Ported from https://gist.github.com/Tasssadar/7833796
  Adapted for bacon
Enable kexec hardboot
Change KEXEC_HB_KERNEL_LOC

Reduces the boot speed on secondary ROM from 40 to 25 seconds