Linux 3.4.3

commit a694d36e943f3fff08e19d942d4db819c94401c1
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Jun 17 11:21:44 2012 -0700

    Linux 3.4.3

commit 0d48d35de9b7dbe7e68d2a741c2f8d6a9e2eed3f
Author: Andy Whitcroft <apw@canonical.com>
Date:   Fri May 4 22:15:11 2012 +0100

    ata_piix: defer disks to the Hyper-V drivers by default

    commit cd006086fa5d91414d8ff9ff2b78fbb593878e3c upstream.

    When we are hosted on a Microsoft Hyper-V hypervisor the guest disks
    are exposed both via the Hyper-V paravirtualised drivers and via an
    emulated SATA disk drive.  In this case we want to use the paravirtualised
    drivers if we can as they are much more efficient.  Note that the Hyper-V
    paravirtualised drivers only expose the virtual hard disk devices, the
    CDROM/DVD devices must still be enumerated.

    Mark the host controller ATA_HOST_IGNORE_ATA to prevent enumeration of
    disk devices.

    BugLink: http://bugs.launchpad.net/bugs/929545
    BugLink: http://bugs.launchpad.net/bugs/942316
    Signed-off-by: Andy Whitcroft <apw@canonical.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Cc: Victor Miasnikov <vvm@tut.by>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54a40b2cf40d655dbbdcc017288be75b1ae1b701
Author: Andy Whitcroft <apw@canonical.com>
Date:   Fri May 4 22:15:10 2012 +0100

    libata: add a host flag to ignore detected ATA devices

    commit db63a4c8115a0bb904496e1cdd3e7488e68b0d06 upstream.

    Where devices are visible via more than one host we sometimes wish to
    indicate that cirtain devices should be ignored on a specific host.  Add a
    host flag indicating that this host wishes to ignore ATA specific devices.

    Signed-off-by: Andy Whitcroft <apw@canonical.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Cc: Victor Miasnikov <vvm@tut.by>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9abcb7517f13aa54152bee6370538b8f56893349
Author: Pavel Shilovsky <piastry@etersoft.ru>
Date:   Thu May 10 19:49:38 2012 +0400

    fuse: fix stat call on 32 bit platforms

    commit 45c72cd73c788dd18c8113d4a404d6b4a01decf1 upstream.

    Now we store attr->ino at inode->i_ino, return attr->ino at the
    first time and then return inode->i_ino if the attribute timeout
    isn't expired. That's wrong on 32 bit platforms because attr->ino
    is 64 bit and inode->i_ino is 32 bit in this case.

    Fix this by saving 64 bit ino in fuse_inode structure and returning
    it every time we call getattr. Also squash attr->ino into inode->i_ino
    explicitly.

    Signed-off-by: Pavel Shilovsky <piastry@etersoft.ru>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5b9a38383178758ddf671b7a5551afab4e504b2
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jun 4 17:05:40 2012 +0100

    drm/i915: Mark the ringbuffers as being in the GTT domain

    commit 3eef8918ff440837f6af791942d8dd07e1a268ee upstream.

    By correctly describing the rinbuffers as being in the GTT domain, it
    appears that we are more careful with the management of the CPU cache
    upon resume and so prevent some coherency issue when submitting commands
    to the GPU later. A secondary effect is that the debug logs are then
    consistent with the actual usage (i.e. they no longer describe the
    ringbuffers as being in the CPU write domain when we are accessing them
    through an wc iomapping.)

    Reported-and-tested-by: Daniel Gnoutcheff <daniel@gnoutcheff.name>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41092
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1e23cbad36dfccd873b19944ebb2d1712a673a7
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Sat Jun 9 10:57:41 2012 -0400

    drm/radeon: fix tiling and command stream checking on evergreen v3

    commit d26098759cf6d32148649c165f87a7590bc25b89 upstream.

    Fix regresson since the introduction of command stream checking on
    evergreen (thread referenced below). Issue is cause by ddx allocating
    bo with formula width*height*bpp while programming the GPU command
    stream with ALIGN(height, 8). In some case (where page alignment does
    not hide the extra size bo should be according to height alignment)
    the kernel will reject the command stream.

    This patch reprogram the command stream to slice - 1 (slice is
    a derivative value from height) which avoid rejecting the command
    stream while keeping the value of command stream checking from a
    security point of view.

    This patch also fix wrong computation of layer size for 2D tiled
    surface. Which should fix issue when 2D color tiling is enabled.
    This dump the radeon KMS_DRIVER_MINOR so userspace can know if
    they are on a fixed kernel or not.

    https://lkml.org/lkml/2012/6/3/80
    https://bugs.freedesktop.org/show_bug.cgi?id=50892
    https://bugs.freedesktop.org/show_bug.cgi?id=50857

    !!! STABLE need a custom version of this patch for 3.4 !!!

    v2: actually bump the minor version and add comment about stable
    v3: do compute the height the ddx was trying to use

    [airlied: drop left over debug]

    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8997b2223b9d81f6085764d08f9de3a2da760333
Author: Dimitri Sivanich <sivanich@sgi.com>
Date:   Tue Jun 5 13:44:36 2012 -0500

    sched: Fix the relax_domain_level boot parameter

    commit a841f8cef4bb124f0f5563314d0beaf2e1249d72 upstream.

    It does not get processed because sched_domain_level_max is 0 at the
    time that setup_relax_domain_level() is run.

    Simply accept the value as it is, as we don't know the value of
    sched_domain_level_max until sched domain construction is completed.

    Fix sched_relax_domain_level in cpuset.  The build_sched_domain() routine calls
    the set_domain_attribute() routine prior to setting the sd->level, however,
    the set_domain_attribute() routine relies on the sd->level to decide whether
    idle load balancing will be off/on.

    Signed-off-by: Dimitri Sivanich <sivanich@sgi.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/20120605184436.GA15668@sgi.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e2b0c74fa03b8788f8f7e9bcc778463e53c49a9
Author: Alan Cox <alan@linux.intel.com>
Date:   Wed Apr 25 14:33:33 2012 +0100

    acpi_video: fix leaking PCI references

    commit cfb46f433a4da97c31780e08a259fac2cb6bd61f upstream.

    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Acked-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f68127d9cf4b358060ce5f9906246262a56f179
Author: Alan Cox <alan@linux.intel.com>
Date:   Wed Apr 25 14:34:04 2012 +0100

    gma500: don't register the ACPI video bus

    commit 155689defc782b486a7e6776a57ecc4ebb37ed52 upstream.

    We are not yet ready for this and it makes a mess on some devices.

    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8bf1e7c7623585d4742d283c027b83f212477af
Author: AnilKumar Ch <anilkumar@ti.com>
Date:   Wed May 23 17:45:11 2012 +0530

    can: c_can: fix race condition in c_can_open()

    commit f461f27a4436dbe691908fe08b867ef888848cc3 upstream.

    Fix the issue of C_CAN interrupts getting disabled forever when canconfig
    utility is used multiple times. According to NAPI usage we disable all
    the hardware interrupts in ISR and re-enable them in poll(). Current
    implementation calls napi_enable() after hardware interrupts are enabled.
    If we get any interrupts between these two steps then we do not process
    those interrupts because napi is not enabled. Mostly these interrupts
    come because of STATUS is not 0x7 or ERROR interrupts. If napi_enable()
    happens before HW interrupts enabled then c_can_poll() function will be
    called eventual re-enabling.

    This patch moves the napi_enable() call before interrupts enabled.

    Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
    Acked-by: Wolfgang Grandegger <wg@grandegger.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8414ac8c1e0ba119febfd2e46c24afda7768cee3
Author: AnilKumar Ch <anilkumar@ti.com>
Date:   Wed May 23 17:45:10 2012 +0530

    can: c_can: fix an interrupt thrash issue with c_can driver

    commit 148c87c89e1a8863d3d965179f3ab1a06490569e upstream.

    This patch fixes an interrupt thrash issue with c_can driver.

    In c_can_isr() function interrupts are disabled and enabled only in
    c_can_poll() function. c_can_isr() & c_can_poll() both read the
    irqstatus flag. However, irqstatus is always read as 0 in c_can_poll()
    because all C_CAN interrupts are disabled in c_can_isr(). This causes
    all interrupts to be re-enabled in c_can_poll() which in turn causes
    another interrupt since the event is not really handled. This keeps
    happening causing a flood of interrupts.

    To fix this, read the irqstatus register in isr and use the same cached
    value in the poll function.

    Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
    Acked-by: Wolfgang Grandegger <wg@grandegger.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f939c6c260e4fe2b2b5e9b2d0f9a5103e28d23d5
Author: AnilKumar Ch <anilkumar@ti.com>
Date:   Wed May 23 17:45:09 2012 +0530

    can: c_can: fix "BUG! echo_skb is occupied!" during transmit

    commit 617caccebe451716df21c069b079d5936ed7b0f3 upstream.

    This patch fixes an issue with transmit routine, which causes
    "can_put_echo_skb: BUG! echo_skb is occupied!" message when
    using "cansequence -p" on D_CAN controller.

    In c_can driver, while transmitting packets tx_echo flag holds
    the no of can frames put for transmission into the hardware.

    As the comment above c_can_do_tx() indicates, if we find any packet
    which is not transmitted then we should stop looking for more.
    In the current implementation this is not taken care of causing the
    said message.

    Also, fix the condition used to find if the packet is transmitted
    or not. Current code skips the first tx message object and ends up
    checking one extra invalid object.

    While at it, fix the comment on top of c_can_do_tx() to use the
    terminology "packet" instead of "package" since it is more
    standard.

    Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
    Acked-by: Wolfgang Grandegger <wg@grandegger.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a06d0d26d87cc397e11e75f6c1fc54d191bf60ef
Author: Bjørn Mork <bjorn@mork.no>
Date:   Tue Jun 5 21:18:10 2012 +0000

    net: sierra_net: device IDs for Aircard 320U++

    commit dd03cff23d694cfb0fdae80cb618e7ced05ea696 upstream.

    Adding device IDs for Aircard 320U and two other devices
    found in the out-of-tree version of this driver.

    Cc: linux@sierrawireless.com
    Cc: Autif Khan <autif.mlist@gmail.com>
    Cc: Tom Cassidy <tomas.cassidy@gmail.com>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a4ea49398c1e32475a65a34cd4ff5de64449bca
Author: Xose Vazquez Perez <xose.vazquez@gmail.com>
Date:   Tue Apr 17 16:28:05 2012 +0200

    wireless: rt2x00: rt2800usb more devices were identified

    commit e828b9fb4f6c3513950759d5fb902db5bd054048 upstream.

    found in 2012_03_22_RT5572_Linux_STA_v2.6.0.0_DPO

    RT3070:
    (0x2019,0x5201)  Planex Communications, Inc. RT8070
    (0x7392,0x4085)  2L Central Europe BV 8070
    7392 is Edimax

    RT35xx:
    (0x1690,0x0761) Askey
    was Fujitsu Stylistic 550, but 1690 is Askey

    Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
    Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb8e114490823c581899112e82ee710ccd14fa11
Author: Xose Vazquez Perez <xose.vazquez@gmail.com>
Date:   Tue Apr 17 01:50:32 2012 +0200

    wireless: rt2x00: rt2800usb add more devices ids

    commit 63b376411173c343bbcb450f95539da91f079e0c upstream.

    They were taken from ralink drivers:
    2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO
    2012_03_22_RT5572_Linux_STA_v2.6.0.0_DPO

    0x1eda,0x2210 RT3070 Airties

    0x083a,0xb511 RT3370 Panasonic
    0x0471,0x20dd RT3370 Philips

    0x1690,0x0764 RT35xx Askey
    0x0df6,0x0065 RT35xx Sitecom
    0x0df6,0x0066 RT35xx Sitecom
    0x0df6,0x0068 RT35xx Sitecom

    0x2001,0x3c1c RT5370 DLink
    0x2001,0x3c1d RT5370 DLink

    2001 is D-Link not Alpha

    Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
    Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ab37d70078783aa8dd6dbec0e614c83ab694cb8
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Fri Jun 1 11:29:40 2012 +0200

    rt2x00: use atomic variable for seqno

    commit e5851dac2c95af7159716832300b9f50c62c648e upstream.

    Remove spinlock as atomic_t can be used instead. Note we use only 16
    lower bits, upper bits are changed but we impilcilty cast to u16.

    This fix possible deadlock on IBSS mode reproted by lockdep:

    =================================
    [ INFO: inconsistent lock state ]
    3.4.0-wl+ #4 Not tainted
    ---------------------------------
    inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
    kworker/u:2/30374 [HC0[0]:SC0[0]:HE1:SE1] takes:
     (&(&intf->seqlock)->rlock){+.?...}, at: [<f9979a20>] rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
    {IN-SOFTIRQ-W} state was registered at:
      [<c04978ab>] __lock_acquire+0x47b/0x1050
      [<c0498504>] lock_acquire+0x84/0xf0
      [<c0835733>] _raw_spin_lock+0x33/0x40
      [<f9979a20>] rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
      [<f9979f2a>] rt2x00queue_write_tx_frame+0x1a/0x300 [rt2x00lib]
      [<f997834f>] rt2x00mac_tx+0x7f/0x380 [rt2x00lib]
      [<f98fe363>] __ieee80211_tx+0x1b3/0x300 [mac80211]
      [<f98ffdf5>] ieee80211_tx+0x105/0x130 [mac80211]
      [<f99000dd>] ieee80211_xmit+0xad/0x100 [mac80211]
      [<f9900519>] ieee80211_subif_start_xmit+0x2d9/0x930 [mac80211]
      [<c0782e87>] dev_hard_start_xmit+0x307/0x660
      [<c079bb71>] sch_direct_xmit+0xa1/0x1e0
      [<c0784bb3>] dev_queue_xmit+0x183/0x730
      [<c078c27a>] neigh_resolve_output+0xfa/0x1e0
      [<c07b436a>] ip_finish_output+0x24a/0x460
      [<c07b4897>] ip_output+0xb7/0x100
      [<c07b2d60>] ip_local_out+0x20/0x60
      [<c07e01ff>] igmpv3_sendpack+0x4f/0x60
      [<c07e108f>] igmp_ifc_timer_expire+0x29f/0x330
      [<c04520fc>] run_timer_softirq+0x15c/0x2f0
      [<c0449e3e>] __do_softirq+0xae/0x1e0
    irq event stamp: 18380437
    hardirqs last  enabled at (18380437): [<c0526027>] __slab_alloc.clone.3+0x67/0x5f0
    hardirqs last disabled at (18380436): [<c0525ff3>] __slab_alloc.clone.3+0x33/0x5f0
    softirqs last  enabled at (18377616): [<c0449eb3>] __do_softirq+0x123/0x1e0
    softirqs last disabled at (18377611): [<c041278d>] do_softirq+0x9d/0xe0

    other info that might help us debug this:
     Possible unsafe locking scenario:

           CPU0
           ----
      lock(&(&intf->seqlock)->rlock);
      <Interrupt>
        lock(&(&intf->seqlock)->rlock);

     *** DEADLOCK ***

    4 locks held by kworker/u:2/30374:
     #0:  (wiphy_name(local->hw.wiphy)){++++.+}, at: [<c045cf99>] process_one_work+0x109/0x3f0
     #1:  ((&sdata->work)){+.+.+.}, at: [<c045cf99>] process_one_work+0x109/0x3f0
     #2:  (&ifibss->mtx){+.+.+.}, at: [<f98f005b>] ieee80211_ibss_work+0x1b/0x470 [mac80211]
     #3:  (&intf->beacon_skb_mutex){+.+...}, at: [<f997a644>] rt2x00queue_update_beacon+0x24/0x50 [rt2x00lib]

    stack backtrace:
    Pid: 30374, comm: kworker/u:2 Not tainted 3.4.0-wl+ #4
    Call Trace:
     [<c04962a6>] print_usage_bug+0x1f6/0x220
     [<c0496a12>] mark_lock+0x2c2/0x300
     [<c0495ff0>] ? check_usage_forwards+0xc0/0xc0
     [<c04978ec>] __lock_acquire+0x4bc/0x1050
     [<c0527890>] ? __kmalloc_track_caller+0x1c0/0x1d0
     [<c0777fb6>] ? copy_skb_header+0x26/0x90
     [<c0498504>] lock_acquire+0x84/0xf0
     [<f9979a20>] ? rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
     [<c0835733>] _raw_spin_lock+0x33/0x40
     [<f9979a20>] ? rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
     [<f9979a20>] rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
     [<f997a5cf>] rt2x00queue_update_beacon_locked+0x5f/0xb0 [rt2x00lib]
     [<f997a64d>] rt2x00queue_update_beacon+0x2d/0x50 [rt2x00lib]
     [<f9977e3a>] rt2x00mac_bss_info_changed+0x1ca/0x200 [rt2x00lib]
     [<f9977c70>] ? rt2x00mac_remove_interface+0x70/0x70 [rt2x00lib]
     [<f98e4dd0>] ieee80211_bss_info_change_notify+0xe0/0x1d0 [mac80211]
     [<f98ef7b8>] __ieee80211_sta_join_ibss+0x3b8/0x610 [mac80211]
     [<c0496ab4>] ? mark_held_locks+0x64/0xc0
     [<c0440012>] ? virt_efi_query_capsule_caps+0x12/0x50
     [<f98efb09>] ieee80211_sta_join_ibss+0xf9/0x140 [mac80211]
     [<f98f0456>] ieee80211_ibss_work+0x416/0x470 [mac80211]
     [<c0496d8b>] ? trace_hardirqs_on+0xb/0x10
     [<c077683b>] ? skb_dequeue+0x4b/0x70
     [<f98f207f>] ieee80211_iface_work+0x13f/0x230 [mac80211]
     [<c045cf99>] ? process_one_work+0x109/0x3f0
     [<c045d015>] process_one_work+0x185/0x3f0
     [<c045cf99>] ? process_one_work+0x109/0x3f0
     [<f98f1f40>] ? ieee80211_teardown_sdata+0xa0/0xa0 [mac80211]
     [<c045ed86>] worker_thread+0x116/0x270
     [<c045ec70>] ? manage_workers+0x1e0/0x1e0
     [<c0462f64>] kthread+0x84/0x90
     [<c0462ee0>] ? __init_kthread_worker+0x60/0x60
     [<c083d382>] kernel_thread_helper+0x6/0x10

    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
    Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6fa9c3400dd4cbf30c597dbde5d6abbc12b9764d
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Jun 5 12:16:50 2012 +0200

    cfg80211: fix interface combinations check

    commit 463454b5dbd8dbab6e2fc6c557329e5b811b9c32 upstream.

    If a given interface combination doesn't contain
    a required interface type then we missed checking
    that and erroneously allowed it even though iface
    type wasn't there at all. Add a check that makes
    sure that all interface types are accounted for.

    Reported-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6382a8c4d9287ddca721edf622100e33c4546b9
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Tue Jun 12 13:15:12 2012 +0200

    ALSA: HDA: Pin fixup for Zotac Z68 motherboard

    commit edfe3bfc1b779ddda9bcff523eb022dda37b93c8 upstream.

    Pin 0x1b was connected to the front panel connector, which according to
    the HDA standard should contain a mic and a headphone. In this case,
    the headphone was listed as "line out" by BIOS.

    BugLink: https://bugs.launchpad.net/bugs/993162
    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 508cb55ffc236b401a84ec7e5caec470e0f85a89
Author: Seth Forshee <seth.forshee@canonical.com>
Date:   Fri Jun 1 09:13:17 2012 -0500

    bcma: add ext PA workaround for BCM4331 and BCM43431

    commit 69aaedd3cfd23b2c732e3cf1227370a35f5c89d4 upstream.

    MacBook Pro models with BCM4331 wireless have been found to have the ext
    PA lines disabled after resuming from S3 without external power attach.
    This causes them to be unable to transmit. Add a workaround to ensure
    that the ext PA lines are enabled on BCM4331. Also extend all handling
    of ext PA line muxing to BCM43431 as is done in the Broadcom SDK.

    BugLink: http://bugs.launchpad.net/bugs/925577
    Cc: Arend van Spriel <arend@broadcom.com>
    Cc: Hauke Mehrtens <hauke@hauke-m.de>
    Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38a3c37777b7a0864b70480067b8606100139c11
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Tue Jun 5 12:31:32 2012 +0100

    ASoC: wm8994: Apply volume updates with clocks enabled

    commit bfd37bb5f681961e255fd2f346c20fdae2ef3f27 upstream.

    Volume updates may not be acted upon if there is no clock applied when
    the volume update is written. Ensure this doesn't happen by writing out
    registers with volume updates after we enable each of the clocks.

    There are more registers updated than before as previously we were
    relying on wm_hubs to set those for controls it manages.

    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d539f9e66ea9aaf4998e98fbfe719f99d5f6590
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Tue Jun 5 12:25:19 2012 +0100

    ASoC: wm8994: Ensure all AIFnCLK events are run from the _late variants

    commit c8fdc1b56611faa7b38eab6b99da5e20113661ff upstream.

    Ensure that all the actions get taken at appropriate times by calling the
    _PRE and _POST events for the aifNclk_ev functions explicitly.

    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 073e100877a39f36163398cde868e98fa6d3f0a1
Author: Arik Nemtsov <arik@wizery.com>
Date:   Sun Jun 3 23:32:32 2012 +0300

    mac80211: fix non RCU-safe sta_list manipulation

    commit 794454ce72a298de6f4536ade597bdcc7dcde7c7 upstream.

    sta_info_cleanup locks the sta_list using rcu_read_lock however
    the delete operation isn't rcu safe. A race between sta_info_cleanup
    timer being called and a STA being removed can occur which leads
    to a panic while traversing sta_list. Fix this by switching to the
    RCU-safe versions.

    Reported-by: Eyal Shapira <eyal@wizery.com>
    Signed-off-by: Arik Nemtsov <arik@wizery.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4bb7f49f4d5ea7a287899178df55b4725bb32d2
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu May 31 15:09:27 2012 +0200

    mac80211: clean up remain-on-channel on interface stop

    commit 71ecfa1893034eeb1c93e02e22ee2ad26d080858 upstream.

    When any interface goes down, it could be the one that we
    were doing a remain-on-channel with. We therefore need to
    cancel the remain-on-channel and flush the related work
    structs so they don't run after the interface has been
    removed or even destroyed.

    It's also possible in this case that an off-channel SKB
    was never transmitted, so free it if this is the case.
    Note that this can also happen if the driver finishes
    the off-channel period without ever starting it.

    Reported-by: Nirav Shah <nirav.j2.shah@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 721632c39add11e5d5fa5dd8b956dcae63d02b17
Author: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Date:   Wed May 30 11:39:33 2012 +0200

    mac80211: fix error in station state transitions during reconfig

    commit bd34ab62a3297bd7685da11b0cbe05ae4cd8b02c upstream.

    As part of hardware reconfig mac80211 tries
    to restore the station state to its values
    before the hardware reconfig, but it only
    goes to the last-state - 1. Fix this
    off-by-one error.

    Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
    Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4c3d440c898725132291e5171b3244c2027c30e
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Wed Jun 6 13:55:02 2012 +0200

    iwlwifi: disable the buggy chain extension feature in HW

    commit d012d04e4d6312ea157b6cf19e9689af934f5aa7 upstream.

    This feature has been reported to be buggy and enabled by
    default. We therefore need to disable it manually.

    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ca732f5673f2a1fa9e4d6451259ae5891fa6b60
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Wed Jun 6 09:13:36 2012 +0200

    iwlwifi: don't mess up the SCD when removing a key

    commit d6ee27eb13beab94056e0de52d81220058ca2297 upstream.

    When we remove a key, we put a key index which was supposed
    to tell the fw that we are actually removing the key. But
    instead the fw took that index as a valid index and messed
    up the SRAM of the device.

    This memory corruption on the device mangled the data of
    the SCD. The impact on the user is that SCD queue 2 got
    stuck after having removed keys.
    The message is the log that was printed is:

    Queue 2 stuck for 10000ms

    This doesn't seem to fix the higher queues that get stuck
    from time to time.

    Reviewed-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a4c9cbfe943986db40b699c5320fdacfa2885b8
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Jun 5 09:38:35 2012 +0200

    iwlwifi: unregister LEDs if mac80211 registration fails

    commit 0e1fa7ef25004b9c1a14147bce61c15c2f1c6744 upstream.

    Otherwise the LEDs stick around and cause issues the
    next time around since they're still there but not
    really hooked up.

    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20528f7e3c40fa95faf5ebc028c16c40216d0b76
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Jun 4 13:43:11 2012 +0200

    iwlwifi: disable WoWLAN if !CONFIG_PM_SLEEP

    commit fcb6ff5e2cb83e1de10631f6621f45ca3401bf61 upstream.

    If CONFIG_PM_SLEEP is disabled, then iwlwifi doesn't
    support suspend/resume handlers and thus mac80211
    (correctly) refuses advertising WoWLAN. Disable
    WoWLAN in the driver in this case.

    Reported-by: Sebastian Kemper <sebastian_ml@gmx.net>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e050dfccceeb07641b8cf50618eb71e5208a6dc
Author: Josef Bacik <josef@redhat.com>
Date:   Wed May 23 16:10:14 2012 -0400

    Btrfs: fall back to non-inline if we don't have enough space

    commit 2adcac1a7331d93a17285804819caa96070b231f upstream.

    If cow_file_range_inline fails with ENOSPC we abort the transaction which
    isn't very nice.  This really shouldn't be happening anyways but there's no
    sense in making it a horrible error when we can easily just go allocate
    normal data space for this stuff.  Thanks,

    Signed-off-by: Josef Bacik <josef@redhat.com>
    Acked-by: Chris Mason <chris.mason@fusionio.com>
    Cc: Alexandre Oliva <oliva@lsd.ic.unicamp.br>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e82c95f9f0cb025da8e1af6df1c29080a78d0f84
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Tue Jun 12 13:28:42 2012 +0200

    drm/ttm: Fix buffer object metadata accounting regression v2

    commit a393c730ab69617c3291a3b0b2a228c9be2fc28c upstream.

    A regression was introduced in the 3.3 rc series, commit
    "drm/ttm: simplify memory accounting for ttm user v2",
    causing the metadata of buffer objects created using the ttm_bo_create()
    function to be accounted twice.
    That causes massive leaks with the vmwgfx driver running for example
    SpecViewperf Catia-03 test 2, eventually killing the app.

    Furthermore, the same commit introduces a regression where
    metadata accounting is leaked if a buffer object is
    initialized with an illegal size. This is also fixed with this commit.

    v2: Fixed an error path and removed an unused variable.

    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Jerome Glisse <jglisse@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc62e8bf1f779a54369e71e665211140a254df5c
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed May 30 01:43:08 2012 +0200

    crypto: aesni-intel - fix unaligned cbc decrypt for x86-32

    commit 7c8d51848a88aafdb68f42b6b650c83485ea2f84 upstream.

    The 32 bit variant of cbc(aes) decrypt is using instructions requiring
    128 bit aligned memory locations but fails to ensure this constraint in
    the code. Fix this by loading the data into intermediate registers with
    load unaligned instructions.

    This fixes reported general protection faults related to aesni.

    References: https://bugzilla.kernel.org/show_bug.cgi?id=43223
    Reported-by: Daniel <garkein@mailueberfall.de>
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25ffc87a852380b75e5ce9618164f506b1254112
Author: Peter Korsgaard <jacmet@sunsite.dk>
Date:   Thu May 31 20:53:08 2012 +1000

    hwrng: atmel-rng - fix race condition leading to repeated bits

    commit 121daad8fd1dce63076fa55aaedd5dc3f981b334 upstream.

    Data valid gets cleared by reading the ISR (status register) and NOT from
    reading ODATA (data register). A new data word can become available between
    checking ISR and reading ODATA, causing us to reuse the same data word next
    time atmel_trng_read() gets called, if that happens before the following
    data word is ready.

    With this fixed, rngtest no longer complains of 'Continous run' errors.
    Before:

    rngtest -c 1000 < /dev/hwrng
    rngtest 3
    Copyright (c) 2004 by Henrique de Moraes Holschuh
    This is free software; see the source for copying conditions.  There is NO warr.

    rngtest: starting FIPS tests...
    rngtest: bits received from input: 20000032
    rngtest: FIPS 140-2 successes: 923
    rngtest: FIPS 140-2 failures: 77
    rngtest: FIPS 140-2(2001-10-10) Monobit: 0
    rngtest: FIPS 140-2(2001-10-10) Poker: 0
    rngtest: FIPS 140-2(2001-10-10) Runs: 1
    rngtest: FIPS 140-2(2001-10-10) Long run: 0
    rngtest: FIPS 140-2(2001-10-10) Continuous run: 76
    rngtest: input channel speed: (min=721.402; avg=46003.510; max=49321.338)Kibitss
    rngtest: FIPS tests speed: (min=11.442; avg=12.714; max=12.801)Mibits/s
    rngtest: Program run time: 1931860 microseconds

    After:

    rngtest -c 1000 < /dev/hwrng
    rngtest 3
    Copyright (c) 2004 by Henrique de Moraes Holschuh
    This is free software; see the source for copying conditions.  There is NO warr.

    rngtest: starting FIPS tests...
    rngtest: bits received from input: 20000032
    rngtest: FIPS 140-2 successes: 1000
    rngtest: FIPS 140-2 failures: 0
    rngtest: FIPS 140-2(2001-10-10) Monobit: 0
    rngtest: FIPS 140-2(2001-10-10) Poker: 0
    rngtest: FIPS 140-2(2001-10-10) Runs: 0
    rngtest: FIPS 140-2(2001-10-10) Long run: 0
    rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
    rngtest: input channel speed: (min=777.518; avg=36988.482; max=43115.342)Kibitss
    rngtest: FIPS tests speed: (min=11.951; avg=12.715; max=12.887)Mibits/s
    rngtest: Program run time: 2035543 microseconds

    Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
    Reported-by: George Pontis <GPontis@z9.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc3aeacdba55676938fc11e00e13699141b9aeb8
Author: Borislav Petkov <borislav.petkov@amd.com>
Date:   Mon Apr 16 18:01:53 2012 +0200

    x86, MCE, AMD: Make APIC LVT thresholding interrupt optional

    commit f227d4306cf30e1d5b6f231e8ef9006c34f3d186 upstream.

    Currently, the APIC LVT interrupt for error thresholding is implicitly
    enabled. However, there are models in the F15h range which do not enable
    it. Make the code machinery which sets up the APIC interrupt support
    an optional setting and add an ->interrupt_capable member to the bank
    representation mirroring that capability and enable the interrupt offset
    programming only if it is true.

    Simplify code and fixup comment style while at it.

    Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
    Cc: Robert Richter <robert.richter@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d9fe5b77cbabd1805b30418ba32b3c1389303d0
Author: Cliff Wickman <cpw@sgi.com>
Date:   Thu Jun 7 08:31:40 2012 -0500

    x86/uv: Fix UV2 BAU legacy mode

    commit d5d2d2eea84b0d8450b082edbc3dbde41fb8bfd8 upstream.

    The SGI Altix UV2 BAU (Broadcast Assist Unit) as used for
    tlb-shootdown (selective broadcast mode) always uses UV2
    broadcast descriptor format. There is no need to clear the
    'legacy' (UV1) mode, because the hardware always uses UV2 mode
    for selective broadcast.

    But the BIOS uses general broadcast and legacy mode, and the
    hardware pays attention to the legacy mode bit for general
    broadcast. So the kernel must not clear that mode bit.

    Signed-off-by: Cliff Wickman <cpw@sgi.com>
    Link: http://lkml.kernel.org/r/E1SccoO-0002Lh-Cb@eag09.americas.sgi.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c573b3798f5fd9e24f9ec23a39c4915c6e024faf
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Thu Jun 7 18:56:06 2012 -0400

    ext4: fix the free blocks calculation for ext3 file systems w/ uninit_bg

    commit b0dd6b70f0fda17ae9762fbb72d98e40a4f66556 upstream.

    Ext3 filesystems that are converted to use as many ext4 file system
    features as possible will enable uninit_bg to speed up e2fsck times.
    These file systems will have a native ext3 layout of inode tables and
    block allocation bitmaps (as opposed to ext4's flex_bg layout).
    Unfortunately, in these cases, when first allocating a block in an
    uninitialized block group, ext4 would incorrectly calculate the number
    of free blocks in that block group, and then errorneously report that
    the file system was corrupt:

    EXT4-fs error (device vdd): ext4_mb_generate_buddy:741: group 30, 32254 clusters in bitmap, 32258 in gd

    This problem can be reproduced via:

        mke2fs -q -t ext4 -O ^flex_bg /dev/vdd 5g
        mount -t ext4 /dev/vdd /mnt
        fallocate -l 4600m /mnt/test

    The problem was caused by a bone headed mistake in the check to see if a
    particular metadata block was part of the block group.

    Many thanks to Kees Cook for finding and bisecting the buggy commit
    which introduced this bug (commit fd034a84e1, present since v3.2).

    Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
    Reported-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Tested-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d913c02b0a172d5dca6280da5b17a407d69bbce4
Author: John Stultz <john.stultz@linaro.org>
Date:   Wed May 30 10:54:57 2012 -0700

    timekeeping: Fix CLOCK_MONOTONIC inconsistency during leapsecond

    commit fad0c66c4bb836d57a5f125ecd38bed653ca863a upstream.

    Commit 6b43ae8a61 (ntp: Fix leap-second hrtimer livelock) broke the
    leapsecond update of CLOCK_MONOTONIC. The missing leapsecond update to
    wall_to_monotonic causes discontinuities in CLOCK_MONOTONIC.

    Adjust wall_to_monotonic when NTP inserted a leapsecond.

    Reported-by: Richard Cochran <richardcochran@gmail.com>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Tested-by: Richard Cochran <richardcochran@gmail.com>
    Link: http://lkml.kernel.org/r/1338400497-12420-1-git-send-email-john.stultz@linaro.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3410afedcda2f504e8fbe02a7f4c49912ce688c8
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Fri Jun 8 14:58:13 2012 +0930

    module_param: stop double-calling parameters.

    commit ae82fdb1406ad41d68f07027fe31f2d35ba22a90 upstream.

    Commit 026cee0086fe1df4cf74691cf273062cc769617d "params:
    <level>_initcall-like kernel parameters" set old-style module
    parameters to level 0.  And we call those level 0 calls where we used
    to, early in start_kernel().

    We also loop through the initcall levels and call the levelled
    module_params before the corresponding initcall.  Unfortunately level
    0 is early_init(), so we call the standard module_param calls twice.

    (Turns out most things don't care, but at least ubi.mtd does).

    Change the level to -1 for standard module_param calls.

    Reported-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6e70e4c7ef345d3af2d2ba98c2d2f175aa64c2a
Author: Steffen Rumler <steffen.rumler.ext@nsn.com>
Date:   Wed Jun 6 16:37:17 2012 +0200

    powerpc: Fix kernel panic during kernel module load

    commit 3c75296562f43e6fbc6cddd3de948a7b3e4e9bcf upstream.

    This fixes a problem which can causes kernel oopses while loading
    a kernel module.

    According to the PowerPC EABI specification, GPR r11 is assigned
    the dedicated function to point to the previous stack frame.
    In the powerpc-specific kernel module loader, do_plt_call()
    (in arch/powerpc/kernel/module_32.c), GPR r11 is also used
    to generate trampoline code.

    This combination crashes the kernel, in the case where the compiler
    chooses to use a helper function for saving GPRs on entry, and the
    module loader has placed the .init.text section far away from the
    .text section, meaning that it has to generate a trampoline for
    functions in the .init.text section to call the GPR save helper.
    Because the trampoline trashes r11, references to the stack frame
    using r11 can cause an oops.

    The fix just uses GPR r12 instead of GPR r11 for generating the
    trampoline code.  According to the statements from Freescale, this is
    safe from an EABI perspective.

    I've tested the fix for kernel 2.6.33 on MPC8541.

    Signed-off-by: Steffen Rumler <steffen.rumler.ext@nsn.com>
    [paulus@samba.org: reworded the description]
    Signed-off-by: Paul Mackerras <paulus@samba.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6a6c7d2e51c9af9ce9fab247b1bc2af3967cfbb
Author: Paul Mackerras <paulus@samba.org>
Date:   Fri Jun 1 18:13:43 2012 +1000

    powerpc/time: Sanity check of decrementer expiration is necessary

    commit 860aed25a1f0936d4852ab936252b47cd1e630f1 upstream.

    This reverts 68568add2c ("powerpc/time: Remove unnecessary sanity check
    of decrementer expiration").  We do need to check whether we have reached
    the expiration time of the next event, because we sometimes get an early
    decrementer interrupt, most notably when we set the decrementer to 1 in
    arch_irq_work_raise().  The effect of not having the sanity check is that
    if timer_interrupt() gets called early, we leave the decrementer set to
    its maximum value, which means we then don't get any more decrementer
    interrupts for about 4 seconds (or longer, depending on timebase
    frequency).  I saw these pauses as a consequence of getting a stray
    hypervisor decrementer interrupt left over from exiting a KVM guest.

    This isn't quite a straight revert because of changes to the surrounding
    code, but it restores the same algorithm as was previously used.

    Acked-by: Anton Blanchard <anton@samba.org>
    Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Paul Mackerras <paulus@samba.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a32293d5c1045e99b70582783b453d08e71cfdb
Author: Roland Dreier <roland@purestorage.com>
Date:   Thu Jun 7 14:21:13 2012 -0700

    btree: fix tree corruption in btree_get_prev()

    commit cbf8ae32f66a9ceb8907ad9e16663c2a29e48990 upstream.

    The memory the parameter __key points to is used as an iterator in
    btree_get_prev(), so if we save off a bkey() pointer in retry_key and
    then assign that to __key, we'll end up corrupting the btree internals
    when we do eg

    	longcpy(__key, bkey(geo, node, i), geo->keylen);

    to return the key value.  What we should do instead is use longcpy() to
    copy the key value that retry_key points to __key.

    This can cause a btree to get corrupted by seemingly read-only
    operations such as btree_for_each_safe.

    [akpm@linux-foundation.org: avoid the double longcpy()]
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Acked-by: Joern Engel <joern@logfs.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 6d6a10124daeccc44f5d291cad4bea64639a2c66
Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date:   Wed Jun 6 11:59:06 2012 -0300

    char/agp: add another Ironlake host bridge

    commit 67384fe3fd450536342330f684ea1f7dcaef8130 upstream.

    This seems to come on Gigabyte H55M-S2V and was discovered through the
    https://bugs.freedesktop.org/show_bug.cgi?id=50381 debugging.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50381
    Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd977c84fc641cecc3b2b62a8f626815a794ad58
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon May 28 22:33:02 2012 +0100

    drm/i915: Reset last_retired_head when resetting ring

    commit c3b20037926e607b6cdaecbf9d3103e2ca63bc31 upstream.

    When we reset the ring control registers, including the HEAD and TAIL of
    the ring, we also need to reset associated state. In this instance, we
    were failing to reset the cached value of ring->last_retired_head and so
    upon the first request for more space following a resume would
    potentially (depending on a narrow race window) believe that the HEAD had
    advanced much further than reality.

    This is a regression from:

    commit a71d8d94525e8fd855c0466fb586ae1cb008f3a2
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Wed Feb 15 11:25:36 2012 +0000

        drm/i915: Record the tail at each request and use it to estimate the head

    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 666b7a8a0355bb510cd9804f6d2973be89045fc4
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Sat May 5 00:39:21 2012 +1000

    drm/nouveau/disp: fix dithering not being enabled on some eDP macbooks

    commit a6a17859f1bdf607650ee055101f54c5f207762b upstream.

    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>