commit 83a5a29e61bc572110c0c4b8fc4e8d7838b8db53
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Aug 4 15:45:13 2013 +0800

    Linux 3.0.89

commit 71ee5d037bc9d215e06248642ea28b559b9440fa
Author: Ren Bigcren <bigcren.ren@sonymobile.com>
Date:   Tue Jul 2 13:34:30 2013 +0200

    USB: storage: Add MicroVault Flash Drive to unusual_devs
    
    commit e7a6121f4929c17215f0cdca3726f4bf3e4e9529 upstream.
    
    The device report an error capacity when read_capacity_16().
    Using read_capacity_10() can get the correct capacity.
    
    Signed-off-by: Ren Bigcren <bigcren.ren@sonymobile.com>
    Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
    Signed-off-by: Oskar Andero <oskar.andero@sonymobile.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5e9f97a04d86f9b4136d1be87d822df8e615f13
Author: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Date:   Wed Jul 3 15:02:40 2013 -0700

    mm/memory-hotplug: fix lowmem count overflow when offline pages
    
    commit cea27eb2a202959783f81254c48c250ddd80e129 upstream.
    
    The logic for the memory-remove code fails to correctly account the
    Total High Memory when a memory block which contains High Memory is
    offlined as shown in the example below.  The following patch fixes it.
    
    Before logic memory remove:
    
    MemTotal:        7603740 kB
    MemFree:         6329612 kB
    Buffers:           94352 kB
    Cached:           872008 kB
    SwapCached:            0 kB
    Active:           626932 kB
    Inactive:         519216 kB
    Active(anon):     180776 kB
    Inactive(anon):   222944 kB
    Active(file):     446156 kB
    Inactive(file):   296272 kB
    Unevictable:           0 kB
    Mlocked:               0 kB
    HighTotal:       7294672 kB
    HighFree:        5704696 kB
    LowTotal:         309068 kB
    LowFree:          624916 kB
    
    After logic memory remove:
    
    MemTotal:        7079452 kB
    MemFree:         5805976 kB
    Buffers:           94372 kB
    Cached:           872000 kB
    SwapCached:            0 kB
    Active:           626936 kB
    Inactive:         519236 kB
    Active(anon):     180780 kB
    Inactive(anon):   222944 kB
    Active(file):     446156 kB
    Inactive(file):   296292 kB
    Unevictable:           0 kB
    Mlocked:               0 kB
    HighTotal:       7294672 kB
    HighFree:        5181024 kB
    LowTotal:       4294752076 kB
    LowFree:          624952 kB
    
    [mhocko@suse.cz: fix CONFIG_HIGHMEM=n build]
    Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: <stable@vger.kernel.org>	[2.6.24+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Zhouping Liu <zliu@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27fe2c366213592a862d8f5160c606eded3947c7
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Sun Aug 4 15:43:40 2013 +0800

    virtio_net: fix race in RX VQ processing
    
    commit cbdadbbf0c790f79350a8f36029208944c5487d0 upstream
    
    virtio net called virtqueue_enable_cq on RX path after napi_complete, so
    with NAPI_STATE_SCHED clear - outside the implicit napi lock.
    This violates the requirement to synchronize virtqueue_enable_cq wrt
    virtqueue_add_buf.  In particular, used event can move backwards,
    causing us to lose interrupts.
    In a debug build, this can trigger panic within START_USE.
    
    Jason Wang reports that he can trigger the races artificially,
    by adding udelay() in virtqueue_enable_cb() after virtio_mb().
    
    However, we must call napi_complete to clear NAPI_STATE_SCHED before
    polling the virtqueue for used buffers, otherwise napi_schedule_prep in
    a callback will fail, causing us to lose RX events.
    
    To fix, call virtqueue_enable_cb_prepare with NAPI_STATE_SCHED
    set (under napi lock), later call virtqueue_poll with
    NAPI_STATE_SCHED clear (outside the lock).
    
    Reported-by: Jason Wang <jasowang@redhat.com>
    Tested-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [wg: Backported to 3.2]
    Signed-off-by: Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ff3d73133cb5a8a3514cc184152c553637e74a8
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Sun Aug 4 15:43:40 2013 +0800

    virtio: support unlocked queue poll
    
    commit cc229884d3f77ec3b1240e467e0236c3e0647c0c upstream.
    
    This adds a way to check ring empty state after enable_cb outside any
    locks. Will be used by virtio_net.
    
    Note: there's room for more optimization: caller is likely to have a
    memory barrier already, which means we might be able to get rid of a
    barrier here.  Deferring this optimization until we do some
    benchmarking.
    
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [wg: Backported to 3.2]
    Signed-off-by: Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b7b1cfac3b60be07d6b2ae8fe4db495de5883a6
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Fri Jul 19 15:51:58 2013 +0100

    xen/evtchn: avoid a deadlock when unbinding an event channel
    
    commit 179fbd5a45f0d4034cc6fd37b8d367a3b79663c4 upstream.
    
    Unbinding an event channel (either with the ioctl or when the evtchn
    device is closed) may deadlock because disable_irq() is called with
    port_user_lock held which is also locked by the interrupt handler.
    
    Think of the IOCTL_EVTCHN_UNBIND is being serviced, the routine has
    just taken the lock, and an interrupt happens. The evtchn_interrupt
    is invoked, tries to take the lock and spins forever.
    
    A quick glance at the code shows that the spinlock is a local IRQ
    variant. Unfortunately that does not help as "disable_irq() waits for
    the interrupt handler on all CPUs to stop running.  If the irq occurs
    on another VCPU, it tries to take port_user_lock and can't because
    the unbind ioctl is holding it." (from David). Hence we cannot
    depend on the said spinlock to protect us. We could make it a system
    wide IRQ disable spinlock but there is a better way.
    
    We can piggyback on the fact that the existence of the spinlock is
    to make get_port_user() checks be up-to-date. And we can alter those
    checks to not depend on the spin lock (as it's protected by u->bind_mutex
    in the ioctl) and can remove the unnecessary locking (this is
    IOCTL_EVTCHN_UNBIND) path.
    
    In the interrupt handler we cannot use the mutex, but we do not
    need it.
    
    "The unbind disables the irq before making the port user stale, so when
    you clear it you are guaranteed that the interrupt handler that might
    use that port cannot be running." (from David).
    
    Hence this patch removes the spinlock usage on the teardown path
    and piggybacks on disable_irq happening before we muck with the
    get_port_user() data. This ensures that the interrupt handler will
    never run on stale data.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    [v1: Expanded the commit description a bit]
    Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbb1314f28d3a5b561b9d3b7598ccf204f88472d
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Jul 20 03:13:55 2013 +0400

    livelock avoidance in sget()
    
    commit acfec9a5a892f98461f52ed5770de99a3e571ae2 upstream.
    
    Eric Sandeen has found a nasty livelock in sget() - take a mount(2) about
    to fail.  The superblock is on ->fs_supers, ->s_umount is held exclusive,
    ->s_active is 1.  Along comes two more processes, trying to mount the same
    thing; sget() in each is picking that superblock, bumping ->s_count and
    trying to grab ->s_umount.  ->s_active is 3 now.  Original mount(2)
    finally gets to deactivate_locked_super() on failure; ->s_active is 2,
    superblock is still ->fs_supers because shutdown will *not* happen until
    ->s_active hits 0.  ->s_umount is dropped and now we have two processes
    chasing each other:
    s_active = 2, A acquired ->s_umount, B blocked
    A sees that the damn thing is stillborn, does deactivate_locked_super()
    s_active = 1, A drops ->s_umount, B gets it
    A restarts the search and finds the same superblock.  And bumps it ->s_active.
    s_active = 2, B holds ->s_umount, A blocked on trying to get it
    ... and we are in the earlier situation with A and B switched places.
    
    The root cause, of course, is that ->s_active should not grow until we'd
    got MS_BORN.  Then failing ->mount() will have deactivate_locked_super()
    shut the damn thing down.  Fortunately, it's easy to do - the key point
    is that grab_super() is called only for superblocks currently on ->fs_supers,
    so it can bump ->s_count and grab ->s_umount first, then check MS_BORN and
    bump ->s_active; we must never increment ->s_count for superblocks past
    ->kill_sb(), but grab_super() is never called for those.
    
    The bug is pretty old; we would've caught it by now, if not for accidental
    exclusion between sget() for block filesystems; the things like cgroup or
    e.g. mtd-based filesystems don't have anything of that sort, so they get
    bitten.  The right way to deal with that is obviously to fix sget()...
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fcaa774ab8375516255249648af76ce16663b6a
Author: Rick Farina (Zero_Chaos) <zerochaos@gentoo.org>
Date:   Mon Jul 29 15:17:59 2013 -0400

    USB: serial: ftdi_sio: add more RT Systems ftdi devices
    
    commit fed1f1ed90bce42ea010e2904cbc04e7b8304940 upstream.
    
    RT Systems makes many usb serial cables based on the ftdi_sio driver for
    programming various amateur radios.  This patch is a full listing of
    their current product offerings and should allow these cables to all
    be recognized.
    
    Signed-off-by: Rick Farina (Zero_Chaos) <zerochaos@gentoo.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ec322493ae29932c23a20ad015921fe133b9ff8
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Jul 30 00:22:53 2013 -0400

    drm/radeon/atom: initialize more atom interpretor elements to 0
    
    commit 42a21826dc54583cdb79cc8477732e911ac9c376 upstream.
    
    The ProcessAuxChannel table on some rv635 boards assumes
    the divmul members are initialized to 0 otherwise we get
    an invalid fb offset since it has a bad mask set when
    setting the fb base.  While here initialize all the
    atom interpretor elements to 0.
    
    Fixes:
    https://bugzilla.kernel.org/show_bug.cgi?id=60639
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0d2313f66fea2e8a5286d5ccebb057810ad4e9b
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Jul 19 17:44:43 2013 -0400

    drm/radeon: improve dac adjust heuristics for legacy pdac
    
    commit 03ed8cf9b28d886c64c7e705c7bb1a365fd8fb95 upstream.
    
    Hopefully avoid more quirks in the future due to bogus
    vbios dac data.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 720c2af54ebce30c402581384e2287e66b4dee8c
Author: Mark Kettenis <kettenis@openbsd.org>
Date:   Sun Jul 21 16:44:09 2013 -0400

    drm/radeon: fix combios tables on older cards
    
    commit cef1d00cd56f600121ad121875655ad410a001b8 upstream.
    
    Noticed that my old Radeon 7500 hung after printing
    
       drm: GPU not posted. posting now...
    
    when it wasn't selected as the primary card the BIOS.  Some digging
    revealed that it was hanging in combios_parse_mmio_table() while
    parsing the ASIC INIT 3 table.  Looking at the BIOS ROM for the card,
    it becomes obvious that there is no ASIC INIT 3 table in the BIOS.
    The code is just processing random garbage.  No surprise it hangs!
    
    Why do I say that there is no ASIC INIT 3 table is the BIOS?  This
    table is found through the MISC INFO table.  The MISC INFO table can
    be found at offset 0x5e in the COMBIOS header.  But the header is
    smaller than that.  The COMBIOS header starts at offset 0x126.  The
    standard PCI Data Structure (the bit that starts with 'PCIR') lives at
    offset 0x180.  That means that the COMBIOS header can not be larger
    than 0x5a bytes and therefore cannot contain a MISC INFO table.
    
    I looked at a dozen or so BIOS images, some my own, some downloaded from:
    
        <http://www.techpowerup.com/vgabios/index.php?manufacturer=ATI&page=1>
    
    It is fairly obvious that the size of the COMBIOS header can be found
    at offset 0x6 of the header.  Not sure if it is a 16-bit number or
    just an 8-bit number, but that doesn't really matter since the tables
    seems to be always smaller than 256 bytes.
    
    So I think combios_get_table_offset() should check if the requested
    table is present.  This can be done by checking the offset against the
    size of the header.  See the diff below.  The diff is against the WIP
    OpenBSD codebase that roughly corresponds to Linux 3.8.13 at this
    point.  But I don't think this bit of the code changed much since
    then.
    
    For what it is worth:
    
    Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8673e4e2f9b08fd036cf9a088a9fe16d681b6ab7
Author: Toshi Kani <toshi.kani@hp.com>
Date:   Wed Jul 10 10:47:13 2013 -0600

    ACPI / memhotplug: Fix a stale pointer in error path
    
    commit d19f503e22316a84c39bc19445e0e4fdd49b3532 upstream.
    
    device->driver_data needs to be cleared when releasing its data,
    mem_device, in an error path of acpi_memory_device_add().
    
    The function evaluates the _CRS of memory device objects, and fails
    when it gets an unexpected resource or cannot allocate memory.  A
    kernel crash or data corruption may occur when the kernel accesses
    the stale pointer.
    
    Signed-off-by: Toshi Kani <toshi.kani@hp.com>
    Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a20b17ba9f0636e757ecbdbd79d460ff1fde0d0
Author: Anton Blanchard <anton@samba.org>
Date:   Mon Jul 15 14:04:50 2013 +1000

    powerpc/modules: Module CRC relocation fix causes perf issues
    
    commit 0e0ed6406e61434d3f38fb58aa8464ec4722b77e upstream.
    
    Module CRCs are implemented as absolute symbols that get resolved by
    a linker script. We build an intermediate .o that contains an
    unresolved symbol for each CRC. genksysms parses this .o, calculates
    the CRCs and writes a linker script that "resolves" the symbols to
    the calculated CRC.
    
    Unfortunately the ppc64 relocatable kernel sees these CRCs as symbols
    that need relocating and relocates them at boot. Commit d4703aef
    (module: handle ppc64 relocating kcrctabs when CONFIG_RELOCATABLE=y)
    added a hook to reverse the bogus relocations. Part of this patch
    created a symbol at 0x0:
    
    # head -2 /proc/kallsyms
    0000000000000000 T reloc_start
    c000000000000000 T .__start
    
    This reloc_start symbol is causing lots of confusion to perf. It
    thinks reloc_start is a massive function that stretches from 0x0 to
    0xc000000000000000 and we get various cryptic errors out of perf,
    including:
    
    problem incrementing symbol count, skipping event
    
    This patch removes the  reloc_start linker script label and instead
    defines it as PHYSICAL_START. We also need to wrap it with
    CONFIG_PPC64 because the ppc32 kernel can set a non zero
    PHYSICAL_START at compile time and we wouldn't want to subtract
    it from the CRCs in that case.
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Acked-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8ab3c8b69ba3922b06e077c39ffc4dbcbeabe64
Author: Tejun Heo <tj@kernel.org>
Date:   Mon Jul 22 16:53:36 2013 -0400

    libata: make it clear that sata_inic162x is experimental
    
    commit bb9696192826a7d9279caf872e95b41bc26c7eff upstream.
    
    sata_inic162x never reached a state where it's reliable enough for
    production use and data corruption is a relatively common occurrence.
    Make the driver generate warning about the issues and mark the Kconfig
    option as experimental.
    
    If the situation doesn't improve, we'd be better off making it depend
    on CONFIG_BROKEN.  Let's wait for several cycles and see if the kernel
    message draws any attention.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Martin Braure de Calignon <braurede@free.fr>
    Reported-by: Ben Hutchings <ben@decadent.org.uk>
    Reported-by: risc4all@yahoo.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbe048b2eebb75f9b5c17b0d948fe5a8ec396cc5
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Mon Jul 8 13:36:19 2013 +0100

    staging: comedi: COMEDI_CANCEL ioctl should wake up read/write
    
    commit 69acbaac303e8cb948801a9ddd0ac24e86cc4a1b upstream.
    
    Comedi devices can do blocking read() or write() (or poll()) if an
    asynchronous command has been set up, blocking for data (for read()) or
    buffer space (for write()).  Various events associated with the
    asynchronous command will wake up the blocked reader or writer (or
    poller).  It is also possible to force the asynchronous command to
    terminate by issuing a `COMEDI_CANCEL` ioctl.  That shuts down the
    asynchronous command, but does not currently wake up the blocked reader
    or writer (or poller).  If the blocked task could be woken up, it would
    see that the command is no longer active and return.  The caller of the
    `COMEDI_CANCEL` ioctl could attempt to wake up the blocked task by
    sending a signal, but that's a nasty workaround.
    
    Change `do_cancel_ioctl()` to wake up the wait queue after it returns
    from `do_cancel()`.  `do_cancel()` can propagate an error return value
    from the low-level comedi driver's cancel routine, but it always shuts
    the command down regardless, so `do_cancel_ioctl()` can wake up he wait
    queue regardless of the return value from `do_cancel()`.
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94c3bbaf01202674a406d075429513e321a5b236
Author: William Gulland <wgulland@google.com>
Date:   Thu Jun 27 16:10:20 2013 -0700

    usb: Clear both buffers when clearing a control transfer TT buffer.
    
    commit 2c7b871b9102c497ba8f972aa5d38532f05b654d upstream.
    
    Control transfers have both IN and OUT (or SETUP) packets, so when
    clearing TT buffers for a control transfer it's necessary to send
    two HUB_CLEAR_TT_BUFFER requests to the hub.
    
    Signed-off-by: William Gulland <wgulland@google.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54b404671f9535d0bd6bf388686cc5f8ee245c36
Author: Jóhann B. Guðmundsson <johannbg@fedoraproject.org>
Date:   Thu Jul 4 21:47:52 2013 +0000

    USB: misc: Add Manhattan Hi-Speed USB DVI Converter to sisusbvga
    
    commit 58fc90db8261b571c026bb8bf23aad48a7233118 upstream.
    
    Signed-off-by: Jóhann B. Guðmundsson <johannbg@fedoraproject.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd8f7d2c00c7ac86c9aa50fc73427009993cec03
Author: Johan Hovold <jhovold@gmail.com>
Date:   Fri Jun 28 12:24:26 2013 +0200

    USB: ti_usb_3410_5052: fix dynamic-id matching
    
    commit 1fad56424f5ad3ce4973505a357212b2e2282b3f upstream.
    
    The driver failed to take the dynamic ids into account when determining
    the device type and therefore all devices were detected as 2-port
    devices when using the dynamic-id interface.
    
    Match on the usb-serial-driver field instead of doing redundant id-table
    searches.
    
    Reported-by: Anders Hammarquist <iko@iko.pp.se>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 11e8ea9e069e6012a634017ad534c25030b1104a
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Wed Jul 24 10:27:13 2013 -0700

    xhci: Avoid NULL pointer deref when host dies.
    
    commit 203a86613fb3bf2767335659513fa98563a3eb71 upstream.
    
    When the host controller fails to respond to an Enable Slot command, and
    the host fails to respond to the register write to abort the command
    ring, the xHCI driver will assume the host is dead, and call
    usb_hc_died().
    
    The USB device's slot_id is still set to zero, and the pointer stored at
    xhci->devs[0] will always be NULL.  The call to xhci_check_args in
    xhci_free_dev should have caught the NULL virt_dev pointer.
    
    However, xhci_free_dev is designed to free the xhci_virt_device
    structures, even if the host is dead, so that we don't leak kernel
    memory.  xhci_free_dev checks the return value from the generic
    xhci_check_args function.  If the return value is -ENODEV, it carries on
    trying to free the virtual device.
    
    The issue is that xhci_check_args looks at the host controller state
    before it looks at the xhci_virt_device pointer.  It will return -ENIVAL
    because the host is dead, and xhci_free_dev will ignore the return
    value, and happily dereference the NULL xhci_virt_device pointer.
    
    The fix is to make sure that xhci_check_args checks the xhci_virt_device
    pointer before it checks the host state.
    
    See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203453 for
    further details.  This patch doesn't solve the underlying issue, but
    will ensure we don't see any more NULL pointer dereferences because of
    the issue.
    
    This patch should be backported to kernels as old as 3.1, that
    contain the commit 7bd89b4017f46a9b92853940fd9771319acb578a "xhci: Don't
    submit commands or URBs to halted hosts."
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Reported-by: Vincent Thiele <vincentthiele@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 67a6ad3b0ca2311d4209338eec23c14331da5d36
Author: Oleksij Rempel <linux@rempel-privat.de>
Date:   Sun Jul 21 15:36:19 2013 +0200

    xhci: fix null pointer dereference on ring_doorbell_for_active_rings
    
    commit d66eaf9f89502971fddcb0de550b01fa6f409d83 upstream.
    
    in some cases where device is attched to xhci port and do not responding,
    for example ath9k_htc with stalled firmware, kernel will
    crash on ring_doorbell_for_active_rings.
    This patch check if pointer exist before it is used.
    
    This patch should be backported to kernels as old as 2.6.35, that
    contain the commit e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 "USB: xhci:
    Correct assumptions about number of rings per endpoint"
    
    Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 197d436deff13594bcc97740147c5ed9e7fe7ddb
Author: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
Date:   Mon Jul 29 09:33:58 2013 +0800

    tracing: Fix irqs-off tag display in syscall tracing
    
    commit 11034ae9c20f4057a6127fc965906417978e69b2 upstream
    
    Initialization of variable irq_flags and pc was missed when backport
    11034ae9c to linux-3.0.y and linux-3.4.y, my fault.
    
    Signed-off-by: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95a9769291fda8caa8a98c0eabff769509a6e1ba
Author: Saurav Kashyap <saurav.kashyap@qlogic.com>
Date:   Fri Jul 12 14:47:51 2013 -0400

    SCSI: qla2xxx: Properly set the tagging for commands.
    
    commit c3ccb1d7cf4c4549151876dd37c0944a682fd9e1 upstream.
    
    This fixes a regression where Xyratex controllers and disks were lost by the
    driver:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=59601
    
    Reported-by: Jack Hill <jackhill@jackhill.us>
    Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
    Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eeba2290fa3d43e5d424964ef54836227c9c21c5
Author: Ewan D. Milne <emilne@redhat.com>
Date:   Fri Nov 2 09:38:34 2012 -0400

    SCSI: sd: fix crash when UA received on DIF enabled device
    
    commit 085b513f97d8d799d28491239be4b451bcd8c2c5 upstream.
    
    sd_prep_fn will allocate a larger CDB for the command via mempool_alloc
    for devices using DIF type 2 protection.  This CDB was being freed
    in sd_done, which results in a kernel crash if the command is retried
    due to a UNIT ATTENTION.  This change moves the code to free the larger
    CDB into sd_unprep_fn instead, which is invoked after the request is
    complete.
    
    It is no longer necessary to call scsi_print_command separately for
    this case as the ->cmnd will no longer be NULL in the normal code path.
    
    Also removed conditional test for DIF type 2 when freeing the larger
    CDB because the protection_type could have been changed via sysfs while
    the command was executing.
    
    Signed-off-by: Ewan D. Milne <emilne@redhat.com>
    Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45cbbc0dd83c048d2c231bfac9cb60ef3d8f0ea6
Author: Chih-Chung Chang <chihchung@chromium.org>
Date:   Mon Jul 15 09:38:46 2013 -0700

    ASoC: max98088 - fix element type of the register cache.
    
    commit cb6f66a2d278e57a6c9d8fb59bd9ebd8ab3965c2 upstream.
    
    The registers of max98088 are 8 bits, not 16 bits. This bug causes the
    contents of registers to be overwritten with bad values when the codec
    is suspended and then resumed.
    
    Signed-off-by: Chih-Chung Chang <chihchung@chromium.org>
    Signed-off-by: Dylan Reid <dgreid@chromium.org>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 738ae485e65ea6304466ef22c7eb6981c5174d60
Author: Ren Bigcren <bigcren.ren@sonymobile.com>
Date:   Tue Jul 2 13:34:30 2013 +0200

    USB: storage: Add MicroVault Flash Drive to unusual_devs
    
    commit e7a6121f4929c17215f0cdca3726f4bf3e4e9529 upstream.
    
    The device report an error capacity when read_capacity_16().
    Using read_capacity_10() can get the correct capacity.
    
    Signed-off-by: Ren Bigcren <bigcren.ren@sonymobile.com>
    Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
    Signed-off-by: Oskar Andero <oskar.andero@sonymobile.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>