commit 3d514b82fc30a1425eba9e7b8f24620a4ec8a633
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Dec 3 12:18:42 2012 -0800

    Linux 3.4.21

commit 0c4528e770362d3497f59e9d15484ce24dd65ba9
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Sep 25 16:40:12 2012 +0200

    iwlwifi: fix 6000 series channel switch command
    
    commit 8f7b8db6e0557c8437adf9371e020cd89a7e85dc upstream.
    
    The channel switch command for 6000 series devices
    is larger than the maximum inline command size of
    320 bytes. The command is therefore refused with a
    warning. Fix this by allocating the command and
    using the NOCOPY mechanism.
    
    Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bffeb2a91830ad2ad841b3d1203d6c7724099d8d
Author: Stanislav Yakovlev <stas.yakovlev@gmail.com>
Date:   Mon Oct 15 14:14:32 2012 +0000

    net/wireless: ipw2200: Fix panic occurring in ipw_handle_promiscuous_tx()
    
    commit bf11315eeda510ea4fc1a2bf972d8155d31d89b4 upstream.
    
    The driver does not count space of radiotap fields when allocating skb for
    radiotap packet. This leads to kernel panic with the following call trace:
    
    ...
    [67607.676067] [<c152f90f>] error_code+0x67/0x6c
    [67607.676067] [<c142f831>] ? skb_put+0x91/0xa0
    [67607.676067] [<f8cf5e5b>] ? ipw_handle_promiscuous_tx+0x16b/0x2d0 [ipw2200]
    [67607.676067] [<f8cf5e5b>] ipw_handle_promiscuous_tx+0x16b/0x2d0 [ipw2200]
    [67607.676067] [<f8cf899b>] ipw_net_hard_start_xmit+0x8b/0x90 [ipw2200]
    [67607.676067] [<f8741c5a>] libipw_xmit+0x55a/0x980 [libipw]
    [67607.676067] [<c143d3e8>] dev_hard_start_xmit+0x218/0x4d0
    ...
    
    This bug was found by VittGam.
    https://bugzilla.kernel.org/show_bug.cgi?id=43255
    
    Signed-off-by: Stanislav Yakovlev <stas.yakovlev@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1103ef8e70a1725b7fd9e0cb18a8b1edb6e5c42d
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Oct 9 10:18:23 2012 +0300

    timekeeping: Cast raw_interval to u64 to avoid shift overflow
    
    commit 5b3900cd409466c0070b234d941650685ad0c791 upstream.
    
    We fixed a bunch of integer overflows in timekeeping code during the 3.6
    cycle.  I did an audit based on that and found this potential overflow.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: John Stultz <johnstul@us.ibm.com>
    Link: http://lkml.kernel.org/r/20121009071823.GA19159@elgon.mountain
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    [ herton: adapt for 3.5, timekeeper instead of tk pointer ]
    Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e84ad739d8a2143e5cd284a4c0462278587e4aa3
Author: Colin Cross <ccross@android.com>
Date:   Mon Oct 8 14:01:12 2012 -0700

    ARM: OMAP: counter: add locking to read_persistent_clock
    
    commit 9d7d6e363b06934221b81a859d509844c97380df upstream.
    
    read_persistent_clock uses a global variable, use a spinlock to
    ensure non-atomic updates to the variable don't overlap and cause
    time to move backwards.
    
    Signed-off-by: Colin Cross <ccross@android.com>
    Signed-off-by: R Sricharan <r.sricharan@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc6058e1a4cc1f76aab5c580322e109cf448ec9b
Author: Jaehoon Chung <jh80.chung@samsung.com>
Date:   Wed Sep 19 14:43:33 2012 +0800

    mmc: sdhci-s3c: fix the wrong number of max bus clocks
    
    commit 5feb54a1ab91a237e247c013b8c4fb100ea347b1 upstream.
    
    We can use up to four bus-clocks; but on module remove, we didn't
    disable the fourth bus clock.
    
    Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee746ff6943cea07e9866e78307154f539440c57
Author: Gavin Shan <shangw@linux.vnet.ibm.com>
Date:   Mon Sep 17 04:34:27 2012 +0000

    powerpc/eeh: Lock module while handling EEH event
    
    commit feadf7c0a1a7c08c74bebb4a13b755f8c40e3bbc upstream.
    
    The EEH core is talking with the PCI device driver to determine the
    action (purely reset, or PCI device removal). During the period, the
    driver might be unloaded and in turn causes kernel crash as follows:
    
    EEH: Detected PCI bus error on PHB#4-PE#10000
    EEH: This PCI device has failed 3 times in the last hour
    lpfc 0004:01:00.0: 0:2710 PCI channel disable preparing for reset
    Unable to handle kernel paging request for data at address 0x00000490
    Faulting instruction address: 0xd00000000e682c90
    cpu 0x1: Vector: 300 (Data Access) at [c000000fc75ffa20]
        pc: d00000000e682c90: .lpfc_io_error_detected+0x30/0x240 [lpfc]
        lr: d00000000e682c8c: .lpfc_io_error_detected+0x2c/0x240 [lpfc]
        sp: c000000fc75ffca0
       msr: 8000000000009032
       dar: 490
     dsisr: 40000000
      current = 0xc000000fc79b88b0
      paca    = 0xc00000000edb0380	 softe: 0	 irq_happened: 0x00
        pid   = 3386, comm = eehd
    enter ? for help
    [c000000fc75ffca0] c000000fc75ffd30 (unreliable)
    [c000000fc75ffd30] c00000000004fd3c .eeh_report_error+0x7c/0xf0
    [c000000fc75ffdc0] c00000000004ee00 .eeh_pe_dev_traverse+0xa0/0x180
    [c000000fc75ffe70] c00000000004ffd8 .eeh_handle_event+0x68/0x300
    [c000000fc75fff00] c0000000000503a0 .eeh_event_handler+0x130/0x1a0
    [c000000fc75fff90] c000000000020138 .kernel_thread+0x54/0x70
    1:mon>
    
    The patch increases the reference of the corresponding driver modules
    while EEH core does the negotiation with PCI device driver so that the
    corresponding driver modules can't be unloaded during the period and
    we're safe to refer the callbacks.
    
    Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    [ herton: backported for 3.5, adjusted driver assignments, return 0
      instead of NULL, assume dev is not NULL ]
    Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7da2f8907ba51acd7d13dd62e71f14972e9b5161
Author: Manuel Lauss <manuel.lauss@gmail.com>
Date:   Thu Nov 22 11:58:22 2012 +0100

    MPI: Fix compilation on MIPS with GCC 4.4 and newer
    
    commit a3cea9894157c20a5b1ec08b7e0b5f2019740c10 upstream.
    
    Since 4.4 GCC on MIPS no longer recognizes the "h" constraint,
    leading to this build failure:
    
      CC      lib/mpi/generic_mpih-mul1.o
    lib/mpi/generic_mpih-mul1.c: In function 'mpihelp_mul_1':
    lib/mpi/generic_mpih-mul1.c:50:3: error: impossible constraint in 'asm'
    
    This patch updates MPI with the latest umul_ppm implementations for MIPS.
    
    Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
    Cc: Linux-MIPS <linux-mips@linux-mips.org>
    Cc: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
    Cc: James Morris <jmorris@namei.org>
    Patchwork: https://patchwork.linux-mips.org/patch/4612/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Cc: Shuah Khan <shuah.khan@hp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53b360c604575070c83d2da83636af4e5c5de35a
Author: Chuansheng Liu <chuansheng.liu@intel.com>
Date:   Mon Nov 26 16:29:54 2012 -0800

    watchdog: using u64 in get_sample_period()
    
    commit 8ffeb9b0e6369135bf03a073514f571ef10606b9 upstream.
    
    In get_sample_period(), unsigned long is not enough:
    
      watchdog_thresh * 2 * (NSEC_PER_SEC / 5)
    
    case1:
      watchdog_thresh is 10 by default, the sample value will be: 0xEE6B2800
    
    case2:
     set watchdog_thresh is 20, the sample value will be: 0x1 DCD6 5000
    
    In case2, we need use u64 to express the sample period.  Otherwise,
    changing the threshold thru proc often can not be successful.
    
    Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
    Acked-by: Don Zickus <dzickus@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Shuah Khan <shuah.khan@hp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 368c8c73d4648843bece41f7c083f11fa4d1aa36
Author: Johan Hovold <jhovold@gmail.com>
Date:   Thu Oct 25 10:29:14 2012 +0200

    USB: mct_u232: fix broken close
    
    commit 5260e458f5eff269a43e4f1e9c47186c57b88ddb upstream.
    
    Make sure generic close is called at close.
    
    The driver relies on the generic write implementation but did not call
    generic close.
    
    Note that the call to kill the read urb is not redundant, as mct_u232
    uses an interrupt urb from the second port as the read urb and that
    generic close therefore fails to kill it.
    
    Compile-only tested.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 47abf714aab1e2f5c293f54a3bd3f0ef7534c38e
Author: Thierry Escande <thierry.escande@linux.intel.com>
Date:   Fri Oct 12 15:25:43 2012 +0200

    NFC: Fix nfc_llcp_local chained list insertion
    
    commit 16a78e9fed5e8baa8480ae3413f4328c4537c599 upstream.
    
    list_add was called with swapped parameters
    
    Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b127f3f930bbeedc3b10b150a4f43a6abeb75836
Author: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Date:   Thu Oct 11 14:04:00 2012 +0200

    NFC: pn533: Fix mem leak in pn533_in_dep_link_up
    
    commit 70418e6efcf4f8652cc08e3f2ab8ae35f0948fd9 upstream.
    
    cmd is allocated in pn533_dep_link_up and passed as an arg to
    pn533_send_cmd_frame_async together with a complete cb.
    
    arg is passed to the cb and must be kfreed there.
    
    Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c09221cefdbd669883f94ff62f055d270df85feb
Author: Szymon Janc <szymon.janc@tieto.com>
Date:   Mon Oct 29 14:04:43 2012 +0100

    NFC: pn533: Fix use after free
    
    commit 770f750bc2b8312489c8e45306f551d08a319d3c upstream.
    
    cmd was freed in pn533_dep_link_up regardless of
    pn533_send_cmd_frame_async return code. Cmd is passed as argument to
    pn533_in_dep_link_up_complete callback and should be freed there.
    
    Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9cfb66219d6e5840df9c4cf06fff70e072be1409
Author: Mauro Carvalho Chehab <mchehab@redhat.com>
Date:   Fri Sep 28 16:16:00 2012 -0300

    get_dvb_firmware: fix download site for tda10046 firmware
    
    commit 25ec43d3e6306978cf66060ed18c4160ce8fc302 upstream.
    
    The previous website doesn't exist anymore. Update it to one site that
    actually exists.
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08ecfb7dd2e41f8aa9bd57468e09fdc5bbbc2ec6
Author: David Milburn <dmilburn@redhat.com>
Date:   Mon Oct 29 18:00:22 2012 -0500

    sata_svw: check DMA start bit before reset
    
    commit b03e66a6be91f8389fcd902ab6c1563db1c9c06b upstream.
    
    If kdump is triggered with pending IO, controller may not respond causing
    kdump to fail.
    
    http://marc.info/?l=linux-ide&m=133032255424658&w=2
    
    During error recovery ata_do_dev_read_id never completes due hang
    in mmio_insw.
    
    ata_do_dev_read_id
     ata_sff_data_xfer
      ioread16_rep
       mmio_insw
    
    if DMA start bit is cleared before reset, PIO command is successful
    and kdump succeeds.
    
    Signed-off-by: David Milburn <dmilburn@redhat.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Cc: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65c03b4c0598a71e125a96985f5a402347f7ffb3
Author: joshua.a.hay@intel.com <joshua.a.hay@intel.com>
Date:   Fri Sep 21 00:08:21 2012 +0000

    ixgbe: add support for X540-AT1
    
    commit df376f0de167754da9b3ece4afdb5bb8bf3fbf3e upstream.
    
    This patch adds device support for Ethernet Controller X540-AT1.
    
    Signed-off-by: Josh Hay <joshua.a.hay@intel.com>
    Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Abdallah Chatila <Abdallah.Chatila@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 865c6f7f4ddc972735cb6bc34a70370df537c650
Author: Petr Matousek <pmatouse@redhat.com>
Date:   Tue Nov 6 19:24:07 2012 +0100

    KVM: x86: invalid opcode oops on SET_SREGS with OSXSAVE bit set (CVE-2012-4461)
    
    commit 6d1068b3a98519247d8ba4ec85cd40ac136dbdf9 upstream.
    
    On hosts without the XSAVE support unprivileged local user can trigger
    oops similar to the one below by setting X86_CR4_OSXSAVE bit in guest
    cr4 register using KVM_SET_SREGS ioctl and later issuing KVM_RUN
    ioctl.
    
    invalid opcode: 0000 [#2] SMP
    Modules linked in: tun ip6table_filter ip6_tables ebtable_nat ebtables
    ...
    Pid: 24935, comm: zoog_kvm_monito Tainted: G      D      3.2.0-3-686-pae
    EIP: 0060:[<f8b9550c>] EFLAGS: 00210246 CPU: 0
    EIP is at kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm]
    EAX: 00000001 EBX: 000f387e ECX: 00000000 EDX: 00000000
    ESI: 00000000 EDI: 00000000 EBP: ef5a0060 ESP: d7c63e70
     DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
    Process zoog_kvm_monito (pid: 24935, ti=d7c62000 task=ed84a0c0
    task.ti=d7c62000)
    Stack:
     00000001 f70a1200 f8b940a9 ef5a0060 00000000 00200202 f8769009 00000000
     ef5a0060 000f387e eda5c020 8722f9c8 00015bae 00000000 ed84a0c0 ed84a0c0
     c12bf02d 0000ae80 ef7f8740 fffffffb f359b740 ef5a0060 f8b85dc1 0000ae80
    Call Trace:
     [<f8b940a9>] ? kvm_arch_vcpu_ioctl_set_sregs+0x2fe/0x308 [kvm]
    ...
     [<c12bfb44>] ? syscall_call+0x7/0xb
    Code: 89 e8 e8 14 ee ff ff ba 00 00 04 00 89 e8 e8 98 48 ff ff 85 c0 74
    1e 83 7d 48 00 75 18 8b 85 08 07 00 00 31 c9 8b 95 0c 07 00 00 <0f> 01
    d1 c7 45 48 01 00 00 00 c7 45 1c 01 00 00 00 0f ae f0 89
    EIP: [<f8b9550c>] kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm] SS:ESP
    0068:d7c63e70
    
    QEMU first retrieves the supported features via KVM_GET_SUPPORTED_CPUID
    and then sets them later. So guest's X86_FEATURE_XSAVE should be masked
    out on hosts without X86_FEATURE_XSAVE, making kvm_set_cr4 with
    X86_CR4_OSXSAVE fail. Userspaces that allow specifying guest cpuid with
    X86_FEATURE_XSAVE even on hosts that do not support it, might be
    susceptible to this attack from inside the guest as well.
    
    Allow setting X86_CR4_OSXSAVE bit only if host has XSAVE support.
    
    Signed-off-by: Petr Matousek <pmatouse@redhat.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5042a551a4805f73c82b5fba0a3c4cc2e372665c
Author: Jan Kara <jack@suse.cz>
Date:   Fri Jun 15 12:52:46 2012 +0200

    scsi: Silence unnecessary warnings about ioctl to partition
    
    commit 6d9359280753d2955f86d6411047516a9431eb51 upstream.
    
    Sometimes, warnings about ioctls to partition happen often enough that they
    form majority of the warnings in the kernel log and users complain. In some
    cases warnings are about ioctls such as SG_IO so it's not good to get rid of
    the warnings completely as they can ease debugging of userspace problems
    when ioctl is refused.
    
    Since I have seen warnings from lots of commands, including some proprietary
    userspace applications, I don't think disallowing the ioctls for processes
    with CAP_SYS_RAWIO will happen in the near future if ever. So lets just
    stop warning for processes with CAP_SYS_RAWIO for which ioctl is allowed.
    
    Acked-by: Paolo Bonzini <pbonzini@redhat.com>
    CC: Paolo Bonzini <pbonzini@redhat.com>
    CC: James Bottomley <JBottomley@parallels.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Cc: satoru takeuchi <satoru.takeuchi@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6495a1b5bc6f9e55eff414975609fef9e4a73662
Author: Tilman Schmidt <tilman@imap.cc>
Date:   Wed Oct 24 08:44:32 2012 +0000

    bas_gigaset: fix pre_reset handling
    
    commit c6fdd8e5d0c65bb8821dc6da26ee1a2ddd58b3cc upstream.
    
    The delayed work function int_in_work() may call usb_reset_device()
    and thus, indirectly, the driver's pre_reset method. Trying to
    cancel the work synchronously in that situation would deadlock.
    Fix by avoiding cancel_work_sync() in the pre_reset method.
    
    If the reset was NOT initiated by int_in_work() this might cause
    int_in_work() to run after the post_reset method, with urb_int_in
    already resubmitted, so handle that case gracefully.
    
    Signed-off-by: Tilman Schmidt <tilman@imap.cc>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06096cf239242e915ee13c48c10306828c828527
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Wed Nov 21 08:57:58 2012 +0100

    ALSA: hda - Add support for Realtek ALC292
    
    commit af02dde8a609d8d071c4b31a82df811a55690a4a upstream.
    
    We found a new codec ID 292, and that just a simple quirk would enable
    sound output/input on this ALC292 chip.
    
    BugLink: https://bugs.launchpad.net/bugs/1081466
    Tested-by: Acelan Kao <acelan.kao@canonical.com>
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 510add68ecdbc4ec3731248acf575753945f43ac
Author: Duncan Roe <duncan_roe@acslink.net.au>
Date:   Wed Oct 10 14:19:50 2012 +0200

    ALSA: hda - Fix missing beep on ASUS X43U notebook
    
    commit 7110005e8d5c3cd418fc4b64f9f124f004422a9a upstream.
    
    Signed-off-by: Duncan Roe <duncan_roe@acslink.net.au>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5f56030f487d3dbcc28be40cdecb8e43888dfa0
Author: Kailang Yang <kailang@realtek.com>
Date:   Sat Oct 6 17:02:30 2012 +0200

    ALSA: hda - Add new codec ALC283 ALC290 support
    
    commit 7ff34ad80b7080fafaac8efa9ef0061708eddd51 upstream.
    
    These are compatible with standard ALC269 parser.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4e9e580078376f7fd53fcf3a27f3a1259ebe463
Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Date:   Fri Nov 23 20:55:06 2012 +0100

    PM / QoS: fix wrong error-checking condition
    
    commit a7227a0faa117d0bc532aea546ae5ac5f89e8ed7 upstream.
    
    dev_pm_qos_add_request() can return 0, 1, or a negative error code,
    therefore the correct error test is "if (error < 0)." Checking just for
    non-zero return code leads to erroneous setting of the req->dev pointer
    to NULL, which then leads to a repeated call to
    dev_pm_qos_add_ancestor_request() in st1232_ts_irq_handler(). This in turn
    leads to an Oops, when the I2C host adapter is unloaded and reloaded again
    because of the inconsistent state of its QoS request list.
    
    Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98165e2b0d355759c16bae8d9ae09b445149cfbd
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Nov 18 22:27:03 2012 -0500

    sparc64: not any error from do_sigaltstack() should fail rt_sigreturn()
    
    commit fae2ae2a900a5c7bb385fe4075f343e7e2d5daa2 upstream.
    
    If a signal handler is executed on altstack and another signal comes,
    we will end up with rt_sigreturn() on return from the second handler
    getting -EPERM from do_sigaltstack().  It's perfectly OK, since we
    are not asking to change the settings; in fact, they couldn't have been
    changed during the second handler execution exactly because we'd been
    on altstack all along.  64bit sigreturn on sparc treats any error from
    do_sigaltstack() as "SIGSEGV now"; we need to switch to the same semantics
    we are using on other architectures.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit acaf0ed4bdd03d31d0df0bf33816bdaceecbe7cc
Author: Jan Kara <jack@suse.cz>
Date:   Fri Nov 23 14:03:04 2012 +0100

    jbd: Fix lock ordering bug in journal_unmap_buffer()
    
    commit 25389bb207987b5774182f763b9fb65ff08761c8 upstream.
    
    Commit 09e05d48 introduced a wait for transaction commit into
    journal_unmap_buffer() in the case we are truncating a buffer undergoing commit
    in the page stradding i_size on a filesystem with blocksize < pagesize. Sadly
    we forgot to drop buffer lock before waiting for transaction commit and thus
    deadlock is possible when kjournald wants to lock the buffer.
    
    Fix the problem by dropping the buffer lock before waiting for transaction
    commit. Since we are still holding page lock (and that is OK), buffer cannot
    disappear under us.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9fa3f41a91e5c279968e5c9962b578aca003c98
Author: Oliver Hartkopp <socketcan@hartkopp.net>
Date:   Mon Nov 26 22:24:23 2012 +0100

    can: bcm: initialize ifindex for timeouts without previous frame reception
    
    commit 81b401100c01d2357031e874689f89bd788d13cd upstream.
    
    Set in the rx_ifindex to pass the correct interface index in the case of a
    message timeout detection. Usually the rx_ifindex value is set at receive
    time. But when no CAN frame has been received the RX_TIMEOUT notification
    did not contain a valid value.
    
    Reported-by: Andre Naujoks <nautsch2@googlemail.com>
    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e937c8ffe7d6ba56a699684a4bc5f6b3edd05a5
Author: Oliver Hartkopp <socketcan@hartkopp.net>
Date:   Wed Nov 21 22:43:59 2012 +0100

    can: peak_usb: fix hwtstamp assignment
    
    commit c9faaa09e2a1335678f09c70a0d0eda095564bab upstream.
    
    The skb->tstamp is set to the hardware timestamp when available in the USB
    urb message. This leads to user visible timestamps which contain the 'uptime'
    of the USB adapter - and not the usual system generated timestamp.
    
    Fix this wrong assignment by applying the available hardware timestamp to the
    skb_shared_hwtstamps data structure - which is intended for this purpose.
    
    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6e782e1275740a5ca4c1a32cc9acfe1b6f82203
Author: Paul Bolle <pebolle@tiscali.nl>
Date:   Mon Nov 19 21:17:31 2012 +0100

    radeon: add AGPMode 1 quirk for RV250
    
    commit 45171002b01b2e2ec4f991eca81ffd8430fd0aec upstream.
    
    The Intel 82855PM host bridge / Mobility FireGL 9000 RV250 combination
    in an (outdated) ThinkPad T41 needs AGPMode 1 for suspend/resume (under
    KMS, that is). So add a quirk for it.
    
    (Change R250 to RV250 in comment for preceding quirk too.)
    
    Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e41cd8f166f6b9a0767dce3cbce65d1f4941b8ba
Author: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
Date:   Tue Nov 13 18:43:03 2012 +0100

    mac80211: deinitialize ibss-internals after emptiness check
    
    commit b78a4932f5fb11fadf41e69c606a33fa6787574c upstream.
    
    The check whether the IBSS is active and can be removed should be
    performed before deinitializing the fields used for the check/search.
    Otherwise, the configured BSS will not be found and removed properly.
    
    To make it more clear for the future, rename sdata->u.ibss to the
    local pointer ifibss which is used within the checks.
    
    This behaviour was introduced by
    f3209bea110cade12e2b133da8b8499689cb0e2e
    ("mac80211: fix IBSS teardown race")
    
    Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
    Cc: Ignacy Gawedzki <i@lri.fr>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fceca5e72e787dd0a8ea29e22a874e363389356c
Author: Darren Hart <dvhart@linux.intel.com>
Date:   Mon Nov 26 16:29:56 2012 -0800

    futex: avoid wake_futex() for a PI futex_q
    
    commit aa10990e028cac3d5e255711fb9fb47e00700e35 upstream.
    
    Dave Jones reported a bug with futex_lock_pi() that his trinity test
    exposed.  Sometime between queue_me() and taking the q.lock_ptr, the
    lock_ptr became NULL, resulting in a crash.
    
    While futex_wake() is careful to not call wake_futex() on futex_q's with
    a pi_state or an rt_waiter (which are either waiting for a
    futex_unlock_pi() or a PI futex_requeue()), futex_wake_op() and
    futex_requeue() do not perform the same test.
    
    Update futex_wake_op() and futex_requeue() to test for q.pi_state and
    q.rt_waiter and abort with -EINVAL if detected.  To ensure any future
    breakage is caught, add a WARN() to wake_futex() if the same condition
    is true.
    
    This fix has seen 3 hours of testing with "trinity -c futex" on an
    x86_64 VM with 4 CPUS.
    
    [akpm@linux-foundation.org: tidy up the WARN()]
    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    Reported-by: Dave Jones <davej@redat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: John Kacur <jkacur@redhat.com>
    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 f42513b9fd98a0f3afa8fe9bc23700b4226e1f6f
Author: Jens Axboe <axboe@kernel.dk>
Date:   Tue Nov 6 12:24:26 2012 +0100

    dm: fix deadlock with request based dm and queue request_fn recursion
    
    commit a8c32a5c98943d370ea606a2e7dc04717eb92206 upstream.
    
    Request based dm attempts to re-run the request queue off the
    request completion path. If used with a driver that potentially does
    end_io from its request_fn, we could deadlock trying to recurse
    back into request dispatch. Fix this by punting the request queue
    run to kblockd.
    
    Tested to fix a quickly reproducible deadlock in such a scenario.
    
    Acked-by: Alasdair G Kergon <agk@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ecf049ce86e1d93bc9a3376facf31d7244338089
Author: NeilBrown <neilb@suse.de>
Date:   Thu Nov 22 15:12:09 2012 +1100

    md/raid10: decrement correct pending counter when writing to replacement.
    
    commit 884162df2aadd7414bef4935e1a54976fd4e3988 upstream.
    
    When a write to a replacement device completes, we carefully
    and correctly found the rdev that the write actually went to
    and the blithely called rdev_dec_pending on the primary rdev,
    even if this write was to the replacement.
    
    This means that any writes to an array while a replacement
    was ongoing would cause the nr_pending count for the primary
    device to go negative, so it could never be removed.
    
    This bug has been present since replacement was introduced in
    3.3, so it is suitable for any -stable kernel since then.
    
    Reported-by: "George Spelvin" <linux@horizon.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c98fbaa55508732bb5a9f46b3c6cf60daa8e526
Author: majianpeng <majianpeng@gmail.com>
Date:   Thu Nov 8 08:56:27 2012 +0800

    md: Avoid write invalid address if read_seqretry returned true.
    
    commit 35f9ac2dcec8f79d7059ce174fd7b7ee3290d620 upstream.
    
    If read_seqretry returned true and bbp was changed, it will write
    invalid address which can cause some serious problem.
    
    This bug was introduced by commit v3.0-rc7-130-g2699b67.
    So fix is suitable for 3.0.y thru 3.6.y.
    
    Reported-by: zhuwenfeng@kedacom.com
    Tested-by: zhuwenfeng@kedacom.com
    Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45bc5c6913e04f1346bfe3401d2f52ad2164b3b2
Author: majianpeng <majianpeng@gmail.com>
Date:   Tue Nov 6 17:13:44 2012 +0800

    md: Reassigned the parameters if read_seqretry returned true in func md_is_badblock.
    
    commit ab05613a0646dcc11049692d54bae76ca9ffa910 upstream.
    
    This bug was introduced by commit(v3.0-rc7-126-g2230dfe).
    So fix is suitable for 3.0.y thru 3.6.y.
    
    Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 262a70e8fbf870359ced2059becf116a249bb2d5
Author: Thomas Betker <thomas.betker@freenet.de>
Date:   Wed Oct 17 22:59:30 2012 +0200

    jffs2: Fix lock acquisition order bug in jffs2_write_begin
    
    commit 5ffd3412ae5536a4c57469cb8ea31887121dcb2e upstream.
    
    jffs2_write_begin() first acquires the page lock, then f->sem. This
    causes an AB-BA deadlock with jffs2_garbage_collect_live(), which first
    acquires f->sem, then the page lock:
    
    jffs2_garbage_collect_live
        mutex_lock(&f->sem)                         (A)
        jffs2_garbage_collect_dnode
            jffs2_gc_fetch_page
                read_cache_page_async
                    do_read_cache_page
                        lock_page(page)             (B)
    
    jffs2_write_begin
        grab_cache_page_write_begin
            find_lock_page
                lock_page(page)                     (B)
        mutex_lock(&f->sem)                         (A)
    
    We fix this by restructuring jffs2_write_begin() to take f->sem before
    the page lock. However, we make sure that f->sem is not held when
    calling jffs2_reserve_space(), as this is not permitted by the locking
    rules.
    
    The deadlock above was observed multiple times on an SoC with a dual
    ARMv7 (Cortex-A9), running the long-term 3.4.11 kernel; it occurred
    when using scp to copy files from a host system to the ARM target
    system. The fix was heavily tested on the same target system.
    
    Signed-off-by: Thomas Betker <thomas.betker@rohde-schwarz.com>
    Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 11371ec0a92756cbaa84b86fbbaa3aeae7457658
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date:   Tue Sep 25 15:27:13 2012 +0530

    mtd: ofpart: Fix incorrect NULL check in parse_ofoldpart_partitions()
    
    commit 5a6ea4af0907f995dc06df21a9c9ef764c7cd3bc upstream.
    
    The pointer returned by kzalloc should be tested for NULL
    to avoid potential NULL pointer dereference later. Incorrect
    pointer was being tested for NULL. Bug introduced by commit fbcf62a3
    (mtd: physmap_of: move parse_obsolete_partitions to become separate
    parser).
    This patch fixes this bug.
    
    Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
    Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
    Cc: Artem Bityutskiy <artem.bityutskiy@intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02bbebe27638111d18f63fa7438231def916bd15
Author: Jiri Engelthaler <engycz@gmail.com>
Date:   Thu Sep 20 16:49:50 2012 +0200

    mtd: slram: invalid checking of absolute end address
    
    commit c36a7ff4578ab6294885aef5ef241aeec4cdb1f0 upstream.
    
    Fixed parsing end absolute address.
    
    Signed-off-by: Jiri Engelthaler <engycz@gmail.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e939e24a7d18f47001ca2e16c4028807120337b3
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date:   Wed Nov 21 19:27:23 2012 +0000

    PARISC: fix user-triggerable panic on parisc
    
    commit 441a179dafc0f99fc8b3a8268eef66958621082e upstream.
    
    int sys32_rt_sigprocmask(int how, compat_sigset_t __user *set, compat_sigset_t __user *oset,
                                        unsigned int sigsetsize)
    {
            sigset_t old_set, new_set;
            int ret;
    
            if (set && get_sigset32(set, &new_set, sigsetsize))
    
    ...
    static int
    get_sigset32(compat_sigset_t __user *up, sigset_t *set, size_t sz)
    {
            compat_sigset_t s;
            int r;
    
            if (sz != sizeof *set) panic("put_sigset32()");
    
    In other words, rt_sigprocmask(69, (void *)69, 69) done by 32bit process
    will promptly panic the box.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c06237754a52bb98462ee787f9b001854d884df
Author: James Bottomley <James.Bottomley@HansenPartnership.com>
Date:   Fri Nov 2 12:30:53 2012 +0000

    PARISC: fix virtual aliasing issue in get_shared_area()
    
    commit 949a05d03490e39e773e8652ccab9157e6f595b4 upstream.
    
    On Thu, 2012-11-01 at 16:45 -0700, Michel Lespinasse wrote:
    > Looking at the arch/parisc/kernel/sys_parisc.c implementation of
    > get_shared_area(), I do have a concern though. The function basically
    > ignores the pgoff argument, so that if one creates a shared mapping of
    > pages 0-N of a file, and then a separate shared mapping of pages 1-N
    > of that same file, both will have the same cache offset for their
    > starting address.
    >
    > This looks like this would create obvious aliasing issues. Am I
    > misreading this ? I can't understand how this could work good enough
    > to be undetected, so there must be something I'm missing here ???
    
    This turns out to be correct and we need to pay attention to the pgoff as
    well as the address when creating the virtual address for the area.
    Fortunately, the bug is rarely triggered as most applications which use pgoff
    tend to use large values (git being the primary one, and it uses pgoff in
    multiples of 16MB) which are larger than our cache coherency modulus, so the
    problem isn't often seen in practise.
    
    Reported-by: Michel Lespinasse <walken@google.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de134053d4084ef640a44f9fd848cb607d2d0457
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Wed Nov 21 10:03:10 2012 +0100

    ALSA: hda - Cirrus: Correctly clear line_out_pins when moving to speaker
    
    commit 34c3d1926bdaf45d3a891dd577482abcdd9faa34 upstream.
    
    If this array is not cleared, the jack related code later might
    fail to create "Internal Speaker Phantom Jack" on Dell Inspiron 3420 and
    Dell Vostro 2420.
    
    BugLink: https://bugs.launchpad.net/bugs/1076840
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75c23fc13e0f252cc4f3e52d45116b8642c6c61a
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Wed Oct 31 16:35:30 2012 +0100

    ALSA: ua101, usx2y: fix broken MIDI output
    
    commit e99ddfde6ae0dd2662bb40435696002b590e4057 upstream.
    
    Commit 88a8516a2128 (ALSA: usbaudio: implement USB autosuspend) added
    autosuspend code to all files making up the snd-usb-audio driver.
    However, midi.c is part of snd-usb-lib and is also used by other
    drivers, not all of which support autosuspend.  Thus, calls to
    usb_autopm_get_interface() could fail, and this unexpected error would
    result in the MIDI output being completely unusable.
    
    Make it work by ignoring the error that is expected with drivers that do
    not support autosuspend.
    
    Reported-by: Colin Fletcher <colin.m.fletcher@googlemail.com>
    Reported-by: Devin Venable <venable.devin@gmail.com>
    Reported-by: Dr Nick Bailey <nicholas.bailey@glasgow.ac.uk>
    Reported-by: Jannis Achstetter <jannis_achstetter@web.de>
    Reported-by: Rui Nuno Capela <rncbc@rncbc.org>
    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9cbecb443503ba3dd6a620e8e43a0273e14dc204
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Nov 21 18:37:38 2012 -0500

    drm/radeon: add new SI pci id
    
    commit 0181bd5dea2ed0696f84591a92da0b6a1f1a2e62 upstream.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6417635908e7643800141fc1d6cf7fe43f4fb5e3
Author: Maciej Patelczyk <maciej.patelczyk@intel.com>
Date:   Mon Oct 15 14:29:03 2012 +0200

    SCSI: isci: copy fis 0x34 response into proper buffer
    
    commit 49bd665c5407a453736d3232ee58f2906b42e83c upstream.
    
    SATA MICROCODE DOWNALOAD fails on isci driver. After receiving Register
    Device to Host (FIS 0x34) frame Initiator resets phy.
    In the frame handler routine response (FIS 0x34) was copied into wrong
    buffer and upper layer did not receive any answer which resulted in
    timeout and reset.
    This patch corrects this bug.
    
    Signed-off-by: Maciej Patelczyk <maciej.patelczyk@intel.com>
    Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d8c210794bb574b1d04492332a399e679caaa63
Author: Bing Zhao <bzhao@marvell.com>
Date:   Thu Nov 15 15:58:47 2012 -0800

    mwifiex: fix system hang issue in cmd timeout error case
    
    commit b1a47aa5e1e159e2cb06d7dfcc17ef5149b09299 upstream.
    
    Reported by Tim Shepard:
    I was seeing sporadic failures (wedgeups), and the majority of those
    failures I saw printed the printouts in mwifiex_cmd_timeout_func with
    cmd = 0xe5 which is CMD_802_11_HS_CFG_ENH.  When this happens, two
    minutes later I get notified that the rtcwake thread is blocked, like
    this:
          INFO: task rtcwake:3495 blocked for more than 120 seconds.
    
    To get the hung thread unblocked we wake up the cmd wait queue and
    cancel the ioctl.
    
    Reported-by: Tim Shepard <shep@laptop.org>
    Signed-off-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6966e1b95a3b866bf076176f7cd3f6898e00ee68
Author: Bing Zhao <bzhao@marvell.com>
Date:   Thu Nov 15 15:58:48 2012 -0800

    mwifiex: report error to MMC core if we cannot suspend
    
    commit dd321acddc3be1371263b8c9e6c6f2af89f63d57 upstream.
    
    When host_sleep_config command fails we should return error to
    MMC core to indicate the failure for our device.
    
    The misspelled variable is also removed as it's redundant.
    
    Signed-off-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 383072079d8f54041bf183a2fa70144bebb82ed8
Author: Albert Pool <albertpool@solcon.nl>
Date:   Tue Oct 30 20:58:06 2012 +0100

    rtlwifi: rtl8192cu: Add new USB ID
    
    commit a485e827f07bfdd0762059386e6e787bed6e81ee upstream.
    
    This is an ISY IWL 2000. Probably a clone of Belkin F7D1102 050d:1102.
    Its FCC ID is the same.
    
    Signed-off-by: Albert Pool <albertpool@solcon.nl>
    Acked-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 82c0abae22f37f93655b8adfa304e207f2ffbfa3
Author: Boris Ostrovsky <boris.ostrovsky@amd.com>
Date:   Thu Nov 15 13:41:50 2012 -0500

    x86, microcode, AMD: Add support for family 16h processors
    
    commit 36c46ca4f322a7bf89aad5462a3a1f61713edce7 upstream.
    
    Add valid patch size for family 16h processors.
    
    [ hpa: promoting to urgent/stable since it is hw enabling and trivial ]
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    Acked-by: Andreas Herrmann <herrmann.der.user@googlemail.com>
    Link: http://lkml.kernel.org/r/1353004910-2204-1-git-send-email-boris.ostrovsky@amd.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8433fcce61cd330b1096e2e4d7601d5251d95b6c
Author: Matt Fleming <matt.fleming@intel.com>
Date:   Tue Nov 20 13:07:46 2012 +0000

    x86, efi: Fix processor-specific memcpy() build error
    
    commit 0f905a43ce955b638139bd84486194770a6a2c08 upstream.
    
    Building for Athlon/Duron/K7 results in the following build error,
    
    arch/x86/boot/compressed/eboot.o: In function `__constant_memcpy3d':
    eboot.c:(.text+0x385): undefined reference to `_mmx_memcpy'
    arch/x86/boot/compressed/eboot.o: In function `efi_main':
    eboot.c:(.text+0x1a22): undefined reference to `_mmx_memcpy'
    
    because the boot stub code doesn't link with the kernel proper, and
    therefore doesn't have access to the 3DNow version of memcpy. So,
    follow the example of misc.c and #undef memcpy so that we use the
    version provided by misc.c.
    
    See https://bugzilla.kernel.org/show_bug.cgi?id=50391
    
    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Reported-by: Ryan Underwood <nemesis@icequake.net>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d4f96299744ee7b8e2c4ad30ee915f1671e9fba
Author: Robert Richter <robert.richter@amd.com>
Date:   Mon Sep 3 20:54:48 2012 +0200

    x86-32: Fix invalid stack address while in softirq
    
    commit 1022623842cb72ee4d0dbf02f6937f38c92c3f41 upstream.
    
    In 32 bit the stack address provided by kernel_stack_pointer() may
    point to an invalid range causing NULL pointer access or page faults
    while in NMI (see trace below). This happens if called in softirq
    context and if the stack is empty. The address at &regs->sp is then
    out of range.
    
    Fixing this by checking if regs and &regs->sp are in the same stack
    context. Otherwise return the previous stack pointer stored in struct
    thread_info. If that address is invalid too, return address of regs.
    
     BUG: unable to handle kernel NULL pointer dereference at 0000000a
     IP: [<c1004237>] print_context_stack+0x6e/0x8d
     *pde = 00000000
     Oops: 0000 [#1] SMP
     Modules linked in:
     Pid: 4434, comm: perl Not tainted 3.6.0-rc3-oprofile-i386-standard-g4411a05 #4 Hewlett-Packard HP xw9400 Workstation/0A1Ch
     EIP: 0060:[<c1004237>] EFLAGS: 00010093 CPU: 0
     EIP is at print_context_stack+0x6e/0x8d
     EAX: ffffe000 EBX: 0000000a ECX: f4435f94 EDX: 0000000a
     ESI: f4435f94 EDI: f4435f94 EBP: f5409ec0 ESP: f5409ea0
      DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
     CR0: 8005003b CR2: 0000000a CR3: 34ac9000 CR4: 000007d0
     DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
     DR6: ffff0ff0 DR7: 00000400
     Process perl (pid: 4434, ti=f5408000 task=f5637850 task.ti=f4434000)
     Stack:
      000003e8 ffffe000 00001ffc f4e39b00 00000000 0000000a f4435f94 c155198c
      f5409ef0 c1003723 c155198c f5409f04 00000000 f5409edc 00000000 00000000
      f5409ee8 f4435f94 f5409fc4 00000001 f5409f1c c12dce1c 00000000 c155198c
     Call Trace:
      [<c1003723>] dump_trace+0x7b/0xa1
      [<c12dce1c>] x86_backtrace+0x40/0x88
      [<c12db712>] ? oprofile_add_sample+0x56/0x84
      [<c12db731>] oprofile_add_sample+0x75/0x84
      [<c12ddb5b>] op_amd_check_ctrs+0x46/0x260
      [<c12dd40d>] profile_exceptions_notify+0x23/0x4c
      [<c1395034>] nmi_handle+0x31/0x4a
      [<c1029dc5>] ? ftrace_define_fields_irq_handler_entry+0x45/0x45
      [<c13950ed>] do_nmi+0xa0/0x2ff
      [<c1029dc5>] ? ftrace_define_fields_irq_handler_entry+0x45/0x45
      [<c13949e5>] nmi_stack_correct+0x28/0x2d
      [<c1029dc5>] ? ftrace_define_fields_irq_handler_entry+0x45/0x45
      [<c1003603>] ? do_softirq+0x4b/0x7f
      <IRQ>
      [<c102a06f>] irq_exit+0x35/0x5b
      [<c1018f56>] smp_apic_timer_interrupt+0x6c/0x7a
      [<c1394746>] apic_timer_interrupt+0x2a/0x30
     Code: 89 fe eb 08 31 c9 8b 45 0c ff 55 ec 83 c3 04 83 7d 10 00 74 0c 3b 5d 10 73 26 3b 5d e4 73 0c eb 1f 3b 5d f0 76 1a 3b 5d e8 73 15 <8b> 13 89 d0 89 55 e0 e8 ad 42 03 00 85 c0 8b 55 e0 75 a6 eb cc
     EIP: [<c1004237>] print_context_stack+0x6e/0x8d SS:ESP 0068:f5409ea0
     CR2: 000000000000000a
     ---[ end trace 62afee3481b00012 ]---
     Kernel panic - not syncing: Fatal exception in interrupt
    
    V2:
    * add comments to kernel_stack_pointer()
    * always return a valid stack address by falling back to the address
      of regs
    
    Reported-by: Yang Wei <wei.yang@windriver.com>
    Signed-off-by: Robert Richter <robert.richter@amd.com>
    Link: http://lkml.kernel.org/r/20120912135059.GZ8285@erda.amd.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Jun Zhang <jun.zhang@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ec1dc266051fc58d977a269f9807b4f987a93ef
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Wed Jun 20 11:47:26 2012 -0500

    rtlwifi: rtl8192se: Fix gcc 4.7.x warning
    
    commit f761b6947dde42890beea59b020e1be87491809e upstream.
    
    With gcc 4.7.x, the following warning is issued as the routine that sets
    the array has the possibility of not initializing the values:
    
      CC [M]  drivers/net/wireless/rtlwifi/rtl8192se/phy.o
    drivers/net/wireless/rtlwifi/rtl8192se/phy.c: In function ‘rtl92s_phy_set_txpower’:
    drivers/net/wireless/rtlwifi/rtl8192se/phy.c:1268:23: warning: ‘ofdmpowerLevel[0]’ may be used uninitialized in this function [-Wuninitialized]
    
    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 6df5eea2553e9b66c2ef1f68dfd4b8867e2ff740
Author: Krzysztof Wilczynski <krzysztof.wilczynski@linux.com>
Date:   Wed May 2 11:34:01 2012 +0100

    scsi: aha152x: Fix sparse warning and make printing pointer address more portable.
    
    commit b631cf1f899f9d2e449884dbccc34940637c639f upstream.
    
    This is to change use of "0x%08x" in favour of "%p" as per ../Documentation/printk-formats.txt,
    which also takes care about the following warning during compilation time:
    
      drivers/scsi/aha152x.c: In function ‘get_command’:
      drivers/scsi/aha152x.c:2987: warning: cast from pointer to integer of different size
    
    Signed-off-by: Krzysztof Wilczynski <krzysztof.wilczynski@linux.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cbe6d9bd065c64cb9eac67d9a12001e095f875b9
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Jun 21 23:36:35 2012 -0700

    mvsas: remove unused variable in mvs_task_exec()
    
    commit cca85013ef54f66eb4616e6f3860549a96c8338b upstream.
    
    We don't use "dev" any more after 07ec747a5f ("libsas: remove
    ata_port.lock management duties from lldds") and it causes a compile
    warning.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Xiangliang Yu <yuxiangl@marvell.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 896c631494d7ed4e609ef7b7b312b8a19b21f394
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue May 29 15:07:26 2012 -0700

    drivers/leds/leds-lp5521.c: fix lp5521_read() error handling
    
    commit 5bc9ad774c063f6b41965e7314f2c26aa5e465a0 upstream.
    
    Gcc 4.6.2 complains that:
    
      drivers/leds/leds-lp5521.c: In function `lp5521_load_program':
      drivers/leds/leds-lp5521.c:214:21: warning: `mode' may be used uninitialized in this function [-Wuninitialized]
      drivers/leds/leds-lp5521.c: In function `lp5521_probe':
      drivers/leds/leds-lp5521.c:788:5: warning: `buf' may be used uninitialized in this function [-Wuninitialized]
      drivers/leds/leds-lp5521.c:740:6: warning: `ret' may be used uninitialized in this function [-Wuninitialized]
    
    These are real problems if lp5521_read() returns an error.  When that
    happens we should handle it, instead of ignoring it or doing a bitwise
    OR with all the other error codes and continuing.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Milo <Milo.Kim@ti.com>
    Cc: Richard Purdie <rpurdie@rpsys.net>
    Cc: Bryan Wu <bryan.wu@canonical.com>
    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 d4cad86a445a5229b58bbb7beaa0753f09314855
Author: Daniel Mack <zonque@gmail.com>
Date:   Mon Jun 18 21:16:31 2012 +0200

    ALSA: snd-usb-caiaq: initialize card pointer
    
    commit da185443c12f5ef7416af50293833a5654854186 upstream.
    
    Fixes the following warning:
    
      CC [M]  sound/usb/caiaq/device.o
    sound/usb/caiaq/device.c: In function ‘snd_probe’:
    sound/usb/caiaq/device.c:500:16: warning: ‘card’ may be used
    uninitialized in this function [-Wmaybe-uninitialized]
    
    Signed-off-by: Daniel Mack <zonque@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2214cc8d585df2bbfc894d0a3acc5a629fa1a985
Author: Szymon Janc <szymon.janc@tieto.com>
Date:   Fri Jun 8 11:33:33 2012 +0200

    Bluetooth: Fix using uninitialized option in RFCMode
    
    commit 8f321f853ea33330c7141977cd34804476e2e07e upstream.
    
    If remote device sends bogus RFC option with invalid length,
    undefined options values are used. Fix this by using defaults when
    remote misbehaves.
    
    This also fixes the following warning reported by gcc 4.7.0:
    
    net/bluetooth/l2cap_core.c: In function 'l2cap_config_rsp':
    net/bluetooth/l2cap_core.c:3302:13: warning: 'rfc.max_pdu_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
    net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.max_pdu_size' was declared here
    net/bluetooth/l2cap_core.c:3298:25: warning: 'rfc.monitor_timeout' may be used uninitialized in this function [-Wmaybe-uninitialized]
    net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.monitor_timeout' was declared here
    net/bluetooth/l2cap_core.c:3297:25: warning: 'rfc.retrans_timeout' may be used uninitialized in this function [-Wmaybe-uninitialized]
    net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.retrans_timeout' was declared here
    net/bluetooth/l2cap_core.c:3295:2: warning: 'rfc.mode' may be used uninitialized in this function [-Wmaybe-uninitialized]
    net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.mode' was declared here
    
    Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f442c50be050521667a8974fcc80cc8b881b2a6
Author: Keith Busch <keith.busch@intel.com>
Date:   Fri Jul 27 11:53:28 2012 -0600

    NVMe: Fix uninitialized iod compiler warning
    
    commit c7d36ab8fa04c213328119a9c0d66985fe204ee5 upstream.
    
    Signed-off-by: Keith Busch <keith.busch@intel.com>
    Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32e11d55e7997fe45c452b71014ee934054a1245
Author: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
Date:   Mon Jun 25 17:47:49 2012 -0300

    UBIFS: fix compilation warning
    
    commit 782759b9f5f5223e0962af60c3457c912fab755f upstream.
    
    Fix the following compilation warning:
    
    fs/ubifs/dir.c: In function 'ubifs_rename':
    fs/ubifs/dir.c:972:15: warning: 'saved_nlink' may be used uninitialized
    in this function
    
    Use the 'uninitialized_var()' macro to get rid of this false-positive.
    
    Artem: massaged the patch a bit.
    
    Signed-off-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>