commit 14aa272fcd1cdbe7173073250c767bc7a37278ce
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Nov 13 12:02:08 2013 +0900

    Linux 3.4.69

commit 69ef8f446862dd467bd9da111c3a8c17446d74b6
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Oct 10 16:45:27 2013 -0400

    drm/radeon/atom: workaround vbios bug in transmitter table on rs780
    
    commit c23632d4e57c0dd20bf50eca08fa0eb8ad3ff680 upstream.
    
    Some rs780 asics seem to be affected as well.
    
    See:
    http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=91f3a6aaf280294b07c05dfe606e6c27b7ba3c72
    
    Fixes:
    https://bugzilla.kernel.org/show_bug.cgi?id=60791
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6a155c67112746f43d8f9c86dfc426dd455060f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Oct 16 11:22:44 2013 +0100

    drm: Prevent overwriting from userspace underallocating core ioctl structs
    
    commit b062672e305ce071f21eb9e18b102c2a430e0999 upstream.
    
    Apply the protections from
    
    commit 1b2f1489633888d4a06028315dc19d65768a1c05
    Author: Dave Airlie <airlied@redhat.com>
    Date:   Sat Aug 14 20:20:34 2010 +1000
    
        drm: block userspace under allocating buffer and having drivers overwrite it (v2)
    
    to the core ioctl structs as well, for we found one instance where there
    is a 32-/64-bit size mismatch and were guilty of writing beyond the end
    of the user's buffer.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Dave Airlie <airlied@redhat.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: dri-devel@lists.freedesktop.org
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b07ef016454ff46f98e633b5a6247ca7e343fb67
Author: Khalid Aziz <khalid.aziz@oracle.com>
Date:   Wed Sep 11 14:22:20 2013 -0700

    mm: fix aio performance regression for database caused by THP
    
    commit 7cb2ef56e6a8b7b368b2e883a0a47d02fed66911 upstream.
    
    I am working with a tool that simulates oracle database I/O workload.
    This tool (orion to be specific -
    <http://docs.oracle.com/cd/E11882_01/server.112/e16638/iodesign.htm#autoId24>)
    allocates hugetlbfs pages using shmget() with SHM_HUGETLB flag.  It then
    does aio into these pages from flash disks using various common block
    sizes used by database.  I am looking at performance with two of the most
    common block sizes - 1M and 64K.  aio performance with these two block
    sizes plunged after Transparent HugePages was introduced in the kernel.
    Here are performance numbers:
    
    		pre-THP		2.6.39		3.11-rc5
    1M read		8384 MB/s	5629 MB/s	6501 MB/s
    64K read	7867 MB/s	4576 MB/s	4251 MB/s
    
    I have narrowed the performance impact down to the overheads introduced by
    THP in __get_page_tail() and put_compound_page() routines.  perf top shows
    >40% of cycles being spent in these two routines.  Every time direct I/O
    to hugetlbfs pages starts, kernel calls get_page() to grab a reference to
    the pages and calls put_page() when I/O completes to put the reference
    away.  THP introduced significant amount of locking overhead to get_page()
    and put_page() when dealing with compound pages because hugepages can be
    split underneath get_page() and put_page().  It added this overhead
    irrespective of whether it is dealing with hugetlbfs pages or transparent
    hugepages.  This resulted in 20%-45% drop in aio performance when using
    hugetlbfs pages.
    
    Since hugetlbfs pages can not be split, there is no reason to go through
    all the locking overhead for these pages from what I can see.  I added
    code to __get_page_tail() and put_compound_page() to bypass all the
    locking code when working with hugetlbfs pages.  This improved performance
    significantly.  Performance numbers with this patch:
    
    		pre-THP		3.11-rc5	3.11-rc5 + Patch
    1M read		8384 MB/s	6501 MB/s	8371 MB/s
    64K read	7867 MB/s	4251 MB/s	6510 MB/s
    
    Performance with 64K read is still lower than what it was before THP, but
    still a 53% improvement.  It does mean there is more work to be done but I
    will take a 53% improvement for now.
    
    Please take a look at the following patch and let me know if it looks
    reasonable.
    
    [akpm@linux-foundation.org: tweak comments]
    Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
    Cc: Pravin B Shelar <pshelar@nicira.com>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Andi Kleen <andi@firstfloor.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c16bfc9ef0f2353e55b6d44fe6f2fddc76260d7
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Oct 29 22:11:06 2013 +0300

    aacraid: missing capable() check in compat ioctl
    
    commit f856567b930dfcdbc3323261bf77240ccdde01f5 upstream.
    
    In commit d496f94d22d1 ('[SCSI] aacraid: fix security weakness') we
    added a check on CAP_SYS_RAWIO to the ioctl.  The compat ioctls need the
    check as well.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 366f8a3ab0757921c4a925f7248e8c3f120305f9
Author: Ming Lei <ming.lei@canonical.com>
Date:   Thu Oct 31 16:34:17 2013 -0700

    lib/scatterlist.c: don't flush_kernel_dcache_page on slab page
    
    commit 3d77b50c5874b7e923be946ba793644f82336b75 upstream.
    
    Commit b1adaf65ba03 ("[SCSI] block: add sg buffer copy helper
    functions") introduces two sg buffer copy helpers, and calls
    flush_kernel_dcache_page() on pages in SG list after these pages are
    written to.
    
    Unfortunately, the commit may introduce a potential bug:
    
     - Before sending some SCSI commands, kmalloc() buffer may be passed to
       block layper, so flush_kernel_dcache_page() can see a slab page
       finally
    
     - According to cachetlb.txt, flush_kernel_dcache_page() is only called
       on "a user page", which surely can't be a slab page.
    
     - ARCH's implementation of flush_kernel_dcache_page() may use page
       mapping information to do optimization so page_mapping() will see the
       slab page, then VM_BUG_ON() is triggered.
    
    Aaro Koskinen reported the bug on ARM/kirkwood when DEBUG_VM is enabled,
    and this patch fixes the bug by adding test of '!PageSlab(miter->page)'
    before calling flush_kernel_dcache_page().
    
    Signed-off-by: Ming Lei <ming.lei@canonical.com>
    Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Tested-by: Simon Baatz <gmbnomis@gmail.com>
    Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10ff8e6bf05b639df6d68abe5351be5d0cc18e4d
Author: Baruch Siach <baruch@tkos.co.il>
Date:   Tue Oct 15 02:22:43 2013 +0400

    xtensa: don't use alternate signal stack on threads
    
    commit cba9a90053e3b7973eff4f1946f33032e98eeed5 upstream.
    
    According to create_thread(3): "The new thread does not inherit the creating
    thread's alternate signal stack". Since commit f9a3879a (Fix sigaltstack
    corruption among cloned threads), current->sas_ss_size is set to 0 for cloned
    processes sharing VM with their parent. Don't use the (nonexistent) alternate
    signal stack in this case. This has been broken since commit 29c4dfd9 ([XTENSA]
    Remove non-rt signal handling).
    
    Fixes the SA_ONSTACK part of the nptl/tst-cancel20 test from uClibc.
    
    Signed-off-by: Baruch Siach <baruch@tkos.co.il>
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Chris Zankel <chris@zankel.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc51af932905754ad594f8d1fc02d61073b7236f
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Oct 29 22:06:04 2013 +0300

    uml: check length in exitcode_proc_write()
    
    commit 201f99f170df14ba52ea4c52847779042b7a623b upstream.
    
    We don't cap the size of buffer from the user so we could write past the
    end of the array here.  Only root can write to this file.
    
    Reported-by: Nico Golde <nico@ngolde.de>
    Reported-by: Fabian Yamaguchi <fabs@goesec.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c373c185f096a93a70f7ebba792cb16f2a8530e
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Oct 29 23:01:11 2013 +0300

    Staging: bcm: info leak in ioctl
    
    commit 8d1e72250c847fa96498ec029891de4dc638a5ba upstream.
    
    The DevInfo.u32Reserved[] array isn't initialized so it leaks kernel
    information to user space.
    
    Reported-by: Nico Golde <nico@ngolde.de>
    Reported-by: Fabian Yamaguchi <fabs@goesec.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c4ff75c8345b3463a4a76af942ee2d401ccf2e2
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Oct 29 22:07:47 2013 +0300

    staging: ozwpan: prevent overflow in oz_cdev_write()
    
    commit c2c65cd2e14ada6de44cb527e7f1990bede24e15 upstream.
    
    We need to check "count" so we don't overflow the ei->data buffer.
    
    Reported-by: Nico Golde <nico@ngolde.de>
    Reported-by: Fabian Yamaguchi <fabs@goesec.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 827a291cb0f3979c05f985fd553e1795d8fe3818
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Oct 28 14:21:49 2013 +0100

    ASoC: dapm: Fix source list debugfs outputs
    
    commit ff18620c2157671a8ee21ebb8e6a3520ea209b1f upstream.
    
    ... due to a copy & paste error.
    
    Spotted by coverity CID 710923.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b187d81c10722b118c9a84fc5518cf062f6d9e7f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Oct 30 08:35:02 2013 +0100

    ASoC: wm_hubs: Add missing break in hp_supply_event()
    
    commit 268ff14525edba31da29a12a9dd693cdd6a7872e upstream.
    
    Spotted by coverity CID 115170.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5812381adfde20cb352d3047190ab45ea5bb59f2
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Thu Oct 31 15:01:37 2013 +0000

    ALSA: fix oops in snd_pcm_info() caused by ASoC DPCM
    
    commit a4461f41b94cb52e0141af717dcf4ef6558c8e2e upstream.
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000008
    pgd = d5300000
    [00000008] *pgd=0d265831, *pte=00000000, *ppte=00000000
    Internal error: Oops: 17 [#1] PREEMPT ARM
    CPU: 0 PID: 2295 Comm: vlc Not tainted 3.11.0+ #755
    task: dee74800 ti: e213c000 task.ti: e213c000
    PC is at snd_pcm_info+0xc8/0xd8
    LR is at 0x30232065
    pc : [<c031b52c>]    lr : [<30232065>]    psr: a0070013
    sp : e213dea8  ip : d81cb0d0  fp : c05f7678
    r10: c05f7770  r9 : fffffdfd  r8 : 00000000
    r7 : d8a968a8  r6 : d8a96800  r5 : d8a96200  r4 : d81cb000
    r3 : 00000000  r2 : d81cb000  r1 : 00000001  r0 : d8a96200
    Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
    Control: 10c5387d  Table: 15300019  DAC: 00000015
    Process vlc (pid: 2295, stack limit = 0xe213c248)
    [<c031b52c>] (snd_pcm_info) from [<c031b570>] (snd_pcm_info_user+0x34/0x9c)
    [<c031b570>] (snd_pcm_info_user) from [<c03164a4>] (snd_pcm_control_ioctl+0x274/0x280)
    [<c03164a4>] (snd_pcm_control_ioctl) from [<c0311458>] (snd_ctl_ioctl+0xc0/0x55c)
    [<c0311458>] (snd_ctl_ioctl) from [<c00eca84>] (do_vfs_ioctl+0x80/0x31c)
    [<c00eca84>] (do_vfs_ioctl) from [<c00ecd5c>] (SyS_ioctl+0x3c/0x60)
    [<c00ecd5c>] (SyS_ioctl) from [<c000e500>] (ret_fast_syscall+0x0/0x48)
    Code: e1a00005 e59530dc e3a01001 e1a02004 (e5933008)
    ---[ end trace cb3d9bdb8dfefb3c ]---
    
    This is provoked when the ASoC front end is open along with its backend,
    (which causes the backend to have a runtime assigned to it) and then the
    SNDRV_CTL_IOCTL_PCM_INFO is requested for the (visible) backend device.
    
    Resolve this by ensuring that ASoC internal backend devices are not
    visible to userspace, just as the commentry for snd_pcm_new_internal()
    says it should be.
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Acked-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 014c0d018c43e8ee99a46fbbbe387677ac3b9907
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Oct 30 12:29:40 2013 +0100

    ALSA: hda - Add a fixup for ASUS N76VZ
    
    commit 6fc16e58adf50c0f1e4478538983fb5ff6f453d4 upstream.
    
    ASUS N76VZ needs the same fixup as N56VZ for supporting the boost
    speaker.
    
    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=846529
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1099a507a89854b10c867f953761940b80b01433
Author: Helge Deller <deller@gmx.de>
Date:   Sat Oct 26 23:19:25 2013 +0200

    parisc: Do not crash 64bit SMP kernels on machines with >= 4GB RAM
    
    commit 54e181e073fc1415e41917d725ebdbd7de956455 upstream.
    
    Since the beginning of the parisc-linux port, sometimes 64bit SMP kernels were
    not able to bring up other CPUs than the monarch CPU and instead crashed the
    kernel.  The reason was unclear, esp. since it involved various machines (e.g.
    J5600, J6750 and SuperDome). Testing showed, that those crashes didn't happened
    when less than 4GB were installed, or if a 32bit Linux kernel was booted.
    
    In the end, the fix for those SMP problems is trivial:
    During the early phase of the initialization of the CPUs, including the monarch
    CPU, the PDC_PSW firmware function to enable WIDE (=64bit) mode is called.
    It's documented that this firmware function may clobber various registers, and
    one one of those possibly clobbered registers is %cr30 which holds the task
    thread info pointer.
    
    Now, if %cr30 would always have been clobbered, then this bug would have been
    detected much earlier. But lots of testing finally showed, that - at least for
    %cr30 - on some machines only the upper 32bits of the 64bit register suddenly
    turned zero after the firmware call.
    
    So, after finding the root cause, the explanation for the various crashes
    became clear:
    - On 32bit SMP Linux kernels all upper 32bit were zero, so we didn't faced this
      problem.
    - Monarch CPUs in 64bit mode always booted sucessfully, because the inital task
      thread info pointer was below 4GB.
    - Secondary CPUs booted sucessfully on machines with less than 4GB RAM because
      the upper 32bit were zero anyay.
    - Secondary CPus failed to boot if we had more than 4GB RAM and the task thread
      info pointer was located above the 4GB boundary.
    
    Finally, the patch to fix this problem is trivial by saving the %cr30 register
    before the firmware call and restoring it afterwards.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f81d0a99446a0c4548d5783807529d075b06c64e
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Sep 24 21:50:23 2013 +0200

    clockevents: Sanitize ticks to nsec conversion
    
    commit 97b9410643475d6557d2517c2aff9fd2221141a9 upstream.
    
    Marc Kleine-Budde pointed out, that commit 77cc982 "clocksource: use
    clockevents_config_and_register() where possible" caused a regression
    for some of the converted subarchs.
    
    The reason is, that the clockevents core code converts the minimal
    hardware tick delta to a nanosecond value for core internal
    usage. This conversion is affected by integer math rounding loss, so
    the backwards conversion to hardware ticks will likely result in a
    value which is less than the configured hardware limitation. The
    affected subarchs used their own workaround (SIGH!) which got lost in
    the conversion.
    
    The solution for the issue at hand is simple: adding evt->mult - 1 to
    the shifted value before the integer divison in the core conversion
    function takes care of it. But this only works for the case where for
    the scaled math mult/shift pair "mult <= 1 << shift" is true. For the
    case where "mult > 1 << shift" we can apply the rounding add only for
    the minimum delta value to make sure that the backward conversion is
    not less than the given hardware limit. For the upper bound we need to
    omit the rounding add, because the backwards conversion is always
    larger than the original latch value. That would violate the upper
    bound of the hardware device.
    
    Though looking closer at the details of that function reveals another
    bogosity: The upper bounds check is broken as well. Checking for a
    resulting "clc" value greater than KTIME_MAX after the conversion is
    pointless. The conversion does:
    
          u64 clc = (latch << evt->shift) / evt->mult;
    
    So there is no sanity check for (latch << evt->shift) exceeding the
    64bit boundary. The latch argument is "unsigned long", so on a 64bit
    arch the handed in argument could easily lead to an unnoticed shift
    overflow. With the above rounding fix applied the calculation before
    the divison is:
    
           u64 clc = (latch << evt->shift) + evt->mult - 1;
    
    So we need to make sure, that neither the shift nor the rounding add
    is overflowing the u64 boundary.
    
    [ukl: move assignment to rnd after eventually changing mult, fix build
     issue and correct comment with the right math]
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
    Cc: Marc Kleine-Budde <mkl@pengutronix.de>
    Cc: nicolas.ferre@atmel.com
    Cc: Marc Pignat <marc.pignat@hevs.ch>
    Cc: john.stultz@linaro.org
    Cc: kernel@pengutronix.de
    Cc: Ronald Wahl <ronald.wahl@raritan.com>
    Cc: LAK <linux-arm-kernel@lists.infradead.org>
    Cc: Ludovic Desroches <ludovic.desroches@atmel.com>
    Link: http://lkml.kernel.org/r/1380052223-24139-1-git-send-email-u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 268417aeea96a1941c2cd14f0f8b5b39c374ad25
Author: Lukasz Dorau <lukasz.dorau@intel.com>
Date:   Thu Oct 24 12:55:17 2013 +1100

    md: Fix skipping recovery for read-only arrays.
    
    commit 61e4947c99c4494336254ec540c50186d186150b upstream.
    
    Since:
            commit 7ceb17e87bde79d285a8b988cfed9eaeebe60b86
            md: Allow devices to be re-added to a read-only array.
    
    spares are activated on a read-only array. In case of raid1 and raid10
    personalities it causes that not-in-sync devices are marked in-sync
    without checking if recovery has been finished.
    
    If a read-only array is degraded and one of its devices is not in-sync
    (because the array has been only partially recovered) recovery will be skipped.
    
    This patch adds checking if recovery has been finished before marking a device
    in-sync for raid1 and raid10 personalities. In case of raid5 personality
    such condition is already present (at raid5.c:6029).
    
    Bug was introduced in 3.10 and causes data corruption.
    
    Signed-off-by: Pawel Baldysiak <pawel.baldysiak@intel.com>
    Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49028693152b88ae7ab2d444df7f73d2f0e3bbfd
Author: Gwendal Grignou <gwendal@google.com>
Date:   Fri Aug 7 16:17:49 2009 -0700

    libata: make ata_eh_qc_retry() bump scmd->allowed on bogus failures
    
    commit f13e220161e738c2710b9904dcb3cf8bb0bcce61 upstream.
    
    libata EH decrements scmd->retries when the command failed for reasons
    unrelated to the command itself so that, for example, commands aborted
    due to suspend / resume cycle don't get penalized; however,
    decrementing scmd->retries isn't enough for ATA passthrough commands.
    
    Without this fix, ATA passthrough commands are not resend to the
    drive, and no error is signalled to the caller because:
    
    - allowed retry count is 1
    - ata_eh_qc_complete fill the sense data, so result is valid
    - sense data is filled with untouched ATA registers.
    
    Signed-off-by: Gwendal Grignou <gwendal@google.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f49c173bb693fa2aea6c96c931f9449ce4885d7b
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Fri Oct 4 10:52:36 2013 +0200

    can: flexcan: flexcan_chip_start: fix regression, mark one MB for TX and abort pending TX
    
    commit d5a7b406c529e4595ce03dc8f6dcf7fa36f106fa upstream.
    
    In patch
    
        0d1862e can: flexcan: fix flexcan_chip_start() on imx6
    
    the loop in flexcan_chip_start() that iterates over all mailboxes after the
    soft reset of the CAN core was removed. This loop put all mailboxes (even the
    ones marked as reserved 1...7) into EMPTY/INACTIVE mode. On mailboxes 8...63,
    this aborts any pending TX messages.
    
    After a cold boot there is random garbage in the mailboxes, which leads to
    spontaneous transmit of CAN frames during first activation. Further if the
    interface was disabled with a pending message (usually due to an error
    condition on the CAN bus), this message is retransmitted after enabling the
    interface again.
    
    This patch fixes the regression by:
    1) Limiting the maximum number of used mailboxes to 8, 0...7 are used by the RX
    FIFO, 8 is used by TX.
    2) Marking the TX mailbox as EMPTY/INACTIVE, so that any pending TX of that
    mailbox is aborted.
    
    Cc: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20b2a1eb2de54d0fce4dee198546cc448589dad8
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date:   Fri Sep 6 21:49:56 2013 -0500

    jfs: fix error path in ialloc
    
    commit 8660998608cfa1077e560034db81885af8e1e885 upstream.
    
    If insert_inode_locked() fails, we shouldn't be calling
    unlock_new_inode().
    
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Tested-by: Michael L. Semon <mlsemon35@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9fda0bdd950b09c42e26cc7e19590ce62e842fee
Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Date:   Tue Oct 8 10:18:20 2013 -0500

    rtlwifi: rtl8192cu: Fix error in pointer arithmetic
    
    commit 9473ca6e920a3b9ca902753ce52833657f9221cc upstream.
    
    An error in calculating the offset in an skb causes the driver to read
    essential device info from the wrong locations. The main effect is that
    automatic gain calculations are nonsense.
    
    Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48cca8f206801410760e7dc5abaa361c3fdba10a
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sun Sep 29 21:39:34 2013 +0200

    mac80211: update sta->last_rx on acked tx frames
    
    commit 0c5b93290b2f3c7a376567c03ae8d385b0e99851 upstream.
    
    When clients are idle for too long, hostapd sends nullfunc frames for
    probing. When those are acked by the client, the idle time needs to be
    updated.
    
    To make this work (and to avoid unnecessary probing), update sta->last_rx
    whenever an ACK was received for a tx packet. Only do this if the flag
    IEEE80211_HW_REPORTS_TX_ACK_STATUS is set.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9ef1eea8bc243c4435c85ea5a30c647ea19995a
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Mon Sep 16 11:12:07 2013 +0300

    mac80211: correctly close cancelled scans
    
    commit a754055a1296fcbe6f32de3a5eaca6efb2fd1865 upstream.
    
    __ieee80211_scan_completed is called from a worker. This
    means that the following flow is possible.
    
     * driver calls ieee80211_scan_completed
     * mac80211 cancels the scan (that is already complete)
     * __ieee80211_scan_completed runs
    
    When scan_work will finally run, it will see that the scan
    hasn't been aborted and might even trigger another scan on
    another band. This leads to a situation where cfg80211's
    scan is not done and no further scan can be issued.
    
    Fix this by setting a new flag when a HW scan is being
    cancelled so that no other scan will be triggered.
    
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 609a45c1bbd45beb7a042b09488f1f971f4a2999
Author: Алексей Крамаренко <alexeyk13@yandex.ru>
Date:   Fri Nov 1 17:26:38 2013 +0400

    USB: serial: ftdi_sio: add id for Z3X Box device
    
    commit e1466ad5b1aeda303f9282463d55798d2eda218c upstream.
    
    Custom VID/PID for Z3X Box device, popular tool for cellphone flashing.
    
    Signed-off-by: Alexey E. Kramarenko <alexeyk13@yandex.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a86db5aa1235625049b9c7676e759206654fd16
Author: Oliver Neukum <oneukum@suse.de>
Date:   Wed Oct 16 12:26:07 2013 +0200

    USB: quirks: add touchscreen that is dazzeled by remote wakeup
    
    commit 614ced91fc6fbb5a1cdd12f0f1b6c9197d9f1350 upstream.
    
    The device descriptors are messed up after remote wakeup
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76d83ad79046e19a5fdc7f0946d845fe3f099ac2
Author: Oliver Neukum <oneukum@suse.de>
Date:   Mon Oct 14 16:22:40 2013 +0200

    USB: quirks.c: add one device that cannot deal with suspension
    
    commit 4294bca7b423d1a5aa24307e3d112a04075e3763 upstream.
    
    The device is not responsive when resumed, unless it is reset.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c09f215220d962cc6f3da92a3be1cb780521f77b
Author: Fangxiaozhi (Franko) <fangxiaozhi@huawei.com>
Date:   Fri Oct 11 03:48:21 2013 +0000

    USB: support new huawei devices in option.c
    
    commit d544db293a44a2a3b09feab7dbd59668b692de71 upstream.
    
    Add new supporting declarations to option.c, to support Huawei new
    devices with new bInterfaceSubClass value.
    
    Signed-off-by: fangxiaozhi <huananhu@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>