commit f18a511703b6667edee4703fdd8b73ca18e232a4
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Jun 1 15:18:44 2012 +0800

    Linux 3.4.1

commit 3e5f29bd22e597d66d9c1013a0ab190e6b48a8ba
Author: Laxman Dewangan <ldewangan@nvidia.com>
Date:   Mon May 7 12:16:19 2012 +0530

    i2c: tegra: notify transfer-complete after clearing status.
    
    commit c889e91d2cc22123f20f40dde0c0a91856a20eea upstream.
    
    The notification of the transfer complete by calling complete()
    should be done after clearing all interrupt status.
    This avoids the race condition of misconfigure the i2c controller
    in multi-core environment.
    
    Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
    Acked-by: Stephen Warren <swarren@wwwdotorg.org>
    Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16d815fd230b81d49d395e91b084f0731ea6e4a2
Author: Marcus Folkesson <marcus.folkesson@gmail.com>
Date:   Thu May 3 15:56:36 2012 +0200

    i2c: davinci: Free requested IRQ in remove
    
    commit 9868a060ccf769c08ec378a9829137e272e9a92c upstream.
    
    The freed IRQ is not necessary the one requested in probe.
    Even if it was, with two or more i2c-controllers it will fails anyway.
    
    Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
    Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07e2c719a35160023c327fac6389e106357d734a
Author: Andi Kleen <andi@firstfloor.org>
Date:   Fri Nov 19 13:16:22 2010 +0100

    MCE: Fix vm86 handling for 32bit mce handler
    
    commit a129a7c84582629741e5fa6f40026efcd7a65bd4 upstream.
    
    When running on 32bit the mce handler could misinterpret
    vm86 mode as ring 0. This can affect whether it does recovery
    or not; it was possible to panic when recovery was actually
    possible.
    
    Fix this by always forcing vm86 to look like ring 3.
    
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91aecc8b34db49950ba118bce93b7e300946a751
Author: Stephen Warren <swarren@nvidia.com>
Date:   Fri May 11 18:01:38 2012 -0600

    ARM: dt: tegra cardhu: fix typo in SDHCI node name
    
    commit 1dfebb426cfd16e2080f8c95e00ca2462f2325d4 upstream.
    
    Cardhu's eMMC controller is on sdhci@78000600, not sdhci@78000400.
    Fix the typo. This roughly doubles the IO performance, since the
    support-8bit property actually takes effect.
    
    Signed-off-by: Stephen Warren <swarren@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8209f1cb6873c4e43fba6e768d244b77f1c9d4b3
Author: Dima Zavin <dima@android.com>
Date:   Mon Apr 30 10:26:14 2012 +0100

    ARM: 7409/1: Do not call flush_cache_user_range with mmap_sem held
    
    commit 435a7ef52db7d86e67a009b36cac1457f8972391 upstream.
    
    We can't be holding the mmap_sem while calling flush_cache_user_range
    because the flush can fault. If we fault on a user address, the
    page fault handler will try to take mmap_sem again. Since both places
    acquire the read lock, most of the time it succeeds. However, if another
    thread tries to acquire the write lock on the mmap_sem (e.g. mmap) in
    between the call to flush_cache_user_range and the fault, the down_read
    in do_page_fault will deadlock.
    
    [will: removed drop of vma parameter as already queued by rmk (7365/1)]
    
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Dima Zavin <dima@android.com>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6019ae78aa65afe273da8c0dfeed8e89fb5edf8f
Author: Dima Zavin <dima@android.com>
Date:   Thu Mar 29 20:44:06 2012 +0100

    ARM: 7365/1: drop unused parameter from flush_cache_user_range
    
    commit 4542b6a0fa6b48d9ae6b41c1efeb618b7a221b2a upstream.
    
    vma isn't used and flush_cache_user_range isn't a standard macro that
    is used on several archs with the same prototype. In fact only unicore32
    has a macro with the same name (with an identical implementation and no
    in-tree users).
    
    This is a part of a patch proposed by Dima Zavin (with Message-id:
    1272439931-12795-1-git-send-email-dima@android.com) that didn't get
    accepted.
    
    Cc: Dima Zavin <dima@android.com>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Cc: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dcff6a45745b9df7f2c9255fc4998be8d52ea67c
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sun May 13 20:09:38 2012 +0300

    iommu: Fix off by one in dmar_get_fault_reason()
    
    commit fefe1ed1398b81e3fadc92d11d91162d343c8836 upstream.
    
    fault_reason - 0x20 == ARRAY_SIZE(irq_remap_fault_reasons) is
    one past the end of the array.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Joerg Roedel <joerg.roedel@amd.com>
    Cc: Youquan Song <youquan.song@intel.com>
    Cc: walter harms <wharms@bfs.de>
    Cc: Suresh Siddha <suresh.b.siddha@intel.com>
    Link: http://lkml.kernel.org/r/20120513170938.GA4280@elgon.mountain
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.2: s/irq_remap_fault_reasons/intr_remap_fault_reasons/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e568e5e8d83af106def2d9353761b5ac01f9df22
Author: David Woodhouse <dwmw2@infradead.org>
Date:   Fri May 25 17:42:54 2012 +0100

    intel-iommu: Add device info into list before doing context mapping
    
    commit e2ad23d04c1304431ab5176c89b7b476ded2d995 upstream.
    
    Add device info into list before doing context mapping, because device
    info will be used by iommu_enable_dev_iotlb(). Without it, ATS won't get
    enabled as it should be.
    
    ATS, while a dubious decision from a security point of view, can be very
    important for performance.
    
    Signed-off-by: Xudong Hao <xudong.hao@intel.com>
    Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
    Acked-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c90791c7638d3c9a0de762d8b416d0e809b1dc31
Author: Chris Metcalf <cmetcalf@tilera.com>
Date:   Fri May 25 12:32:09 2012 -0400

    tile: fix bug where fls(0) was not returning 0
    
    commit 9f1d62bed7f015d11b9164078b7fea433b474114 upstream.
    
    This is because __builtin_clz(0) returns 64 for the "undefined" case
    of 0, since the builtin just does a right-shift 32 and "clz" instruction.
    So, use the alpha approach of casting to u32 and using __builtin_clzll().
    
    Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5bdf9b518d0ff03455dce3da9bce8ad95c25e6d
Author: Ming Lei <ming.lei@canonical.com>
Date:   Thu May 17 10:27:12 2012 +0800

    mmc: omap_hsmmc: pass IRQF_ONESHOT to request_threaded_irq
    
    commit db35f83ef47b5f180f2670d11f5f93992314ea09 upstream.
    
    The flag of IRQF_ONESHOT should be passed to request_threaded_irq,
    otherwise the following failure message should be dumped because
    hardware handler is defined as NULL:
    
    [    3.383483] genirq: Threaded irq requested with handler=NULL and
    !ONESHOT for irq 368
    [    3.392730] omap_hsmmc: probe of omap_hsmmc.0 failed with error -22
    
    The patch fixes one kernel hang bug which is caused by mmc card
    probe failure and root device can't be brought up.
    
    Signed-off-by: Ming Lei <ming.lei@canonical.com>
    Acked-by: Venkatraman S <svenkatr@ti.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6cd4efb3a17356075c8e3f1bd191b4d120714851
Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Date:   Tue Apr 24 17:56:29 2012 +0200

    mmc: cd-gpio: protect against NULL context in mmc_cd_gpio_free()
    
    commit 0e9f480bb553d39ee06ccd45639ba7a5446a7b81 upstream.
    
    Do not oops, even if mmc_cd_gpio_free() is mistakenly called on a driver
    cleanup path, even though a previous call to mmc_cd_gpio_request() failed.
    
    Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
    [stable@: please apply to 3.3-stable]
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 11c8c735ebf68c754bdd94cebd307a96fcd95068
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
Date:   Mon Apr 16 19:16:54 2012 -0400

    mmc: sdio: avoid spurious calls to interrupt handlers
    
    commit bbbc4c4d8c5face097d695f9bf3a39647ba6b7e7 upstream.
    
    Commit 06e8935feb ("optimized SDIO IRQ handling for single irq")
    introduced some spurious calls to SDIO function interrupt handlers,
    such as when the SDIO IRQ thread is started, or the safety check
    performed upon a system resume.  Let's add a flag to perform the
    optimization only when a real interrupt is signaled by the host
    driver and we know there is no point confirming it.
    
    Reported-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
    Signed-off-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6b2a258ab83555e062cd2bc2a0ade31b8c118d1
Author: Tony Luck <tony.luck@intel.com>
Date:   Wed May 23 14:14:22 2012 -0700

    x86/mce: Fix check for processor context when machine check was taken.
    
    commit 875e26648cf9b6db9d8dc07b7959d7c61fb3f49c upstream.
    
    Linus pointed out that there was no value is checking whether m->ip
    was zero - because zero is a legimate value.  If we have a reliable
    (or faked in the VM86 case) "m->cs" we can use it to tell whether we
    were in user mode or kernelwhen the machine check hit.
    
    Reported-by: Linus Torvalds <torvalds@linuxfoundation.org>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c51ac8ac9a82d4883c9b62247cca98195da8cd63
Author: H. Peter Anvin <hpa@zytor.com>
Date:   Thu May 24 07:01:38 2012 -0700

    x86, relocs: Add jiffies and jiffies_64 to the relative whitelist
    
    commit ea17e7414bc62e8d3bde8d08e3df1d921c518c17 upstream.
    
    The symbol jiffies is created in the linker script as an alias to
    jiffies_64.  Unfortunately this is done outside any section, and
    apparently GNU ld 2.21 doesn't carry the section with it, so we end up
    with an absolute symbol and therefore a broken kernel.
    
    Add jiffies and jiffies_64 to the whitelist.
    
    The most disturbing bit with this discovery is that it shows that we
    have had multiple linker bugs in this area crossing multiple
    generations, and have been silently building bad kernels for some time.
    
    Link: http://lkml.kernel.org/r/20120524171604.0d98284f3affc643e9714470@canb.auug.org.au
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c47c685100285be39ff7e347f762480b448b956
Author: H. Peter Anvin <hpa@zytor.com>
Date:   Wed May 23 14:02:34 2012 -0700

    x86-32, relocs: Whitelist more symbols for ld bug workaround
    
    commit fd952815307f0f272bf49fd364a7fd2f9992bc42 upstream.
    
    As noted in checkin:
    
    a3e854d95 x86, relocs: Workaround for binutils 2.22.52.0.1 section bug
    
    ld version 2.22.52.0.[12] can incorrectly promote relative symbols to
    absolute, if the output section they appear in is otherwise empty.
    
    Since checkin:
    
    6520fe55 x86, realmode: 16-bit real-mode code support for relocs tool
    
    we actually check for this and error out rather than silently creating
    a kernel which will malfunction if relocated.
    
    Ingo found a configuration in which __start_builtin_fw triggered the
    warning.
    
    Go through the linker script sources and look for more symbols that
    could plausibly get bogusly promoted to absolute, and add them to the
    whitelist.
    
    In general, if the following error triggers:
    
    	Invalid absolute R_386_32 relocation: <symbol>
    
    ... then we should verify that <symbol> is really meant to be
    relocated, and add it and any related symbols manually to the S_REL
    regexp.
    
    Please note that 6520fe55 does not introduce the error, only the check
    for the error -- without 6520fe55 this version of ld will simply
    produce a corrupt kernel if CONFIG_RELOCATABLE is set on x86-32.
    
    Reported-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46592a6929ec62012bb1b089026b9df6c4827ff9
Author: Jarkko Sakkinen <jarkko.sakkinen@intel.com>
Date:   Mon May 21 20:51:24 2012 +0300

    x86, relocs: Build clean fix
    
    commit b2d668da9307c4c163dd603d2bb3cadb10f9fd37 upstream.
    
    relocs was not cleaned up when "make clean" is issued. This
    patch fixes the issue.
    
    Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@intel.com>
    Link: http://lkml.kernel.org/r/1337622684-6834-1-git-send-email-jarkko.sakkinen@intel.com
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70a4571f9abef85e20c60a4654883d5250a36246
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Wed Mar 21 09:50:36 2012 -0300

    media: uvcvideo: Fix ENUMINPUT handling
    
    commit 31c5f0c5e25ed71eeced170f113bb590f2f1f6f3 upstream.
    
    Properly validate the user-supplied index against the number of inputs.
    The code used the pin local variable instead of the index by mistake.
    
    Reported-by: Jozef Vesely <vesely@gjh.sk>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c2cc4a3922738f434fe4872a850f40095cc79d3
Author: Michael Krufky <mkrufky@linuxtv.org>
Date:   Thu Mar 22 13:55:05 2012 -0300

    smsusb: add autodetection support for USB ID 2040:c0a0
    
    commit 4d1b58b84472d1d300a66e1c5fd765b21e74ba15 upstream.
    
    Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed14f88b0953dd749bcae068dd9bc1a5e556a789
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri May 18 15:31:12 2012 +0100

    nouveau: nouveau_set_bo_placement takes TTM flags
    
    commit c284815debba2f14ee2fd07b1b4cc972ab116110 upstream.
    
    This seems to be wrong to me, spotted while thinking about dma-buf.
    
    Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 474d1f4678a679a98eaf53801e7f95c61ae9daa7
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Mon May 21 16:54:10 2012 +0100

    xen: do not map the same GSI twice in PVHVM guests.
    
    commit 68c2c39a76b094e9b2773e5846424ea674bf2c46 upstream.
    
    PV on HVM guests map GSIs into event channels. At restore time the
    event channels are resumed by restore_pirqs.
    
    Device drivers might try to register the same GSI again through ACPI at
    restore time, but the GSI has already been mapped and bound by
    restore_pirqs. This patch detects these situations and avoids
     mapping the same GSI multiple times.
    
    Without this patch we get:
    (XEN) irq.c:2235: dom4: pirq 23 or emuirq 28 already mapped
    and waste a pirq.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 284e7be895509cdaf9f58e2f789c00b5e9da2244
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue May 15 11:47:47 2012 +0300

    hvc_xen: NULL dereference on allocation failure
    
    commit 201a52bea928687b7557728b176ac4f8a37d5cbd upstream.
    
    If kzalloc() returns a NULL here, we pass a NULL to
    xencons_disconnect_backend() which will cause an Oops.
    
    Also I removed the __GFP_ZERO while I was at it since kzalloc() implies
    __GFP_ZERO.
    
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e799d5e79f04b8099c1bd2ff9dc047d3fefd2c1
Author: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Date:   Fri May 11 15:29:50 2012 -0700

    spi/spi-fsl-spi: reference correct pdata in fsl_spi_cs_control
    
    commit 067aa4815a9bc12a569d8a06afef50ba5773afbf upstream.
    
    Commit 178db7d3, "spi: Fix device unregistration when unregistering
    the bus master", changed spi device initialization of dev.parent pointer
    to be the master's device pointer instead of his parent.
    
    This introduced a bug in spi-fsl-spi, since its usage of spi device
    pointer was not updated accordingly. This was later fixed by commit
    5039a86, "spi/mpc83xx: fix NULL pdata dereference bug", but it missed
    another spot on fsl_spi_cs_control function where we also need to update
    usage of spi device pointer. This change address that.
    
    Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
    Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
    Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc9f6719d012a955d3e87f720c8ed9d03f2b9020
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu May 3 12:22:06 2012 +0200

    gpio: mpc8xxx: Prevent NULL pointer deref in demux handler
    
    commit d6de85e85edcc38c9edcde45a0a568818fcddc13 upstream.
    
    commit cfadd838(powerpc/8xxx: Fix interrupt handling in MPC8xxx GPIO
    driver) added an unconditional call of chip->irq_eoi() to the demux
    handler.
    
    This leads to a NULL pointer derefernce on MPC512x platforms which use
    this driver as well.
    
    Make it conditional.
    
    Reported-by: Thomas Wucher <thwucher@linutronix.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Felix Radensky <felix@embedded-sol.com>
    Cc: Kumar Gala <galak@kernel.crashing.org>
    Cc: Grant Likely <grant.likely@secretlab.ca>
    Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8a0b3e41b7cac5dcd6408073f70818bb9675f25
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun May 13 22:29:25 2012 +0200

    drm/i915: don't clobber the pipe param in sanitize_modesetting
    
    commit a9dcf84b14ef4e9a609910367576995e6f32f3dc upstream.
    
    ... we need it later on in the function to clean up pipe <-> plane
    associations. This regression has been introduced in
    
    commit f47166d2b0001fcb752b40c5a2d4db986dfbea68
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Thu Mar 22 15:00:50 2012 +0000
    
        drm/i915: Sanitize BIOS debugging bits from PIPECONF
    
    Spotted by staring at debug output of an (as it turns out) totally
    unrelated bug.
    
    v2: I've totally failed to do the s/pipe/i/ correctly, spotted by
    Chris Wilson.
    
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-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 629bdbbcd239bae8ef798c1f9c2c4cd006ecf389
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Sat Apr 14 18:41:32 2012 -0700

    drm/i915: [GEN7] Use HW scheduler for fixed function shaders
    
    commit a1e969e0332de7a430e62822cee8f2ec8d83cd7c upstream.
    
    This originally started as a patch from Bernard as a way of simply
    setting the VS scheduler. After submitting the RFC patch, we decided to
    also modify the DS scheduler. To be most explicit, I've made the patch
    explicitly set all scheduler modes, and included the defines for other
    modes (in case someone feels frisky later).
    
    The rest of the story gets a bit weird. The first version of the patch
    showed an almost unbelievable performance improvement. Since rebasing my
    branch it appears the performance improvement has gone, unfortunately.
    But setting these bits seem to be the right thing to do given that the
    docs describe corruption that can occur with the default settings.
    
    In summary, I am seeing no more perf improvements (or regressions) in my
    limited testing, but we believe this should be set to prevent rendering
    corruption, therefore cc stable.
    
    v1: Clear bit 4 also (Ken + Eugeni)
    Do a full clear + set of the bits we want (Me).
    
    Cc: Bernard Kilarski <bernard.r.kilarski@intel.com>
    Reviewed-by (RFC): Kenneth Graunke <kenneth@whitecape.org>
    Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
    Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b019d4bf936fa7212341053f337c6714f29fc95e
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed May 9 21:45:43 2012 +0100

    drm/i915: Avoid a double-read of PCH_IIR during interrupt handling
    
    commit 9adab8b5a7fde248504f484e197589f3e3c922e2 upstream.
    
    Currently the code re-reads PCH_IIR during the hotplug interrupt
    processing. Not only is this a wasted read, but introduces a potential
    for handling a spurious interrupt as we then may not clear all the
    interrupts processed (since the re-read IIR may contains more interrupts
    asserted than we clear using the result of the original read).
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46f736c6f722e9a71ab552178a6bf4edf85ba371
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Sun May 6 16:01:05 2012 -0500

    b43legacy: Fix error due to MMIO access with SSB unpowered
    
    commit 8f4b20388fa77226a3605627a33a23f90d559e50 upstream.
    
    There is a dummy read of a PCI MMIO register that occurs before the SSB bus
    has been powered, which is an error. This bug has not been seen earlier,
    but was apparently exposed when udev was updated to version 182.
    
    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 10c4a0daae42270ef15c208e95556587a1cd5fd5
Author: Alan Cox <alan@linux.intel.com>
Date:   Mon May 21 15:27:44 2012 +0100

    gma500: Fix Poulsbo suspend/resume crash on devices with SDVO ports
    
    commit 7beff62ee39d3ccf088bb77f61a63037f714d235 upstream.
    
    Reported-by: Guillaume Clément <guillaume@baobob.org>
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit edad2199132a88f160c4939d1ad3eecc4c33b211
Author: Andiry Xu <andiry.xu@gmail.com>
Date:   Sat May 5 00:50:10 2012 +0800

    usbcore: enable USB2 LPM if port suspend fails
    
    commit c3e751e4f4754793bb52bd5ae30e9cc027edbb12 upstream.
    
    USB2 LPM is disabled when device begin to suspend and enabled after device
    is resumed. That's because USB spec does not define the transition from
    U1/U2 state to U3 state.
    
    If usb_port_suspend() fails, usb_port_resume() is never called, and USB2 LPM
    is disabled in this situation. Enable USB2 LPM if port suspend fails.
    
    This patch should be backported to kernels as old as 3.2, that contain
    the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2
    hardware LPM".
    
    Signed-off-by: Andiry Xu <andiry.xu@gmail.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61fb50b8328e61b6038d99c6333a60b5b02328d8
Author: Oliver Neukum <oneukum@suse.de>
Date:   Thu May 10 10:19:21 2012 +0200

    USB: fix resource leak in xhci power loss path
    
    commit f8a9e72d125f4e00ec529ba67b674321a1f3bf31 upstream.
    
    Some more data structures must be freed and counters
    reset if an XHCI controller has lost power. The failure
    to do so renders some chips inoperative after a certain number
    of S4 cycles.
    
    This patch should be backported to kernels as old as 3.2,
    that contain the commits c29eea621900f18287d50519f72cb9113746d75a
    "xhci: Implement HS/FS/LS bandwidth checking." and
    commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe
    "xhci: Implement HS/FS/LS bandwidth checking."
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 587c53c66ccee465f78d4d23c75aa9e4899597af
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Tue May 8 09:22:49 2012 -0700

    xhci: Add new short TX quirk for Fresco Logic host.
    
    commit 1530bbc6272d9da1e39ef8e06190d42c13a02733 upstream.
    
    Sergio reported that when he recorded audio from a USB headset mic
    plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
    "robotic".  When plugged into the USB 2.0 port under EHCI on the same
    laptop, the audio sounded fine.  The device is:
    
    Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset
    
    The problem was tracked down to the Fresco Logic xHCI host controller
    not correctly reporting short transfers on isochronous IN endpoints.
    The driver would submit a 96 byte transfer, the device would only send
    88 or 90 bytes, and the xHCI host would report the transfer had a
    "successful" completion code, with an untransferred buffer length of 8
    or 6 bytes.
    
    The successful completion code and non-zero untransferred length is a
    contradiction.  The xHCI host is supposed to only mark a transfer as
    successful if all the bytes are transferred.  Otherwise, the transfer
    should be marked with a short packet completion code.  Without the EHCI
    bus trace, we wouldn't know whether the xHCI driver should trust the
    completion code or the untransferred length.  With it, we know to trust
    the untransferred length.
    
    Add a new xHCI quirk for the Fresco Logic host controller.  If a
    transfer is reported as successful, but the untransferred length is
    non-zero, print a warning.  For the Fresco Logic host, change the
    completion code to COMP_SHORT_TX and process the transfer like a short
    transfer.
    
    This should be backported to stable kernels that contain the commit
    f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some
    Fresco Logic hosts."  That commit was marked for stable kernels as old
    as 2.6.36.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Reported-by: Sergio Correia <lists@uece.net>
    Tested-by: Sergio Correia <lists@uece.net>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9022f1306507d81a527c86ec756c938c3b8bc70
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Tue May 8 07:09:26 2012 -0700

    xhci: Reset reserved command ring TRBs on cleanup.
    
    commit 33b2831ac870d50cc8e01c317b07fb1e69c13fe1 upstream.
    
    When the xHCI driver needs to clean up memory (perhaps due to a failed
    register restore on resume from S3 or resume from S4), it needs to reset
    the number of reserved TRBs on the command ring to zero.  Otherwise,
    several resume cycles (about 30) with a UAS device attached will
    continually increment the number of reserved TRBs, until all command
    submissions fail because there isn't enough room on the command ring.
    
    This patch should be backported to kernels as old as 2.6.32,
    that contain the commit 913a8a344ffcaf0b4a586d6662a2c66a7106557d
    "USB: xhci: Change how xHCI commands are handled."
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3cb26c10b08940959884d8f35097ecbb4bbac9d
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Apr 23 15:06:09 2012 +0200

    usb-xhci: Handle COMP_TX_ERR for isoc tds
    
    commit 9c745995ae5c4ff787f34a359de908facc11ee00 upstream.
    
    While testing unplugging an UVC HD webcam with usb-redirection (so through
    usbdevfs), my userspace usb-redir code was getting a value of -1 in
    iso_frame_desc[n].status, which according to Documentation/usb/error-codes.txt
    is not a valid value.
    
    The source of this -1 is the default case in xhci-ring.c:process_isoc_td()
    adding a kprintf there showed the value of trb_comp_code to be COMP_TX_ERR
    in this case, so this patch adds handling for that completion code to
    process_isoc_td().
    
    This was observed and tested with the following xhci controller:
    1033:0194 NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)
    
    Note: I also wonder if setting frame->status to -1 (-EPERM) is the best we can
    do, but since I cannot come up with anything better I've left that as is.
    
    This patch should be backported to kernels as old as 2.6.36, which contain the
    commit 04e51901dd44f40a5a385ced897f6bca87d5f40a "USB: xHCI: Isochronous
    transfer implementation".
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6842282219e127d1ef3d6346082ab80214bbcbf
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Mon Apr 16 10:56:47 2012 -0700

    xhci: Avoid dead ports when CONFIG_USB_XHCI_HCD=n
    
    commit 51c9e6c7732b67769c0a514d31f505e49fa82dd4 upstream.
    
    If the user chooses to say "no" to CONFIG_USB_XHCI_HCD on a system
    with an Intel Panther Point chipset, the PCI quirks code or the EHCI
    driver will switch the ports over to the xHCI host, but the xHCI driver
    will never load.  The ports will be powered off and seem "dead" to the
    user.
    
    Fix this by only switching the ports over if CONFIG_USB_XHCI_HCD is
    either compiled in, or compiled as a module.
    
    This patch should be backported to stable kernels as old as 3.0,
    that contain commit 69e848c2090aebba5698a1620604c7dccb448684
    "Intel xhci: Support EHCI/xHCI port switching."
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Reported-by: Eric Anholt <eric.anholt@intel.com>
    Reported-by: David Bein <d.bein@f5.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 296b8ce71ac3c48cd43d9373b444d9856cfeebff
Author: Andiry Xu <andiry.xu@amd.com>
Date:   Sat Apr 14 02:54:30 2012 +0800

    xHCI: keep track of ports being resumed and indicate in hub_status_data
    
    commit f370b9968a220a3d79d870dd7dee674cc0ff3d10 upstream.
    
    This commit adds a bit-array to xhci bus_state for keeping track of
    which ports are undergoing a resume transition. If any of the bits
    are set when xhci_hub_status_data() is called, the routine will return
    a non-zero value even if no ports have any status changes pending.
    This will allow usbcore to handle races between root-hub suspend and
    port wakeup.
    
    This patch should be backported to kernels as old as 3.4, that contain
    the commit 879d38e6bc36d73b0ac40ec9b0d839fda9fa8b1a "USB: fix race
    between root-hub suspend and remote wakeup".
    
    Signed-off-by: Andiry Xu <andiry.xu@amd.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce5833387ab9481e2d83939a4a36203e3461ef73
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Thu Feb 9 15:55:13 2012 -0800

    xhci: Add Lynx Point to list of Intel switchable hosts.
    
    commit 1c12443ab8eba71a658fae4572147e56d1f84f66 upstream.
    
    The upcoming Intel Lynx Point chipset includes an xHCI host controller
    that can have ports switched from the EHCI host controller, just like
    the Intel Panther Point xHCI host.  This time, ports from both EHCI
    hosts can be switched to the xHCI host controller.  The PCI config
    registers to do the port switching are in the exact same place in the
    xHCI PCI configuration registers, with the same semantics.
    
    Hooray for shipping patches for next-gen hardware before the current gen
    hardware is even available for purchase!
    
    This patch should be backported to stable kernels as old as 3.0,
    that contain commit 69e848c2090aebba5698a1620604c7dccb448684
    "Intel xhci: Support EHCI/xHCI port switching."
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be89311ce0799bba12f6b9f73228c2b264074a8c
Author: Steffen Müller <steffen.mueller@radio-frei.de>
Date:   Mon Apr 30 13:05:34 2012 +0200

    usb: add USB_QUIRK_RESET_RESUME for M-Audio 88es
    
    commit 166cb70e97bd83d7ae9bbec6ae59a178fd9bb823 upstream.
    
    Tested-by: Steffen Müller <steffen.mueller@radio-frei.de>
    Signed-off-by: Steffen Müller <steffen.mueller@radio-frei.de>
    Signed-off-by: Stefan Seyfried <seife+kernel@b1-systems.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66595c7dabba38c4ad40bad992c3f612b75a9f71
Author: Peter Chen <peter.chen@freescale.com>
Date:   Sun Apr 1 15:17:16 2012 +0800

    usb: gadget: fsl_udc_core: dTD's next dtd pointer need to be updated once written
    
    commit 4d0947dec4db1224354e2f6f00ae22ce38e62a43 upstream.
    
    dTD's next dtd pointer need to be updated once CPU writes it, or this
    request may not be handled by controller, then host will get NAK from
    device forever.
    
    This problem occurs when there is a request is handling, we need to add
    a new request to dTD list, if this new request is added before the current
    one is finished, the new request is intended to added as next dtd pointer
    at current dTD, but without wmb(), the dTD's next dtd pointer may not be
    updated when the controller reads it. In that case, the controller will
    still get Terminate Bit is 1 at dTD's next dtd pointer, that means there is
    no next request, then this new request is missed by controller.
    
    Signed-off-by: Peter Chen <peter.chen@freescale.com>
    Acked-by: Li Yang <leoli@freescale.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c8e06de9d7d35461601d987605d091d3c817fba
Author: Darren Hart <dvhart@linux.intel.com>
Date:   Fri May 11 13:56:57 2012 -0700

    USB: serial: ti_usb_3410_5052: Add support for the FRI2 serial console
    
    commit 975dc33b82cb887d75a29b1e3835c8eb063a8e99 upstream.
    
    The Kontron M2M development board, also known as the Fish River Island II,
    has an optional daughter card providing access to the PCH_UART (EG20T) via
    a ti_usb_3410_5052 uart to usb chip.
    
    http://us.kontron.com/products/systems+and+platforms/m2m/m2m+smart+services+developer+kit.html
    
    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    CC: Al Borchers <alborchers@steinerpoint.com>
    CC: Peter Berger <pberger@brimson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c84ac3a2f033f13f55e737b4b9e3395b66c523d4
Author: Huajun Li <huajun.li.lee@gmail.com>
Date:   Fri May 18 20:12:51 2012 +0800

    USB: Remove races in devio.c
    
    commit 4e09dcf20f7b5358615514c2ec8584b248ab8874 upstream.
    
    There exist races in devio.c, below is one case,
    and there are similar races in destroy_async()
    and proc_unlinkurb().  Remove these races.
    
     cancel_bulk_urbs()        async_completed()
    -------------------                -----------------------
     spin_unlock(&ps->lock);
    
                               list_move_tail(&as->asynclist,
    		                    &ps->async_completed);
    
                               wake_up(&ps->wait);
    
                               Lead to free_async() be triggered,
                               then urb and 'as' will be freed.
    
     usb_unlink_urb(as->urb);
     ===> refer to the freed 'as'
    
    Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: Oncaphillis <oncaphillis@snafu.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 33c3504a085337d80750d2ab68e8ea2127b63ba5
Author: Nicolas Ferre <nicolas.ferre@atmel.com>
Date:   Wed May 9 10:48:54 2012 +0200

    USB: ohci-at91: add a reset function to fix race condition
    
    commit 07e4e556eff4938eb2edf2591de3aa7d7fb82b52 upstream.
    
    A possible race condition appears because we are not initializing
    the ohci->regs before calling usb_hcd_request_irqs().
    We move the call to ohci_init() in hcd->driver->reset() instead of
    hcd->driver->start() to fix this.
    This was experienced when we share the same IRQ line between OHCI and EHCI
    controllers.
    
    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Tested-by: Christian Eggers <christian.eggers@kathrein.de>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 658b069b7c6b5d91cd89a24dde34ec91918f6e25
Author: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Date:   Thu May 10 10:31:21 2012 +0900

    USB: gpio_vbus: provide an appropriate debounce interval
    
    commit 934ccec4da14dc0586dfe08b36166364bdd2181b upstream.
    
    In commit c2344f13b59e007d782a3e591ebc551bc583a8b7 (USB: gpio_vbus:
    add delayed vbus_session calls, 2009-01-24), usb_gadget_vbus_connect()
    and ...disconnect() were extracted from the interrupt handler, so to
    allow vbus_session handlers to deal with msleep() calls.
    
    This patch takes the approach one step further.
    
    USB2.0 specification (7.1.7.3 Connect and Disconnect Signaling) says
    that the USB system software (shall) provide a debounce interval with
    a minimum duration of 100 ms, which ensures that the electrical and
    mechanical connection is stable before software attempts to reset
    the attached device.
    
    Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ada3a3d0cb75f4cb015a2521badcffcf6d16ba45
Author: Russ Dill <Russ.Dill@ti.com>
Date:   Fri May 4 04:24:47 2012 -0700

    USB: EHCI: OMAP: Finish ehci omap phy reset cycle before adding hcd.
    
    commit 3aa2ae74ba630ec9b98736d64aea8e4cb490861d upstream.
    
    'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0f) created a regression
    with Beagleboard xM if booting the kernel after running 'usb start' under u-boot.
    
    Finishing the reset before calling 'usb_add_hcd' fixes the regression. This is most likely due to
    usb_add_hcd calling the driver's reset and init functions which expect the hardware to be
    up and running.
    
    Signed-off-by: Russ Dill <Russ.Dill@ti.com>
    Acked-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54c6b536f2c7ebc77f74937c3f4789ef191aa479
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date:   Fri May 18 20:29:56 2012 +0200

    USB: ehci-platform: remove update_device
    
    commit 8377c94f627f7943da9a7eefdb21fd2e9e7ec629 upstream.
    
    The update_device callback is not needed and the function used here is
    from the pci ehci driver. Without this patch we get a compile error if
    ehci-platform is compiled without ehci-pci.
    
    Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0053c7e96ee9a516e7e8499f6fc28c0d9c43d40c
Author: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
Date:   Mon Apr 16 14:19:07 2012 -0700

    usb: usbtest: two super speed fixes for usbtest
    
    commit 6a23ccd216b6a8ba2c67a9f9d8969b4431ad2920 upstream.
    
    bMaxPacketSize0 field for super speed is a power of 2, not a count.
    The size itself is always 512.
    
    Max packet size for a super speed bulk endpoint is 1024, so
    allocate the urb size in halt_simple() accordingly.
    
    Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
    Acked-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit faf7fee9add05c8cebc2e7c8e6ff3feea364b868
Author: Matthias Fend <Matthias.Fend@wolfvision.net>
Date:   Mon May 7 14:37:30 2012 +0200

    USB: ffs-test: fix length argument of out function call
    
    commit eb9c5836384cd2a276254df6254ed71117983626 upstream.
    
    The out functions should only handle actual available data instead of the complete buffer.
    Otherwise for example the ep0_consume function will report ghost events since it tries to decode
    the complete buffer - which may contain partly invalid data.
    
    Signed-off-by: Matthias Fend <matthias.fend@wolfvision.net>
    Acked-by: Michal Nazarewicz <mina86@mina86.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5872d789e93efed59705b849de8b665c48d6b75
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue May 8 15:15:25 2012 -0400

    usb-storage: unusual_devs entry for Yarvik PMP400 MP4 player
    
    commit df767b71e5816692134d59c0c17e0f77cd73333d upstream.
    
    This patch (as1553) adds an unusual_dev entrie for the Yarvik PMP400
    MP4 music player.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Jesse Feddema <jdfeddema@gmail.com>
    Tested-by: Jesse Feddema <jdfeddema@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2aa5c3521c154db6e3bbbda1a2f0b07da4938626
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon May 7 11:20:06 2012 -0400

    usb-serial: ftdi_sio: fix oops during autosuspend
    
    commit 5cbe61c5aff0a8ada691eb8b07dbfb55c303f640 upstream.
    
    This patch (as1550) fixes a bug in the usb-serial core that affects
    the ftdi_sio driver and most likely others as well.  The core
    implements suspend and resume routines, but it doesn't store pointers
    to those routines in the usb_driver structures that it registers,
    even though it does set those drivers' supports_autosuspend flag.  The
    end result is that when one of these devices is autosuspended, we try
    to call through a NULL pointer.
    
    The patch fixes the problem by setting the suspend and resume method
    pointers to the appropriate routines in the USB serial core, along
    with the supports_autosuspend field, in each driver as it is
    registered.
    
    This should be back-ported to all the stable kernels that have the new
    usb_serial_register_drivers() interface.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: Frank Schäfer <schaefer.frank@gmx.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27234cee48f54e3f3125e44bc8b05c42b977a113
Author: Éric Piel <piel@delmic.com>
Date:   Mon May 7 12:37:54 2012 +0200

    USB: ftdi-sio: add support for Physik Instrumente E-861
    
    commit b69cc672052540e8efb1368420f10d7d4d8b8a3d upstream.
    
    This adds VID/PID for the PI E-861. Without it, I had to do:
    modprobe -q ftdi-sio product=0x1008 vendor=0x1a72
    
    http://www.physikinstrumente.com/en/products/prdetail.php?sortnr=900610
    
    Signed-off-by: Éric Piel <piel@delmic.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0afed68fb1d586034be7a7e038488e83c37a89f
Author: Alan Cox <alan@linux.intel.com>
Date:   Mon May 14 14:51:22 2012 +0100

    tty: Allow uart_register/unregister/register
    
    commit 1e66cded334e6cea596c72f6f650eec351b1e959 upstream.
    
    This is legitimate but because we don't clear the drv->state pointer in the
    unregister code causes a bogus BUG().
    
    Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42880
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b3539aad80702d68bcc3211fb4f5779f84d9d75
Author: Arnaud Patard <apatard@hupstream.com>
Date:   Wed Apr 25 12:17:24 2012 +0200

    8250_pci: fix pch uart matching
    
    commit aaa10eb1d0034eccc096f583fe308f0921617598 upstream.
    
    The rules used to make 8250_pci "ignore" the PCH uarts are lacking pci subids
    entries, preventing it to match and thus is breaking serial port support for
    theses systems.
    
    This has been tested on a nanoETXexpress-TT, which has a specifici uart clock.
    
    Tested-by: Erwan Velu <Erwan.Velu@zodiacaerospace.com>
    [stable@: please apply to 3.0-stable, 3.2-stable and 3.3-stable]
    Signed-off-by: Arnaud Patard <apatard@hupstream.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4bc0181430409b4ffbac0da0a286b1ea0a91dfe
Author: Christian Melki <christian.melki@ericsson.se>
Date:   Mon Apr 30 11:21:26 2012 +0200

    8250.c: less than 2400 baud fix.
    
    commit f9a9111b540fd67db5dab332f4b83d86c90e27b1 upstream.
    
    We noticed that we were loosing data at speed less than 2400 baud.
    It turned out our (TI16750 compatible) uart with 64 byte outgoing fifo
    was truncated to 16 byte (bit 5 sets fifo len) when modifying the fcr
    reg.
    The input code still fills the buffer with 64 bytes if I remember
    correctly and thus data is lost.
    Our fix was to remove whiping of the fcr content and just add the
    TRIGGER_1 which we want for latency.
    I can't see why this would not work on less than 2400 always, for all
    uarts ...
    Otherwise one would have to make sure the filling of the fifo re-checks
    the current state of available fifo size (urrk).
    
    Signed-off-by: Christian Melki <christian.melki@ericsson.se>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fa8ba3d8d0f49c4b087a026889a1154c3d94901
Author: Lothar Waßmann <LW@KARO-electronics.de>
Date:   Thu May 3 11:37:12 2012 +0200

    Add missing call to uart_update_timeout()
    
    commit 8b979f7c6bf13a57e7b6002f1175312a44773960 upstream.
    
    This patch fixes a problem reported here:
    http://article.gmane.org/gmane.linux.ports.arm.kernel/155242/match=auart
    
    Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51c75d344b36152159b19466964dab4ae1a19fcd
Author: Shaohua Li <shli@kernel.org>
Date:   Mon May 21 09:26:59 2012 +1000

    md: using GFP_NOIO to allocate bio for flush request
    
    commit b5e1b8cee7ad58a15d2fa79bcd7946acb592602d upstream.
    
    A flush request is usually issued in transaction commit code path, so
    using GFP_KERNEL to allocate memory for flush request bio falls into
    the classic deadlock issue.
    
    This is suitable for any -stable kernel to which it applies as it
    avoids a possible deadlock.
    
    Signed-off-by: Shaohua Li <shli@fusionio.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab9094fa038106675b40dbb5ee78b60255d6c436
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed May 23 12:48:13 2012 +0100

    mm: mempolicy: Let vma_merge and vma_split handle vma->vm_policy linkages
    
    commit 05f144a0d5c2207a0349348127f996e104ad7404 upstream.
    
    Dave Jones' system call fuzz testing tool "trinity" triggered the
    following bug error with slab debugging enabled
    
        =============================================================================
        BUG numa_policy (Not tainted): Poison overwritten
        -----------------------------------------------------------------------------
    
        INFO: 0xffff880146498250-0xffff880146498250. First byte 0x6a instead of 0x6b
        INFO: Allocated in mpol_new+0xa3/0x140 age=46310 cpu=6 pid=32154
         __slab_alloc+0x3d3/0x445
         kmem_cache_alloc+0x29d/0x2b0
         mpol_new+0xa3/0x140
         sys_mbind+0x142/0x620
         system_call_fastpath+0x16/0x1b
        INFO: Freed in __mpol_put+0x27/0x30 age=46268 cpu=6 pid=32154
         __slab_free+0x2e/0x1de
         kmem_cache_free+0x25a/0x260
         __mpol_put+0x27/0x30
         remove_vma+0x68/0x90
         exit_mmap+0x118/0x140
         mmput+0x73/0x110
         exit_mm+0x108/0x130
         do_exit+0x162/0xb90
         do_group_exit+0x4f/0xc0
         sys_exit_group+0x17/0x20
         system_call_fastpath+0x16/0x1b
        INFO: Slab 0xffffea0005192600 objects=27 used=27 fp=0x          (null) flags=0x20000000004080
        INFO: Object 0xffff880146498250 @offset=592 fp=0xffff88014649b9d0
    
    This implied a reference counting bug and the problem happened during
    mbind().
    
    mbind() applies a new memory policy to a range and uses mbind_range() to
    merge existing VMAs or split them as necessary.  In the event of splits,
    mpol_dup() will allocate a new struct mempolicy and maintain existing
    reference counts whose rules are documented in
    Documentation/vm/numa_memory_policy.txt .
    
    The problem occurs with shared memory policies.  The vm_op->set_policy
    increments the reference count if necessary and split_vma() and
    vma_merge() have already handled the existing reference counts.
    However, policy_vma() screws it up by replacing an existing
    vma->vm_policy with one that potentially has the wrong reference count
    leading to a premature free.  This patch removes the damage caused by
    policy_vma().
    
    With this patch applied Dave's trinity tool runs an mbind test for 5
    minutes without error.  /proc/slabinfo reported that there are no
    numa_policy or shared_policy_node objects allocated after the test
    completed and the shared memory region was deleted.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Cc: Dave Jones <davej@redhat.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Stephen Wilson <wilsons@start.ca>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: 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 24312d34c95702e51240f58c073db30630170fbf
Author: Tejun Heo <tj@kernel.org>
Date:   Mon May 14 15:04:50 2012 -0700

    workqueue: skip nr_running sanity check in worker_enter_idle() if trustee is active
    
    commit 544ecf310f0e7f51fa057ac2a295fc1b3b35a9d3 upstream.
    
    worker_enter_idle() has WARN_ON_ONCE() which triggers if nr_running
    isn't zero when every worker is idle.  This can trigger spuriously
    while a cpu is going down due to the way trustee sets %WORKER_ROGUE
    and zaps nr_running.
    
    It first sets %WORKER_ROGUE on all workers without updating
    nr_running, releases gcwq->lock, schedules, regrabs gcwq->lock and
    then zaps nr_running.  If the last running worker enters idle
    inbetween, it would see stale nr_running which hasn't been zapped yet
    and trigger the WARN_ON_ONCE().
    
    Fix it by performing the sanity check iff the trustee is idle.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ed2cb7819e7df0e0fe0cce574c64e57b4806fe1
Author: Bjørn Mork <bjorn@mork.no>
Date:   Wed May 9 13:53:23 2012 +0200

    USB: cdc-wdm: remove from device list on disconnect
    
    commit 6286d85e8efdb59252d1ceb99a56fa6b0b11526c upstream.
    
    Prevents dereferencing an invalid struct usb_interface
    pointer.
    
    Always delete entry from device list whether or not the
    rest of the device state cleanup is postponed. The device
    list uses desc->intf as key, and wdm_open will dereference
    this key while searching for a matching device.  A device
    should not appear in the list unless probe() has succeeded
    and disconnect() has not finished.
    
    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 577bd3ef6eed18ea3c866b2f25b14aa5e139b41f
Author: Bjørn Mork <bjorn@mork.no>
Date:   Wed May 9 13:53:22 2012 +0200

    USB: cdc-wdm: cannot use dev_printk when device is gone
    
    commit 6b0b79d38806481c1c8fffa7c5842f3c83679a42 upstream.
    
    We cannot dereference a removed USB interface for
    dev_printk. Use pr_debug instead where necessary.
    
    Flush errors are expected if device is unplugged and are
    therefore best ingored at this point.
    
    Move the kill_urbs() call in wdm_release with dev_dbg()
    for the non disconnect, as we know it has already been
    called if WDM_DISCONNECTING is set.  This does not
    actually fix anything, but keeps the code more consistent.
    
    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0765ea47c9ab8466b8765ff768251b572670148
Author: Bjørn Mork <bjorn@mork.no>
Date:   Wed May 9 13:53:21 2012 +0200

    USB: cdc-wdm: poll must return POLLHUP if device is gone
    
    commit 616b6937e348ef2b4c6ea5fef2cd3c441145efb0 upstream.
    
    Else the poll will be restarted indefinitely in a tight loop,
    preventing final device cleanup.
    
    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fccfda602805358246118c8ed991a0cb32160d0f
Author: Oliver Neukum <oliver@neukum.org>
Date:   Fri Apr 27 14:36:37 2012 +0200

    USB: cdc-wdm: fix memory leak
    
    commit 2f338c8a1904e2e7aa5a8bd12fb0cf2422d17da4 upstream.
    
    cleanup() is not called if the last close() comes after
    disconnect(). That leads to a memory leak. Rectified
    by checking for an earlier disconnect() in release()
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eae68611b2683cc1a9a7ca669c60a65020071004
Author: Oliver Neukum <oliver@neukum.org>
Date:   Fri Apr 27 14:23:54 2012 +0200

    USB: cdc-wdm: sanitize error returns
    
    commit 24a85bae5da2b43fed423859c09c5a81ab359473 upstream.
    
    wdm_flush() returns unsanitized USB error codes.
    They must be cleaned up to before being anded to user space
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1542bf241dcf836035ecc67c1df4a96c097bd0b
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Apr 18 23:16:45 2012 -0700

    docs: update HOWTO for 2.6.x -> 3.x versioning
    
    commit 591bfc6bf9e5e25e464fd4c87d64afd5135667c4 upstream.
    
    The HOWTO document needed updating for the new kernel versioning. The
    git URI for -next was updated as well.
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bbe784b683f6e49bc345577fc5398344bc7c289e
Author: Anton Vorontsov <anton.vorontsov@linaro.org>
Date:   Fri May 11 17:17:17 2012 -0700

    persistent_ram: Fix buffer size clamping during writes
    
    commit 484dd30e016eb425b0de871357fff2c9bb93be45 upstream.
    
    This is a longstanding bug, almost unnoticeable when calling
    persistent_ram_write() for small buffers.
    
    But when called for large data buffers, the write routine behaves
    incorrectly, as the size may never update: instead of clamping
    the size to the maximum buffer size, buffer_size_add_clamp() returns
    an error (which is never checked by the write routine, btw).
    
    To fix this, we now use buffer_size_add() that actually clamps the
    size to the max value.
    
    Also remove buffer_size_add_clamp(), it is no longer needed.
    
    Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
    Acked-by: Colin Cross <ccross@android.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f09f8dad903d3c469bf11b49c2d4c5259906a153
Author: Richard Weinberger <richard@nod.at>
Date:   Sat Apr 14 17:29:30 2012 +0200

    um: Implement a custom pte_same() function
    
    commit f15b9000eb1d09bbaa4b0a6b2089d7e1f64e84b3 upstream.
    
    UML uses the _PAGE_NEWPAGE flag to mark pages which are not jet
    installed on the host side using mmap().
    pte_same() has to ignore this flag, otherwise unuse_pte_range()
    is unable to unuse the page because two identical
    page tables entries with different _PAGE_NEWPAGE flags would not
    match and swapoff() would never return.
    
    Analyzed-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d7a75d7dc0c8c8e60f8c40622b7e3519e702714
Author: Richard Weinberger <richard@nod.at>
Date:   Sat Apr 14 17:46:01 2012 +0200

    um: Fix __swp_type()
    
    commit 2b76ebaa728f8a3967c52aa189261c72fe56a6f1 upstream.
    
    The current __swp_type() function uses a too small bitshift.
    Using more than one swap files causes bad pages because
    the type bits clash with other page flags.
    
    Analyzed-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f7bac87c60030bc2a0bb58789696f9624d5e8d9
Author: Jonathan Nieder <jrnieder@gmail.com>
Date:   Fri May 11 16:17:16 2012 +0200

    HID: logitech: read all 32 bits of report type bitfield
    
    commit 44d27f7dfedd9aadc082cda31462f6600f56e4ec upstream.
    
    On big-endian systems (e.g., Apple PowerBook), trying to use a
    logitech wireless mouse with the Logitech Unifying Receiver does not
    work with v3.2 and later kernels.  The device doesn't show up in
    /dev/input.  Older kernels work fine.
    
    That is because the new hid-logitech-dj driver claims the device.  The
    device arrival notification appears:
    
    	20 00 41 02 00 00 00 00 00 00 00 00 00 00 00
    
    and we read the report_types bitfield (02 00 00 00) to find out what
    kind of device it is.  Unfortunately the driver only reads the first 8
    bits and treats that value as a 32-bit little-endian number, so on a
    powerpc the report type seems to be 0x02000000 and is not recognized.
    
    Even on little-endian machines, connecting a media center remote
    control (report type 00 01 00 00) with this driver loaded would
    presumably fail for the same reason.
    
    Fix both problems by using get_unaligned_le32() to read all four
    bytes, which is a little clearer anyway.  After this change, the
    wireless mouse works on Hugo's PowerBook again.
    
    Based on a patch by Nestor Lopez Casado.
    Addresses http://bugs.debian.org/671292
    
    Reported-by: Hugo Osvaldo Barrera <hugo@osvaldobarrera.com.ar>
    Inspired-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 774a93aa647f8939867c8ff956847bc63dd51cb3
Author: Oliver Neukum <oliver@neukum.org>
Date:   Mon Apr 30 09:13:46 2012 +0200

    usbhid: prevent deadlock during timeout
    
    commit 8815bb09af21316aeb5f8948b24ac62181670db2 upstream.
    
    On some HCDs usb_unlink_urb() can directly call the
    completion handler. That limits the spinlocks that can
    be taken in the handler to locks not held while calling
    usb_unlink_urb()
    To prevent a race with resubmission, this patch exposes
    usbcore's infrastructure for blocking submission, uses it
    and so drops the lock without causing a race in usbhid.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Acked-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59784034b157f70d1e8cf56b114527faeadecfaf
Author: David Herrmann <dh.herrmann@googlemail.com>
Date:   Tue May 8 16:52:31 2012 +0200

    HID: wiimote: Fix IR data parser
    
    commit 74b89e8a3625c17c7452532dfb997ac4f1a38751 upstream.
    
    We incorrectly parse incoming IR data. The extra byte contains the upper
    bits and not the lower bits of the x/y coordinates. User-space expects
    absolute position data from us so this patch does not break existing
    applications. On the contrary, it extends the virtual view and fixes
    garbage reports for margin areas of the virtual screen.
    
    Reported-by: Peter Bukovsky <bukovsky.peter@gmail.com>
    Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f830c404b611cc9c47a0f91c1c91103e3ff8e30
Author: Robert Richter <robert.richter@amd.com>
Date:   Fri May 18 12:40:42 2012 +0200

    perf/x86: Update event scheduling constraints for AMD family 15h models
    
    commit 5bcdf5e4fee3c45e1281c25e4941f2163cb28c65 upstream.
    
    This update is for newer family 15h cpu models from 0x02 to 0x1f.
    
    Signed-off-by: Robert Richter <robert.richter@amd.com>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Link: http://lkml.kernel.org/r/1337337642-1621-1-git-send-email-robert.richter@amd.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d026b7150e38a1764d83fc57b6e4448d5e278eaf
Author: Julia Lawall <Julia.Lawall@lip6.fr>
Date:   Sun Apr 22 13:37:09 2012 +0200

    drivers/staging/comedi/comedi_fops.c: add missing vfree
    
    commit abae41e6438b798e046d721b6ccdd55b4a398170 upstream.
    
    aux_free is freed on all other exits from the function.  By removing the
    return, we can benefit from the vfree already at the end of the function.
    
    Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b10dfc7a2b20aaf6fad56f7b0725c4aaa9438ad1
Author: Yishai Hadas <yishaih@mellanox.com>
Date:   Thu May 10 23:28:05 2012 +0300

    IB/core: Fix mismatch between locked and pinned pages
    
    commit c4870eb874ac16dccef40e1bc7a002c7e9156adc upstream.
    
    Commit bc3e53f682d9 ("mm: distinguish between mlocked and pinned
    pages") introduced a separate counter for pinned pages and used it in
    the IB stack.  However, in ib_umem_get() the pinned counter is
    incremented, but ib_umem_release() wrongly decrements the locked
    counter.  Fix this.
    
    Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
    Reviewed-by: Christoph Lameter <cl@linux.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7716183bcc917203fb8353a226a0228167b9e832
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Fri May 18 10:58:26 2012 +0200

    fbdev: sh_mobile_lcdc: Don't confuse line size with pitch
    
    commit 72c04af9a2d57b7945cf3de8e71461bd80695d50 upstream.
    
    When using the MERAM the LCDC line size needs to be programmed with a
    MERAM-specific value different than the real frame buffer pitch. Fix it.
    
    Reported-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3083d9d9e5860c365e93b1e96aa65613fa829fb
Author: Eric Paris <eparis@redhat.com>
Date:   Wed Apr 4 13:47:11 2012 -0400

    SELinux: if sel_make_bools errors don't leave inconsistent state
    
    commit 154c50ca4eb9ae472f50b6a481213e21ead4457d upstream.
    
    We reset the bool names and values array to NULL, but do not reset the
    number of entries in these arrays to 0.  If we error out and then get back
    into this function we will walk these NULL pointers based on the belief
    that they are non-zero length.
    
    Signed-off-by: Eric Paris <eparis@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 305d212b5e9d473230de491b2b722424af1dfc9b
Author: David Howells <dhowells@redhat.com>
Date:   Fri May 11 10:56:56 2012 +0100

    KEYS: Use the compat keyctl() syscall wrapper on Sparc64 for Sparc32 compat
    
    commit 45de6767dc51358a188f75dc4ad9dfddb7fb9480 upstream.
    
    Use the 32-bit compat keyctl() syscall wrapper on Sparc64 for Sparc32 binary
    compatibility.
    
    Without this, keyctl(KEYCTL_INSTANTIATE_IOV) is liable to malfunction as it
    uses an iovec array read from userspace - though the kernel should survive this
    as it checks pointers and sizes anyway.
    
    I think all the other keyctl() function should just work, provided (a) the top
    32-bits of each 64-bit argument register are cleared prior to invoking the
    syscall routine, and the 32-bit address space is right at the 0-end of the
    64-bit address space.  Most of the arguments are 32-bit anyway, and so for
    those clearing is not required.
    
    Signed-off-by: David Howells <dhowells@redhat.com
    cc: "David S. Miller" <davem@davemloft.net>
    cc: sparclinux@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae5b51f1aa5ccba9c36b16c56d3c000125ae7e41
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon May 7 17:59:47 2012 +0000

    powerpc: Fix broken cpu_idle_wait() implementation
    
    commit 9cd75e13de2dcf32ecc21c7f277cff3c0ced059e upstream.
    
    commit 771dae818 (powerpc/cpuidle: Add cpu_idle_wait() to allow
    switching of idle routines) implemented cpu_idle_wait() for powerpc.
    
    The changelog says:
     "The equivalent routine for x86 is in arch/x86/kernel/process.c
      but the powerpc implementation is different.":
    
    Unfortunately the changelog is completely useless as it does not tell
    _WHY_ it is different.
    
    Aside of being different the implementation is patently wrong.
    
    The rescheduling IPI is async. That means that there is no guarantee,
    that the other cores have executed the IPI when cpu_idle_wait()
    returns. But that's the whole purpose of this function: to guarantee
    that no CPU uses the old idle handler anymore.
    
    Use the smp_functional_call() based implementation, which fulfils the
    requirements.
    
    [ This code is going to replaced by a core version to remove all the
      pointless copies in arch/*, but this one should go to stable ]
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
    Cc: Trinabh Gupta <g.trinabh@gmail.com>
    Cc: Arun R Bharadwaj <arun.r.bharadwaj@gmail.com>
    Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Link: http://lkml.kernel.org/r/20120507175651.980164748@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ece17ce979baa62e074ba2d617e3a3ffc77ada84
Author: Steve Wise <swise@opengridcomputing.com>
Date:   Mon Apr 30 15:31:29 2012 -0500

    RDMA/cxgb4: Drop peer_abort when no endpoint found
    
    commit 14b9222808bb8bfefc71f72bc0dbdcf3b2f0140f upstream.
    
    Log a warning and drop the abort message.  Otherwise we will do a
    bogus wake_up() and crash.
    
    Signed-off-by: Steve Wise <swise@opengridcomputing.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 466dab407e47968777912aa23e5c66d1bd715405
Author: Steve Wise <swise@opengridcomputing.com>
Date:   Fri Apr 27 10:24:33 2012 -0500

    RDMA/cxgb4: Use dst parameter in import_ep()
    
    commit bd61baaf59669accae2720799394a51fecabe5d9 upstream.
    
    Function import_ep() is incorrectly using ep->dst instead of the dst
    ptr passed in.  This causes a crash when accepting new rdma connections
    becase ep->dst is not initialized yet.
    
    Signed-off-by: Steve Wise <swise@opengridcomputing.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7a1a2016dba604884bfffb2e5ccf0ebc41b6e52
Author: Steve Wise <swise@opengridcomputing.com>
Date:   Fri Apr 27 09:59:16 2012 -0500

    RDMA/cxgb4: Always wake up waiters in c4iw_peer_abort_intr()
    
    commit 0f1dcfae6bc5563424346ad3a03282b8235a4c33 upstream.
    
    This fixes a race where an ingress abort fails to wake up the thread
    blocked in rdma_init() causing the app to hang.
    
    Signed-off-by: Steve Wise <swise@opengridcomputing.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 694450c8fa0dd37c49910c8d278cd68fab219006
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Mon Apr 30 11:57:44 2012 -0700

    isci: fix oem parameter validation on single controller skus
    
    commit fc25f79af321c01a739150ba2c09435cf977a63d upstream.
    
    OEM parameters [1] are parsed from the platform option-rom / efi
    driver.  By default the driver was validating the parameters for the
    dual-controller case, but in single-controller case only the first set
    of parameters may be valid.
    
    Limit the validation to the number of actual controllers detected
    otherwise the driver may fail to parse the valid parameters leading to
    driver-load or runtime failures.
    
    [1] the platform specific set of phy address, configuration,and analog
        tuning values
    
    Reported-by: Dave Jiang <dave.jiang@intel.com>
    Tested-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3102e700882480237273c4e45a65f23fce0dd345
Author: nagalakshmi.nandigama@lsi.com <nagalakshmi.nandigama@lsi.com>
Date:   Tue Mar 20 12:10:01 2012 +0530

    SCSI: mpt2sas: Fix for panic happening because of improper memory allocation
    
    commit e42fafc25fa86c61824e8d4c5e7582316415d24f upstream.
    
    The ioc->pfacts member in the IOC structure is getting set to zero
    following a call to _base_get_ioc_facts due to the memset in that routine.
    So if the ioc->pfacts was read after a host reset, there would be a NULL
    pointer dereference. The routine _base_get_ioc_facts is called from context
    of host reset.  The problem in _base_get_ioc_facts  is the size of
    Mpi2IOCFactsReply is 64, whereas the sizeof "struct mpt2sas_facts" is 60,
    so there is a four byte overflow resulting from the memset.
    
    Also, there is memset in _base_get_port_facts using the incorrect structure,
    it should be "struct mpt2sas_port_facts" instead of Mpi2PortFactsReply.
    
    Signed-off-by: Nagalakshmi Nandigama <nagalakshmi.nandigama@lsi.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit afde0dae8ee521686465141a44aa8060f4805cab
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date:   Wed May 9 09:37:30 2012 +0200

    s390/pfault: fix task state race
    
    commit d5e50a51ccbda36b379aba9d1131a852eb908dda upstream.
    
    When setting the current task state to TASK_UNINTERRUPTIBLE this can
    race with a different cpu. The other cpu could set the task state after
    it inspected it (while it was still TASK_RUNNING) to TASK_RUNNING which
    would change the state from TASK_UNINTERRUPTIBLE to TASK_RUNNING again.
    
    This race was always present in the pfault interrupt code but didn't
    cause anything harmful before commit f2db2e6c "[S390] pfault: cpu hotplug
    vs missing completion interrupts" which relied on the fact that after
    setting the task state to TASK_UNINTERRUPTIBLE the task would really
    sleep.
    Since this is not necessarily the case the result may be a list corruption
    of the pfault_list or, as observed, a use-after-free bug while trying to
    access the task_struct of a task which terminated itself already.
    
    To fix this, we need to get a reference of the affected task when receiving
    the initial pfault interrupt and add special handling if we receive yet
    another initial pfault interrupt when the task is already enqueued in the
    pfault list.
    
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae77ce9aa720eefa34f3644d0d9e3ce3976e8f07
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon May 21 12:52:42 2012 -0700

    Fix blocking allocations called very early during bootup
    
    commit 31a67102f4762df5544bc2dfb34a931233d2a5b2 upstream.
    
    During early boot, when the scheduler hasn't really been fully set up,
    we really can't do blocking allocations because with certain (dubious)
    configurations the "might_resched()" calls can actually result in
    scheduling events.
    
    We could just make such users always use GFP_ATOMIC, but quite often the
    code that does the allocation isn't really aware of the fact that the
    scheduler isn't up yet, and forcing that kind of random knowledge on the
    initialization code is just annoying and not good for anybody.
    
    And we actually have a the 'gfp_allowed_mask' exactly for this reason:
    it's just that the kernel init sequence happens to set it to allow
    blocking allocations much too early.
    
    So move the 'gfp_allowed_mask' initialization from 'start_kernel()'
    (which is some of the earliest init code, and runs with preemption
    disabled for good reasons) into 'kernel_init()'.  kernel_init() is run
    in the newly created thread that will become the 'init' process, as
    opposed to the early startup code that runs within the context of what
    will be the first idle thread.
    
    So by the time we reach 'kernel_init()', we know that the scheduler must
    be at least limping along, because we've already scheduled from the idle
    thread into the init thread.
    
    Reported-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: David Rientjes <rientjes@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 538926ed486b8012193586e0c2dceda20e9c032a
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Sun May 13 18:35:56 2012 +0100

    regulator: core: Release regulator-regulator supplies on error
    
    commit e81dba85c6388dfabcb76cbc2b8bd02836a53ae5 upstream.
    
    If we fail while registering a regulator make sure we release the supply
    for the regulator if there is one.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Acked-by: Liam Girdwood <lrg@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c68b0f805f759fa0c61b9bbfb2ca0324b00cbd3
Author: Luis R. Rodriguez <mcgrof@frijolero.org>
Date:   Fri Mar 23 07:23:31 2012 -0700

    cfg80211: warn if db.txt is empty with CONFIG_CFG80211_INTERNAL_REGDB
    
    commit 80007efeff0568375b08faf93c7aad65602cb97e upstream.
    
    It has happened twice now where elaborate troubleshooting has
    undergone on systems where CONFIG_CFG80211_INTERNAL_REGDB [0]
    has been set but yet net/wireless/db.txt was not updated.
    
    Despite the documentation on this it seems system integrators could
    use some more help with this, so throw out a kernel warning at boot time
    when their database is empty.
    
    This does mean that the error-prone system integrator won't likely
    realize the issue until they boot the machine but -- it does not seem
    to make sense to enable a build bug breaking random build testing.
    
    [0] http://wireless.kernel.org/en/developers/Regulatory/CRDA#CONFIG_CFG80211_INTERNAL_REGDB
    
    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    Cc: Youngsin Lee <youngsin@qualcomm.com>
    Cc: Raja Mani <rmani@qca.qualcomm.com>
    Cc: Senthil Kumar Balasubramanian <senthilb@qca.qualcomm.com>
    Cc: Vipin Mehta <vipimeht@qca.qualcomm.com>
    Cc: yahuan@qca.qualcomm.com
    Cc: jjan@qca.qualcomm.com
    Cc: vthiagar@qca.qualcomm.com
    Cc: henrykim@qualcomm.com
    Cc: jouni@qca.qualcomm.com
    Cc: athiruve@qca.qualcomm.com
    Cc: cjkim@qualcomm.com
    Cc: philipk@qca.qualcomm.com
    Cc: sunnykim@qualcomm.com
    Cc: sskwak@qualcomm.com
    Cc: kkim@qualcomm.com
    Cc: mattbyun@qualcomm.com
    Cc: ryanlee@qualcomm.com
    Cc: simbap@qualcomm.com
    Cc: krislee@qualcomm.com
    Cc: conner@qualcomm.com
    Cc: hojinkim@qualcomm.com
    Cc: honglee@qualcomm.com
    Cc: johnwkim@qualcomm.com
    Cc: jinyong@qca.qualcomm.com
    Signed-off-by: Luis R. Rodriguez <mcgrof@frijolero.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64126fa12b904d5dae0b7e33fac540c46faf67c5
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon May 21 16:06:20 2012 -0700

    vfs: make AIO use the proper rw_verify_area() area helpers
    
    commit a70b52ec1aaeaf60f4739edb1b422827cb6f3893 upstream.
    
    We had for some reason overlooked the AIO interface, and it didn't use
    the proper rw_verify_area() helper function that checks (for example)
    mandatory locking on the file, and that the size of the access doesn't
    cause us to overflow the provided offset limits etc.
    
    Instead, AIO did just the security_file_permission() thing (that
    rw_verify_area() also does) directly.
    
    This fixes it to do all the proper helper functions, which not only
    means that now mandatory file locking works with AIO too, we can
    actually remove lines of code.
    
    Reported-by: Manish Honap <manish_honap_vit@yahoo.co.in>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e1468e1f16dcd141bb256fd7320687b5b8bc975
Author: Tilman Schmidt <tilman@imap.cc>
Date:   Wed Apr 25 13:02:20 2012 +0000

    isdn/gigaset: improve error handling querying firmware version
    
    commit e055d03dc088a990fe5ea24a2d64033a168da23c upstream.
    
    An out-of-place "OK" response to the "AT+GMR" (get firmware version)
    command turns out to be, more often than not, a delayed response to
    a previous command rather than an actual error, so continue waiting
    for the version number in that case.
    
    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 cdbf0ff56f0690ac4b6335427d565a858512ab1f
Author: Tilman Schmidt <tilman@imap.cc>
Date:   Wed Apr 25 13:02:20 2012 +0000

    isdn/gigaset: fix CAPI disconnect B3 handling
    
    commit 62a1cfe052346b96a552b6a9178d412c709711bb upstream.
    
    If DISCONNECT_B3_IND was synthesized because of a DISCONNECT_REQ
    with existing logical connections, the connection state wasn't
    updated accordingly. Also the emitted DISCONNECT_B3_IND message
    wasn't included in the debug log as requested.
    This patch fixes both of these issues.
    
    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 83c7de21cba00269b226fa5a01f613db64619b67
Author: Tilman Schmidt <tilman@imap.cc>
Date:   Wed Apr 25 13:02:19 2012 +0000

    isdn/gigaset: ratelimit CAPI message dumps
    
    commit 8e618aad5348b6e6c5a90e8d97ea643197963b20 upstream.
    
    Introduce a global ratelimit for CAPI message dumps to protect
    against possible log flood.
    Drop the ratelimit for ignored messages which is now covered by the
    global one.
    
    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>