commit 6a84d5503f13803c7b91f79d8ae0ecca25361ac9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Oct 2 10:43:38 2012 -0700

    Linux 3.5.5

commit b3109b3c87de5f6d98d8418c5f1931d9d2609ae0
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Jul 13 19:15:40 2012 +0100

    ARM: 7467/1: mutex: use generic xchg-based implementation for ARMv6+
    
    commit a76d7bd96d65fa5119adba97e1b58d95f2e78829 upstream.
    
    The open-coded mutex implementation for ARMv6+ cores suffers from a
    severe lack of barriers, so in the uncontended case we don't actually
    protect any accesses performed during the critical section.
    
    Furthermore, the code is largely a duplication of the ARMv6+ atomic_dec
    code but optimised to remove a branch instruction, as the mutex fastpath
    was previously inlined. Now that this is executed out-of-line, we can
    reuse the atomic access code for the locking (in fact, we use the xchg
    code as this produces shorter critical sections).
    
    This patch uses the generic xchg based implementation for mutexes on
    ARMv6+, which introduces barriers to the lock/unlock operations and also
    has the benefit of removing a fair amount of inline assembly code.
    
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Nicolas Pitre <nico@linaro.org>
    Reported-by: Shan Kang <kangshan0910@gmail.com>
    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 56015aefc7a036e7a6156a2b5b3eb6e975354e86
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sun Sep 23 19:33:55 2012 +0300

    vmwgfx: corruption in vmw_event_fence_action_create()
    
    commit 68c4fce737c4b963e336435f225621dc21138397 upstream.
    
    We don't allocate enough data for this struct.  As soon as we start
    modifying event->event on the next lines, then we're going beyond the
    end of the memory we allocated.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Dave Airlie <airlied@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1757408bfe3adca81ff1c88fcb2d578864f8e9d
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Wed Aug 29 14:08:42 2012 +0300

    drm/i915: only enable sdvo hotplug irq if needed
    
    commit fcbc50da7753b210b4442ca9abc4efbd4e481f6e upstream.
    
    Avoid constant wakeups caused by noisy irq lines when we don't even care
    about the irq. This should be particularly useful for i945g/gm where the
    hotplug has been disabled:
    
    commit 768b107e4b3be0acf6f58e914afe4f337c00932b
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Fri May 4 11:29:56 2012 +0200
    
        drm/i915: disable sdvo hotplug on i945g/gm
    
    v2: While at it, remove the bogus hotplug_active read, and do not mask
    hotplug_active[0] before checking whether the irq is needed, per discussion
    with Daniel on IRC.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38442
    Tested-by: Dominik Köppl <dominik@devwork.org>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ae8e8788b2d284b0af01e1e4f67e3d22b0161b9
Author: Dave Airlie <airlied@redhat.com>
Date:   Tue Sep 25 16:17:43 2012 +1000

    drm/udl: limit modes to the sku pixel limits.
    
    commit 3a75885848996baab5276ff37ebf7295c3c753f0 upstream.
    
    Otherwise when X starts we commonly get a black screen scanning
    out nothing, its wierd dpms on/off from userspace brings it back,
    
    With this on F18, multi-seat works again with my 1920x1200 monitor
    which is above the sku limit for the device I have.
    
    Reviewed-by: Alex Deucher <alexander.deucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94270e68d318d1d2a1654804512815999adc4b55
Author: NeilBrown <neilb@suse.de>
Date:   Thu Sep 27 12:35:21 2012 +1000

    md/raid10: fix "enough" function for detecting if array is failed.
    
    commit 80b4812407c6b1f66a4f2430e69747a13f010839 upstream.
    
    The 'enough' function is written to work with 'near' arrays only
    in that is implicitly assumes that the offset from one 'group' of
    devices to the next is the same as the number of copies.
    In reality it is the number of 'near' copies.
    
    So change it to make this number explicit.
    
    This bug makes it possible to run arrays without enough drives
    present, which is dangerous.
    It is appropriate for an -stable kernel, but will almost certainly
    need to be modified for some of them.
    
    Reported-by: Jakub Husák <jakub@gooseman.cz>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa0dd16bd04e36a10c3e271732d349f869b4f2c0
Author: Roland Stigge <stigge@antcom.de>
Date:   Thu Sep 20 10:48:03 2012 +0200

    gpio-lpc32xx: Fix value handling of gpio_direction_output()
    
    commit b1268d3737c6316016026245eef276eda6b0a621 upstream.
    
    For GPIOs of gpio-lpc32xx, gpio_direction_output() ignores the value argument
    (initial value of output). This patch fixes this by setting the level
    accordingly.
    
    Signed-off-by: Roland Stigge <stigge@antcom.de>
    Acked-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae4c274366793c3c963f569ef624a0300d855627
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Wed Sep 26 11:57:30 2012 +0100

    ASoC: wm2000: Correct register size
    
    commit d0e12f3ff3472cbd8f52d3c0e6ee07a841787c40 upstream.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc093debd67b1618e8fa4bd93b625c23388bcf92
Author: Daniel Mack <zonque@gmail.com>
Date:   Thu Sep 27 10:26:01 2012 +0200

    ALSA: snd-usb: fix next_packet_size calls for pause case
    
    commit 8dce30c89113e314d29d3b8f362aadff8087fccb upstream.
    
    Also fix the calls to next_packet_size() for the pause case. This was
    missed in 245baf983 ("ALSA: snd-usb: fix calls to next_packet_size").
    
    Signed-off-by: Daniel Mack <zonque@gmail.com>
    Reviewed-by: Takashi Iwai <tiwai@suse.de>
    Reported-and-tested-by: Christian Tefzer <ctrefzer@gmx.de>
    [ Taking directly because Takashi is on vacation  - Linus ]
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a7de1b5ec4d3eaabc9d596207f40c2b5f82b723
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Sep 26 13:09:53 2012 -0400

    USB: Fix race condition when removing host controllers
    
    commit 0d00dc2611abbe6ad244d50569c2ee82ce42846c upstream.
    
    This patch (as1607) fixes a race that can occur if a USB host
    controller is removed while a process is reading the
    /sys/kernel/debug/usb/devices file.
    
    The usb_device_read() routine uses the bus->root_hub pointer to
    determine whether or not the root hub is registered.  The is not a
    valid test, because the pointer is set before the root hub gets
    registered and remains set even after the root hub is unregistered and
    deallocated.  As a result, usb_device_read() or usb_device_dump() can
    access freed memory, causing an oops.
    
    The patch changes the test to use the hcd->rh_registered flag, which
    does get set and cleared at the appropriate times.  It also makes sure
    to hold the usb_bus_list_lock mutex while setting the flag, so that
    usb_device_read() will become aware of new root hubs as soon as they
    are registered.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Don Zickus <dzickus@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3d26f1be9179d422223d2f33d647d5459c984e3
Author: Joachim Eastwood <manabian@gmail.com>
Date:   Sun Sep 23 22:56:00 2012 +0200

    USB: ohci-at91: fix null pointer in ohci_hcd_at91_overcurrent_irq
    
    commit 01bb6501779ed0b6dc6c55be34b49eaa6306fdd8 upstream.
    
    Fixes the following NULL pointer dereference:
    [    7.740000] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
    [    7.810000] Unable to handle kernel NULL pointer dereference at virtual address 00000028
    [    7.810000] pgd = c3a38000
    [    7.810000] [00000028] *pgd=23a8c831, *pte=00000000, *ppte=00000000
    [    7.810000] Internal error: Oops: 17 [#1] PREEMPT ARM
    [    7.810000] Modules linked in: ohci_hcd(+) regmap_i2c snd_pcm usbcore snd_page_alloc at91_cf snd_timer pcmcia_rsrc snd soundcore gpio_keys regmap_spi pcmcia_core usb_common nls_base
    [    7.810000] CPU: 0    Not tainted  (3.6.0-rc6-mpa+ #264)
    [    7.810000] PC is at __gpio_to_irq+0x18/0x40
    [    7.810000] LR is at ohci_hcd_at91_overcurrent_irq+0x24/0xb4 [ohci_hcd]
    [    7.810000] pc : [<c01392d4>]    lr : [<bf08f694>]    psr: 40000093
    [    7.810000] sp : c3a11c40  ip : c3a11c50  fp : c3a11c4c
    [    7.810000] r10: 00000000  r9 : c02dcd6e  r8 : fefff400
    [    7.810000] r7 : 00000000  r6 : c02cc928  r5 : 00000030  r4 : c02dd168
    [    7.810000] r3 : c02e7350  r2 : ffffffea  r1 : c02cc928  r0 : 00000000
    [    7.810000] Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
    [    7.810000] Control: c000717f  Table: 23a38000  DAC: 00000015
    [    7.810000] Process modprobe (pid: 285, stack limit = 0xc3a10270)
    [    7.810000] Stack: (0xc3a11c40 to 0xc3a12000)
    [    7.810000] 1c40: c3a11c6c c3a11c50 bf08f694 c01392cc c3a11c84 c2c38b00 c3806900 00000030
    [    7.810000] 1c60: c3a11ca4 c3a11c70 c0051264 bf08f680 c3a11cac c3a11c80 c003e764 c3806900
    [    7.810000] 1c80: c2c38b00 c02cb05c c02cb000 fefff400 c3806930 c3a11cf4 c3a11cbc c3a11ca8
    [    7.810000] 1ca0: c005142c c005123c c3806900 c3805a00 c3a11cd4 c3a11cc0 c0053f24 c00513e4
    [    7.810000] 1cc0: c3a11cf4 00000030 c3a11cec c3a11cd8 c005120c c0053e88 00000000 00000000
    [    7.810000] 1ce0: c3a11d1c c3a11cf0 c00124d0 c00511e0 01400000 00000001 00000012 00000000
    [    7.810000] 1d00: ffffffff c3a11d94 00000030 00000000 c3a11d34 c3a11d20 c005120c c0012438
    [    7.810000] 1d20: c001dac4 00000012 c3a11d4c c3a11d38 c0009b08 c00511e0 c00523fc 60000013
    [    7.810000] 1d40: c3a11d5c c3a11d50 c0008510 c0009ab4 c3a11ddc c3a11d60 c0008eb4 c00084f0
    [    7.810000] 1d60: 00000000 00000030 00000000 00000080 60000013 bf08f670 c3806900 c2c38b00
    [    7.810000] 1d80: 00000030 c3806930 00000000 c3a11ddc c3a11d88 c3a11da8 c0054190 c00523fc
    [    7.810000] 1da0: 60000013 ffffffff c3a11dec c3a11db8 00000000 c2c38b00 bf08f670 c3806900
    [    7.810000] 1dc0: 00000000 00000080 c02cc928 00000030 c3a11e0c c3a11de0 c0052764 c00520d8
    [    7.810000] 1de0: c3a11dfc 00000000 00000000 00000002 bf090f61 00000004 c02cc930 c02cc928
    [    7.810000] 1e00: c3a11e4c c3a11e10 bf090978 c005269c bf090f61 c02cc928 bf093000 c02dd170
    [    7.810000] 1e20: c3a11e3c c02cc930 c02cc930 bf0911d0 bf0911d0 bf093000 c3a10000 00000000
    [    7.810000] 1e40: c3a11e5c c3a11e50 c0155b7c bf090808 c3a11e7c c3a11e60 c0154690 c0155b6c
    [    7.810000] 1e60: c02cc930 c02cc964 bf0911d0 c3a11ea0 c3a11e9c c3a11e80 c015484c c01545e8
    [    7.810000] 1e80: 00000000 00000000 c01547e4 bf0911d0 c3a11ec4 c3a11ea0 c0152e58 c01547f4
    [    7.810000] 1ea0: c381b88c c384ab10 c2c10540 bf0911d0 00000000 c02d7518 c3a11ed4 c3a11ec8
    [    7.810000] 1ec0: c01544c0 c0152e0c c3a11efc c3a11ed8 c01536cc c01544b0 bf091075 c3a11ee8
    [    7.810000] 1ee0: bf049af0 bf09120c bf0911d0 00000000 c3a11f1c c3a11f00 c0154e9c c0153628
    [    7.810000] 1f00: bf049af0 bf09120c 000ae190 00000000 c3a11f2c c3a11f20 c0155f58 c0154e04
    [    7.810000] 1f20: c3a11f44 c3a11f30 bf093054 c0155f1c 00000000 00006a4f c3a11f7c c3a11f48
    [    7.810000] 1f40: c0008638 bf093010 bf09120c 000ae190 00000000 c00093c4 00006a4f bf09120c
    [    7.810000] 1f60: 000ae190 00000000 c00093c4 00000000 c3a11fa4 c3a11f80 c004fdc4 c000859c
    [    7.810000] 1f80: c3a11fa4 000ae190 00006a4f 00016eb8 000ad018 00000080 00000000 c3a11fa8
    [    7.810000] 1fa0: c0009260 c004fd58 00006a4f 00016eb8 000ae190 00006a4f 000ae100 00000000
    [    7.810000] 1fc0: 00006a4f 00016eb8 000ad018 00000080 000adba0 000ad208 00000000 000ad3d8
    [    7.810000] 1fe0: beaf7ae8 beaf7ad8 000172b8 b6e4e940 20000010 000ae190 00000000 00000000
    [    7.810000] Backtrace:
    [    7.810000] [<c01392bc>] (__gpio_to_irq+0x0/0x40) from [<bf08f694>] (ohci_hcd_at91_overcurrent_irq+0x24/0xb4 [ohci_hcd])
    [    7.810000] [<bf08f670>] (ohci_hcd_at91_overcurrent_irq+0x0/0xb4 [ohci_hcd]) from [<c0051264>] (handle_irq_event_percpu+0x38/0x1a8)
    [    7.810000]  r6:00000030 r5:c3806900 r4:c2c38b00
    [    7.810000] [<c005122c>] (handle_irq_event_percpu+0x0/0x1a8) from [<c005142c>] (handle_irq_event+0x58/0x7c)
    [    7.810000] [<c00513d4>] (handle_irq_event+0x0/0x7c) from [<c0053f24>] (handle_simple_irq+0xac/0xd8)
    [    7.810000]  r5:c3805a00 r4:c3806900
    [    7.810000] [<c0053e78>] (handle_simple_irq+0x0/0xd8) from [<c005120c>] (generic_handle_irq+0x3c/0x48)
    [    7.810000]  r4:00000030
    [    7.810000] [<c00511d0>] (generic_handle_irq+0x0/0x48) from [<c00124d0>] (gpio_irq_handler+0xa8/0xfc)
    [    7.810000]  r4:00000000
    [    7.810000] [<c0012428>] (gpio_irq_handler+0x0/0xfc) from [<c005120c>] (generic_handle_irq+0x3c/0x48)
    [    7.810000] [<c00511d0>] (generic_handle_irq+0x0/0x48) from [<c0009b08>] (handle_IRQ+0x64/0x88)
    [    7.810000]  r4:00000012
    [    7.810000] [<c0009aa4>] (handle_IRQ+0x0/0x88) from [<c0008510>] (at91_aic_handle_irq+0x30/0x38)
    [    7.810000]  r5:60000013 r4:c00523fc
    [    7.810000] [<c00084e0>] (at91_aic_handle_irq+0x0/0x38) from [<c0008eb4>] (__irq_svc+0x34/0x60)
    [    7.810000] Exception stack(0xc3a11d60 to 0xc3a11da8)
    [    7.810000] 1d60: 00000000 00000030 00000000 00000080 60000013 bf08f670 c3806900 c2c38b00
    [    7.810000] 1d80: 00000030 c3806930 00000000 c3a11ddc c3a11d88 c3a11da8 c0054190 c00523fc
    [    7.810000] 1da0: 60000013 ffffffff
    [    7.810000] [<c00520c8>] (__setup_irq+0x0/0x458) from [<c0052764>] (request_threaded_irq+0xd8/0x134)
    [    7.810000] [<c005268c>] (request_threaded_irq+0x0/0x134) from [<bf090978>] (ohci_hcd_at91_drv_probe+0x180/0x41c [ohci_hcd])
    [    7.810000] [<bf0907f8>] (ohci_hcd_at91_drv_probe+0x0/0x41c [ohci_hcd]) from [<c0155b7c>] (platform_drv_probe+0x20/0x24)
    [    7.810000] [<c0155b5c>] (platform_drv_probe+0x0/0x24) from [<c0154690>] (driver_probe_device+0xb8/0x20c)
    [    7.810000] [<c01545d8>] (driver_probe_device+0x0/0x20c) from [<c015484c>] (__driver_attach+0x68/0x88)
    [    7.810000]  r7:c3a11ea0 r6:bf0911d0 r5:c02cc964 r4:c02cc930
    [    7.810000] [<c01547e4>] (__driver_attach+0x0/0x88) from [<c0152e58>] (bus_for_each_dev+0x5c/0x9c)
    [    7.810000]  r6:bf0911d0 r5:c01547e4 r4:00000000
    [    7.810000] [<c0152dfc>] (bus_for_each_dev+0x0/0x9c) from [<c01544c0>] (driver_attach+0x20/0x28)
    [    7.810000]  r7:c02d7518 r6:00000000 r5:bf0911d0 r4:c2c10540
    [    7.810000] [<c01544a0>] (driver_attach+0x0/0x28) from [<c01536cc>] (bus_add_driver+0xb4/0x22c)
    [    7.810000] [<c0153618>] (bus_add_driver+0x0/0x22c) from [<c0154e9c>] (driver_register+0xa8/0x144)
    [    7.810000]  r7:00000000 r6:bf0911d0 r5:bf09120c r4:bf049af0
    [    7.810000] [<c0154df4>] (driver_register+0x0/0x144) from [<c0155f58>] (platform_driver_register+0x4c/0x60)
    [    7.810000]  r7:00000000 r6:000ae190 r5:bf09120c r4:bf049af0
    [    7.810000] [<c0155f0c>] (platform_driver_register+0x0/0x60) from [<bf093054>] (ohci_hcd_mod_init+0x54/0x8c [ohci_hcd])
    [    7.810000] [<bf093000>] (ohci_hcd_mod_init+0x0/0x8c [ohci_hcd]) from [<c0008638>] (do_one_initcall+0xac/0x174)
    [    7.810000]  r4:00006a4f
    [    7.810000] [<c000858c>] (do_one_initcall+0x0/0x174) from [<c004fdc4>] (sys_init_module+0x7c/0x1a0)
    [    7.810000] [<c004fd48>] (sys_init_module+0x0/0x1a0) from [<c0009260>] (ret_fast_syscall+0x0/0x2c)
    [    7.810000]  r7:00000080 r6:000ad018 r5:00016eb8 r4:00006a4f
    [    7.810000] Code: e24cb004 e59f3028 e1a02000 e7930180 (e5903028)
    [    7.810000] ---[ end trace 85aa37ed128143b5 ]---
    [    7.810000] Kernel panic - not syncing: Fatal exception in interrupt
    
    Commit 6fffb77c (USB: ohci-at91: fix PIO handling in relation with number of
    ports) started setting unused pins to EINVAL. But this exposed a bug in the
    ohci_hcd_at91_overcurrent_irq function where the gpio was used without being
    checked to see if it is valid.
    
    This patches fixed the issue by adding the gpio valid check.
    
    Signed-off-by: Joachim Eastwood <joachim.eastwood@jotron.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b8b3d7b9720603433f7ab99a114a2f3e1453c71
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Sep 12 14:58:03 2012 +0300

    usb: chipidea: cleanup dma_pool if udc_start() fails
    
    commit ad6b1b97fe8504957d017cd6e4168cac8903d3f3 upstream.
    
    If udc_start() fails the qh_pool dma-pool cannot be closed because
    it's still in use. This patch factors out the dma_pool_free() loop
    into destroy_eps() and calls it in the error path of udc_start(),
    too.
    
    Reviewed-by: Richard Zhao <richard.zhao@freescale.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [mkl: backport to v3.5]
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

commit b739070c21f7279c4e508d4af7c5752b345966cb
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Sep 12 14:58:02 2012 +0300

    usb: chipidea: udc: fix error path in udc_start()
    
    commit c9d1f947a85e38b6dded469470c95ed62430cb3f upstream.
    
    This patch fixes the error path of udc_start(). Now NULL is used to
    unset the peripheral with otg_set_peripheral().
    
    Cc: stable <stable@vger.kernel.org>
    Reviewed-by: Richard Zhao <richard.zhao@freescale.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 647aac2b3cc4016aeb62b0952e90065fdff595ea
Author: Tejun Heo <tj@kernel.org>
Date:   Thu Jul 19 13:52:53 2012 -0700

    kthread_worker: reimplement flush_kthread_work() to allow freeing the work item being executed
    
    commit 46f3d976213452350f9d10b0c2780c2681f7075b upstream.
    
    kthread_worker provides minimalistic workqueue-like interface for
    users which need a dedicated worker thread (e.g. for realtime
    priority).  It has basic queue, flush_work, flush_worker operations
    which mostly match the workqueue counterparts; however, due to the way
    flush_work() is implemented, it has a noticeable difference of not
    allowing work items to be freed while being executed.
    
    While the current users of kthread_worker are okay with the current
    behavior, the restriction does impede some valid use cases.  Also,
    removing this difference isn't difficult and actually makes the code
    easier to understand.
    
    This patch reimplements flush_kthread_work() such that it uses a
    flush_work item instead of queue/done sequence numbers.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Colin Cross <ccross@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 164743c183e486910153252ab3429f4bbea994af
Author: Tejun Heo <tj@kernel.org>
Date:   Thu Jul 19 13:52:53 2012 -0700

    kthread_worker: reorganize to prepare for flush_kthread_work() reimplementation
    
    commit 9a2e03d8ed518a61154f18d83d6466628e519f94 upstream.
    
    Make the following two non-functional changes.
    
    * Separate out insert_kthread_work() from queue_kthread_work().
    
    * Relocate struct kthread_flush_work and kthread_flush_work_fn()
      definitions above flush_kthread_work().
    
    v2: Added lockdep_assert_held() in insert_kthread_work() as suggested
        by Andy Walls.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Andy Walls <awalls@md.metrocast.net>
    Cc: Colin Cross <ccross@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e116de8f0cba1231b545eb982d1f73be68dacd38
Author: Stanislav Kinsbursky <skinsbursky@parallels.com>
Date:   Tue Jul 3 16:46:41 2012 +0400

    NFSd: set nfsd_serv to NULL after service destruction
    
    commit 57c8b13e3cd0f94944c9691ce7f58e5fcef8a12d upstream.
    
    In nfsd_destroy():
    
    	if (destroy)
    		svc_shutdown_net(nfsd_serv, net);
    	svc_destroy(nfsd_server);
    
    svc_shutdown_net(nfsd_serv, net) calls nfsd_last_thread(), which sets
    nfsd_serv to NULL, causing a NULL dereference on the following line.
    
    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea8c40cf20877a61e211853e0425bc808344e881
Author: Stanislav Kinsbursky <skinsbursky@parallels.com>
Date:   Tue Jul 3 16:46:41 2012 +0400

    NFSd: introduce nfsd_destroy() helper
    
    commit 19f7e2ca44dfc3c1b3f499fc46801f98d403500f upstream.
    
    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 398f3001cf89e55b06ada5072df5f9da0137c9c4
Author: Seth Forshee <seth.forshee@canonical.com>
Date:   Wed Aug 8 08:27:03 2012 -0500

    irq_remap: disable IRQ remapping if any IOAPIC lacks an IOMMU
    
    commit 32ab31e01e2def6f48294d872d9bb42573aae00f upstream.
    
    The ACPI tables in the Macbook Air 5,1 define a single IOAPIC with id 2,
    but the only remapping unit described in the DMAR table matches id 0.
    Interrupt remapping fails as a result, and the kernel panics with the
    message "timer doesn't work through Interrupt-remapped IO-APIC."
    
    To fix this, check each IOAPIC for a corresponding IOMMU. If an IOMMU is
    not found, do not allow IRQ remapping to be enabled.
    
    v2: Move check to parse_ioapics_under_ir(), raise log level to KERN_ERR,
        and add FW_BUG to the log message
    v3: Skip check if IOMMU doesn't support interrupt remapping and remove
        existing check that the IOMMU count equals the IOAPIC count
    
    Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
    Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
    Acked-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
    Acked-by: Cho, Yu-Chen <acho@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4320e705bd7b6e17f72bfec17dfb5d035af8af2f
Author: Bjørn Mork <bjorn@mork.no>
Date:   Thu Aug 23 12:13:58 2012 +0200

    net: qmi_wwan: new devices: UML290 and K5006-Z
    
    commit 10cbc1d97a7c7f9ae862fffe27b771ef0da9c461 upstream.
    
    Newer firmware versions for the Pantech UML290 use a different
    subclass ID.  The Windows driver match on both IDs, so we do
    that as well.
    
    The ZTE (Vodafone) K5006-Z is a new device.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Cc: Dan Williams <dcbw@redhat.com>
    Cc: Thomas Schäfer <tschaefer@t-online.de>
    [bmork: backported to 3.4: use driver whitelisting]
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa7b0bb7ae256dbe58d46da2f906060482cb7928
Author: Bjørn Mork <bjorn@mork.no>
Date:   Thu Aug 23 12:13:57 2012 +0200

    net: qmi_wwan: add Sierra Wireless devices
    
    commit 9b469a60d68b13c288d5c3fc23de29d9d482dbe6 upstream.
    
    Add 6 new devices and one modified device, based on
    information from laptop vendor Windows drivers.
    
    Sony provides a driver with two new devices using
    a Gobi 2k+ layout (1199:68a5 and 1199:68a9).  The
    Sony driver also adds a non-standard QMI/net
    interface to the already supported 1199:9011
    Gobi device. We do not know whether this is an
    alternate interface number or an additional
    interface which might be present, but that doesn't
    really matter.
    
    Lenovo provides a driver supporting 4 new devices:
     - MC7770 (1199:901b) with standard Gobi 2k+ layout
     - MC7700 (0f3d:68a2) with layout similar to MC7710
     - MC7750 (114f:68a2) with layout similar to MC7710
     - EM7700 (1199:901c) with layout similar to MC7710
    
    Note regaring the three devices similar to MC7710:
    
    The Windows drivers only support interface #8 on these
    devices.  The MC7710 can support QMI/net functions on
    interface #19 and #20 as well, and this driver is
    verified to work on interface #19 (a firmware bug is
    suspected to prevent #20 from working).
    
    We do not enable these additional interfaces until they
    either show up in a Windows driver or are verified to
    work in some other way.  Therefore limiting the new
    devices to interface #8 for now.
    
    [bmork: backported to 3.4: use driver whitelisting]
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7d4d1577bac1050e43358e8c435289ae3c08c35
Author: Bjørn Mork <bjorn@mork.no>
Date:   Thu Jul 12 01:18:26 2012 +0000

    net: qmi_wwan: add ZTE MF821D
    
    commit db8dacf953a70274172236957a4b97d4fdb376f0 upstream.
    
    Sold by O2 (telefonica germany) under the name "LTE4G"
    
    Tested-by: Thomas Schäfer <tschaefer@t-online.de>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19fa18a644a6303d49295d921e651b7e19a3a75f
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed Aug 22 16:08:17 2012 -0400

    NFS: Fix Oopses in nfs_lookup_revalidate and nfs4_lookup_revalidate
    
    [Fixed upstream as part of 0b728e1911c, but that's a much larger patch,
    this is only the nfs portion backported as needed.]
    
    Fix the following Oops in 3.5.1:
    
     BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
     IP: [<ffffffffa03789cd>] nfs_lookup_revalidate+0x2d/0x480 [nfs]
     PGD 337c63067 PUD 0
     Oops: 0000 [#1] SMP
     CPU 5
     Modules linked in: nfs fscache nfsd lockd nfs_acl auth_rpcgss sunrpc af_packet binfmt_misc cpufreq_conservative cpufreq_userspace cpufreq_powersave dm_mod acpi_cpufreq mperf coretemp gpio_ich kvm_intel joydev kvm ioatdma hid_generic igb lpc_ich i7core_edac edac_core ptp serio_raw dca pcspkr i2c_i801 mfd_core sg pps_core usbhid crc32c_intel microcode button autofs4 uhci_hcd ttm drm_kms_helper drm i2c_algo_bit sysimgblt sysfillrect syscopyarea ehci_hcd usbcore usb_common scsi_dh_rdac scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh edd fan ata_piix thermal processor thermal_sys
    
     Pid: 30431, comm: java Not tainted 3.5.1-2-default #1 Supermicro X8DTT/X8DTT
     RIP: 0010:[<ffffffffa03789cd>]  [<ffffffffa03789cd>] nfs_lookup_revalidate+0x2d/0x480 [nfs]
     RSP: 0018:ffff8801b418bd38  EFLAGS: 00010292
     RAX: 00000000fffffff6 RBX: ffff88032016d800 RCX: 0000000000000020
     RDX: ffffffff00000000 RSI: 0000000000000000 RDI: ffff8801824a7b00
     RBP: ffff8801b418bdf8 R08: 7fffff0034323030 R09: fffffffff04c03ed
     R10: ffff8801824a7b00 R11: 0000000000000002 R12: ffff8801824a7b00
     R13: ffff8801824a7b00 R14: 0000000000000000 R15: ffff8803201725d0
     FS:  00002b53a46cb700(0000) GS:ffff88033fc20000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000038 CR3: 000000020a426000 CR4: 00000000000007e0
     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
     DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
     Process java (pid: 30431, threadinfo ffff8801b418a000, task ffff8801b5d20600)
     Stack:
      ffff8801b418be44 ffff88032016d800 ffff8801b418bdf8 0000000000000000
      ffff8801824a7b00 ffff8801b418bdd7 ffff8803201725d0 ffffffff8116a9c0
      ffff8801b5c38dc0 0000000000000007 ffff88032016d800 0000000000000000
     Call Trace:
      [<ffffffff8116a9c0>] lookup_dcache+0x80/0xe0
      [<ffffffff8116aa43>] __lookup_hash+0x23/0x90
      [<ffffffff8116b4a5>] lookup_one_len+0xc5/0x100
      [<ffffffffa03869a3>] nfs_sillyrename+0xe3/0x210 [nfs]
      [<ffffffff8116cadf>] vfs_unlink.part.25+0x7f/0xe0
      [<ffffffff8116f22c>] do_unlinkat+0x1ac/0x1d0
      [<ffffffff815717b9>] system_call_fastpath+0x16/0x1b
      [<00002b5348b5f527>] 0x2b5348b5f526
     Code: ec 38 b8 f6 ff ff ff 4c 89 64 24 18 4c 89 74 24 28 49 89 fc 48 89 5c 24 08 48 89 6c 24 10 49 89 f6 4c 89 6c 24 20 4c 89 7c 24 30 <f6> 46 38 40 0f 85 d1 00 00 00 e8 c4 c4 df e0 48 8b 58 30 49 89
     RIP  [<ffffffffa03789cd>] nfs_lookup_revalidate+0x2d/0x480 [nfs]
      RSP <ffff8801b418bd38>
     CR2: 0000000000000038
     ---[ end trace 845113ed191985dd ]---
    
    This Oops affects 3.5 kernels and older, and is due to lookup_one_len()
    calling down to the dentry revalidation code with a NULL pointer
    to struct nameidata.
    
    It is fixed upstream by commit 0b728e1911c (stop passing nameidata *
    to ->d_revalidate())
    
    Reported-by: Richard Ems <richard.ems@cape-horn-eng.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40324cd9f8c247f5be4114d5721c1bb66965c172
Author: Andreas Schwab <schwab@linux-m68k.org>
Date:   Sat Jun 9 15:58:56 2012 +0200

    sound/aoa: Adapt to new i2c probing scheme
    
    commit 26b0d14106954ae46d2f4f7eec3481828a210f7d upstream.
    
    The i2c-powermac driver now creates the i2c devices properly
    from the device-tree, including workarounds for broken or
    missing device-tree bits, so let's just use the normal probe
    methods and get rid of the hand made device creation code.
    
    Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Elimar Riesebieter <riesebie@lxtec.de>
    Cc: Michel Dänzer <michel@daenzer.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a07d6f9f4536af97bcb0d387d7280b1f4568b109
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Mon Jun 18 12:00:50 2012 +1000

    i2c/powermac: Improve detection of devices from device-tree
    
    commit 3a3dd0186f619b74e61e6f29dddcaf59af7d3cac upstream.
    
    This patch adds a number of workarounds for broken Apple device-trees
    mostly around sound chips. It handles creating the missing audio codec
    devices and works around various issues with missing addresses or
    missing compatible properties.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Michel Dänzer <michel@daenzer.net>
    Cc: Elimar Riesebieter <riesebie@lxtec.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a122873c3232b60cfbbd58ab58c906926dba7dc0
Author: Keshava Munegowda <keshava_mgowda@ti.com>
Date:   Fri Jul 20 15:13:35 2012 +0530

    OMAP: USB : Fix the EHCI enumeration and core retention issue
    
    commit 872c495dd0f9d1f48814a8ee80c2c7b3b7c3b4d9 upstream.
    
    This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
    "Fix OMAP EHCI suspend/resume failure (i693)" is causing
    the usb hub and device detection fails in beagle XM
    causeing NFS not functional. This affects the core retention too.
    The same commit logic needs to be revisted adhering to hwmod and
    device tree framework.
    for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
    titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted.
    
    This patch is validated on BeagleXM with NFS support over
    usb ethernet and USB mass storage and other device detection.
    
    Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
    Acked-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a93689e1da5687e462363fde567e9b7abd570124
Author: Darren Hart <dvhart@linux.intel.com>
Date:   Tue Jun 19 14:00:18 2012 -0700

    pch_uart: Add eg20t_port lock field, avoid recursive spinlocks
    
    commit 2588aba002d14e938c2f56d299ecf3e7ce1302a5 upstream.
    
    pch_uart_interrupt() takes priv->port.lock which leads to two recursive
    spinlock calls if low_latency==1 or CONFIG_PREEMPT_RT_FULL=y (one
    otherwise):
    
    pch_uart_interrupt
      spin_lock_irqsave(priv->port.lock, flags)
      case PCH_UART_IID_RDR_TO (data ready)
      handle_rx_to
        push_rx
          tty_port_tty_get
            spin_lock_irqsave(&port->lock, flags) <--- already hold this lock
            ...
          tty_flip_buffer_push
            ...
            flush_to_ldisc
              spin_lock_irqsave(&tty->buf.lock)
                spin_lock_irqsave(&tty->buf.lock)
                disc->ops->receive_buf(tty, char_buf)
                  n_tty_receive_buf
                    tty->ops->flush_chars()
                    uart_flush_chars
                      uart_start
                        spin_lock_irqsave(&port->lock) <--- already hold this lock
    
    Avoid this by using a dedicated lock to protect the eg20t_port structure
    and IO access to its membase. This is more consistent with the 8250
    driver.  Ensure priv->lock is always take prior to priv->port.lock when
    taken at the same time.
    
    V2: Remove inadvertent whitespace change.
    V3: Account for oops_in_progress for the private lock in
        pch_console_write().
    
    Note: Like the 8250 driver, if a printk is introduced anywhere inside
          the pch_console_write() critical section, the kernel will hang
          on a recursive spinlock on the private lock. The oops case is
          handled by using a trylock in the oops_in_progress case.
    
    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    CC: Tomoya MORINAGA <tomoya.rohm@gmail.com>
    CC: Feng Tang <feng.tang@intel.com>
    CC: Alexander Stein <alexander.stein@systec-electronic.com>
    Acked-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e518b46f7552d53be920c9b0415784fe0172e9d
Author: Timur Tabi <timur@freescale.com>
Date:   Mon Jul 23 15:43:32 2012 -0500

    powerpc/85xx: p1022ds: fix DIU/LBC switching with NAND enabled
    
    commit 896c01cb4bb3cfc2c0ea9873fa7a9f8bd0a7c8d8 upstream.
    
    In order for indirect mode on the PIXIS to work properly, both chip selects
    need to be set to GPCM mode, otherwise writes to the chip select base
    addresses will not actually post to the local bus -- they'll go to the
    NAND controller instead.  Therefore, we need to set BR0 and BR1 to GPCM
    mode before switching to indirect mode.
    
    Signed-off-by: Timur Tabi <timur@freescale.com>
    Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 769f1c1a00de9a155cd905000943ed336500cee4
Author: Timur Tabi <timur@freescale.com>
Date:   Fri Jul 13 14:28:42 2012 -0500

    powerpc/85xx: p1022ds: disable the NAND flash node if video is enabled
    
    commit 6269f2584a359766f53005c676daff8aee60cbed upstream.
    
    The Freescale P1022 has a unique pin muxing "feature" where the DIU video
    controller's video signals are muxed with 24 of the local bus address signals.
    When the DIU is enabled, the bulk of the local bus is disabled, preventing
    access to memory-mapped devices like NAND flash and the pixis FPGA.
    
    Therefore, if the DIU is going to be enabled, then memory-mapped devices on
    the localbus, like NAND flash, need to be disabled.
    
    This patch is similar to "powerpc/85xx: p1022ds: disable the NOR flash node
    if video is enabled", except that it disables the NAND flash node instead.
    This PIXIS node needs to remain enabled because it is used by platform code
    to switch into indirect mode.
    
    Signed-off-by: Timur Tabi <timur@freescale.com>
    Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 774093a4f9b16c74f3ffb264314a798528786ff6
Author: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Date:   Fri Jul 6 17:19:43 2012 +0900

    pch_uart: Fix parity setting issue
    
    commit 38bd2a1ac736901d1cf4971c78ef952ba92ef78b upstream.
    
    Parity Setting value is reverse.
    E.G. In case of setting ODD parity, EVEN value is set.
    This patch inverts "if" condition.
    
    Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
    Acked-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 775436806eb348affdc7693341b0f23ed8147ebd
Author: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Date:   Fri Jul 6 17:19:42 2012 +0900

    pch_uart: Fix rx error interrupt setting issue
    
    commit 9539dfb7ac1c84522fe1f79bb7dac2990f3de44a upstream.
    
    Rx Error interrupt(E.G. parity error) is not enabled.
    So, when parity error occurs, error interrupt is not occurred.
    As a result, the received data is not dropped.
    
    This patch adds enable/disable rx error interrupt code.
    
    Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
    Acked-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca6be9203a58f70e7489e14ff8a5af162276b049
Author: Alan Cox <alan@linux.intel.com>
Date:   Mon Jul 2 18:51:38 2012 +0100

    pch_uart: Fix missing break for 16 byte fifo
    
    commit 9bc03743fff0770dc5a5324ba92e67cc377f16ca upstream.
    
    Otherwise we fall back to the wrong value.
    
    Reported-by: <dcb314@hotmail.com>
    Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44091
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b80cf03c46f5fab17df853930ffadd02aacf11e
Author: Douglas Bagnall <douglas@paradise.net.nz>
Date:   Fri Jul 6 23:27:57 2012 -0300

    media: Avoid sysfs oops when an rc_dev's raw device is absent
    
    commit 720bb6436ff30fccad05cf5bdf961ea5b1f5686d upstream.
    
    For some reason, when the lirc daemon learns that a usb remote control
    has been unplugged, it wants to read the sysfs attributes of the
    disappearing device. This is useful for uncovering transient
    inconsistencies, but less so for keeping the system running when such
    inconsistencies exist.
    
    Under some circumstances (like every time I unplug my dvb stick from
    my laptop), lirc catches an rc_dev whose raw event handler has been
    removed (presumably by ir_raw_event_unregister), and proceeds to
    interrogate the raw protocols supported by the NULL pointer.
    
    This patch avoids the NULL dereference, and ignores the issue of how
    this state of affairs came about in the first place.
    
    Version 2 incorporates changes recommended by Mauro Carvalho Chehab
    (-ENODEV instead of -EINVAL, and a signed-off-by).
    
    Signed-off-by: Douglas Bagnall <douglas@paradise.net.nz>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4eb34389b35064542b62099a14a51a43cf49598c
Author: John Stultz <john.stultz@linaro.org>
Date:   Tue Sep 11 14:56:21 2012 -0400

    time: Move ktime_t overflow checking into timespec_valid_strict
    
    commit cee58483cf56e0ba355fdd97ff5e8925329aa936 upstream.
    
    Andreas Bombe reported that the added ktime_t overflow checking added to
    timespec_valid in commit 4e8b14526ca7 ("time: Improve sanity checking of
    timekeeping inputs") was causing problems with X.org because it caused
    timeouts larger then KTIME_T to be invalid.
    
    Previously, these large timeouts would be clamped to KTIME_MAX and would
    never expire, which is valid.
    
    This patch splits the ktime_t overflow checking into a new
    timespec_valid_strict function, and converts the timekeeping codes
    internal checking to use this more strict function.
    
    Reported-and-tested-by: Andreas Bombe <aeb@debian.org>
    Cc: Zhouping Liu <zliu@redhat.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e64f897ce0d333d574143c0a23b1299d6137b4a
Author: John Stultz <john.stultz@linaro.org>
Date:   Tue Sep 11 14:56:20 2012 -0400

    time: Avoid making adjustments if we haven't accumulated anything
    
    commit bf2ac312195155511a0f79325515cbb61929898a upstream.
    
    If update_wall_time() is called and the current offset isn't large
    enough to accumulate, avoid re-calling timekeeping_adjust which may
    change the clock freq and can cause 1ns inconsistencies with
    CLOCK_REALTIME_COARSE/CLOCK_MONOTONIC_COARSE.
    
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/1345595449-34965-5-git-send-email-john.stultz@linaro.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7df3d033efb005c6018512933078566cd6f49463
Author: John Stultz <john.stultz@linaro.org>
Date:   Tue Sep 11 14:56:19 2012 -0400

    time: Improve sanity checking of timekeeping inputs
    
    commit 4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b upstream.
    
    Unexpected behavior could occur if the time is set to a value large
    enough to overflow a 64bit ktime_t (which is something larger then the
    year 2262).
    
    Also unexpected behavior could occur if large negative offsets are
    injected via adjtimex.
    
    So this patch improves the sanity check timekeeping inputs by
    improving the timespec_valid() check, and then makes better use of
    timespec_valid() to make sure we don't set the time to an invalid
    negative value or one that overflows ktime_t.
    
    Note: This does not protect from setting the time close to overflowing
    ktime_t and then letting natural accumulation cause the overflow.
    
    Reported-by: CAI Qian <caiqian@redhat.com>
    Reported-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Zhouping Liu <zliu@redhat.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Link: http://lkml.kernel.org/r/1344454580-17031-1-git-send-email-john.stultz@linaro.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25d97e9ecea68839ac7d55e8ccd381111254bfb2
Author: Jarod Wilson <jarod@redhat.com>
Date:   Mon Jun 4 13:05:24 2012 -0300

    media: lirc_sir: make device registration work
    
    commit 4b71ca6bce8fab3d08c61bf330e781f957934ae1 upstream.
    
    For one, the driver device pointer needs to be filled in, or the lirc core
    will refuse to load the driver. And we really need to wire up all the
    platform_device bits. This has been tested via the lirc sourceforge tree
    and verified to work, been sitting there for months, finally getting
    around to sending it. :\
    
    Signed-off-by: Jarod Wilson <jarod@redhat.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    CC: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f83989550ace0aa91464051cbaddc10e1b85778
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Jun 22 13:36:05 2012 +0200

    sched: Fix race in task_group()
    
    commit 8323f26ce3425460769605a6aece7a174edaa7d1 upstream.
    
    Stefan reported a crash on a kernel before a3e5d1091c1 ("sched:
    Don't call task_group() too many times in set_task_rq()"), he
    found the reason to be that the multiple task_group()
    invocations in set_task_rq() returned different values.
    
    Looking at all that I found a lack of serialization and plain
    wrong comments.
    
    The below tries to fix it using an extra pointer which is
    updated under the appropriate scheduler locks. Its not pretty,
    but I can't really see another way given how all the cgroup
    stuff works.
    
    Reported-and-tested-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/1340364965.18025.71.camel@twins
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 589e9fa686c2a02b48a36057c9ba5a7327059074
Author: Daniel J Blueman <daniel@quora.org>
Date:   Mon Jul 23 12:22:37 2012 +0800

    libata: Prevent interface errors with Seagate FreeAgent GoFlex
    
    commit c531077f40abc9f2129c4c83a30b3f8d6ce1c0e7 upstream.
    
    When using my Seagate FreeAgent GoFlex eSATAp external disk enclosure,
    interface errors are always seen until 1.5Gbps is negotiated [1]. This
    occurs using any disk in the enclosure, and when the disk is connected
    directly with a generic passive eSATAp cable, we see stable 3Gbps
    operation as expected.
    
    Blacklist 3Gbps mode to avoid dataloss and the ~30s delay bus reset
    and renegotiation incurs.
    
    Signed-off-by: Daniel J Blueman <daniel@quora.org>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac6519ad79a7553efcb335d85fec6f0b4ce89454
Author: Weiping Pan <wpan@redhat.com>
Date:   Mon Jul 23 10:37:48 2012 +0800

    rds: set correct msg_namelen
    
    commit 06b6a1cf6e776426766298d055bb3991957d90a7 upstream.
    
    Jay Fenlason (fenlason@redhat.com) found a bug,
    that recvfrom() on an RDS socket can return the contents of random kernel
    memory to userspace if it was called with a address length larger than
    sizeof(struct sockaddr_in).
    rds_recvmsg() also fails to set the addr_len paramater properly before
    returning, but that's just a bug.
    There are also a number of cases wher recvfrom() can return an entirely bogus
    address. Anything in rds_recvmsg() that returns a non-negative value but does
    not go through the "sin = (struct sockaddr_in *)msg->msg_name;" code path
    at the end of the while(1) loop will return up to 128 bytes of kernel memory
    to userspace.
    
    And I write two test programs to reproduce this bug, you will see that in
    rds_server, fromAddr will be overwritten and the following sock_fd will be
    destroyed.
    Yes, it is the programmer's fault to set msg_namelen incorrectly, but it is
    better to make the kernel copy the real length of address to user space in
    such case.
    
    How to run the test programs ?
    I test them on 32bit x86 system, 3.5.0-rc7.
    
    1 compile
    gcc -o rds_client rds_client.c
    gcc -o rds_server rds_server.c
    
    2 run ./rds_server on one console
    
    3 run ./rds_client on another console
    
    4 you will see something like:
    server is waiting to receive data...
    old socket fd=3
    server received data from client:data from client
    msg.msg_namelen=32
    new socket fd=-1067277685
    sendmsg()
    : Bad file descriptor
    
    /***************** rds_client.c ********************/
    
    int main(void)
    {
    	int sock_fd;
    	struct sockaddr_in serverAddr;
    	struct sockaddr_in toAddr;
    	char recvBuffer[128] = "data from client";
    	struct msghdr msg;
    	struct iovec iov;
    
    	sock_fd = socket(AF_RDS, SOCK_SEQPACKET, 0);
    	if (sock_fd < 0) {
    		perror("create socket error\n");
    		exit(1);
    	}
    
    	memset(&serverAddr, 0, sizeof(serverAddr));
    	serverAddr.sin_family = AF_INET;
    	serverAddr.sin_addr.s_addr = inet_addr("127.0.0.1");
    	serverAddr.sin_port = htons(4001);
    
    	if (bind(sock_fd, (struct sockaddr*)&serverAddr, sizeof(serverAddr)) < 0) {
    		perror("bind() error\n");
    		close(sock_fd);
    		exit(1);
    	}
    
    	memset(&toAddr, 0, sizeof(toAddr));
    	toAddr.sin_family = AF_INET;
    	toAddr.sin_addr.s_addr = inet_addr("127.0.0.1");
    	toAddr.sin_port = htons(4000);
    	msg.msg_name = &toAddr;
    	msg.msg_namelen = sizeof(toAddr);
    	msg.msg_iov = &iov;
    	msg.msg_iovlen = 1;
    	msg.msg_iov->iov_base = recvBuffer;
    	msg.msg_iov->iov_len = strlen(recvBuffer) + 1;
    	msg.msg_control = 0;
    	msg.msg_controllen = 0;
    	msg.msg_flags = 0;
    
    	if (sendmsg(sock_fd, &msg, 0) == -1) {
    		perror("sendto() error\n");
    		close(sock_fd);
    		exit(1);
    	}
    
    	printf("client send data:%s\n", recvBuffer);
    
    	memset(recvBuffer, '\0', 128);
    
    	msg.msg_name = &toAddr;
    	msg.msg_namelen = sizeof(toAddr);
    	msg.msg_iov = &iov;
    	msg.msg_iovlen = 1;
    	msg.msg_iov->iov_base = recvBuffer;
    	msg.msg_iov->iov_len = 128;
    	msg.msg_control = 0;
    	msg.msg_controllen = 0;
    	msg.msg_flags = 0;
    	if (recvmsg(sock_fd, &msg, 0) == -1) {
    		perror("recvmsg() error\n");
    		close(sock_fd);
    		exit(1);
    	}
    
    	printf("receive data from server:%s\n", recvBuffer);
    
    	close(sock_fd);
    
    	return 0;
    }
    
    /***************** rds_server.c ********************/
    
    int main(void)
    {
    	struct sockaddr_in fromAddr;
    	int sock_fd;
    	struct sockaddr_in serverAddr;
    	unsigned int addrLen;
    	char recvBuffer[128];
    	struct msghdr msg;
    	struct iovec iov;
    
    	sock_fd = socket(AF_RDS, SOCK_SEQPACKET, 0);
    	if(sock_fd < 0) {
    		perror("create socket error\n");
    		exit(0);
    	}
    
    	memset(&serverAddr, 0, sizeof(serverAddr));
    	serverAddr.sin_family = AF_INET;
    	serverAddr.sin_addr.s_addr = inet_addr("127.0.0.1");
    	serverAddr.sin_port = htons(4000);
    	if (bind(sock_fd, (struct sockaddr*)&serverAddr, sizeof(serverAddr)) < 0) {
    		perror("bind error\n");
    		close(sock_fd);
    		exit(1);
    	}
    
    	printf("server is waiting to receive data...\n");
    	msg.msg_name = &fromAddr;
    
    	/*
    	 * I add 16 to sizeof(fromAddr), ie 32,
    	 * and pay attention to the definition of fromAddr,
    	 * recvmsg() will overwrite sock_fd,
    	 * since kernel will copy 32 bytes to userspace.
    	 *
    	 * If you just use sizeof(fromAddr), it works fine.
    	 * */
    	msg.msg_namelen = sizeof(fromAddr) + 16;
    	/* msg.msg_namelen = sizeof(fromAddr); */
    	msg.msg_iov = &iov;
    	msg.msg_iovlen = 1;
    	msg.msg_iov->iov_base = recvBuffer;
    	msg.msg_iov->iov_len = 128;
    	msg.msg_control = 0;
    	msg.msg_controllen = 0;
    	msg.msg_flags = 0;
    
    	while (1) {
    		printf("old socket fd=%d\n", sock_fd);
    		if (recvmsg(sock_fd, &msg, 0) == -1) {
    			perror("recvmsg() error\n");
    			close(sock_fd);
    			exit(1);
    		}
    		printf("server received data from client:%s\n", recvBuffer);
    		printf("msg.msg_namelen=%d\n", msg.msg_namelen);
    		printf("new socket fd=%d\n", sock_fd);
    		strcat(recvBuffer, "--data from server");
    		if (sendmsg(sock_fd, &msg, 0) == -1) {
    			perror("sendmsg()\n");
    			close(sock_fd);
    			exit(1);
    		}
    	}
    
    	close(sock_fd);
    	return 0;
    }
    
    Signed-off-by: Weiping Pan <wpan@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d039ed8264695916335c639d8de77c3b1ff18e71
Author: Li Zhong <zhong@linux.vnet.ibm.com>
Date:   Tue Jul 24 15:02:49 2012 -0700

    Fix a dead loop in async_synchronize_full()
    
    [Fixed upstream by commits 2955b47d2c1983998a8c5915cb96884e67f7cb53 and
    a4683487f90bfe3049686fc5c566bdc1ad03ace6 from Dan Williams, but they are much
    more intrusive than this tiny fix, according to Andrew - gregkh]
    
    This patch tries to fix a dead loop in  async_synchronize_full(), which
    could be seen when preemption is disabled on a single cpu machine.
    
    void async_synchronize_full(void)
    {
            do {
                    async_synchronize_cookie(next_cookie);
            } while (!list_empty(&async_running) || !
    list_empty(&async_pending));
    }
    
    async_synchronize_cookie() calls async_synchronize_cookie_domain() with
    &async_running as the default domain to synchronize.
    
    However, there might be some works in the async_pending list from other
    domains. On a single cpu system, without preemption, there is no chance
    for the other works to finish, so async_synchronize_full() enters a dead
    loop.
    
    It seems async_synchronize_full() wants to synchronize all entries in
    all running lists(domains), so maybe we could just check the entry_count
    to know whether all works are finished.
    
    Currently, async_synchronize_cookie_domain() expects a non-NULL running
    list ( if NULL, there would be NULL pointer dereference ), so maybe a
    NULL pointer could be used as an indication for the functions to
    synchronize all works in all domains.
    
    Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
    Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Tested-by: Christian Kujau <lists@nerdbynature.de>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Dan Williams <dan.j.williams@gmail.com>
    Cc: Christian Kujau <lists@nerdbynature.de>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7afc1629143b046165e5e304056b47a9942e876
Author: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Date:   Thu Aug 23 21:32:44 2012 -0300

    Bluetooth: Fix sending a HCI Authorization Request over LE links
    
    commit d8343f125710fb596f7a88cd756679f14f4e77b9 upstream.
    
    In the case that the link is already in the connected state and a
    Pairing request arrives from the mgmt interface, hci_conn_security()
    would be called but it was not considering LE links.
    
    Reported-by: João Paulo Rechi Vita <jprvita@openbossa.org>
    Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 257f3932617fa8019b779f6fa0d327c50885ff8a
Author: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Date:   Thu Aug 23 21:32:43 2012 -0300

    Bluetooth: Change signature of smp_conn_security()
    
    commit cc110922da7e902b62d18641a370fec01a9fa794 upstream.
    
    To make it clear that it may be called from contexts that may not have
    any knowledge of L2CAP, we change the connection parameter, to receive
    a hci_conn.
    
    This also makes it clear that it is checking the security of the link.
    
    Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 222616daa324e7a7c911d8f513181417b55ba2df
Author: Andre Guedes <andre.guedes@openbossa.org>
Date:   Wed Aug 1 20:34:15 2012 -0300

    Bluetooth: Fix use-after-free bug in SMP
    
    commit 61a0cfb008f57ecf7eb28ee762952fb42dc15d15 upstream.
    
    If SMP fails, we should always cancel security_timer delayed work.
    Otherwise, security_timer function may run after l2cap_conn object
    has been freed.
    
    This patch fixes the following warning reported by ODEBUG:
    
    WARNING: at lib/debugobjects.c:261 debug_print_object+0x7c/0x8d()
    Hardware name: Bochs
    ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x27
    Modules linked in: btusb bluetooth
    Pid: 440, comm: kworker/u:2 Not tainted 3.5.0-rc1+ #4
    Call Trace:
     [<ffffffff81174600>] ? free_obj_work+0x4a/0x7f
     [<ffffffff81023eb8>] warn_slowpath_common+0x7e/0x97
     [<ffffffff81023f65>] warn_slowpath_fmt+0x41/0x43
     [<ffffffff811746b1>] debug_print_object+0x7c/0x8d
     [<ffffffff810394f0>] ? __queue_work+0x241/0x241
     [<ffffffff81174fdd>] debug_check_no_obj_freed+0x92/0x159
     [<ffffffff810ac08e>] slab_free_hook+0x6f/0x77
     [<ffffffffa0019145>] ? l2cap_conn_del+0x148/0x157 [bluetooth]
     [<ffffffff810ae408>] kfree+0x59/0xac
     [<ffffffffa0019145>] l2cap_conn_del+0x148/0x157 [bluetooth]
     [<ffffffffa001b9a2>] l2cap_recv_frame+0xa77/0xfa4 [bluetooth]
     [<ffffffff810592f9>] ? trace_hardirqs_on_caller+0x112/0x1ad
     [<ffffffffa001c86c>] l2cap_recv_acldata+0xe2/0x264 [bluetooth]
     [<ffffffffa0002b2f>] hci_rx_work+0x235/0x33c [bluetooth]
     [<ffffffff81038dc3>] ? process_one_work+0x126/0x2fe
     [<ffffffff81038e22>] process_one_work+0x185/0x2fe
     [<ffffffff81038dc3>] ? process_one_work+0x126/0x2fe
     [<ffffffff81059f2e>] ? lock_acquired+0x1b5/0x1cf
     [<ffffffffa00028fa>] ? le_scan_work+0x11d/0x11d [bluetooth]
     [<ffffffff81036fb6>] ? spin_lock_irq+0x9/0xb
     [<ffffffff81039209>] worker_thread+0xcf/0x175
     [<ffffffff8103913a>] ? rescuer_thread+0x175/0x175
     [<ffffffff8103cfe0>] kthread+0x95/0x9d
     [<ffffffff812c5054>] kernel_threadi_helper+0x4/0x10
     [<ffffffff812c36b0>] ? retint_restore_args+0x13/0x13
     [<ffffffff8103cf4b>] ? flush_kthread_worker+0xdb/0xdb
     [<ffffffff812c5050>] ? gs_change+0x13/0x13
    
    This bug can be reproduced using hctool lecc or l2test tools and
    bluetoothd not running.
    
    Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d601ddf0e5050fcdb2b1db1a9120cf0a9412817b
Author: Henrik Rydberg <rydberg@euromail.se>
Date:   Sat Aug 25 19:28:06 2012 +0200

    Bluetooth: Add support for Apple vendor-specific devices
    
    commit 1fa6535faf055cd71311ab887e94fc234f04ee18 upstream.
    
    As pointed out by Gustavo and Marcel, all Apple-specific Broadcom
    devices seen so far have the same interface class, subclass and
    protocol numbers. This patch adds an entry which matches all of them,
    using the new USB_VENDOR_AND_INTERFACE_INFO() macro.
    
    In particular, this patch adds support for the MacBook Pro Retina
    (05ac:8286), which is not in the present list.
    
    Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
    Tested-by: Shea Levy <shea@shealevy.com>
    Acked-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 765488029cc1735004acc06d6913ffe705c64c58
Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Date:   Mon Aug 6 15:36:49 2012 -0300

    Bluetooth: Use USB_VENDOR_AND_INTERFACE() for Broadcom devices
    
    commit 92c385f46b30f4954e9dd2d2005c12d233b479ea upstream.
    
    Many Broadcom devices has a vendor specific devices class, with this rule
    we match all existent and future controllers with this behavior.
    
    We also remove old rules to that matches product id for Broadcom devices.
    
    Tested-by: John Hommel <john.hommel@hp.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd1a42b3a30d2f2ffd7787efb5e60a5e914eead6
Author: Yevgeniy Melnichuk <yevgeniy.melnichuk@googlemail.com>
Date:   Tue Aug 7 19:48:10 2012 +0530

    Bluetooth: Add support for Sony Vaio T-Series
    
    commit bc21fde2d549d1cb1ebef04016eb7affa43bb5c1 upstream.
    
    Add Sony Vaio T-Series Bluetooth Module( 0x489:0xE036) to
    the blacklist of btusb module and add it to the ath3k module.
    
    output of cat /sys/kernel/debug/usb/devices
    
    T:  Bus=01 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  5 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0489 ProdID=e036 Rev= 0.02
    S:  Manufacturer=Atheros Communications
    S:  Product=Bluetooth USB Host Controller
    S:  SerialNumber=Alaska Day 2006
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    
    Signed-off-by: Yevgeniy Melnichuk <yevgeniy.melnichuk@googlemail.com>
    Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
    Acked-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 456f44935e59a39ba6e4af1d73b1a4f348a47cd2
Author: Peng Chen <pengchen@qca.qualcomm.com>
Date:   Wed Aug 1 10:11:59 2012 +0800

    Bluetooth: add support for atheros 0489:e057
    
    commit 2096ae6ca647302d50a68aa36cb66a00e7dfac70 upstream.
    
        Add support for the AR3012 chip found on Fioxconn.
    
        usb-devices shows:
    
        T:  Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 44 Spd=12   MxCh= 0
        D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
        P:  Vendor=0489 ProdID=e057 Rev= 0.02
        C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
        I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
        E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
        E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
        E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
        I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
        E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
        E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
        I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
        E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
        E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
        I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
        E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
        E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
        I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
        E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
        E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
        I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
        E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
        E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
        I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
        E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
        E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    
    Signed-off-by: Peng Chen <pengchen@qca.qualcomm.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d40b94545d1013830872f68f81d72557149ae97
Author: Manoj Iyer <manoj.iyer@canonical.com>
Date:   Tue Jul 10 14:07:38 2012 -0500

    Bluetooth: btusb: Add vendor specific ID (0a5c:21f4) BCM20702A0
    
    commit 61c964ba1748e984cb232b431582815899bf10fe upstream.
    
    Patch adds support for BCM20702A0 device id (0a5c:21f4).
    
    usb-devices after patch was applied:
    T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
    D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
    P: Vendor=0a5c ProdID=21f4 Rev=01.12
    S: Manufacturer=Broadcom Corp
    S: Product=BCM20702A0
    S: SerialNumber=E4D53DF154D6
    C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
    I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
    
    usb-devices before patch was applied:
    T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
    D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
    P: Vendor=0a5c ProdID=21f4 Rev=01.12
    S: Manufacturer=Broadcom Corp
    S: Product=BCM20702A0
    S: SerialNumber=E4D53DF154D6
    C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
    I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
    
    Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
    Tested-by: Chris Gagnon <chris.gagnon@canonical.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc534755ea9ee245424864d5b049a5202deff854
Author: Ping Cheng <pinglinux@gmail.com>
Date:   Tue Jun 12 00:14:12 2012 -0700

    Input: wacom - rearrange type enum
    
    commit ea2e60244573a9204c8cee9b4fb181106784c617 upstream.
    
    So we can simplify a few type related if statements
    
    Also fixes https://bugzilla.kernel.org/show_bug.cgi?id=46821
    
    Signed-off-by: Ping Cheng <pingc@wacom.com>
    Acked-by: Chris Bagwell <chris@cnpbagwell.com>
    Reviewed-by: Jason Gerecke <killertofu@gmail.com>
    Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4bb04e1b2eafc36c4cb5d36259911247e67f0ca7
Author: Ping Cheng <pinglinux@gmail.com>
Date:   Tue Jul 24 23:54:11 2012 -0700

    Input: wacom - add support to Cintiq 22HD
    
    commit d838c644fea603eb24811333c6e2cf4f9722bf10 upstream.
    
    Signed-off-by: Ping Cheng <pingc@wacom.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Cc: Joseph Salisbury <joseph.salisbury@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 814b1489d0e0d0d869f3d675fb791478370de9d3
Author: Lai Jiangshan <laijs@cn.fujitsu.com>
Date:   Sun Sep 2 00:28:19 2012 +0800

    workqueue: UNBOUND -> REBIND morphing in rebind_workers() should be atomic
    
    commit 96e65306b81351b656835c15931d1d237b252f27 upstream.
    
    The compiler may compile the following code into TWO write/modify
    instructions.
    
    	worker->flags &= ~WORKER_UNBOUND;
    	worker->flags |= WORKER_REBIND;
    
    so the other CPU may temporarily see worker->flags which doesn't have
    either WORKER_UNBOUND or WORKER_REBIND set and perform local wakeup
    prematurely.
    
    Fix it by using single explicit assignment via ACCESS_ONCE().
    
    Because idle workers have another WORKER_NOT_RUNNING flag, this bug
    doesn't exist for them; however, update it to use the same pattern for
    consistency.
    
    tj: Applied the change to idle workers too and updated comments and
        patch description a bit.
    
    Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 63bd905214a37724dce79131461366d16a6397db
Author: Richard Cochran <richardcochran@gmail.com>
Date:   Thu Sep 20 19:11:12 2012 +0000

    gianfar: fix phc index build failure
    
    commit 28889b7e7818342f6c254e27b9b2c68702ab867a upstream.
    
    This patch fixes a build failure introduced in commit 66636287
    ("gianfar: Support the get_ts_info ethtool method."). Not only was a
    global variable inconsistently named, but also it was not exported as
    it should have been.
    
    This fix is also needed in stable version 3.5.
    
    Signed-off-by: Richard Cochran <richardcochran@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 679663e954700404017a781250f7fd8e749b3529
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Aug 21 18:57:10 2012 +0200

    iwlwifi: fix flow handler debug code
    
    commit 94543a8d4fb302817014981489f15cb3b92ec3c2 upstream.
    
    iwl_dbgfs_fh_reg_read() can cause crashes and/or
    BUG_ON in slub because the ifdefs are wrong, the
    code in iwl_dump_fh() should use DEBUGFS, not
    DEBUG to protect the buffer writing code.
    
    Also, while at it, clean up the arguments to the
    function, some code and make it generally safer.
    
    Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    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 cf7516923d7ee975b21a1ea633f6a9c65fef66e3
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Aug 21 18:57:11 2012 +0200

    iwlwifi: protect SRAM debugfs
    
    commit 4fc79db178f0a0ede479b4713e00df2d106028b3 upstream.
    
    If the device is not started, we can't read its
    SRAM and attempting to do so will cause issues.
    Protect the debugfs read.
    
    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 54abcfeb2ce031f864b8a8c574333446af335c3c
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Tue Sep 18 19:48:59 2012 +0200

    iwlwifi: don't double free the interrupt in failure path
    
    commit a7be50b7e30f9d77cb059a7ffdb781bb0fb92eba upstream.
    
    When the driver can't get the HW ready, we would release
    the interrupt twice which made the kernel complain loudly.
    
    Reported-by: Brian Cockrell <brian.cockrell@intel.com>
    Tested-by: Brian Cockrell <brian.cockrell@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 0bcaf42e89b5be757bf4ffc4063411c8ebe40e06
Author: Maxim Levitsky <maximlevitsky@gmail.com>
Date:   Tue Aug 14 02:22:07 2012 +0300

    drm/nv86/fifo: suspend fix
    
    commit 2064db725cc6d4ea19a24c138bc37939b63e3ae6 upstream.
    
    This fix is a backport from the reworked nouveau driver.  It masks off the
    engines we're not expecting to use before attempting a channel kickoff.
    
    Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Cc: Sven Joachim <svenjoac@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit edec121abe8f51e14d328dfc893ae704567f4466
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Sep 15 09:41:57 2012 +0100

    drm/i915: Reduce a pin-leak BUG into a WARN
    
    commit 7e81a42e341a4f15d76624b7c02ffb21b085b56f upstream.
    
    Pin-leaks persist and we get the perennial bug reports of machine
    lockups to the BUG_ON(pin_count==MAX). If we instead loudly report that
    the object cannot be pinned at that time it should prevent the driver from
    locking up, and hopefully restore a semblance of working whilst still
    leaving us a OOPS to debug.
    
    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 be1454d861fd19352590c9dfb1523e4612ac79bb
Author: Wang Xingchao <xingchao.wang@intel.com>
Date:   Thu Sep 13 07:43:22 2012 +0800

    drm/i915: HDMI - Clear Audio Enable bit for Hot Plug
    
    commit b98b60167279df3acac9422c3c9820d9ebbcf9fb upstream.
    
    Clear Audio Enable bit to trigger unsolicated event to notify Audio
    Driver part the HDMI hot plug change. The patch fixed the bug when
    remove HDMI cable the bit was not cleared correctly.
    
    In intel_hdmi_dpms(), if intel_hdmi->has_audio been true, the "Audio enable bit" will
    be set to trigger unsolicated event to notify Alsa driver the change.
    
    intel_hdmi->has_audio will be reset to false from intel_hdmi_detect() after
    remove the hdmi cable, here's debug log:
    
    [  187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2
    [  187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0
    
    so when comes back to intel_hdmi_dpms(), the "Audio enable bit" will not be cleared. And this
    cause the eld infomation and pin presence doesnot update accordingly in alsa driver side.
    
    This patch will also trigger unsolicated event to alsa driver to notify the hot plug event:
    
    [  187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1
    [  187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0
    
    Signed-off-by: Wang Xingchao <xingchao.wang@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8291fe24ce3c4ba59e1b046641d1e471af4cf31
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Sep 11 12:37:55 2012 +0200

    drm/i915: enable lvds pin pairs before dpll on gen2
    
    commit 5b5896e4e1f353ef3dbc4e4e9ee44d53ccf105d7 upstream.
    
    Otherwise things migt not work too well.
    
    Breakage introduced in
    
    commit eb1cbe4848b01f9f073064377875bc7d71eb401b
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Wed Mar 28 23:12:16 2012 +0200
    
        drm/i915: split PLL update code out of i9xx_crtc_mode_set
    
    Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb87978823e46ea55759534011f2e2c16eac2a2b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Sep 9 11:54:16 2012 +0200

    drm/i915: set the right gen3 flip_done mode also at resume
    
    commit 974a3b0f9f05b748fe11f1afc31efc32aa5160cb upstream.
    
    Currently we've only frobbed this bit at irq_init time, but did
    not restore it at resume time. Move it to the gen3 clock gating
    function to fix this.
    
    Notice while reading through code.
    
    Reviewed-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 0dad2cd60e63c523e0968b159facabda6ce23fb8
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri Sep 14 13:28:23 2012 +1000

    drm/nouveau: fix booting with plymouth + dumb support
    
    commit 610bd7da160f76f1644ecb4cd7f39511b49a22cc upstream.
    
    We noticed a plymouth bug on Fedora 18, and I then
    noticed this stupid thinko, fixing it fixed the problem
    with plymouth.
    
    Acked-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 576fb84aaf06b3293667ea511c71b0e701651f9e
Author: Christian König <deathsimple@vodafone.de>
Date:   Thu Sep 13 10:33:47 2012 +0200

    drm/radeon: make 64bit fences more robust v3
    
    commit f492c171a38d77fc13a8998a0721f2da50835224 upstream.
    
    Only increase the higher 32bits if we really detect a wrap around.
    
    v2: instead of increasing the higher 32bits just use the higher
        32bits from the last emitted fence.
    v3: also use last emitted fence value as upper limit.
    
    The intention of this patch is to make fences as robust as
    they where before introducing 64bit fences. This is
    necessary because on older systems it looks like the fence
    value gets corrupted on initialization.
    
    Fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=51344
    
    Should also fix:
    https://bugs.freedesktop.org/show_bug.cgi?id=54129
    https://bugs.freedesktop.org/show_bug.cgi?id=54662
    https://bugzilla.redhat.com/show_bug.cgi?id=846505
    https://bugzilla.redhat.com/show_bug.cgi?id=845639
    
    3.5 needs a separate patch due to changes in the
    fence code.  Will send that out separately.
    
    Signed-off-by: Christian König <deathsimple@vodafone.de>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eefc86d74b3e70ae4d478a2a1bebb16a90a63061
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Aug 29 19:48:26 2012 -0400

    drm/radeon: fix dig encoder selection on DCE61
    
    commit 41fa54377057ab38bc3e08ebb46168a7daf2e63b upstream.
    
    Was using the DCE41 code which was wrong. Fixes
    blank displays on a number of Trinity systems.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22c4c520ca2685c66fc74fbfce144411fe01fbae
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Tue Aug 28 16:50:22 2012 -0400

    drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740
    
    commit 4a2b6662c3632176b4fdf012243dd3751367bf1f upstream.
    
    It seems some of those IGP dislike non dma32 page despite what
    documentation says. Fix regression since we allowed non dma32
    pages. It seems it only affect some revision of those IGP chips
    as we don't know which one just force dma32 for all of them.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=785375
    
    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 33159fb77f79d5852ed5daca00ccfe3d444c07f2
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Aug 21 19:06:21 2012 -0400

    drm/radeon: don't disable plls that are in use by other crtcs
    
    commit 4e58591c8961b3e31709313f75819f2eec06e322 upstream.
    
    Some plls are shared for DP.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b56c58b6bb015741b54ad1aa5abd46db274ac0a1
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Aug 20 11:06:21 2012 -0400

    drm/radeon: convert radeon vfct code to use acpi_get_table_with_size
    
    commit 7c3906d04a4587dceaa78cc1ae6b14e6454ee02a upstream.
    
    Allows us to verify the table size.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56422e822e5829a9822abd786efc6acfa59bc94f
Author: Xu, Anhua <anhua.xu@intel.com>
Date:   Mon Aug 13 03:08:33 2012 +0000

    drm/i915: fix wrong order of parameters in port checking functions
    
    commit b70ad586162609141f0aa9eb34790f31a8954f89 upstream.
    
    Wrong order of parameters passed-in when calling hdmi/adpa
    /lvds_pipe_enabled(), 2nd and 3rd parameters are reversed.
    
    This bug was indroduced by
    
    commit 1519b9956eb4b4180fa3f47c73341463cdcfaa37
    Author: Keith Packard <keithp@keithp.com>
    Date:   Sat Aug 6 10:35:34 2011 -0700
    
        drm/i915: Fix PCH port pipe select in CPT disable paths
    
    The reachable tag for this commit is v3.1-rc1-3-g1519b99
    
    Signed-off-by: Anhua Xu <anhua.xu@intel.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44876
    Tested-by: Daniel Schroeder <sec@dschroeder.info>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf903695675047612f52b260545a1e9c9438c08b
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Aug 24 18:21:21 2012 -0400

    drm/radeon/atom: powergating fixes for DCE6
    
    commit c205b232a64fed6d26edd7e40985b396de99a27f upstream.
    
    Power gating is per crtc pair, but the powergating registers
    should be called individually.  The hw handles power up/down
    properly.  The pair is powered up if either crtc in the pair
    is powered up and the pair is not powered down until both
    crtcs in the pair are powered down.  This simplifies
    programming and should save additional power as the previous
    code never actually power gated the crtc pair.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76a271deba25e001c25a5e24420838506858e426
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Aug 22 09:54:56 2012 -0400

    drm/radeon/atom: rework DIG modesetting on DCE3+
    
    commit 8d1af57ae3c4458ed0de93ef97f388dd1b3239c7 upstream.
    
    The ordering is important and the current drm code
    wasn't cutting it for modern DIG encoders.  We need
    to have information about crtc before setting up
    the encoders so I've shifted the ordering a bit.
    Probably we'll need a full rework akin to danvet's
    recent intel patchs.  This patch fixes numerous
    issues with DP bridge chips and makes link training
    much more reliable.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df6a5ea44759e88b7c025704cd9cb6a6e64188a4
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Mon Aug 27 16:22:49 2012 +1000

    drm/nvc0/copy: check PUNITS to determine which copy engines are disabled
    
    commit 14f0458a41e033dee31ba605137419385c03fc78 upstream.
    
    On some Fermi chipsets (NVCE particularly) PCOPY1 doesn't exist.  And if
    what I've seen on Kepler is true of Fermi too, chipsets of the same type
    can have different PCOPY units available.
    
    This should fix a v3.5 regression reported by a number of people effecting
    suspend/resume on NVC8/NVCE chipsets.
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01949a3b2bdbccdeee3e35f047c15eac76e2c940
Author: Jakob Bornecrantz <jakob@vmware.com>
Date:   Thu Aug 16 08:29:03 2012 +0000

    drm: Check for invalid cursor flags
    
    commit 7c4eaca4162d0b5ad4fb39f974d7ffd71b9daa09 upstream.
    
    Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 985e9e0c17ed6aabccc895a68b6202e763746367
Author: AceLan Kao <acelan.kao@canonical.com>
Date:   Wed Jul 4 15:20:14 2012 +0800

    asus-nb-wmi: add some video toggle keys
    
    commit 3766054fff4af1b58a1440a284907887f4d2e8be upstream.
    
    There are some new video switch keys that used by newer machines.
    0xA0 - SDSP HDMI only
    0xA1 - SDSP LCD + HDMI
    0xA2 - SDSP CRT + HDMI
    0xA3 - SDSP TV + HDMI
    But in Linux, there is no suitable userspace application to handle this,
    so, mapping them all to KEY_SWITCHVIDEOMODE.
    
    Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Cc: Tim Gardner <tim.gardner@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 345f1f9cea2fda5e2444fdcbc620487fca7033df
Author: Paul Menzel <paulepanter@users.sourceforge.net>
Date:   Wed Aug 8 23:12:19 2012 +0200

    drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
    
    commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b upstream.
    
    Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with
    vertical stripes in the top half.
    
    In commit bc42aabc [2]
    
            commit bc42aabc6a01b92b0f961d65671564e0e1cd7592
            Author: Adam Jackson <ajax@redhat.com>
            Date:   Wed May 23 16:26:54 2012 -0400
    
                drm/edid/quirks: ViewSonic VA2026w
    
    Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which
    is also needed for this ASUS monitor.
    
    All log files and output from `xrandr` is included in the referenced
    Bugzilla report #17629.
    
    Please note that this monitor only has a VGA (D-Sub) connector [1].
    
    [1] http://www.asus.com/Display/LCD_Monitors/VW222S/
    [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17629
    Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
    Cc: <dri-devel@lists.freedesktop.org>
    Cc: Adam Jackson <ajax@redhat.com>
    Cc: Ian Pilcher <arequipeno@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5fc64113b5ecc359fe1a005e7c531d25733e7f5
Author: Corentin Chary <corentin.chary@gmail.com>
Date:   Mon Aug 20 23:01:51 2012 +0200

    asus-laptop: HRWS/HWRS typo
    
    commit 8871e99f89b7d7b1ea99de550eea2a56273f42ab upstream.
    
    Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=24222
    Signed-off-by: Corentin Chary <corentin.chary@gmail.com>
    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d642614af34400285a252b1458f5d42b438185c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Aug 15 10:41:45 2012 +0200

    drm/i915: use hsw rps tuning values everywhere on gen6+
    
    commit 1ee9ae3244c4789f3184c5123f3b2d7e405b3f4c upstream.
    
    James Bottomley reported [1] a massive power regression, due to the
    enabling of semaphores by default in 3.5. A workaround for him is to
    again disable semaphores. And indeed, his system has a very hard time
    to enter rc6 with semaphores enabled.
    
    Ben Widawsky run around with a kill-a-watt a lot and noticed:
    - There are indeed a few rare systems that seem to have a hard time
      entering rc6 when desktop-idle.
    - One machine, The Indestructible Toshiba regressed in this behaviour
      between 3.5 and 3.6 in a merge commit! So rc6 behaviour with the
      current setting seems to be highly timing dependent and not robust
      at all.
    - The behaviour James reported wrt semaphores seems to be a freak
      timing thing that only happens on his specific machine, confirming
      that enabling semaphores shouldn't reduce rc6 residency.
    
    Now furthermore the Google ChromeOS guys reported [2] a while ago that
    at least on some machines a simply a blinking cursor can keep the gpu
    turbo at the highest frequency. This is because the current rps limits
    used on snb/ivb are highly asymmetric.
    
    On the theory that gpu turbo and rc6 tuning values are related, we've
    tried whether the much saner looking (since much less asymmetric) rps
    tuning values used for hsw would also help entering rc6 more robustly.
    
    And it seems to mostly work, and we don't really have the resources to
    through-roughly tune things in any better way: The values from the
    ChromeOS ppl seem to fare a bit worse for James' machine, so I guess
    we better stick with something vpg (the gpu hw/windows group)
    provided, hoping that they've done their jobs.
    
    Reference[1]: http://lists.freedesktop.org/archives/dri-devel/2012-July/025675.html
    Reference[2]: http://lists.freedesktop.org/archives/intel-gfx/2012-July/018692.html
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53393
    Tested-by: Ben Widawsky <ben@bwidawsk.net>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit efb269742ee6b7a7f929054fde8bfaa4ccb3f0de
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Mon Aug 13 13:22:35 2012 +0300

    drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads
    
    commit f1a2f5b7c5f0941d23eef0a095c0b99bf8d051e6 upstream.
    
    GMBUS was enabled over bit-banging as the default in commits:
    
    commit c3dfefa0a6d235bd465309e12f4c56ea16e71111
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Tue Feb 14 22:37:25 2012 +0100
    
        drm/i915: reenable gmbus on gen3+ again
    
    and
    
    commit 0fb3f969c8683505fb7323c06bf8a999a5a45a15
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Fri Mar 2 19:38:30 2012 +0100
    
        drm/i915: enable gmbus on gen2
    
    Unfortunately, GMBUS seems to fail on some CRT displays. Add a bit-banging
    fallback to CRT EDID reads.
    
    LKML-Reference: <201207251020.47637.maciej.rutecki@gmail.com>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45881
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Tested-by: Alex Ferrando <alferpal@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3e3373115a6472419fb84663e99ce52f8e77cfa
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Mon Aug 13 13:22:34 2012 +0300

    drm/i915: extract connector update from intel_ddc_get_modes() for reuse
    
    commit 4eab81366465aedcfd26de960c595bc03599c09f upstream.
    
    Refactor the connector update part of intel_ddc_get_modes() into a separate
    intel_connector_update_modes() function for reuse. No functional changes.
    
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45881
    Tested-by: Alex Ferrando <alferpal@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38eda0433d5af9bb2655e7a4ca3c9bc9c0515112
Author: Christian König <deathsimple@vodafone.de>
Date:   Mon Aug 20 15:38:47 2012 +0200

    drm/radeon: init lockup timeout on ring init
    
    commit 48c0ac9911839daf188e4a0b6b132ac31050a241 upstream.
    
    Reset the lockup timeout on ring (re-)initialisation.
    
    Otherwise we get error messages like this on gpu resets:
    [ 1559.949177] radeon 0000:01:00.0: GPU lockup CP stall for more than 1482270msec
    
    Signed-off-by: Christian König <deathsimple@vodafone.de>
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bfbccc4db370e1225644973b470a85f497d8bee3
Author: Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
Date:   Mon Aug 20 15:16:04 2012 +0100

    drm/radeon/kms: extend the Fujitsu D3003-S2 board connector quirk to cover later silicon stepping
    
    commit 52e9b39d9a89ae33662596bd30e62dd56bddbe73 upstream.
    
    There is a more recent APU stepping with a new PCI ID
    shipping in the same board by Fujitsu which needs the
    same quirk to correctly mark the back plane connectors.
    
    Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01edc881f64ff092978f333a5328e18a988f180b
Author: David Lamparter <equinox@diac24.net>
Date:   Thu Aug 16 15:45:20 2012 -0400

    drm/radeon: implement ACPI VFCT vbios fetch (v3)
    
    commit 268ba0a99f89a84dc5eb312470896113d0709c74 upstream.
    
    This is required for pure UEFI systems.  The vbios is stored
    in ACPI rather than at the legacy vga location.
    
    Fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=26891
    
    V2: fix #ifdefs as per Greg's comments
    V3: fix it harder
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Jerome Glisse <jglisse@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f54f145719f453dccc73304cd427096bf7b806c
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Aug 16 15:39:09 2012 -0400

    drm/radeon: split ATRM support out from the ATPX handler (v3)
    
    commit c61e2775873f603148e8e998a938721b7d222d24 upstream.
    
    There are systems that use ATRM, but not ATPX.
    
    Fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=41265
    
    V2: fix #ifdefs as per Greg's comments
    V3: fix it harder
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 209568409a933a4041d0fd47992c10e53473fb0e
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Mon Aug 6 12:32:21 2012 -0400

    drm/radeon: fence virtual address and free it once idle v4
    
    commit e43b5ec05afdc232be25aa481315035c1888d389 upstream.
    
    Virtual address need to be fenced to know when we can safely remove it.
    This patch also properly clear the pagetable. Previously it was
    serouisly broken.
    
    Kernel 3.5/3.4 need a similar patch but adapted for difference in mutex locking.
    
    v2: For to update pagetable when unbinding bo (don't bailout if
        bo_va->valid is true).
    v3: Add kernel 3.5/3.4 comment.
    v4: Fix compilation warnings.
    
    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02472191d07a0af5cad86c9f9ea406c8c2918395
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Aug 21 18:52:56 2012 -0400

    drm/radeon/ss: use num_crtc rather than hardcoded 6
    
    commit 5317670692f61675394db2eb6713484b67383750 upstream.
    
    When checking if a pll is in use.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8a7171e7540553e48707f5d1a98cf824a66bcce
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Fri Aug 17 14:40:04 2012 -0400

    drm/radeon: avoid turning off spread spectrum for used pll
    
    commit 5efcc76c13a745f98e7b6604d6aca49761be1970 upstream.
    
    If spread spectrum is enabled and in use for a given pll we
    should not turn it off as it will lead to turning off display
    for crtc that use the pll (this behavior was observed on chelsea
    edp).
    
    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e9b8a5333503decc32e04c910068eca4e4ec6c2
Author: Dave Airlie <airlied@redhat.com>
Date:   Tue Aug 21 16:29:47 2012 +1000

    fbcon: fix race condition between console lock and cursor timer (v1.1)
    
    commit d8636a2717bb3da2a7ce2154bf08de90bb8c87b0 upstream.
    
    So we've had a fair few reports of fbcon handover breakage between
    efi/vesafb and i915 surface recently, so I dedicated a couple of
    days to finding the problem.
    
    Essentially the last thing we saw was the conflicting framebuffer
    message and that was all.
    
    So after much tracing with direct netconsole writes (printks
    under console_lock not so useful), I think I found the race.
    
    Thread A (driver load)    Thread B (timer thread)
      unbind_con_driver ->              |
      bind_con_driver ->                |
      vc->vc_sw->con_deinit ->          |
      fbcon_deinit ->                   |
      console_lock()                    |
          |                             |
          |                       fbcon_flashcursor timer fires
          |                       console_lock() <- blocked for A
          |
          |
    fbcon_del_cursor_timer ->
      del_timer_sync
      (BOOM)
    
    Of course because all of this is under the console lock,
    we never see anything, also since we also just unbound the active
    console guess what we never see anything.
    
    Hopefully this fixes the problem for anyone seeing vesafb->kms
    driver handoff.
    
    v1.1: add comment suggestion from Alan.
    
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Tested-by: Josh Boyer <jwboyer@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d9ed3f9251d5222d6abf0f938207fb8f02659d6
Author: Robin Holt <holt@sgi.com>
Date:   Tue Aug 21 16:16:02 2012 -0700

    drivers/misc/sgi-xp/xpc_uv.c: SGI XPC fails to load when cpu 0 is out of IRQ resources
    
    commit 7838f994b4fceff24c343f4e26a6cf4393869579 upstream.
    
    On many of our larger systems, CPU 0 has had all of its IRQ resources
    consumed before XPC loads.  Worst cases on machines with multiple 10
    GigE cards and multiple IB cards have depleted the entire first socket
    of IRQs.
    
    This patch makes selecting the node upon which IRQs are allocated (as
    well as all the other GRU Message Queue structures) specifiable as a
    module load param and has a default behavior of searching all nodes/cpus
    for an available resources.
    
    [akpm@linux-foundation.org: fix build: include cpu.h and module.h]
    Signed-off-by: Robin Holt <holt@sgi.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70581c172679ca0a29da01c6bb40577c804476da
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Wed Aug 15 21:32:04 2012 +0200

    PM / Runtime: Check device PM QoS setting before "no callbacks" check
    
    commit 55d7ec4520e86d735d178c15d7df33d507bd43c6 upstream.
    
    If __dev_pm_qos_read_value(dev) returns a negative value,
    rpm_suspend() should return -EPERM for dev even if its
    power.no_callbacks flag is set.  For this to happen, the device's
    power.no_callbacks flag has to be checked after the PM QoS check,
    so move the PM QoS check to rpm_check_suspend_allowed() (this will
    make it cover idle notifications as well as runtime suspend too).
    
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7bdf66e37d4350195de86c8e44540627550a00d9
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Wed Aug 15 21:31:55 2012 +0200

    PM / Runtime: Clear power.deferred_resume on success in rpm_suspend()
    
    commit 58a34de7b1a920d287d17d2ca08bc9aaf7e6d35b upstream.
    
    The power.deferred_resume can only be set if the runtime PM status
    of device is RPM_SUSPENDING and it should be cleared after its
    status has been changed, regardless of whether or not the runtime
    suspend has been successful.  However, it only is cleared on
    suspend failure, while it may remain set on successful suspend and
    is happily leaked to rpm_resume() executed in that case.
    
    That shouldn't happen, so if power.deferred_resume is set in
    rpm_suspend() after the status has been changed to RPM_SUSPENDED,
    clear it before calling rpm_resume().  Then, it doesn't need to be
    cleared before changing the status to RPM_SUSPENDING any more,
    because it's always cleared after the status has been changed to
    either RPM_SUSPENDED (on success) or RPM_ACTIVE (on failure).
    
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 30c575314dda6c51307ee06df67ae2fc44794d11
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Wed Aug 15 21:31:45 2012 +0200

    PM / Runtime: Fix rpm_resume() return value for power.no_callbacks set
    
    commit 7f321c26c04807834fef4c524d2b21573423fc74 upstream.
    
    For devices whose power.no_callbacks flag is set, rpm_resume()
    should return 1 if the device's parent is already active, so that
    the callers of pm_runtime_get() don't think that they have to wait
    for the device to resume (asynchronously) in that case (the core
    won't queue up an asynchronous resume in that case, so there's
    nothing to wait for anyway).
    
    Modify the code accordingly (and make sure that an idle notification
    will be queued up on success, even if 1 is to be returned).
    
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 342c666ccbce089f1c34fc7bcbf35df834af2cf0
Author: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date:   Tue Aug 21 16:16:10 2012 -0700

    drivers/rtc/rtc-rs5c348.c: fix hour decoding in 12-hour mode
    
    commit 7dbfb315b2aaef0a115765946bf3026d074c33a7 upstream.
    
    Correct the offset by subtracting 20 from tm_hour before taking the
    modulo 12.
    
    [ "Why 20?" I hear you ask. Or at least I did.
    
      Here's the reason why: RS5C348_BIT_PM is 32, and is - stupidly -
      included in the RS5C348_HOURS_MASK define.  So it's really subtracting
      out that bit to get "hour+12".  But then because it does things modulo
      12, it needs to add the 12 in again afterwards anyway.
    
      This code is confused.  It would be much clearer if RS5C348_HOURS_MASK
      just didn't include the RS5C348_BIT_PM bit at all, then it wouldn't
      need to do the silly subtract either.
    
      Whatever. It's all just math, the end result is the same.   - Linus ]
    
    Reported-by: James Nute <newten82@gmail.com>
    Tested-by: James Nute <newten82@gmail.com>
    Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
    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 4a74b60aa6551430ed6e700568199f50eca67028
Author: Suresh Siddha <suresh.b.siddha@intel.com>
Date:   Tue Jul 31 10:29:14 2012 -0700

    x86, avx: don't use avx instructions with "noxsave" boot param
    
    commit c6fd893da927c6cefb2ece22402765379921a834 upstream.
    
    Clear AVX, AVX2 features along with clearing XSAVE feature bits,
    as part of the parsing "noxsave" parameter.
    
    Fixes the kernel boot panic with "noxsave" boot parameter.
    
    We could have checked cpu_has_osxsave along with cpu_has_avx etc, but Peter
    mentioned clearing the feature bits will be better for uses like
    static_cpu_has() etc.
    
    Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
    Link: http://lkml.kernel.org/r/1343755754.2041.2.camel@sbsiddha-desk.sc.intel.com
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ad3eca2bd7f1a10d59816ae8262877d265d0f6f
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Aug 10 15:22:09 2012 +0100

    mutex: Place lock in contended state after fastpath_lock failure
    
    commit 0bce9c46bf3b15f485d82d7e81dabed6ebcc24b1 upstream.
    
    ARM recently moved to asm-generic/mutex-xchg.h for its mutex
    implementation after the previous implementation was found to be missing
    some crucial memory barriers. However, this has revealed some problems
    running hackbench on SMP platforms due to the way in which the
    MUTEX_SPIN_ON_OWNER code operates.
    
    The symptoms are that a bunch of hackbench tasks are left waiting on an
    unlocked mutex and therefore never get woken up to claim it. This boils
    down to the following sequence of events:
    
            Task A        Task B        Task C        Lock value
    0                                                     1
    1       lock()                                        0
    2                     lock()                          0
    3                     spin(A)                         0
    4       unlock()                                      1
    5                                   lock()            0
    6                     cmpxchg(1,0)                    0
    7                     contended()                    -1
    8       lock()                                        0
    9       spin(C)                                       0
    10                                  unlock()          1
    11      cmpxchg(1,0)                                  0
    12      unlock()                                      1
    
    At this point, the lock is unlocked, but Task B is in an uninterruptible
    sleep with nobody to wake it up.
    
    This patch fixes the problem by ensuring we put the lock into the
    contended state if we fail to acquire it on the fastpath, ensuring that
    any blocked waiters are woken up when the mutex is released.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Chris Mason <chris.mason@fusionio.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Reviewed-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/n/tip-6e9lrw2avczr0617fzl5vqb8@git.kernel.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19aaa209bfd9f6afbad8605e891f1aaf727c31ca
Author: Dirk Behme <dirk.behme@de.bosch.com>
Date:   Fri Aug 31 10:02:47 2012 +0200

    tty: serial: imx: don't reinit clock in imx_setup_ufcr()
    
    commit 7be0670f7b9198382938a03ff3db7f47ef6b4780 upstream.
    
    Remove the clock configuration from imx_setup_ufcr(). This
    isn't needed here and will cause garbage output if done.
    
    To be be sure that we only touch the bits we want (TXTL and RXTL)
    we have to mask out all other bits of the UFCR register. Add
    one non-existing bit macro for this, too (bit 6, DCEDTE on i.MX6).
    
    Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
    CC: Shawn Guo <shawn.guo@linaro.org>
    CC: Sascha Hauer <s.hauer@pengutronix.de>
    CC: Troy Kisky <troy.kisky@boundarydevices.com>
    CC: Xinyu Chen <xinyu.chen@freescale.com>
    Acked-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34d4dda865d8174f4a437f313c457c42a8fa9535
Author: Xinyu Chen <xinyu.chen@freescale.com>
Date:   Mon Aug 27 09:36:51 2012 +0200

    tty: serial: imx: console write routing is unsafe on SMP
    
    commit 9ec1882df244c4ee1baa692676fef5e8b0f5487d upstream.
    
    The console feature's write routing is unsafe on SMP with
    the startup/shutdown call.
    
    There could be several consumers of the console
    * the kernel printk
    * the init process using /dev/kmsg to call printk to show log
    * shell, which open /dev/console and write with sys_write()
    
    The shell goes into the normal uart open/write routing,
    but the other two go into the console operations.
    The open routing calls imx serial startup, which will write USR1/2
    register without any lock and critical with imx_console_write call.
    
    Add a spin_lock for startup/shutdown/console_write routing.
    
    This patch is a port from Freescale's Android kernel.
    
    Signed-off-by: Xinyu Chen <xinyu.chen@freescale.com>
    Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
    CC: Sascha Hauer <s.hauer@pengutronix.de>
    Acked-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5871ff53f3cd0968ef2fa86e43cea64f65ebca81
Author: Moiz Sonasath <m-sonasath@ti.com>
Date:   Wed Sep 5 08:34:26 2012 +0300

    usb: host: xhci: fix compilation error for non-PCI based stacks
    
    commit 296365781903226a3fb8758901eaeec09d2798e4 upstream.
    
    For non PCI-based stacks, this function call
    usb_disable_xhci_ports(to_pci_dev(hcd->self.controller));
    made from xhci_shutdown is not applicable.
    
    Ideally, we wouldn't have any PCI-specific code on
    a generic driver such as the xHCI stack, but it looks
    like we should just stub usb_disable_xhci_ports() out
    for non-PCI devices.
    
    [ balbi@ti.com: slight improvement to commit log ]
    
    This patch should be backported to kernels as old as 3.0, since the
    commit it fixes (e95829f474f0db3a4d940cae1423783edd966027 "xhci: Switch
    PPT ports to EHCI on shutdown.") was marked for stable.
    
    Signed-off-by: Moiz Sonasath<m-sonasath@ti.com>
    Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc89785d7528f237b0db9272696a7ef48af35026
Author: Manoj Iyer <manoj.iyer@canonical.com>
Date:   Wed Aug 22 11:53:18 2012 -0500

    xhci: Recognize USB 3.0 devices as superspeed at powerup
    
    commit 29d214576f936db627ff62afb9ef438eea18bcd2 upstream.
    
    On Intel Panther Point chipset USB 3.0 devices show up as
    high-speed devices on powerup, but after an s3 cycle they are
    correctly recognized as SuperSpeed. At powerup switch the port
    to xHCI so that USB 3.0 devices are correctly recognized.
    
    BugLink: http://bugs.launchpad.net/bugs/1000424
    
    This patch should be backported to kernels as old as 3.0, that contain
    commit ID 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
    EHCI/xHCI port switching."
    
    Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81b16bdce56ffb9db6027acb6b54df6c397da465
Author: Matthew Garrett <mjg@redhat.com>
Date:   Tue Aug 14 16:44:49 2012 -0400

    xhci: Make handover code more robust
    
    commit e955a1cd086de4d165ae0f4c7be7289d84b63bdc upstream.
    
    My test platform (Intel DX79SI) boots reliably under BIOS, but frequently
    crashes when booting via UEFI. I finally tracked this down to the xhci
    handoff code. It seems that reads from the device occasionally just return
    0xff, resulting in xhci_find_next_cap_offset generating a value that's
    larger than the resource region. We then oops when attempting to read the
    value. Sanity checking that value lets us avoid the crash.
    
    I've no idea what's causing the underlying problem, and xhci still doesn't
    actually *work* even with this, but the machine at least boots which will
    probably make further debugging easier.
    
    This should be backported to kernels as old as 2.6.31, that contain the
    commit 66d4eadd8d067269ea8fead1a50fe87c2979a80d "USB: xhci: BIOS handoff
    and HW initialization."
    
    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6f58d9e9d68b8b622073ad5ee1a80f0f02a0316
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Aug 13 19:57:03 2012 +0300

    xhci: Fix a logical vs bitwise AND bug
    
    commit 052c7f9ffb0e95843e75448d02664459253f9ff8 upstream.
    
    The intent was to test whether the flag was set.
    
    This patch should be backported to stable kernels as old as 3.0, since
    it fixes a bug in commit e95829f474f0db3a4d940cae1423783edd966027 "xhci:
    Switch PPT ports to EHCI on shutdown.", which was marked for stable.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ebe93346ca0356975854c33d50cc8c0266c7537
Author: Ruchika Kharwar <ruchika@ti.com>
Date:   Fri Aug 10 09:58:30 2012 +0300

    usb: host: xhci-plat: use ioremap_nocache
    
    commit 319acdfc064169023cd9ada5085b434fbcdacec2 upstream.
    
    Use the ioremap_nocache variant of the ioremap API in
    order to make sure our memory will be marked uncachable.
    
    This patch should be backported to kernels as old as 3.4, that contain
    the commit 3429e91a661e1f383aecc86c6bbcf65afb15c892 "usb: host: xhci:
    add platform driver support".
    
    Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d4a9f02165d6495dd02659ef506d48ff9a49a08
Author: Keng-Yu Lin <kengyu@canonical.com>
Date:   Fri Aug 10 01:39:23 2012 +0800

    Intel xhci: Only switch the switchable ports
    
    commit a96874a2a92feaef607ddd3137277a788cb927a6 upstream.
    
    With a previous patch to enable the EHCI/XHCI port switching, it switches
    all the available ports.
    
    The assumption is not correct because the BIOS may expect some ports
    not switchable by the OS.
    
    There are two more registers that contains the information of the switchable
    and non-switchable ports.
    
    This patch adds the checking code for the two register so that only the
    switchable ports are altered.
    
    This patch should be backported to kernels as old as 3.0, that contain
    commit ID 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
    EHCI/xHCI port switching."
    
    Signed-off-by: Keng-Yu Lin <kengyu@canonical.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa97b7e16f405a544972386709a1d2bf60b8b832
Author: Alexis R. Cortes <alexis.cortes@ti.com>
Date:   Fri Aug 3 14:00:27 2012 -0500

    usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
    
    commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 upstream.
    
    This patch is intended to work around a known issue on the
    SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
    between a device and the host past the usual handshake timeout.
    
    If that happens on the first insertion, the host controller
    port will enter in Compliance Mode and NO port status event will
    be generated (as per xHCI Spec) making impossible to detect this
    event by software. The port will remain in compliance mode until
    a warm reset is applied to it.
    
    As a result of this, the port will seem "dead" to the user and no
    device connections or disconnections will be detected.
    
    For solving this, the patch creates a timer which polls every 2
    seconds the link state of each host controller's port (this
    by reading the PORTSC register) and recovers the port by issuing a
    Warm reset every time Compliance mode is detected.
    
    If a xHC USB3.0 port has previously entered to U0, the compliance
    mode issue will NOT occur only until system resumes from
    sleep/hibernate, therefore, the compliance mode timer is stopped
    when all xHC USB 3.0 ports have entered U0. The timer is initialized
    again after each system resume.
    
    Since the issue is being caused by a piece of hardware, the timer
    will be enabled ONLY on those systems that have the SN65LVPE502CP
    installed (this patch uses DMI strings for detecting those systems)
    therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
    has been added to the xhci stack).
    
    This patch applies for these systems:
    Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
    
    This patch should be backported to kernels as old as 3.2, as that was
    the first kernel to support warm reset.  The kernels will need to
    contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
    hot reset for USB3 fails, try warm reset" and commit
    8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
    port status CAS".  The first patch add warm reset support, and the
    second patch modifies the USB core to issue a warm reset when the port
    is in compliance mode.
    
    Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3463944f5e02edcf804f2838e4b9f149c4f3d342
Author: Sergei Poselenov <sposelenov@emcraft.com>
Date:   Sun Sep 2 13:14:32 2012 +0400

    rt2800usb: Added rx packet length validity check
    
    commit efd5d6b03bd9c9e0df646c56fb5f4f3e25e5c1ac upstream.
    
    On our system (ARM Cortex-M3 SOC running linux-2.6.33)
    frequent crashes were observed in the rt2800usb module
    because of the invalid length of the received packet (3392,
    46920...). This patch adds the sanity check on the packet
    legth. Also, changed WARNING to ERROR in rt2x00lib_rxdone()
    so that the bad packet condition would be noticed.
    
    The fix was tested on the latest compat-wireless-3.5.1-1-snpc.
    
    Signed-off-by: Sergei Poselenov <sposelenov@emcraft.com>
    Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00f008d4f31bf349279c52efb109bc62d1c93acc
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Sep 4 10:41:02 2012 -0400

    USB: add device quirk for Joss Optical touchboard
    
    commit 92fc7a8b0f20bdb243c706daf42658e8e0cd2ef0 upstream.
    
    This patch (as1604) adds a CONFIG_INTF_STRINGS quirk for the Joss
    infrared touchboard device.  The device doesn't like to be asked for
    its interface strings.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: adam ? <adam3337@wp.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 994f290171f0018246612b9cfd890a184d7dd7a6
Author: Nicolas Ferre <nicolas.ferre@atmel.com>
Date:   Wed Aug 29 11:49:18 2012 +0200

    USB: ohci-at91: fix PIO handling in relation with number of ports
    
    commit 6fffb77c8393151b0cf8cef1b9c2ba90587dd2e8 upstream.
    
    If the number of ports present on the SoC/board is not the maximum
    and that the platform data is not filled with all data, there is
    an easy way to mess the PIO setup for this interface.
    This quick fix addresses mis-configuration in USB host platform data
    that is common in at91 boards since commit 0ee6d1e (USB: ohci-at91:
    change maximum number of ports) that did not modified the associatd
    board files.
    
    Reported-by: Klaus Falkner <klaus.falkner@solectrix.de>
    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3185f2bc212f82e8237f613adb9469359e413233
Author: Bjørn Mork <bjorn@mork.no>
Date:   Mon Sep 10 22:17:34 2012 +0200

    USB: cdc-wdm: fix wdm_find_device* return value
    
    commit 6a44886899ef8cc396e230e492e6a56a883889f3 upstream.
    
    A logic error made the wdm_find_device* functions
    return a bogus pointer into static data instead of
    the intended NULL no matching device was found.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e210fa515c902c869bcd27679ae305b468a73f5
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Tue Aug 21 14:56:16 2012 +0530

    usb: dwc3: core: fix incorrect usage of resource pointer
    
    commit 066618bc350cc6035c3a0fc559a8ac02f55785a9 upstream.
    
    Populate the resources for xhci afresh instead of directly using the
    *struct resource* of core. *resource* structure has parent, sibling,
    child pointers which should be filled only by resource API's. By
    directly using the *resource* pointer of core in xhci, these parent,
    sibling, child pointers are already populated even before
    *platform_device_add* causing side effects.
    
    Reported-by: Ruchika Kharwar <ruchika@ti.com>
    Tested-by: Moiz Sonasath <m-sonasath@ti.com>
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 543ab2172cd454c46231762331abd24a90a272b0
Author: Pratyush Anand <pratyush.anand@st.com>
Date:   Fri Aug 10 13:42:16 2012 +0530

    usb: dwc3: ep0: correct cache sync issue in case of ep0_bounced
    
    commit 0416e494ce7dc84e2719bc9fb7daecb330476074 upstream.
    
    In case of ep0 out, if length is not aligned to maxpacket size then we use
    dwc->ep_bounce_addr for dma transfer and not request->dma. Since, we have
    alreday done memcpy from dwc->ep0_bounce to request->buf, so we do not need to
    issue cache sync function. In fact, cache sync function will bring wrong data
    in request->buf from request->dma in this scenario.
    
    So, cache sync function must not be executed in case of ep0 bounced.
    
    Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08e95568e5ad2bf0b73d589ce0bd675438fd2842
Author: Michael Grzeschik <m.grzeschik@pengutronix.de>
Date:   Wed Sep 12 14:58:04 2012 +0300

    usb: chipidea: udc: don't stall endpoint if request list is empty in isr_tr_complete_low
    
    commit db89960e50f45274c07dc60926b5a49489b8a7a0 upstream.
    
    When attaching an imx28 or imx53 in USB gadget mode to a Windows host and
    starting a rndis connection we see this message every 4-10 seconds:
    
        g_ether gadget: high speed config #2: RNDIS
    
    Analysis shows that each time this message is printed, the rndis connection is
    re-establish due to a reset because of a stalled endpoint (ep 0, dir 1). The
    endpoint is stalled because the reqeust complete bit on that endpoint is set,
    but in isr_tr_complete_low() the endpoint request list (mEp->qh.queue) is
    empty.
    
    This patch removed this check, because the code doesn't take the following
    situation into account:
    
    The loop over all endpoints in isr_tr_complete_handler() will call ep_nuke() on
    both ep0/dir0 and ep/dir1 in the first loop. Pending reqeusts will be flushed
    and completed here. There seems to be a race condition, the request is nuked,
    but the request complete bit will be set, too. The subsequent check (in
    ep0/dir1's loop cycle) for endpoint request list (mEp->qh.queue) empty will
    fail.
    
    Both other mainline chipidea drivers (mv_udc_core.c and fsl_udc_core.c) don't
    have this check.
    
    Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a3855f7b0b7e47bb77db5f1e1000c68ae549cc6
Author: Michael Grzeschik <m.grzeschik@pengutronix.de>
Date:   Wed Sep 12 14:58:00 2012 +0300

    usb: chipidea: udc: fix setup of endpoint maxpacket size
    
    commit 7f67c38bdcb6d8bce02e10521fbf1618b586319f upstream.
    
    This patch changes the setup of the endpoint maxpacket size. All non control
    endpoints are initialized with an undefined ((unsigned short)~0) maxpacket
    size. The maxpacket size of Endpoint 0 will be kept at CTRL_PAYLOAD_MAX.
    
    Some gadget drivers check for the maxpacket size before they enable the
    endpoint, which leads to a wrong state in these drivers.
    
    Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
    Acked-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f83444297c8221497145cd26746099610a7d6f8
Author: Éric Piel <piel@delmic.com>
Date:   Tue Sep 4 17:25:06 2012 +0200

    USB: ftdi-sio: add support for more Physik Instrumente devices
    
    commit dafc4f7be1a556ca3868d343c00127728b397068 upstream.
    
    Commit b69cc672052540 added support for the E-861.  After acquiring a C-867, I
    realised that every Physik Instrumente's device has a different PID. They are
    listed in the Windows device driver's .inf file. So here are all PIDs for the
    current (and probably future) USB devices from Physik Instrumente.
    
    Compiled, but only actually tested on the E-861 and C-867.
    
    Signed-off-by: Éric Piel <piel@delmic.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ab6aa6c9dacb16168b090899f4e140081280e96
Author: Bjørn Mork <bjorn@mork.no>
Date:   Mon Sep 10 12:01:05 2012 +0200

    USB: ftdi_sio: do not claim CDC ACM function
    
    commit f08dea734844aa42ec57c229b0b73b3d7d21f810 upstream.
    
    The Microchip vid:pid 04d8:000a is used for their CDC ACM
    demo firmware application.  This is a device with a single
    function conforming to the CDC ACM specification and with
    the intention of demonstrating CDC ACM class firmware and
    driver interaction.  The demo is used on a number of
    development boards, and may also be used unmodified by
    vendors using Microchip hardware.
    
    Some vendors have re-used this vid:pid for other types of
    firmware, emulating FTDI chips. Attempting to continue to
    support such devices without breaking class based
    applications that by matching on interface
    class/subclass/proto being ff/ff/00.  I have no information
    about the actual device or interface descriptors, but this
    will at least make the proper CDC ACM devices work again.
    Anyone having details of the offending device's descriptors
    should update this entry with the details.
    
    Reported-by: Florian Wöhrl <fw@woehrl.biz>
    Reported-by: Xiaofan Chen <xiaofanc@gmail.com>
    Cc: Alan Cox <alan@linux.intel.com>
    Cc: Bruno Thomsen <bruno.thomsen@gmail.com>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 142bfa4fc78d70ff5fc05bca734e230c334e6235
Author: Horst Schirmeier <horst@schirmeier.com>
Date:   Fri Aug 31 00:00:28 2012 +0200

    USB: ftdi_sio: PID for NZR SEM 16+ USB
    
    commit 26a538b9ea2a3ee10dafc0068f0560dfd7b7ba37 upstream.
    
    This adds the USB PID for the NZR SEM 16+ USB energy monitor device
    <http://www.nzr.de>.  It works perfectly with the GPL software on
    <http://schou.dk/linux/sparometer/>.
    
    Signed-off-by: Horst Schirmeier <horst@schirmeier.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f49b5d4530ef3b1ccc34473ccdb84dd48be2aa0d
Author: Pavankumar Kondeti <pkondeti@codeaurora.org>
Date:   Fri Sep 7 11:23:28 2012 +0530

    EHCI: Update qTD next pointer in QH overlay region during unlink
    
    commit 3d037774b42ed677f699b1dce7d548d55f4e4c2b upstream.
    
    There is a possibility of QH overlay region having reference to a stale
    qTD pointer during unlink.
    
    Consider an endpoint having two pending qTD before unlink process begins.
    The endpoint's QH queue looks like this.
    
    qTD1 --> qTD2 --> Dummy
    
    To unlink qTD2, QH is removed from asynchronous list and Asynchronous
    Advance Doorbell is programmed.  The qTD1's next qTD pointer is set to
    qTD2'2 next qTD pointer and qTD2 is retired upon controller's doorbell
    interrupt.  If QH's current qTD pointer points to qTD1, transfer overlay
    region still have reference to qTD2. But qtD2 is just unlinked and freed.
    This may cause EHCI system error.  Fix this by updating qTD next pointer
    in QH overlay region with the qTD next pointer of the current qTD.
    
    Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84efc564e8839d601c0656cab9c9fbe1c621ea7e
Author: Weston Andros Adamson <dros@netapp.com>
Date:   Thu Sep 6 15:54:27 2012 -0400

    NFS: return error from decode_getfh in decode open
    
    commit 01913b49cf1dc6409a07dd2a4cc6af2e77f3c410 upstream.
    
    If decode_getfh failed, nfs4_xdr_dec_open would return 0 since the last
    decode_* call must have succeeded.
    
    Signed-off-by: Weston Andros Adamson <dros@netapp.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b1b2f56616a89659cd132ef4e20267b45c6535a
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Tue Sep 4 11:05:07 2012 -0400

    NFS: Fix a problem with the legacy binary mount code
    
    commit 872ece86ea5c367aa92f44689c2d01a1c767aeb3 upstream.
    
    Apparently, am-utils is still using the legacy binary mountdata interface,
    and is having trouble parsing /proc/mounts due to the 'port=' field being
    incorrectly set.
    
    The following patch should fix up the regression.
    
    Reported-by: Marius Tolzmann <tolzmann@molgen.mpg.de>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7566f7007c8734ebcbb4cb125b159ca1b7563c74
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Mon Sep 3 14:56:02 2012 -0400

    NFS: Fix the initialisation of the readdir 'cookieverf' array
    
    commit c3f52af3e03013db5237e339c817beaae5ec9e3a upstream.
    
    When the NFS_COOKIEVERF helper macro was converted into a static
    inline function in commit 99fadcd764 (nfs: convert NFS_*(inode)
    helpers to static inline), we broke the initialisation of the
    readdir cookies, since that depended on doing a memset with an
    argument of 'sizeof(NFS_COOKIEVERF(inode))' which therefore
    changed from sizeof(be32 cookieverf[2]) to sizeof(be32 *).
    
    At this point, NFS_COOKIEVERF seems to be more of an obfuscation
    than a helper, so the best thing would be to just get rid of it.
    
    Also see: https://bugzilla.kernel.org/show_bug.cgi?id=46881
    
    Reported-by: Andi Kleen <andi@firstfloor.org>
    Reported-by: David Binderman <dcb314@hotmail.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d8c4fe7165af0406de34cc835993f06f5ae7268
Author: Gertjan van Wingerde <gwingerde@gmail.com>
Date:   Fri Aug 31 19:22:11 2012 +0200

    rt2x00: Fix rfkill polling prior to interface start.
    
    commit a396e10019eaf3809b0219c966865aaafec12630 upstream.
    
    We need to program the rfkill switch GPIO pin direction to input at
    device initialization time, not only when the interface is brought up.
    Doing this only when the interface is brought up could lead to rfkill
    detecting the switch is turned on erroneously and inability to create
    the interface and bringing it up.
    
    Reported-and-tested-by: Andreas Messer <andi@bastelmap.de>
    Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
    Acked-by: Ivo Van Doorn <ivdoorn@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ef41fe91382703c960a6f906c72e0baeb8442bf
Author: Gertjan van Wingerde <gwingerde@gmail.com>
Date:   Fri Aug 31 19:22:10 2012 +0200

    rt2x00: Fix word size of rt2500usb MAC_CSR19 register.
    
    commit 6ced58a5dbb94dbfbea1b33ca3c56d1e929cd548 upstream.
    
    The register is 16 bits wide, not 32.
    
    Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
    Acked-by: Ivo Van Doorn <ivdoorn@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a77399badc9091734c3d8ebdd2230d91e53e05ab
Author: Gertjan van Wingerde <gwingerde@gmail.com>
Date:   Fri Aug 31 19:22:09 2012 +0200

    rt2x00: Identify ASUS USB-N53 device.
    
    commit 177ef8360fabdc49ff08d2598c06e7f7a36b53e3 upstream.
    
    This is an RT3572 based device.
    
    Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de>
    Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
    Acked-by: Ivo Van Doorn <ivdoorn@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit feec4959301512e10e4291c2cfbe4a26c399828e
Author: Nicolas Ferre <nicolas.ferre@atmel.com>
Date:   Tue Sep 11 17:21:45 2012 +0200

    dmaengine: at_hdmac: check that each sg data length is non-null
    
    commit c456797681db814f4f5b36909e8e94047bf53d9c upstream.
    
    Avoid the construction of a malformed DMA request sent to
    the DMA controller.
    Log message is for debug only because this condition is unlikely to
    append and may only trigger at driver development time.
    
    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f102108bd4b5bb05dbfe39ea5af709d4aa537368
Author: Nicolas Ferre <nicolas.ferre@atmel.com>
Date:   Tue Sep 11 17:21:44 2012 +0200

    dmaengine: at_hdmac: fix comment in atc_prep_slave_sg()
    
    commit c618a9be0e8c0f36baee2560860a0118a428fb26 upstream.
    
    s/dma_memcpy/slave_sg/ and it is sg length that we are
    talking about.
    
    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 466307f8c4a8db558e743ea08696e1ef35c5bf52
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date:   Mon Sep 17 15:20:23 2012 +0530

    DMA: PL330: Check the pointer returned by kzalloc
    
    commit 61c6e7531d3b66b33187b8cdd700fd8ab93ffd62 upstream.
    
    kzalloc could return NULL. Hence add a check to avoid
    NULL pointer dereference.
    
    Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
    Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
    Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91ca7fa056484366b1d6ccbe94c4526d0b4b0186
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date:   Mon Sep 17 15:20:22 2012 +0530

    DMA: PL330: Fix potential NULL pointer dereference in pl330_submit_req()
    
    commit 2e2c682becb20416c140aa0d6d3137b51a5c76da upstream.
    
    'r->cfg' is being checked for NULL. However, it is dereferenced
    in the previous statements. Thus moving those statements within
    the check.
    
    Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
    Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
    Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 475d145745db51eea5d153307b2db7f8e6954ebb
Author: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Date:   Fri Sep 14 15:36:57 2012 -0700

    cfg80211: fix possible circular lock on reg_regdb_search()
    
    commit a85d0d7f3460b1a123b78e7f7e39bf72c37dfb78 upstream.
    
    When call_crda() is called we kick off a witch hunt search
    for the same regulatory domain on our internal regulatory
    database and that work gets kicked off on a workqueue, this
    is done while the cfg80211_mutex is held. If that workqueue
    kicks off it will first lock reg_regdb_search_mutex and
    later cfg80211_mutex but to ensure two CPUs will not contend
    against cfg80211_mutex the right thing to do is to have the
    reg_regdb_search() wait until the cfg80211_mutex is let go.
    
    The lockdep report is pasted below.
    
    cfg80211: Calling CRDA to update world regulatory domain
    
    ======================================================
    [ INFO: possible circular locking dependency detected ]
    3.3.8 #3 Tainted: G           O
    -------------------------------------------------------
    kworker/0:1/235 is trying to acquire lock:
     (cfg80211_mutex){+.+...}, at: [<816468a4>] set_regdom+0x78c/0x808 [cfg80211]
    
    but task is already holding lock:
     (reg_regdb_search_mutex){+.+...}, at: [<81646828>] set_regdom+0x710/0x808 [cfg80211]
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #2 (reg_regdb_search_mutex){+.+...}:
           [<800a8384>] lock_acquire+0x60/0x88
           [<802950a8>] mutex_lock_nested+0x54/0x31c
           [<81645778>] is_world_regdom+0x9f8/0xc74 [cfg80211]
    
    -> #1 (reg_mutex#2){+.+...}:
           [<800a8384>] lock_acquire+0x60/0x88
           [<802950a8>] mutex_lock_nested+0x54/0x31c
           [<8164539c>] is_world_regdom+0x61c/0xc74 [cfg80211]
    
    -> #0 (cfg80211_mutex){+.+...}:
           [<800a77b8>] __lock_acquire+0x10d4/0x17bc
           [<800a8384>] lock_acquire+0x60/0x88
           [<802950a8>] mutex_lock_nested+0x54/0x31c
           [<816468a4>] set_regdom+0x78c/0x808 [cfg80211]
    
    other info that might help us debug this:
    
    Chain exists of:
      cfg80211_mutex --> reg_mutex#2 --> reg_regdb_search_mutex
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(reg_regdb_search_mutex);
                                   lock(reg_mutex#2);
                                   lock(reg_regdb_search_mutex);
      lock(cfg80211_mutex);
    
     *** DEADLOCK ***
    
    3 locks held by kworker/0:1/235:
     #0:  (events){.+.+..}, at: [<80089a00>] process_one_work+0x230/0x460
     #1:  (reg_regdb_work){+.+...}, at: [<80089a00>] process_one_work+0x230/0x460
     #2:  (reg_regdb_search_mutex){+.+...}, at: [<81646828>] set_regdom+0x710/0x808 [cfg80211]
    
    stack backtrace:
    Call Trace:
    [<80290fd4>] dump_stack+0x8/0x34
    [<80291bc4>] print_circular_bug+0x2ac/0x2d8
    [<800a77b8>] __lock_acquire+0x10d4/0x17bc
    [<800a8384>] lock_acquire+0x60/0x88
    [<802950a8>] mutex_lock_nested+0x54/0x31c
    [<816468a4>] set_regdom+0x78c/0x808 [cfg80211]
    
    Reported-by: Felix Fietkau <nbd@openwrt.org>
    Tested-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
    Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c1d6b74e6c442c47dbc1849da9587574cb10e6c
Author: Ira W. Snyder <iws@ovro.caltech.edu>
Date:   Tue Sep 11 15:58:15 2012 -0700

    can: janz-ican3: fix support for older hardware revisions
    
    commit e21093ef6fb4cbecdf926102286dbe280ae965db upstream.
    
    The Revision 1.0 Janz CMOD-IO Carrier Board does not have support for
    the reset registers. To support older hardware, the code is changed to
    use the hardware reset register on the Janz VMOD-ICAN3 hardware itself.
    
    Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af22fdf400b6d4e7721d01166b88996e456fd55f
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Sep 19 14:58:45 2012 +0200

    can: ti_hecc: fix oops during rmmod
    
    commit ab04c8bd423edb03e2148350a091836c196107fc upstream.
    
    This patch fixes an oops which occurs when unloading the driver, while the
    network interface is still up. The problem is that first the io mapping is
    teared own, then the CAN device is unregistered, resulting in accessing the
    hardware's iomem:
    
    [  172.744232] Unable to handle kernel paging request at virtual address c88b0040
    [  172.752441] pgd = c7be4000
    [  172.755645] [c88b0040] *pgd=87821811, *pte=00000000, *ppte=00000000
    [  172.762207] Internal error: Oops: 807 [#1] PREEMPT ARM
    [  172.767517] Modules linked in: ti_hecc(-) can_dev
    [  172.772430] CPU: 0    Not tainted  (3.5.0alpha-00037-g3554cc0 #126)
    [  172.778961] PC is at ti_hecc_close+0xb0/0x100 [ti_hecc]
    [  172.784423] LR is at __dev_close_many+0x90/0xc0
    [  172.789123] pc : [<bf00c768>]    lr : [<c033be58>]    psr: 60000013
    [  172.789123] sp : c5c1de68  ip : 00040081  fp : 00000000
    [  172.801025] r10: 00000001  r9 : c5c1c000  r8 : 00100100
    [  172.806457] r7 : c5d0a48c  r6 : c5d0a400  r5 : 00000000  r4 : c5d0a000
    [  172.813232] r3 : c88b0000  r2 : 00000001  r1 : c5d0a000  r0 : c5d0a000
    [  172.820037] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
    [  172.827423] Control: 10c5387d  Table: 87be4019  DAC: 00000015
    [  172.833404] Process rmmod (pid: 600, stack limit = 0xc5c1c2f0)
    [  172.839447] Stack: (0xc5c1de68 to 0xc5c1e000)
    [  172.843994] de60:                   bf00c6b8 c5c1dec8 c5d0a000 c5d0a000 00200200 c033be58
    [  172.852478] de80: c5c1de44 c5c1dec8 c5c1dec8 c033bf2c c5c1de90 c5c1de90 c5d0a084 c5c1de44
    [  172.860992] dea0: c5c1dec8 c033c098 c061d3dc c5d0a000 00000000 c05edf28 c05edb34 c000d724
    [  172.869476] dec0: 00000000 c033c2f8 c5d0a084 c5d0a084 00000000 c033c370 00000000 c5d0a000
    [  172.877990] dee0: c05edb00 c033c3b8 c5d0a000 bf00d3ac c05edb00 bf00d7c8 bf00d7c8 c02842dc
    [  172.886474] df00: c02842c8 c0282f90 c5c1c000 c05edb00 bf00d7c8 c0283668 bf00d7c8 00000000
    [  172.894989] df20: c0611f98 befe2f80 c000d724 c0282d10 bf00d804 00000000 00000013 c0068a8c
    [  172.903472] df40: c5c538e8 685f6974 00636365 c61571a8 c5cb9980 c61571a8 c6158a20 c00c9bc4
    [  172.911987] df60: 00000000 00000000 c5cb9980 00000000 c5cb9980 00000000 c7823680 00000006
    [  172.920471] df80: bf00d804 00000880 c5c1df8c 00000000 000d4267 befe2f80 00000001 b6d90068
    [  172.928985] dfa0: 00000081 c000d5a0 befe2f80 00000001 befe2f80 00000880 b6d90008 00000008
    [  172.937469] dfc0: befe2f80 00000001 b6d90068 00000081 00000001 00000000 befe2eac 00000000
    [  172.945983] dfe0: 00000000 befe2b18 00023ba4 b6e6addc 60000010 befe2f80 a8e00190 86d2d344
    [  172.954498] [<bf00c768>] (ti_hecc_close+0xb0/0x100 [ti_hecc]) from [<c033be58>] (__dev__registered_many+0xc0/0x2a0)
    [  172.984161] [<c033c098>] (rollback_registered_many+0xc0/0x2a0) from [<c033c2f8>] (rollback_registered+0x20/0x30)
    [  172.994750] [<c033c2f8>] (rollback_registered+0x20/0x30) from [<c033c370>] (unregister_netdevice_queue+0x68/0x98)
    [  173.005401] [<c033c370>] (unregister_netdevice_queue+0x68/0x98) from [<c033c3b8>] (unregister_netdev+0x18/0x20)
    [  173.015899] [<c033c3b8>] (unregister_netdev+0x18/0x20) from [<bf00d3ac>] (ti_hecc_remove+0x60/0x80 [ti_hecc])
    [  173.026245] [<bf00d3ac>] (ti_hecc_remove+0x60/0x80 [ti_hecc]) from [<c02842dc>] (platform_drv_remove+0x14/0x18)
    [  173.036712] [<c02842dc>] (platform_drv_remove+0x14/0x18) from [<c0282f90>] (__device_release_driver+0x7c/0xbc)
    
    Tested-by: Jan Luebbe <jlu@pengutronix.de>
    Cc: Anant Gole <anantgole@ti.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 428230a6fdf3ffc710d055e1af112e719c735be3
Author: Søren Holm <sgh@sgh.dk>
Date:   Mon Sep 17 21:50:57 2012 +0000

    asix: Support DLink DUB-E100 H/W Ver C1
    
    commit ed3770a9cd5764a575b83810ea679bbff2b03082 upstream.
    
    Signed-off-by: Søren Holm <sgh@sgh.dk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa1915bfa2141edf04caf9d1cee48e46d93bae2b
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Tue Sep 11 11:11:13 2012 -0500

    rtlwifi: rtl8192ce: Log message that B_CUT device may not work
    
    commit 022e1d0680c7b4366017393417b8758be5abcee8 upstream.
    
    There are a number of problems that occur for the latest version
    of the Realtek RTL8188CE device with the in-kernel driver. These
    include selection of the wrong firmware, and system lockup. A full
    fix is known, but is too invasive for inclusion in stable. This patch
    fixes the problem with loading the wrong firmware, and logs a message
    that the device may not work for kernels 3.6 and older.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: Anisse Astier <anisse@astier.eu>
    Cc: Li Chaoming <chaoming_li@realsil.com.cn>
    Tested-by: Anisse Astier <anisse@astier.eu>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7286d61084143f84267380bfb540c8ab9d4a2d7
Author: Robert Richter <robert.richter@amd.com>
Date:   Wed Jul 25 19:12:45 2012 +0200

    perf/x86/ibs: Check syscall attribute flags
    
    commit bad9ac2d7f878a31cf1ae8c1ee3768077d222bcb upstream.
    
    Current implementation simply ignores attribute flags. Thus, there is
    no notification to userland of unsupported features. Check syscall's
    attribute flags to let userland know if a feature is supported by the
    kernel. This is also needed to distinguish between future kernels what
    might support a feature.
    
    Signed-off-by: Robert Richter <robert.richter@amd.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/20120910093018.GO8285@erda.amd.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78dc73459b6368ed7c2dedb7ea273f33d87fac2a
Author: Jovi Zhang <bookjovi@gmail.com>
Date:   Wed Aug 22 10:34:08 2012 +0800

    MIPS: mm: Add compound tail page _mapcount when mapped
    
    commit af89fa3986b9d034a286544ab1ed95096496a2f9 upstream.
    
    See commit b6999b191 which did the same modification for x86's mm/gup,
    
    Quote from commit b6999b191:
        "If compound pages are used and the page is a
        tail page, gup_huge_pmd() increases _mapcount to record tail page are
        mapped while gup_huge_pud does not do that."
    
    [ralf@linux-mips.org: fixed rejects caused by the original patch getting
    linewrapped.]
    
    Signed-off-by: Jovi Zhang <boojovi@gmail.com>
    Cc: Youquan Song <youquan.song@intel.com>
    Cc: Andi Kleen <andi@firstfloor.org>
    Patchwork: https://patchwork.linux-mips.org/patch/4291/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83d4a1078de4231ffbd4f0caddc3a5b404f49df6
Author: Anisse Astier <anisse@astier.eu>
Date:   Wed Sep 19 11:10:48 2012 -0700

    Input: i8042 - disable mux on Toshiba C850D
    
    commit 8669cf6793bb38307a30fb6b9565ddc8840ebd3f upstream.
    
    On Toshiba Satellite C850D, the touchpad and the keyboard might randomly
    not work at boot. Preventing MUX mode activation solves this issue.
    
    Signed-off-by: Anisse Astier <anisse@astier.eu>
    Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18f48bf4f50fa66d5dfcb2d3a225a2648db9796c
Author: Wen Congyang <wency@cn.fujitsu.com>
Date:   Thu Sep 20 14:04:47 2012 +0800

    tracing: Don't call page_to_pfn() if page is NULL
    
    commit 85f2a2ef1d0ab99523e0b947a2b723f5650ed6aa upstream.
    
    When allocating memory fails, page is NULL. page_to_pfn() will
    cause the kernel panicked if we don't use sparsemem vmemmap.
    
    Link: http://lkml.kernel.org/r/505AB1FF.8020104@cn.fujitsu.com
    
    Acked-by: Mel Gorman <mel@csn.ul.ie>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Minchan Kim <minchan@kernel.org>
    Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cfa259e003d1d7a3ecca5b30b7d1361838c7dbe3
Author: Matthew Leach <matthew.leach@arm.com>
Date:   Tue Sep 11 17:56:57 2012 +0100

    ARM: 7532/1: decompressor: reset SCTLR.TRE for VMSA ARMv7 cores
    
    commit e1e5b7e4251c7538ca08c2c5545b0c2fbd8a6635 upstream.
    
    This patch zeroes the SCTLR.TRE bit prior to setting the mapping as
    cacheable for ARMv7 cores in the decompressor, ensuring that the
    memory region attributes are obtained from the C and B bits, not from
    the page tables.
    
    Cc: Nicolas Pitre <nico@fluxnic.net>
    Reviewed-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Matthew Leach <matthew.leach@arm.com>
    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 dd2b53aed0496eca6f309ed39502a0dddf1a05ef
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date:   Sun Sep 16 22:28:35 2012 -0300

    ARM: imx: armadillo5x0: Fix illegal register access
    
    commit 35495173e1df621dff0e9a244accbe32cd28a98f upstream.
    
    Since commit eb92044eb (ARM i.MX3: Make ccm base address a variable )
    it is necessary to pass the CCM register base as a variable.
    
    Fix the CCM register access in mach-armadillo5x0 by passing mx3_ccm_base and
    avoid illegal accesses.
    
    Also applies to v3.5
    
    Reported-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c13bdc66baf034b40cac9d7637dbff48783e012d
Author: Toshi Kani <toshi.kani@hp.com>
Date:   Mon Aug 27 12:52:24 2012 -0600

    hpwdt: Fix kdump issue in hpwdt
    
    commit 308b135e4fcc00c80c07e0e04e7afa8edf78583c upstream.
    
    kdump can be interrupted by watchdog timer when the timer is left
    activated on the crash kernel. Changed the hpwdt driver to disable
    watchdog timer at boot-time. This assures that watchdog timer is
    disabled until /dev/watchdog is opened, and prevents watchdog timer
    to be left running on the crash kernel.
    
    Signed-off-by: Toshi Kani <toshi.kani@hp.com>
    Tested-by: Lisa Mitchell <lisa.mitchell@hp.com>
    Signed-off-by: Thomas Mingarelli <Thomas.Mingarelli@hp.com>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8bf0fbfae17c8444de42b5de64bda9ac8dad0ad7
Author: Mark Salter <msalter@redhat.com>
Date:   Mon Sep 24 17:17:38 2012 -0700

    c/r: prctl: fix build error for no-MMU case
    
    commit be8cfc4af15cf611dfeb66a1fb5df43d5f1e280a upstream.
    
    Commit 1ad75b9e1628 ("c/r: prctl: add minimal address test to
    PR_SET_MM") added some address checking to prctl_set_mm() used by
    checkpoint-restore.  This causes a build error for no-MMU systems:
    
       kernel/sys.c: In function 'prctl_set_mm':
       kernel/sys.c:1868:34: error: 'mmap_min_addr' undeclared (first use in this function)
    
    The test for mmap_min_addr doesn't make a lot of sense for no-MMU code
    as noted in commit 6e1415467614 ("NOMMU: Optimise away the
    {dac_,}mmap_min_addr tests").
    
    This patch defines mmap_min_addr as 0UL in the no-MMU case so that the
    compiler will optimize away tests for "addr < mmap_min_addr".
    
    Signed-off-by: Mark Salter <msalter@redhat.com>
    Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.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 2f5c31b0f2b8c6bfb004e24aef80c1df75452001
Author: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Date:   Wed Aug 29 10:02:09 2012 +0200

    Bluetooth: mgmt: Fix enabling LE while powered off
    
    commit 562fcc246ebe31ade6e1be08585673b9b2785498 upstream.
    
    When new BT USB adapter is plugged in it's configured while still being powered
    off (HCI_AUTO_OFF flag is set), thus Set LE will only set dev_flags but won't
    write changes to controller. As a result it's not possible to start device
    discovery session on LE controller as it uses interleaved discovery which
    requires LE Supported Host flag in extended features.
    
    This patch ensures HCI Write LE Host Supported is sent when Set Powered is
    called to power on controller and clear HCI_AUTO_OFF flag.
    
    Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
    Acked-by: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca7efbe83d037083693cecb27ea275646340cefa
Author: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Date:   Fri Sep 14 16:34:46 2012 -0300

    Bluetooth: Fix not removing power_off delayed work
    
    commit 78c04c0bf52360dc2f7185e99c8e9aa05d73ae5a upstream.
    
    For example, when a usb reset is received (I could reproduce it
    running something very similar to this[1] in a loop) it could be
    that the device is unregistered while the power_off delayed work
    is still scheduled to run.
    
    Backtrace:
    
    WARNING: at lib/debugobjects.c:261 debug_print_object+0x7c/0x8d()
    Hardware name: To Be Filled By O.E.M.
    ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x26
    Modules linked in: nouveau mxm_wmi btusb wmi bluetooth ttm coretemp drm_kms_helper
    Pid: 2114, comm: usb-reset Not tainted 3.5.0bt-next #2
    Call Trace:
     [<ffffffff8124cc00>] ? free_obj_work+0x57/0x91
     [<ffffffff81058f88>] warn_slowpath_common+0x7e/0x97
     [<ffffffff81059035>] warn_slowpath_fmt+0x41/0x43
     [<ffffffff8124ccb6>] debug_print_object+0x7c/0x8d
     [<ffffffff8106e3ec>] ? __queue_work+0x259/0x259
     [<ffffffff8124d63e>] ? debug_check_no_obj_freed+0x6f/0x1b5
     [<ffffffff8124d667>] debug_check_no_obj_freed+0x98/0x1b5
     [<ffffffffa00aa031>] ? bt_host_release+0x10/0x1e [bluetooth]
     [<ffffffff810fc035>] kfree+0x90/0xe6
     [<ffffffffa00aa031>] bt_host_release+0x10/0x1e [bluetooth]
     [<ffffffff812ec2f9>] device_release+0x4a/0x7e
     [<ffffffff8123ef57>] kobject_release+0x11d/0x154
     [<ffffffff8123ed98>] kobject_put+0x4a/0x4f
     [<ffffffff812ec0d9>] put_device+0x12/0x14
     [<ffffffffa009472b>] hci_free_dev+0x22/0x26 [bluetooth]
     [<ffffffffa0280dd0>] btusb_disconnect+0x96/0x9f [btusb]
     [<ffffffff813581b4>] usb_unbind_interface+0x57/0x106
     [<ffffffff812ef988>] __device_release_driver+0x83/0xd6
     [<ffffffff812ef9fb>] device_release_driver+0x20/0x2d
     [<ffffffff813582a7>] usb_driver_release_interface+0x44/0x7b
     [<ffffffff81358795>] usb_forced_unbind_intf+0x45/0x4e
     [<ffffffff8134f959>] usb_reset_device+0xa6/0x12e
     [<ffffffff8135df86>] usbdev_do_ioctl+0x319/0xe20
     [<ffffffff81203244>] ? avc_has_perm_flags+0xc9/0x12e
     [<ffffffff812031a0>] ? avc_has_perm_flags+0x25/0x12e
     [<ffffffff81050101>] ? do_page_fault+0x31e/0x3a1
     [<ffffffff8135eaa6>] usbdev_ioctl+0x9/0xd
     [<ffffffff811126b1>] vfs_ioctl+0x21/0x34
     [<ffffffff81112f7b>] do_vfs_ioctl+0x408/0x44b
     [<ffffffff81208d45>] ? file_has_perm+0x76/0x81
     [<ffffffff8111300f>] sys_ioctl+0x51/0x76
     [<ffffffff8158db22>] system_call_fastpath+0x16/0x1b
    
    [1] http://cpansearch.perl.org/src/DPAVLIN/Biblio-RFID-0.03/examples/usbreset.c
    
    Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c5aef4e6205321a9811caa9f69b9f42dd79317c
Author: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Date:   Wed Aug 29 10:02:08 2012 +0200

    Bluetooth: mgmt: Fix enabling SSP while powered off
    
    commit 3d1cbdd6aefff711bcf389fdabc4af9bc22e8201 upstream.
    
    When new BT USB adapter is plugged in it's configured while still being powered
    off (HCI_AUTO_OFF flag is set), thus Set SSP will only set dev_flags but won't
    write changes to controller. As a result remote devices won't use Secure Simple
    Pairing with our device due to SSP Host Support flag disabled in extended
    features and may also reject SSP attempt from our side (with possible fallback
    to legacy pairing).
    
    This patch ensures HCI Write Simple Pairing Mode is sent when Set Powered is
    called to power on controller and clear HCI_AUTO_OFF flag.
    
    Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
    Acked-by: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c0bd09175067fdd190ebe8b2e6757d9d9cb7efe
Author: Wang Sen <senwang@linux.vnet.ibm.com>
Date:   Mon Jul 30 14:25:06 2012 +0800

    SCSI: scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
    
    commit 27e99ade81368e6fdda3212bff9345177cf9e57a upstream.
    
    When using the commands below to write some data to a virtio-scsi LUN of the
    QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash.
    
            # sudo mkfs.ext4 /dev/sdb  (/dev/sdb is the virtio-scsi LUN.)
            # sudo mount /dev/sdb /mnt
            # dd if=/dev/zero of=/mnt/file bs=1M count=1024
    
    In current implementation, sg_set_buf is called to add buffers to sg list which
    is put into the virtqueue eventually. But if there are some HighMem pages in
    table->sgl you can not get virtual address by sg_virt. So, sg_virt(sg_elem) may
    return NULL value. This will cause QEMU exit when virtqueue_map_sg is called
    in QEMU because an invalid GPA is passed by virtqueue.
    
    Two solutions are discussed here:
    http://lkml.indiana.edu/hypermail/linux/kernel/1207.3/00675.html
    
    Finally, value assignment approach was adopted because:
    
    Value assignment creates a well-formed scatterlist, because the termination
    marker in source sg_list has been set in blk_rq_map_sg(). The last entry of the
    source sg_list is just copied to the the last entry in destination list.  Note
    that, for now, virtio_ring does not care about the form of the scatterlist and
    simply processes the first out_num + in_num consecutive elements of the sg[]
    array.
    
    I have tested the patch on my workstation. QEMU would not crash any more.
    
    Signed-off-by: Wang Sen <senwang@linux.vnet.ibm.com>
    Acked-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e9ca240ff7e18983868f4861cbbfbfff3ff7868
Author: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Date:   Fri Sep 14 16:34:25 2012 -0500

    SCSI: hpsa: fix handling of protocol error
    
    commit 256d0eaac87da1e993190846064f339f4c7a63f5 upstream.
    
    If a command status of CMD_PROTOCOL_ERR is received, this
    information should be conveyed to the SCSI mid layer, not
    dropped on the floor.  CMD_PROTOCOL_ERR may be received
    from the Smart Array for any commands destined for an external
    RAID controller such as a P2000, or commands destined for tape
    drives or CD/DVD-ROM drives, if for instance a cable is
    disconnected.  This mostly affects multipath configurations, as
    disconnecting a cable on a non-multipath configuration is not
    going to do anything good regardless of whether CMD_PROTOCOL_ERR
    is handled correctly or not.  Not handling CMD_PROTOCOL_ERR
    correctly in a multipath configaration involving external RAID
    controllers may cause data corruption, so this is quite a serious
    bug.  This bug should not normally cause a problem for direct
    attached disk storage.
    
    Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fea3ffaf810a8a27c651d36930436176b0cf3ae
Author: Eddie Wai <eddie.wai@broadcom.com>
Date:   Tue Aug 21 10:35:53 2012 -0700

    SCSI: bnx2i: Fixed NULL ptr deference for 1G bnx2 Linux iSCSI offload
    
    commit d6532207116307eb7ecbfa7b9e02c53230096a50 upstream.
    
    This patch fixes the following kernel panic invoked by uninitialized fields
    in the chip initialization for the 1G bnx2 iSCSI offload.
    
    One of the bits in the chip initialization is being used by the latest
    firmware to control overflow packets.  When this control bit gets enabled
    erroneously, it would ultimately result in a bad packet placement which would
    cause the bnx2 driver to dereference a NULL ptr in the placement handler.
    
    This can happen under certain stress I/O environment under the Linux
    iSCSI offload operation.
    
    This change only affects Broadcom's 5709 chipset.
    
    Unable to handle kernel NULL pointer dereference at 0000000000000008 RIP:
     [<ffffffff881f0e7d>] :bnx2:bnx2_poll_work+0xd0d/0x13c5
    Pid: 0, comm: swapper Tainted: G     ---- 2.6.18-333.el5debug #2
    RIP: 0010:[<ffffffff881f0e7d>]  [<ffffffff881f0e7d>] :bnx2:bnx2_poll_work+0xd0d/0x13c5
    RSP: 0018:ffff8101b575bd50  EFLAGS: 00010216
    RAX: 0000000000000005 RBX: ffff81007c5fb180 RCX: 0000000000000000
    RDX: 0000000000000ffc RSI: 00000000817e8000 RDI: 0000000000000220
    RBP: ffff81015bbd7ec0 R08: ffff8100817e9000 R09: 0000000000000000
    R10: ffff81007c5fb180 R11: 00000000000000c8 R12: 000000007a25a010
    R13: 0000000000000000 R14: 0000000000000005 R15: ffff810159f80558
    FS:  0000000000000000(0000) GS:ffff8101afebc240(0000) knlGS:0000000000000000
    CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    CR2: 0000000000000008 CR3: 0000000000201000 CR4: 00000000000006a0
    Process swapper (pid: 0, threadinfo ffff8101b5754000, task ffff8101afebd820)
    Stack:  000000000000000b ffff810159f80000 0000000000000040 ffff810159f80520
     ffff810159f80500 00cf00cf8008e84b ffffc200100939e0 ffff810009035b20
     0000502900000000 000000be00000001 ffff8100817e7810 00d08101b575bea8
    Call Trace:
     <IRQ>  [<ffffffff8008e0d0>] show_schedstat+0x1c2/0x25b
     [<ffffffff881f1886>] :bnx2:bnx2_poll+0xf6/0x231
     [<ffffffff8000c9b9>] net_rx_action+0xac/0x1b1
     [<ffffffff800125a0>] __do_softirq+0x89/0x133
     [<ffffffff8005e30c>] call_softirq+0x1c/0x28
     [<ffffffff8006d5de>] do_softirq+0x2c/0x7d
     [<ffffffff8006d46e>] do_IRQ+0xee/0xf7
     [<ffffffff8005d625>] ret_from_intr+0x0/0xa
     <EOI>  [<ffffffff801a5780>] acpi_processor_idle_simple+0x1c5/0x341
     [<ffffffff801a573d>] acpi_processor_idle_simple+0x182/0x341
     [<ffffffff801a55bb>] acpi_processor_idle_simple+0x0/0x341
     [<ffffffff80049560>] cpu_idle+0x95/0xb8
     [<ffffffff80078b1c>] start_secondary+0x479/0x488
    
    Signed-off-by: Eddie Wai <eddie.wai@broadcom.com>
    Reviewed-by: Mike Christie <michaelc@cs.wisc.edu>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 727f6b2f3e047848cff1ad6c043eb95da93c8c95
Author: sreekanth.reddy@lsi.com <sreekanth.reddy@lsi.com>
Date:   Wed Aug 22 16:55:13 2012 +0530

    SCSI: mpt2sas: Fix for issue - Unable to boot from the drive connected to HBA
    
    commit 10cce6d8b5af0b32bc4254ae4a28423a74c0921c upstream.
    
    This patch checks whether HBA is SAS2008 B0 controller.
    if it is a SAS2008 B0 controller then it use IO-APIC interrupt instead of MSIX,
    as SAS2008 B0 controller doesn't support MSIX interrupts.
    
    [jejb: fix whitespace problems]
    Signed-off-by: Sreekanth Reddy <sreekanth.reddy@lsi.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4134110803b08c03f051a1c7379474f28ebec83
Author: James Bottomley <jbottomley@parallels.com>
Date:   Thu Jun 21 07:50:02 2012 +0000

    SCSI: lpfc: fix problems with -Werror
    
    commit 4bdd03e61b7a5c4c6bc2b25d46fcd491788fdfb3 upstream.
    
    Commit d38bd3aef ("Add -Werror compilation flag") is causing build breakage
    with random gcc incarnations.  These look like gcc problems, but we shouldn't
    break the build because of a bad gcc.  Fix this by adding a make flag
    
    WARNINGS_BECOME_ERRORS=1
    
    which is the same as aic7xxx uses so ordinarily the build doesn't use -Werror
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Cc: Alex Iannicelli <alex.iannicelli@emulex.com>
    Cc: James Smart <james.smart@emulex.com>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Cc: Mike Pagano <mpagano@gentoo.org>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>

commit 18e140c64679d53fe0952b12fd9bd01df1e8d29d
Author: Hante Meuleman <meuleman@broadcom.com>
Date:   Tue Sep 11 21:16:48 2012 +0200

    brcmfmac: Fix big endian host configuration data.
    
    commit e020a83d0942a5aceac35986500c9834efc8707d upstream.
    
    Fixes big endian host configuration parameters.
    
    Reviewed-by: Arend Van Spriel <arend@broadcom.com>
    Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
    Signed-off-by: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae3853800b6604f73ac07c5e766593b5605529f2
Author: Hante Meuleman <meuleman@broadcom.com>
Date:   Tue Sep 11 21:16:47 2012 +0200

    brcmfmac: fix big endian bug in i-scan.
    
    commit ed205b361956c96e0d8c09a8c9135a6a79cd9541 upstream.
    
    ssid len is 32 bit and needs endian conversion for big endian systems.
    
    Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
    Signed-off-by: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2d0b03cd7cb264258e7473a4a3ef72f48752999
Author: Eliad Peller <eliad@wizery.com>
Date:   Tue Sep 4 17:44:45 2012 +0300

    mac80211: clear bssid on auth/assoc failure
    
    commit 3d2abdfdf14f4d6decc2023708211e19b096f4ca upstream.
    
    ifmgd->bssid wasn't cleared properly in some
    auth/assoc failure cases, causing mac80211 and
    the low-level driver to go out of sync.
    
    Clear ifmgd->bssid on failure, and notify the driver.
    
    Signed-off-by: Eliad Peller <eliad@wizery.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2306783b6e793e80943656e8238b5a367428ee8e
Author: Santiago Leon <santil@linux.vnet.ibm.com>
Date:   Tue Sep 4 14:41:37 2012 +0000

    ibmveth: Fix alignment of rx queue bug
    
    commit d90c92fee89ccd75ef2646f3bde0b4c0450666c3 upstream.
    
    This patch fixes a bug found by Nish Aravamudan
    (https://lkml.org/lkml/2012/5/15/220) where the driver is not following
    the spec (it is not aligning the rx buffer on a 16-byte boundary) and the
    hypervisor aborts the registration, making the device unusable.
    
    The fix follows BenH's recommendation (https://lkml.org/lkml/2012/7/20/461)
    to replace the kmalloc+map for a single call to dma_alloc_coherent()
    because that function always aligns to a 16-byte boundary.
    
    The stable trees will run into this bug whenever the rx buffer kmalloc call
    returns something not aligned on a 16-byte boundary.
    
    Signed-off-by: Santiago Leon <santil@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a899124734999d85d0b23371a367d92cfb82ee2
Author: Bjørn Mork <bjorn@mork.no>
Date:   Sun Sep 2 22:26:18 2012 +0000

    net: usbnet: fix softirq storm on suspend
    
    commit 85e87870fa18ec9f5df98e2d3b48f3699560a570 upstream.
    
    Suspending an open usbnet device results in constant
    rescheduling of usbnet_bh.
    
    commit 65841fd5 "usbnet: handle remote wakeup asap"
    refactored the usbnet_bh code to allow sharing the
    urb allocate and submit code with usbnet_resume. In
    this process, a test for, and immediate return on,
    ENOLINK from rx_submit was unintentionally dropped.
    
    The rx queue will not grow if rx_submit fails,
    making usbnet_bh reschedule itself.  This results
    in a softirq storm if the error is persistent.
    rx_submit translates the usb_submit_urb error
    EHOSTUNREACH into ENOLINK, so this is an expected
    and persistent error for a suspended device. The
    old code tested for this condition and avoided
    rescheduling.  Putting this test back.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Cc: Ming Lei <ming.lei@canonical.com>
    Cc: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 623678ee75bbe765b6688ff05f0a435e959fa016
Author: Dave Airlie <airlied@redhat.com>
Date:   Tue Aug 28 01:53:54 2012 +0000

    vmwgfx: add dumb ioctl support
    
    commit 5e1782d224c79b26ab7d5c31e3f87657000714fb upstream.
    
    Testing and works with the -modesetting driver,
    
    Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e151dc53628c447f196e96808cf7b9eab17a027
Author: Jeff Layton <jlayton@redhat.com>
Date:   Tue Sep 18 14:21:01 2012 -0400

    cifs: fix return value in cifsConvertToUTF16
    
    commit c73f693989d7a7d99ec66a7065295a0c93d0b127 upstream.
    
    This function returns the wrong value, which causes the callers to get
    the length of the resulting pathname wrong when it contains non-ASCII
    characters.
    
    This seems to fix https://bugzilla.samba.org/show_bug.cgi?id=6767
    
    Reported-by: Baldvin Kovacs <baldvin.kovacs@gmail.com>
    Reported-and-Tested-by: Nicolas Lefebvre <nico.lefebvre@gmail.com>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd4af90712fa632c5feae6f0afc8378833fce601
Author: Nestor Lopez Casado <nlopezcasad@logitech.com>
Date:   Fri Sep 21 12:21:34 2012 +0200

    HID: Fix logitech-dj: missing Unifying device issue
    
    commit 596264082f10dd4a567c43d4526b2f54ac5520bc upstream.
    
    This patch fixes an issue introduced after commit 4ea5454203d991ec
    ("HID: Fix race condition between driver core and ll-driver").
    
    After that commit, hid-core discards any incoming packet that arrives while
    hid driver's probe function is being executed.
    
    This broke the enumeration process of hid-logitech-dj, that must receive
    control packets in-band with the mouse and keyboard packets. Discarding mouse
    or keyboard data at the very begining is usually fine, but it is not the case
    for control packets.
    
    This patch forces a re-enumeration of the paired devices when a packet arrives
    that comes from an unknown device.
    
    Based on a patch originally written by Benjamin Tissoires.
    
    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 1607e7b7045c1dbd5072c6aabde7d9159ca39356
Author: Alan Cox <alan@linux.intel.com>
Date:   Tue Sep 4 15:10:08 2012 +0100

    dj: memory scribble in logi_dj
    
    commit 8a55ade76551e3927b4e41ee9e7751875d18bc25 upstream.
    
    Allocate a structure not a pointer to it !
    
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9304b81bd45689d9fac80ce689a36841aefeba33
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Tue Sep 11 13:43:17 2012 -0700

    hwmon: (ad7314) Add 'name' sysfs attribute
    
    commit 3ceefe4319636d89d4bdf40dca9471970f942e4f upstream.
    
    The 'name' sysfs attribute is mandatory for hwmon devices, but was missing
    in this driver.
    
    Cc: Jonathan Cameron <jic23@cam.ac.uk>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Jean Delvare <khali@linux-fr.org>
    Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3aa7516bf06846d00b0f93f10e466dcfc7d95cce
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Tue Sep 11 13:39:08 2012 -0700

    hwmon: (ads7871) Add 'name' sysfs attribute
    
    commit 4e21f4eaa49f78d3e977e316514c941053871c76 upstream.
    
    The 'name' sysfs attribute is mandatory for hwmon devices, but was missing
    in this driver.
    
    Cc: Paul Thomas <pthomas8589@gmail.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Jean Delvare <khali@linux-fr.org>
    Acked-by: Paul Thomas <pthomas8589@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0c2ca340080d3f918cc69c8cc7516ccd85f2799
Author: Andreas Herrmann <andreas.herrmann3@amd.com>
Date:   Sun Sep 23 20:27:32 2012 +0200

    hwmon: (fam15h_power) Tweak runavg_range on resume
    
    commit 5f0ecb907deb1e6f28071ee3bd568903b9da1be4 upstream.
    
    The quirk introduced with commit
    00250ec90963b7ef6678438888f3244985ecde14 (hwmon: fam15h_power: fix
    bogus values with current BIOSes) is not only required during driver
    load but also when system resumes from suspend. The BIOS might set the
    previously recommended (but unsuitable) initilization value for the
    running average range register during resume.
    
    Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
    Tested-by: Andreas Hartmann <andihartmann@01019freenet.de>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c362fb1c80ded1b396d9f2fabfdbe6632ec9120
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Fri Aug 17 10:22:37 2012 -0400

    xen/boot: Disable NUMA for PV guests.
    
    commit 8d54db795dfb1049d45dc34f0dddbc5347ec5642 upstream.
    
    The hypervisor is in charge of allocating the proper "NUMA" memory
    and dealing with the CPU scheduler to keep them bound to the proper
    NUMA node. The PV guests (and PVHVM) have no inkling of where they
    run and do not need to know that right now. In the future we will
    need to inject NUMA configuration data (if a guest spans two or more
    NUMA nodes) so that the kernel can make the right choices. But those
    patches are not yet present.
    
    In the meantime, disable the NUMA capability in the PV guest, which
    also fixes a bootup issue. Andre says:
    
    "we see Dom0 crashes due to the kernel detecting the NUMA topology not
    by ACPI, but directly from the northbridge (CONFIG_AMD_NUMA).
    
    This will detect the actual NUMA config of the physical machine, but
    will crash about the mismatch with Dom0's virtual memory. Variation of
    the theme: Dom0 sees what it's not supposed to see.
    
    This happens with the said config option enabled and on a machine where
    this scanning is still enabled (K8 and Fam10h, not Bulldozer class)
    
    We have this dump then:
    NUMA: Warning: node ids are out of bound, from=-1 to=-1 distance=10
    Scanning NUMA topology in Northbridge 24
    Number of physical nodes 4
    Node 0 MemBase 0000000000000000 Limit 0000000040000000
    Node 1 MemBase 0000000040000000 Limit 0000000138000000
    Node 2 MemBase 0000000138000000 Limit 00000001f8000000
    Node 3 MemBase 00000001f8000000 Limit 0000000238000000
    Initmem setup node 0 0000000000000000-0000000040000000
      NODE_DATA [000000003ffd9000 - 000000003fffffff]
    Initmem setup node 1 0000000040000000-0000000138000000
      NODE_DATA [0000000137fd9000 - 0000000137ffffff]
    Initmem setup node 2 0000000138000000-00000001f8000000
      NODE_DATA [00000001f095e000 - 00000001f0984fff]
    Initmem setup node 3 00000001f8000000-0000000238000000
    Cannot find 159744 bytes in node 3
    BUG: unable to handle kernel NULL pointer dereference at (null)
    IP: [<ffffffff81d220e6>] __alloc_bootmem_node+0x43/0x96
    Pid: 0, comm: swapper Not tainted 3.3.6 #1 AMD Dinar/Dinar
    RIP: e030:[<ffffffff81d220e6>]  [<ffffffff81d220e6>] __alloc_bootmem_node+0x43/0x96
    .. snip..
      [<ffffffff81d23024>] sparse_early_usemaps_alloc_node+0x64/0x178
      [<ffffffff81d23348>] sparse_init+0xe4/0x25a
      [<ffffffff81d16840>] paging_init+0x13/0x22
      [<ffffffff81d07fbb>] setup_arch+0x9c6/0xa9b
      [<ffffffff81683954>] ? printk+0x3c/0x3e
      [<ffffffff81d01a38>] start_kernel+0xe5/0x468
      [<ffffffff81d012cf>] x86_64_start_reservations+0xba/0xc1
      [<ffffffff81007153>] ? xen_setup_runstate_info+0x2c/0x36
      [<ffffffff81d050ee>] xen_start_kernel+0x565/0x56c
    "
    
    so we just disable NUMA scanning by setting numa_off=1.
    
    Reported-and-Tested-by: Andre Przywara <andre.przywara@amd.com>
    Acked-by: Andre Przywara <andre.przywara@amd.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91101fc0dc638cc70981b4d065240c2b87353049
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Wed Sep 19 08:30:55 2012 -0400

    xen/boot: Disable BIOS SMP MP table search.
    
    commit bd49940a35ec7d488ae63bd625639893b3385b97 upstream.
    
    As the initial domain we are able to search/map certain regions
    of memory to harvest configuration data. For all low-level we
    use ACPI tables - for interrupts we use exclusively ACPI _PRT
    (so DSDT) and MADT for INT_SRC_OVR.
    
    The SMP MP table is not used at all. As a matter of fact we do
    not even support machines that only have SMP MP but no ACPI tables.
    
    Lets follow how Moorestown does it and just disable searching
    for BIOS SMP tables.
    
    This also fixes an issue on HP Proliant BL680c G5 and DL380 G6:
    
    9f->100 for 1:1 PTE
    Freeing 9f-100 pfn range: 97 pages freed
    1-1 mapping on 9f->100
    .. snip..
    e820: BIOS-provided physical RAM map:
    Xen: [mem 0x0000000000000000-0x000000000009efff] usable
    Xen: [mem 0x000000000009f400-0x00000000000fffff] reserved
    Xen: [mem 0x0000000000100000-0x00000000cfd1dfff] usable
    .. snip..
    Scan for SMP in [mem 0x00000000-0x000003ff]
    Scan for SMP in [mem 0x0009fc00-0x0009ffff]
    Scan for SMP in [mem 0x000f0000-0x000fffff]
    found SMP MP-table at [mem 0x000f4fa0-0x000f4faf] mapped at [ffff8800000f4fa0]
    (XEN) mm.c:908:d0 Error getting mfn 100 (pfn 5555555555555555) from L1 entry 0000000000100461 for l1e_owner=0, pg_owner=0
    (XEN) mm.c:4995:d0 ptwr_emulate: could not get_page_from_l1e()
    BUG: unable to handle kernel NULL pointer dereference at           (null)
    IP: [<ffffffff81ac07e2>] xen_set_pte_init+0x66/0x71
    . snip..
    Pid: 0, comm: swapper Not tainted 3.6.0-rc6upstream-00188-gb6fb969-dirty #2 HP ProLiant BL680c G5
    .. snip..
    Call Trace:
     [<ffffffff81ad31c6>] __early_ioremap+0x18a/0x248
     [<ffffffff81624731>] ? printk+0x48/0x4a
     [<ffffffff81ad32ac>] early_ioremap+0x13/0x15
     [<ffffffff81acc140>] get_mpc_size+0x2f/0x67
     [<ffffffff81acc284>] smp_scan_config+0x10c/0x136
     [<ffffffff81acc2e4>] default_find_smp_config+0x36/0x5a
     [<ffffffff81ac3085>] setup_arch+0x5b3/0xb5b
     [<ffffffff81624731>] ? printk+0x48/0x4a
     [<ffffffff81abca7f>] start_kernel+0x90/0x390
     [<ffffffff81abc356>] x86_64_start_reservations+0x131/0x136
     [<ffffffff81abfa83>] xen_start_kernel+0x65f/0x661
    (XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
    
    which is that ioremap would end up mapping 0xff using _PAGE_IOMAP
    (which is what early_ioremap sticks as a flag) - which meant
    we would get MFN 0xFF (pte ff461, which is OK), and then it would
    also map 0x100 (b/c ioremap tries to get page aligned request, and
    it was trying to map 0xf4fa0 + PAGE_SIZE - so it mapped the next page)
    as _PAGE_IOMAP. Since 0x100 is actually a RAM page, and the _PAGE_IOMAP
    bypasses the P2M lookup we would happily set the PTE to 1000461.
    Xen would deny the request since we do not have access to the
    Machine Frame Number (MFN) of 0x100. The P2M[0x100] is for example
    0x80140.
    
    Fixes-Oracle-Bugzilla: https://bugzilla.oracle.com/bugzilla/show_bug.cgi?id=13665
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 927766ff00c2f45847b77c9732c2e130313e0d0e
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Wed Sep 12 12:44:30 2012 +0100

    xen/m2p: do not reuse kmap_op->dev_bus_addr
    
    commit 2fc136eecd0c647a6b13fcd00d0c41a1a28f35a5 upstream.
    
    If the caller passes a valid kmap_op to m2p_add_override, we use
    kmap_op->dev_bus_addr to store the original mfn, but dev_bus_addr is
    part of the interface with Xen and if we are batching the hypercalls it
    might not have been written by the hypervisor yet. That means that later
    on Xen will write to it and we'll think that the original mfn is
    actually what Xen has written to it.
    
    Rather than "stealing" struct members from kmap_op, keep using
    page->index to store the original mfn and add another parameter to
    m2p_remove_override to get the corresponding kmap_op instead.
    It is now responsibility of the caller to keep track of which kmap_op
    corresponds to a particular page in the m2p_override (gntdev, the only
    user of this interface that passes a valid kmap_op, is already doing that).
    
    Reported-and-Tested-By: Sander Eikelenboom <linux@eikelenboom.it>
    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 8534c2b953b7ac2f54a025c62d3057d67f72a888
Author: qiuxishi <qiuxishi@gmail.com>
Date:   Mon Sep 17 14:09:24 2012 -0700

    memory hotplug: fix section info double registration bug
    
    commit f14851af0ebb32745c6c5a2e400aa0549f9d20df upstream.
    
    There may be a bug when registering section info.  For example, on my
    Itanium platform, the pfn range of node0 includes the other nodes, so
    other nodes' section info will be double registered, and memmap's page
    count will equal to 3.
    
      node0: start_pfn=0x100,    spanned_pfn=0x20fb00, present_pfn=0x7f8a3, => 0x000100-0x20fc00
      node1: start_pfn=0x80000,  spanned_pfn=0x80000,  present_pfn=0x80000, => 0x080000-0x100000
      node2: start_pfn=0x100000, spanned_pfn=0x80000,  present_pfn=0x80000, => 0x100000-0x180000
      node3: start_pfn=0x180000, spanned_pfn=0x80000,  present_pfn=0x80000, => 0x180000-0x200000
    
      free_all_bootmem_node()
    	register_page_bootmem_info_node()
    		register_page_bootmem_info_section()
    
    When hot remove memory, we can't free the memmap's page because
    page_count() is 2 after put_page_bootmem().
    
      sparse_remove_one_section()
    	free_section_usemap()
    		free_map_bootmem()
    			put_page_bootmem()
    
    [akpm@linux-foundation.org: add code comment]
    Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Cc: "Luck, Tony" <tony.luck@intel.com>
    Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39a9f8fe2d179b708c0f46f7a1fbee19b390843c
Author: Jianguo Wu <wujianguo@huawei.com>
Date:   Mon Sep 17 14:08:56 2012 -0700

    mm/ia64: fix a memory block size bug
    
    commit 05cf96398e1b6502f9e191291b715c7463c9d5dd upstream.
    
    I found following definition in include/linux/memory.h, in my IA64
    platform, SECTION_SIZE_BITS is equal to 32, and MIN_MEMORY_BLOCK_SIZE
    will be 0.
    
      #define MIN_MEMORY_BLOCK_SIZE     (1 << SECTION_SIZE_BITS)
    
    Because MIN_MEMORY_BLOCK_SIZE is int type and length of 32bits,
    so MIN_MEMORY_BLOCK_SIZE(1 << 32) will will equal to 0.
    Actually when SECTION_SIZE_BITS >= 31, MIN_MEMORY_BLOCK_SIZE will be wrong.
    This will cause wrong system memory infomation in sysfs.
    I think it should be:
    
      #define MIN_MEMORY_BLOCK_SIZE     (1UL << SECTION_SIZE_BITS)
    
    And "echo offline > memory0/state" will cause following call trace:
    
      kernel BUG at mm/memory_hotplug.c:885!
      sh[6455]: bugcheck! 0 [1]
      Pid: 6455, CPU 0, comm:                   sh
      psr : 0000101008526030 ifs : 8000000000000fa4 ip  : [<a0000001008c40f0>]    Not tainted (3.6.0-rc1)
      ip is at offline_pages+0x210/0xee0
      Call Trace:
        show_stack+0x80/0xa0
        show_regs+0x640/0x920
        die+0x190/0x2c0
        die_if_kernel+0x50/0x80
        ia64_bad_break+0x3d0/0x6e0
        ia64_native_leave_kernel+0x0/0x270
        offline_pages+0x210/0xee0
        alloc_pages_current+0x180/0x2a0
    
    Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Cc: "Luck, Tony" <tony.luck@intel.com>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    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 23cffc536a2f396e1e752527460d545e816ee654
Author: Benoît Locher <Benoit.Locher@skf.com>
Date:   Mon Aug 27 15:02:45 2012 +0200

    can: mcp251x: avoid repeated frame bug
    
    commit cab32f39dcc5b35db96497dc0a026b5dea76e4e7 upstream.
    
    The MCP2515 has a silicon bug causing repeated frame transmission, see section
    5 of MCP2515 Rev. B Silicon Errata Revision G (March 2007).
    
    Basically, setting TXBnCTRL.TXREQ in either SPI mode (00 or 11) will eventually
    cause the bug. The workaround proposed by Microchip is to use mode 00 and send
    a RTS command on the SPI bus to initiate the transmission.
    
    Signed-off-by: Benoît Locher <Benoit.Locher@skf.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3da7f1ade823595e37e37bca09d9d9f24c945e9a
Author: Karsten Keil <keil@b1-systems.de>
Date:   Thu Sep 13 04:36:20 2012 +0000

    mISDN: Fix wrong usage of flush_work_sync while holding locks
    
    commit 4b921eda53366b319602351ff4d7256fafa4bd1b upstream.
    
    It is a bad idea to hold a spinlock and call flush_work_sync.
    Move the workqueue cleanup outside the spinlock and use cancel_work_sync,
    on closing the channel this seems to be the more correct function.
    Remove the never used and constant return value of mISDN_freebchannel.
    
    Signed-off-by: Karsten Keil <keil@b1-systems.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dff9a4f031d1804f41b0f45c53543284b93548df
Author: Alan Cox <alan@linux.intel.com>
Date:   Wed Sep 12 10:05:04 2012 +0000

    gma500: Fix regression on Oaktrail devices
    
    commit 26df641eac05abe1a3276eea441359b4d1120816 upstream.
    
    The register map patches didn't set one value for the GMA600 which
    means the Fujitsu Q550 dies on boot with the GMA500 driver enabled.
    
    Add the map entry so we don't read from the device MMIO + 0 by mistake.
    
    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 900404e5d201d0a6d2806f615b41e939713d55db
Author: Charles Wang <muming.wq@taobao.com>
Date:   Mon Aug 20 16:02:33 2012 +0800

    sched: Add missing call to calc_load_exit_idle()
    
    commit 749c8814f08f12baa4a9c2812a7c6ede7d69507d upstream.
    
    Azat Khuzhin reported high loadavg in Linux v3.6
    
    After checking the upstream scheduler code, I found Peter's commit:
    
      5167e8d5417b sched/nohz: Rewrite and fix load-avg computation -- again
    
    not fully applied, missing the call to calc_load_exit_idle().
    
    After that idle exit in sampling window will always be calculated
    to non-idle, and the load will be higher than normal.
    
    This patch adds the missing call to calc_load_exit_idle().
    
    Signed-off-by: Charles Wang <muming.wq@taobao.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/1345449754-27130-1-git-send-email-muming.wq@gmail.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f1adf647e76af1c5108b12b2e17331f69565d38
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Tue Sep 11 08:22:14 2012 -0700

    hwmon: (ina2xx) Fix word size register read and write operations
    
    commit 080b98e9ab30734bda2f1b8b33cd55a4c4ef406a upstream.
    
    The driver uses be16_to_cpu and cpu_to_be16 to convert data in SMBus word
    operations from chip to host byte order. However, the data passed from and to
    the SMBus word API functions is in host byte order, not in chip byte order.
    Conversion should therefore use swab16 instead of be16 to change the byte order.
    
    Replace driver internal word conversion functions with SMBus API functions to
    solve the problem.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc080eed5c61471ab1204b70bf7efe22c5181087
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Tue Jun 19 08:00:00 2012 -0700

    hwmon: (twl4030-madc-hwmon) Initialize uninitialized structure elements
    
    commit 73d7c119255615a26070f9d6cdb722a166a29015 upstream.
    
    twl4030_madc_conversion uses do_avg and type structure elements of
    twl4030_madc_request. Initialize structure to avoid random operation.
    
    Fix for: Coverity CID 200794 Uninitialized scalar variable.
    
    Cc: Keerthy <j-keerthy@ti.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Jean Delvare <khali@linux-fr.org>
    Acked-by: Keerthy <j-keerthy@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a63a2a60287396a16c43c844913f59e01e9e0ce
Author: Kevin Hilman <khilman@ti.com>
Date:   Mon Sep 17 14:09:17 2012 -0700

    drivers/rtc/rtc-twl.c: ensure all interrupts are disabled during probe
    
    commit 8dcebaa9a0ae8a0487f4342f3d56d2cb1c980860 upstream.
    
    On some platforms, bootloaders are known to do some interesting RTC
    programming.  Without going into the obscurities as to why this may be
    the case, suffice it to say the the driver should not make any
    assumptions about the state of the RTC when the driver loads.  In
    particular, the driver probe should be sure that all interrupts are
    disabled until otherwise programmed.
    
    This was discovered when finding bursty I2C traffic every second on
    Overo platforms.  This I2C overhead was keeping the SoC from hitting
    deep power states.  The cause was found to be the RTC firing every
    second on the I2C-connected TWL PMIC.
    
    Special thanks to Felipe Balbi for suggesting to look for a rogue driver
    as the source of the I2C traffic rather than the I2C driver itself.
    
    Special thanks to Steve Sakoman for helping track down the source of the
    continuous RTC interrups on the Overo boards.
    
    Signed-off-by: Kevin Hilman <khilman@ti.com>
    Cc: Felipe Balbi <balbi@ti.com>
    Tested-by: Steve Sakoman <steve@sakoman.com>
    Cc: Alessandro Zummo <a.zummo@towertech.it>
    Tested-by: Shubhrajyoti Datta <omaplinuxkernel@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69a9b3628594b74d481a4e4f4e96a2b9141d853a
Author: Li Haifeng <omycle@gmail.com>
Date:   Mon Sep 17 14:09:21 2012 -0700

    mm/page_alloc: fix the page address of higher page's buddy calculation
    
    commit 0ba8f2d59304dfe69b59c034de723ad80f7ab9ac upstream.
    
    The heuristic method for buddy has been introduced since commit
    43506fad21ca ("mm/page_alloc.c: simplify calculation of combined index
    of adjacent buddy lists").  But the page address of higher page's buddy
    was wrongly calculated, which will lead page_is_buddy to fail for ever.
    IOW, the heuristic method would be disabled with the wrong page address
    of higher page's buddy.
    
    Calculating the page address of higher page's buddy should be based
    higher_page with the offset between index of higher page and index of
    higher page's buddy.
    
    Signed-off-by: Haifeng Li <omycle@gmail.com>
    Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Cc: KyongHo Cho <pullip.cho@samsung.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Minchan Kim <minchan.kim@gmail.com>
    Cc: Johannes Weiner <jweiner@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab04daac5dbe4fd2d1a3152d2dd850fbd3ab94bb
Author: Dylan Reid <dgreid@chromium.org>
Date:   Sat Sep 1 01:38:19 2012 -0700

    ASoC: samsung dma - Don't indicate support for pause/resume.
    
    commit 57b2d68863f281737d8596cb3d76d89d9cc54fd8 upstream.
    
    The pause and resume operations indicate that the stream can be
    un-paused/resumed from the exact location they were paused/suspended.
    This is not true for this driver, the pause and suspend triggers share
    the same code path with stop, they flush all pending DMA transfers.
    This drops all pending samples.  The pause_release/resume triggers are
    the same as start, except that prepare won't be called beforehand,
    nothing will be enqueued to the DMA engine and nothing will happen (no
    audio).  Removing the pause flag will let apps know that it isn't
    supported.  Removing the resume flag will cause user space to call
    prepare and start instead of resume, so audio will continue playing when
    the system wakes up.
    
    Before removing the pause and resume flags, I tested this on an exynos
    5250, using 'aplay -i'. Pause/un-pause leads to silence followed by a
    write error.  Suspend/resume testing led to the same result.  Removing
    the two flags fixes suspend/resume (since snd_pcm_prepare is called
    again). And leads to a proper reporting of pause not supported.
    
    Signed-off-by: Dylan Reid <dgreid@chromium.org>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea11e00964349c413950b0fe0d45422f92a9dd49
Author: Paul Clements <paul.clements@steeleye.com>
Date:   Mon Sep 17 14:09:02 2012 -0700

    nbd: clear waiting_queue on shutdown
    
    commit fded4e090c60100d709318896c79816d68d5b47d upstream.
    
    Fix a serious but uncommon bug in nbd which occurs when there is heavy
    I/O going to the nbd device while, at the same time, a failure (server,
    network) or manual disconnect of the nbd connection occurs.
    
    There is a small window between the time that the nbd_thread is stopped
    and the socket is shutdown where requests can continue to be queued to
    nbd's internal waiting_queue.  When this happens, those requests are
    never completed or freed.
    
    The fix is to clear the waiting_queue on shutdown of the nbd device, in
    the same way that the nbd request queue (queue_head) is already being
    cleared.
    
    Signed-off-by: Paul Clements <paul.clements@steeleye.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0177d47e166d716789e3fb5b58cfddf451ab8998
Author: NeilBrown <neilb@suse.de>
Date:   Wed Sep 19 12:52:30 2012 +1000

    md/raid5: fix calculate of 'degraded' when a replacement becomes active.
    
    commit e5c86471f933608db5d43679f84cb4346c32033e upstream.
    
    When a replacement device becomes active, we mark the device that it
    replaces as 'faulty' so that it can subsequently get removed.
    However 'calc_degraded' only pays attention to the primary device, not
    the replacement, so the array appears to become degraded, which is
    wrong.
    
    So teach 'calc_degraded' to consider any replacement if a primary
    device is faulty.
    
    This is suitable for -stable as an incorrect 'degraded' value can
    confuse md and could lead to data corruption.
    This is only relevant for 3.3 and later.
    
    Reported-by: Robin Hill <robin@robinhill.me.uk>
    Reported-by: John Drescher <drescherjm@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 71a5d69e4007fd336672f052f98730fa383fe49b
Author: NeilBrown <neilb@suse.de>
Date:   Wed Sep 19 12:54:22 2012 +1000

    md: make sure metadata is updated when spares are activated or removed.
    
    commit 6dafab6b1383e912cd252fa809570b484eb6e0dc upstream.
    
    It isn't always necessary to update the metadata when spares are
    removed as the presence-or-not of a spare isn't really important to
    the integrity of an array.
    Also activating a spare doesn't always require updating the metadata
    as the update on 'recovery-completed' is usually sufficient.
    
    However the introduction of 'replacement' devices have made these
    transitions sometimes more important.  For example the 'Replacement'
    flag isn't cleared until the original device is removed, so we need
    to ensure a metadata update after that 'spare' is removed.
    
    So set MD_CHANGE_DEVS whenever a spare is activated or removed, to
    complement the current situation where it is set when a spare is added
    or a device is failed (or a number of other less common situations).
    
    This is suitable for -stable as out-of-data metadata could lead
    to data corruption.
    This is only relevant for 3.3 and later 9when 'replacement' as
    introduced.
    
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f75a855c75feb7ca747c505c714973741b5c2920
Author: NeilBrown <neilb@suse.de>
Date:   Sat Aug 18 09:51:42 2012 +1000

    md/raid10: fix problem with on-stack allocation of r10bio structure.
    
    commit e0ee778528bbaad28a5c69d2e219269a3a096607 upstream.
    
    A 'struct r10bio' has an array of per-copy information at the end.
    This array is declared with size [0] and r10bio_pool_alloc allocates
    enough extra space to store the per-copy information depending on the
    number of copies needed.
    
    So declaring a 'struct r10bio on the stack isn't going to work.  It
    won't allocate enough space, and memory corruption will ensue.
    
    So in the two places where this is done, declare a sufficiently large
    structure and use that instead.
    
    The two call-sites of this bug were introduced in 3.4 and 3.5
    so this is suitable for both those kernels.  The patch will have to
    be modified for 3.4 as it only has one bug.
    
    Reported-by: Ivan Vasilyev <ivan.vasilyev@gmail.com>
    Tested-by: Ivan Vasilyev <ivan.vasilyev@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ed7a69d881a940185cebab49e22f7d5daa0767f
Author: NeilBrown <neilb@suse.de>
Date:   Thu Aug 16 16:46:12 2012 +1000

    md: Don't truncate size at 4TB for RAID0 and Linear
    
    commit 667a5313ecd7308d79629c0738b0db588b0b0a4e upstream.
    
    commit 27a7b260f71439c40546b43588448faac01adb93
       md: Fix handling for devices from 2TB to 4TB in 0.90 metadata.
    
    changed 0.90 metadata handling to truncated size to 4TB as that is
    all that 0.90 can record.
    However for RAID0 and Linear, 0.90 doesn't need to record the size, so
    this truncation is not needed and causes working arrays to become too small.
    
    So avoid the truncation for RAID0 and Linear
    
    This bug was introduced in 3.1 and is suitable for any stable kernels
    from then onwards.
    As the offending commit was tagged for 'stable', any stable kernel
    that it was applied to should also get this patch.  That includes
    at least 2.6.32, 2.6.33 and 3.0. (Thanks to Ben Hutchings for
    providing that list).
    
    Signed-off-by: Neil Brown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df4d11d1581f21352b2a727c2a62ede4f0aa48b7
Author: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Date:   Wed Sep 12 13:26:55 2012 +0300

    digsig: add hash size comparision on signature verification
    
    commit bc01637a80f5b670bd70a0279d3f93fa8de1c96d upstream.
    
    When pkcs_1_v1_5_decode_emsa() returns without error and hash sizes do
    not match, hash comparision is not done and digsig_verify_rsa() returns
    no error.  This is a bug and this patch fixes it.
    
    The bug was introduced in v3.3 by commit b35e286a640f ("lib/digsig:
    pkcs_1_v1_5_decode_emsa cleanup").
    
    Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99c9bffe490072ec4a1b72bc7ca7c6c7048e2c9b
Author: Mel Gorman <mgorman@suse.de>
Date:   Sun Aug 19 14:41:03 2012 +1200

    Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts
    
    commit 67a806d9499353fabd5b5ff07337f3aa88a1c3ba upstream.
    
    The following build error occurred during an alpha build:
    
      net/core/sock.c:274:36: error: initializer element is not constant
    
    Dave Anglin says:
    > Here is the line in sock.i:
    >
    > struct static_key memalloc_socks = ((struct static_key) { .enabled =
    > ((atomic_t) { (0) }) });
    
    The above line contains two compound literals.  It also uses a designated
    initializer to initialize the field enabled.  A compound literal is not a
    constant expression.
    
    The location of the above statement isn't fully clear, but if a compound
    literal occurs outside the body of a function, the initializer list must
    consist of constant expressions.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Michael Cree <mcree@orcon.net.nz>
    Acked-by: Matt Turner <mattst88@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d822616ca81881d8c19d0b473e79ba241c700de
Author: Markus Trippelsdorf <markus@trippelsdorf.de>
Date:   Sat Aug 18 18:35:51 2012 -0600

    dyndbg: fix for SOH in logging messages
    
    commit ebdc82899ec5ed35af1c79ed6a4eeda69dad9b90 upstream.
    
    commit af7f2158fde was done against master, and clashed with structured
    logging's change of KERN_LEVEL to SOH.
    
    Bisected and fixed by Markus Trippelsdorf.
    
    Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
    Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Jason Baron <jbaron@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff525db26bb2ec9a78ab50f9ef943e13e95f90b2
Author: Bjørn Mork <bjorn@mork.no>
Date:   Sun Sep 2 15:41:34 2012 +0200

    kobject: fix oops with "input0: bad kobj_uevent_env content in show_uevent()"
    
    commit 60e233a56609fd963c59e99bd75c663d63fa91b6 upstream.
    
    Fengguang Wu <fengguang.wu@intel.com> writes:
    
    > After the __devinit* removal series, I can still get kernel panic in
    > show_uevent(). So there are more sources of bug..
    >
    > Debug patch:
    >
    > @@ -343,8 +343,11 @@ static ssize_t show_uevent(struct device
    >                 goto out;
    >
    >         /* copy keys to file */
    > -       for (i = 0; i < env->envp_idx; i++)
    > +       dev_err(dev, "uevent %d env[%d]: %s/.../%s\n", env->buflen, env->envp_idx, top_kobj->name, dev->kobj.name);
    > +       for (i = 0; i < env->envp_idx; i++) {
    > +               printk(KERN_ERR "uevent %d env[%d]: %s\n", (int)count, i, env->envp[i]);
    >                 count += sprintf(&buf[count], "%s\n", env->envp[i]);
    > +       }
    >
    > Oops message, the env[] is again not properly initilized:
    >
    > [   44.068623] input input0: uevent 61 env[805306368]: input0/.../input0
    > [   44.069552] uevent 0 env[0]: (null)
    
    This is a completely different CONFIG_HOTPLUG problem, only
    demonstrating another reason why CONFIG_HOTPLUG should go away.  I had a
    hard time trying to disable it anyway ;-)
    
    The problem this time is lots of code assuming that a call to
    add_uevent_var() will guarantee that env->buflen > 0.  This is not true
    if CONFIG_HOTPLUG is unset.  So things like this end up overwriting
    env->envp_idx because the array index is -1:
    
    	if (add_uevent_var(env, "MODALIAS="))
    		return -ENOMEM;
            len = input_print_modalias(&env->buf[env->buflen - 1],
    				   sizeof(env->buf) - env->buflen,
    				   dev, 0);
    
    Don't know what the best action is, given that there seem to be a *lot*
    of this around the kernel.  This patch "fixes" the problem for me, but I
    don't know if it can be considered an appropriate fix.
    
    [ It is the correct fix for now, for 3.7 forcing CONFIG_HOTPLUG to
    always be on is the longterm fix, but it's too late for 3.6 and older
    kernels to resolve this that way - gregkh ]
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Tested-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0143215fec6628fbc3045f5b179fad44838c5988
Author: Alan Cox <alan@linux.intel.com>
Date:   Tue Sep 4 16:07:18 2012 +0100

    ahci: Add alternate identifier for the 88SE9172
    
    commit 17c60c6b763cb5b83b0185e7d38d01d18e55a05a upstream.
    
    This can also appear as 0x9192. Reported in bugzilla and confirmed with the
    board documentation for these boards.
    
    Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42970
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3d2a5eb91f00d4d16ccc1871a7e1dbf759e54bd
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Fri Jul 20 20:34:25 2012 +0200

    usb: gadget: at91udc: Don't check for ep->ep.desc
    
    commit f3bb8e63a8ee0398dffe412e774d8801db7e1bf1 upstream.
    
    Earlier we used to check for ep->ep.desc to figure out if this ep has
    already been enabled and if so, abort.
    Ido Shayevitz removed the usb_endpoint_descriptor from private udc
    structure 5a6506f00 ("usb: gadget: Update at91_udc to use
    usb_endpoint_descriptor	inside the struct usb_ep") but did not fix up
    the ep_enable condition because _now_ the member is always true and we
    can't check if this ep is enabled twice.
    
    Cc: Ido Shayevitz <idos@codeaurora.org>
    Tested-by: Fabio Porcedda <fabio.porcedda@gmail.com>
    Tested-by: Mario Isidoro <Mario.Isidoro@tecmic.pt>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdee0b397af9199d78bbbb1d3d3fd20140b8777e
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Fri Jul 20 20:34:24 2012 +0200

    usb: gadget: at91udc: don't overwrite driver data
    
    commit 8b7dda554cf61e87523dee412eaf598f8646bd79 upstream.
    
    The driver was converted to the new start/stop interface in f3d8bf34c2
    ("usb: gadget: at91_udc: convert to new style start/stop interface").
    I overlooked that the driver is overwritting the private data which is
    used by the composite framework. The udc driver doesn't read it, it is
    only written here.
    
    Tested-by: Fabio Porcedda <fabio.porcedda@gmail.com>
    Tested-by: Mario Isidoro <Mario.Isidoro@tecmic.pt>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fd97e46e63c94bb532922850f381ced90c77e71
Author: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Date:   Sun Aug 19 21:54:59 2012 +0200

    usb: gadget: dummy_hcd: add support for USB_DT_BOS on rh
    
    commit 3b9c1c5ba7a95caae8440ea47308496b14f7301a upstream.
    
    Without a reply for USB_DT_BOS the USB3 mode does not work since
    448b6eb1 ("USB: Make sure to fetch the BOS desc for roothubs.).
    
    Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5da200019dab1a1763f8361fdfd94389bf7f37a
Author: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Date:   Sun Aug 19 21:54:58 2012 +0200

    usb: gadget: dummy_hcd: fixup error probe path
    
    commit 1b68a4ca2d038addb7314211d122fb6d7002b38b upstream.
    
    If USB2 host controller probes fine but USB3 does not then we don't
    remove the USB controller properly and lock up the system while the HUB
    code will try to enumerate the USB2 controller and access memory which
    is no longer available in case the dummy_hcd was compiled as a module.
    
    This is a problem since 448b6eb1 ("USB: Make sure to fetch the BOS desc
    for roothubs.) if used in USB3 mode because dummy does not provide this
    descriptor and explodes later.
    
    Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed60c28a0c7861e2c5df2a985c11f757564b66a9
Author: Michael Grzeschik <m.grzeschik@pengutronix.de>
Date:   Wed Sep 12 14:58:01 2012 +0300

    usb: chipidea: udc: add pullup fuction, needed by the uvc gadget
    
    commit c0a48e6c75f2ac190d812bea5fc339696e434c2e upstream.
    
    Add function to physicaly enable or disable of pullup connection on the USB-D+
    line. The uvc gaget will fail, if this function is not implemented.
    
    Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
    Acked-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 032fe3671c1efa8218ea28f145b62c16ad720960
Author: Robert Richter <robert.richter@amd.com>
Date:   Thu Jul 19 18:28:26 2012 +0200

    oprofile, s390: Fix uninitialized memory access when writing to oprofilefs
    
    commit 81ff3478d9ba7f0b48b0abef740e542fd83adf79 upstream.
    
    If oprofilefs_ulong_from_user() is called with count equals zero, *val
    remains unchanged. Depending on the implementation it might be
    uninitialized. Fixing users of oprofilefs_ulong_ from_user().
    
    We missed these s390 changes with:
    
     913050b oprofile: Fix uninitialized memory access when writing to writing to oprofilefs
    
    Signed-off-by: Robert Richter <robert.richter@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3b569c5ff1573af7db3ea362e67e5d24ac97344
Author: Ian Chen <ian.cy.chen@samsung.com>
Date:   Wed Aug 29 15:05:36 2012 +0900

    mmc: card: Skip secure erase on MoviNAND; causes unrecoverable corruption.
    
    commit 3550ccdb9d8d350e526b809bf3dd92b550a74fe1 upstream.
    
    For several MoviNAND eMMC parts, there are known issues with secure
    erase and secure trim.  For these specific MoviNAND devices, we skip
    these operations.
    
    Specifically, there is a bug in the eMMC firmware that causes
    unrecoverable corruption when the MMC is erased with MMC_CAP_ERASE
    enabled.
    
    References:
    
    http://forum.xda-developers.com/showthread.php?t=1644364
    https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkB
    
    Signed-off-by: Ian Chen <ian.cy.chen@samsung.com>
    Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
    Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 30545f24d99ae348670402ccc193381f7e591857
Author: Ludovic Desroches <ludovic.desroches@atmel.com>
Date:   Tue Jul 24 11:42:04 2012 +0200

    mmc: atmel-mci: not busy flag has also to be used for read operations
    
    commit 077d40731edc90ee9dedf63249034c8cd5f694ce upstream.
    
    Even if the datasheet says that the not busy flag has to be used only
    for write operations, it's false except for version lesser than v2xx.
    
    Not waiting on the not busy flag for read operations can cause the
    controller to hang-up during the initialization of some SD cards
    with DMA after the first CMD6 -- the next command is sent too early.
    
    Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a9422ec45b63e7d6703b5b668a750039956ba09
Author: Shawn Guo <shawn.guo@linaro.org>
Date:   Wed Aug 22 23:10:01 2012 +0800

    mmc: sdhci-esdhc: break out early if clock is 0
    
    commit 74f330bceaa7b88d06062e1cac3d519a3dfc041e upstream.
    
    Since commit 30832ab56 ("mmc: sdhci: Always pass clock request value
    zero to set_clock host op") was merged, esdhc_set_clock starts hitting
    "if (clock == 0)" where ESDHC_SYSTEM_CONTROL has been operated.  This
    causes SDHCI card-detection function being broken.  Fix the regression
    by moving "if (clock == 0)" above ESDHC_SYSTEM_CONTROL operation.
    
    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3dd2bf1c4b2f5feed0486d706f6020ce78ffb93c
Author: Lauri Hintsala <lauri.hintsala@bluegiga.com>
Date:   Tue Jul 17 17:16:10 2012 +0300

    mmc: mxs-mmc: fix deadlock caused by recursion loop
    
    commit fc108d24d3a6da63576a460e122fa1df0cbdea20 upstream.
    
    Release the lock before mmc_signal_sdio_irq is called by
    mxs_mmc_enable_sdio_irq.
    
    Backtrace:
    [   65.470000] =============================================
    [   65.470000] [ INFO: possible recursive locking detected ]
    [   65.470000] 3.5.0-rc5 #2 Not tainted
    [   65.470000] ---------------------------------------------
    [   65.470000] ksdioirqd/mmc0/73 is trying to acquire lock:
    [   65.470000]  (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]
    [   65.470000]
    [   65.470000] but task is already holding lock:
    [   65.470000]  (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]
    [   65.470000]
    [   65.470000] other info that might help us debug this:
    [   65.470000]  Possible unsafe locking scenario:
    [   65.470000]
    [   65.470000]        CPU0
    [   65.470000]        ----
    [   65.470000]   lock(&(&host->lock)->rlock#2);
    [   65.470000]   lock(&(&host->lock)->rlock#2);
    [   65.470000]
    [   65.470000]  *** DEADLOCK ***
    [   65.470000]
    [   65.470000]  May be due to missing lock nesting notation
    [   65.470000]
    [   65.470000] 1 lock held by ksdioirqd/mmc0/73:
    [   65.470000]  #0:  (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]
    [   65.470000]
    [   65.470000] stack backtrace:
    [   65.470000] [<c0014990>] (unwind_backtrace+0x0/0xf4) from [<c005ccb8>] (__lock_acquire+0x14f8/0x1b98)
    [   65.470000] [<c005ccb8>] (__lock_acquire+0x14f8/0x1b98) from [<c005d3f8>] (lock_acquire+0xa0/0x108)
    [   65.470000] [<c005d3f8>] (lock_acquire+0xa0/0x108) from [<c02f671c>] (_raw_spin_lock_irqsave+0x48/0x5c)
    [   65.470000] [<c02f671c>] (_raw_spin_lock_irqsave+0x48/0x5c) from [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc])
    [   65.470000] [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) from [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc])
    [   65.470000] [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) from [<c0219b38>] (sdio_irq_thread+0x1bc/0x274)
    [   65.470000] [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) from [<c003c324>] (kthread+0x8c/0x98)
    [   65.470000] [<c003c324>] (kthread+0x8c/0x98) from [<c00101ac>] (kernel_thread_exit+0x0/0x8)
    [   65.470000] BUG: spinlock lockup suspected on CPU#0, ksdioirqd/mmc0/73
    [   65.470000]  lock: 0xc3358724, .magic: dead4ead, .owner: ksdioirqd/mmc0/73, .owner_cpu: 0
    [   65.470000] [<c0014990>] (unwind_backtrace+0x0/0xf4) from [<c01b46b0>] (do_raw_spin_lock+0x100/0x144)
    [   65.470000] [<c01b46b0>] (do_raw_spin_lock+0x100/0x144) from [<c02f6724>] (_raw_spin_lock_irqsave+0x50/0x5c)
    [   65.470000] [<c02f6724>] (_raw_spin_lock_irqsave+0x50/0x5c) from [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc])
    [   65.470000] [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) from [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc])
    [   65.470000] [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) from [<c0219b38>] (sdio_irq_thread+0x1bc/0x274)
    [   65.470000] [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) from [<c003c324>] (kthread+0x8c/0x98)
    [   65.470000] [<c003c324>] (kthread+0x8c/0x98) from [<c00101ac>] (kernel_thread_exit+0x0/0x8)
    
    Reported-by: Attila Kinali <attila@kinali.ch>
    Signed-off-by: Lauri Hintsala <lauri.hintsala@bluegiga.com>
    Acked-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f58f96c17afa66e4f67b3711c0d28ba30d97edbd
Author: Lauri Hintsala <lauri.hintsala@bluegiga.com>
Date:   Tue Jul 17 17:16:09 2012 +0300

    mmc: mxs-mmc: fix deadlock in SDIO IRQ case
    
    commit 1af36b2a993dddfa3d6860ec4879c9e8abc9b976 upstream.
    
    Release the lock before mmc_signal_sdio_irq is called by mxs_mmc_irq_handler.
    
    Backtrace:
    [   79.660000] =============================================
    [   79.660000] [ INFO: possible recursive locking detected ]
    [   79.660000] 3.4.0-00009-g3e96082-dirty #11 Not tainted
    [   79.660000] ---------------------------------------------
    [   79.660000] swapper/0 is trying to acquire lock:
    [   79.660000]  (&(&host->lock)->rlock#2){-.....}, at: [<c026ea3c>] mxs_mmc_enable_sdio_irq+0x18/0xd4
    [   79.660000]
    [   79.660000] but task is already holding lock:
    [   79.660000]  (&(&host->lock)->rlock#2){-.....}, at: [<c026f744>] mxs_mmc_irq_handler+0x1c/0xe8
    [   79.660000]
    [   79.660000] other info that might help us debug this:
    [   79.660000]  Possible unsafe locking scenario:
    [   79.660000]
    [   79.660000]        CPU0
    [   79.660000]        ----
    [   79.660000]   lock(&(&host->lock)->rlock#2);
    [   79.660000]   lock(&(&host->lock)->rlock#2);
    [   79.660000]
    [   79.660000]  *** DEADLOCK ***
    [   79.660000]
    [   79.660000]  May be due to missing lock nesting notation
    [   79.660000]
    [   79.660000] 1 lock held by swapper/0:
    [   79.660000]  #0:  (&(&host->lock)->rlock#2){-.....}, at: [<c026f744>] mxs_mmc_irq_handler+0x1c/0xe8
    [   79.660000]
    [   79.660000] stack backtrace:
    [   79.660000] [<c0014bd0>] (unwind_backtrace+0x0/0xf4) from [<c005f9c0>] (__lock_acquire+0x1948/0x1d48)
    [   79.660000] [<c005f9c0>] (__lock_acquire+0x1948/0x1d48) from [<c005fea0>] (lock_acquire+0xe0/0xf8)
    [   79.660000] [<c005fea0>] (lock_acquire+0xe0/0xf8) from [<c03a8460>] (_raw_spin_lock_irqsave+0x44/0x58)
    [   79.660000] [<c03a8460>] (_raw_spin_lock_irqsave+0x44/0x58) from [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4)
    [   79.660000] [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) from [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8)
    [   79.660000] [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) from [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254)
    [   79.660000] [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) from [<c006bff8>] (handle_irq_event+0x3c/0x5c)
    [   79.660000] [<c006bff8>] (handle_irq_event+0x3c/0x5c) from [<c006e6d0>] (handle_level_irq+0x90/0x110)
    [   79.660000] [<c006e6d0>] (handle_level_irq+0x90/0x110) from [<c006b930>] (generic_handle_irq+0x38/0x50)
    [   79.660000] [<c006b930>] (generic_handle_irq+0x38/0x50) from [<c00102fc>] (handle_IRQ+0x30/0x84)
    [   79.660000] [<c00102fc>] (handle_IRQ+0x30/0x84) from [<c000f058>] (__irq_svc+0x38/0x60)
    [   79.660000] [<c000f058>] (__irq_svc+0x38/0x60) from [<c0010520>] (default_idle+0x2c/0x40)
    [   79.660000] [<c0010520>] (default_idle+0x2c/0x40) from [<c0010a90>] (cpu_idle+0x64/0xcc)
    [   79.660000] [<c0010a90>] (cpu_idle+0x64/0xcc) from [<c04ff858>] (start_kernel+0x244/0x2c8)
    [   79.660000] BUG: spinlock lockup on CPU#0, swapper/0
    [   79.660000]  lock: c398cb2c, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0
    [   79.660000] [<c0014bd0>] (unwind_backtrace+0x0/0xf4) from [<c01ddb1c>] (do_raw_spin_lock+0xf0/0x144)
    [   79.660000] [<c01ddb1c>] (do_raw_spin_lock+0xf0/0x144) from [<c03a8468>] (_raw_spin_lock_irqsave+0x4c/0x58)
    [   79.660000] [<c03a8468>] (_raw_spin_lock_irqsave+0x4c/0x58) from [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4)
    [   79.660000] [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) from [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8)
    [   79.660000] [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) from [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254)
    [   79.660000] [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) from [<c006bff8>] (handle_irq_event+0x3c/0x5c)
    [   79.660000] [<c006bff8>] (handle_irq_event+0x3c/0x5c) from [<c006e6d0>] (handle_level_irq+0x90/0x110)
    [   79.660000] [<c006e6d0>] (handle_level_irq+0x90/0x110) from [<c006b930>] (generic_handle_irq+0x38/0x50)
    [   79.660000] [<c006b930>] (generic_handle_irq+0x38/0x50) from [<c00102fc>] (handle_IRQ+0x30/0x84)
    [   79.660000] [<c00102fc>] (handle_IRQ+0x30/0x84) from [<c000f058>] (__irq_svc+0x38/0x60)
    [   79.660000] [<c000f058>] (__irq_svc+0x38/0x60) from [<c0010520>] (default_idle+0x2c/0x40)
    [   79.660000] [<c0010520>] (default_idle+0x2c/0x40) from [<c0010a90>] (cpu_idle+0x64/0xcc)
    [   79.660000] [<c0010a90>] (cpu_idle+0x64/0xcc) from [<c04ff858>] (start_kernel+0x244/0x2c8)
    
    Signed-off-by: Lauri Hintsala <lauri.hintsala@bluegiga.com>
    Acked-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b681c4bcca83cf7b580896907deefbbc4de1f368
Author: Aaron Lu <aaron.lu@intel.com>
Date:   Fri Sep 14 20:54:44 2012 +0200

    ACPI / PM: Use KERN_DEBUG when no power resources are found
    
    commit f25b70613c048ceb1df052576fda03321ebf41cf upstream.
    
    commit a606dac368eed5696fb38e16b1394f1d049c09e9 adds support to link
    devices which have _PRx, if a device does not have _PRx, a warning
    message will be printed.
    
    This commit is for ZPODD on Intel ZPODD capable platforms, on other
    platforms, it has no problem if there is no power resource for this
    device, so a warning here is not appropriate, change it to debug.
    
    Reported-by: Borislav Petkov <bp@amd64.org>
    Signed-off-by: Aaron Lu <aaron.lu@intel.com>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af01caedb95f2503ee5778f17d315240743f2921
Author: Lin Ming <ming.m.lin@intel.com>
Date:   Fri Sep 14 00:26:33 2012 +0200

    ACPI / PM: Fix resource_lock dead lock in acpi_power_on_device
    
    commit 40bf66ec9791f1452b90b82aadc3b6e6aee201f5 upstream.
    
    Commit 0090def("ACPI: Add interface to register/unregister device
    to/from power resources") used resource_lock to protect the devices list
    that relies on power resource. It caused a mutex dead lock, as below
    
        acpi_power_on ---> lock resource_lock
          __acpi_power_on
            acpi_power_on_device
              acpi_power_get_inferred_state
                acpi_power_get_list_state ---> lock resource_lock
    
    This patch adds a new mutex "devices_lock" to protect the devices list
    and calls acpi_power_on_device in acpi_power_on, instead of
    __acpi_power_on, after the resource_lock is released.
    
    [rjw: Changed data type of a boolean variable to bool.]
    
    Signed-off-by: Lin Ming <ming.m.lin@intel.com>
    Signed-off-by: Aaron Lu <aaron.lu@intel.com>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0926f480e6a22c9705c762134efcc30ea0d05c2a
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Fri Sep 14 00:26:24 2012 +0200

    ACPI / PM: Infer parent power state from child if unknown, v2
    
    commit 8f7412a792bc989d1bddd3c802282eec09456d57 upstream.
    
    It turns out that there are ACPI BIOSes defining device objects with
    _PSx and without either _PSC or _PRx.  For devices corresponding to
    those ACPI objetcs __acpi_bus_get_power() returns ACPI_STATE_UNKNOWN
    and their initial power states are regarded as unknown as a result.
    If such a device is a parent of another power-manageable device, the
    child cannot be put into a low-power state through ACPI, because
    __acpi_bus_set_power() refuses to change power states of devices
    whose parents' power states are unknown.
    
    To work around this problem, observe that the ACPI power state of
    a device cannot be higher-power (lower-number) than the power state
    of its parent.  Thus, if the device's _PSC method or the
    configuration of its power resources indicates that the device is
    in D0, the device's parent has to be in D0 as well.  Consequently,
    if the parent's power state is unknown when we've just learned that
    its child's power state is D0, we can safely set the parent's
    power.state field to ACPI_STATE_D0.
    
    Tested-by: Aaron Lu <aaron.lu@intel.com>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19f8467b6bfdb13b3c235a0ebab98cc5a342a066
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date:   Mon Aug 20 14:59:25 2012 +0100

    perf_event: Switch to internal refcount, fix race with close()
    
    commit a6fa941d94b411bbd2b6421ffbde6db3c93e65ab upstream.
    
    Don't mess with file refcounts (or keep a reference to file, for
    that matter) in perf_event.  Use explicit refcount of its own
    instead.  Deal with the race between the final reference to event
    going away and new children getting created for it by use of
    atomic_long_inc_not_zero() in inherit_event(); just have the
    latter free what it had allocated and return NULL, that works
    out just fine (children of siblings of something doomed are
    created as singletons, same as if the child of leader had been
    created and immediately killed).
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/20120820135925.GG23464@ZenIV.linux.org.uk
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc2878098a0b35fd463fa86283265ac73dca5738
Author: Stephen Warren <swarren@nvidia.com>
Date:   Fri Aug 24 21:20:15 2012 -0600

    sound: tegra_alc5632: remove HP detect GPIO inversion
    
    commit c921928661eda599d73a6a86e58bdd5aecfa18cb upstream.
    
    Both the schematics and practical testing show that the HP detect GPIO
    is high when the headphones are plugged in. Hence, the snd_soc_jack_gpio
    should not specify to invert the signal.
    
    Signed-off-by: Stephen Warren <swarren@nvidia.com>
    Acked-by: Andrey Danin <danindrey@mail.ru>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 546e54d4776683c34a1d52ee6ebbbfa7d9aa63c3
Author: Francesco Ruggeri <fruggeri@aristanetworks.com>
Date:   Thu Sep 13 15:03:37 2012 -0700

    fs/proc: fix potential unregister_sysctl_table hang
    
    commit 6bf6104573482570f7103d3e5ddf9574db43a363 upstream.
    
    The unregister_sysctl_table() function hangs if all references to its
    ctl_table_header structure are not dropped.
    
    This can happen sometimes because of a leak in proc_sys_lookup():
    proc_sys_lookup() gets a reference to the table via lookup_entry(), but
    it does not release it when a subsequent call to sysctl_follow_link()
    fails.
    
    This patch fixes this leak by making sure the reference is always
    dropped on return.
    
    See also commit 076c3eed2c31 ("sysctl: Rewrite proc_sys_lookup
    introducing find_entry and lookup_entry") which reorganized this code in
    3.4.
    
    Tested in Linux 3.4.4.
    
    Signed-off-by: Francesco Ruggeri <fruggeri@aristanetworks.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 038f1e830f681524b724d1a10bf1909c5f55606b
Author: Bjørn Mork <bjorn@mork.no>
Date:   Tue Sep 11 09:40:31 2012 +0200

    USB: option: replace ZTE K5006-Z entry with vendor class rule
    
    commit ba9edaa468869a8cea242a411066b0f490751798 upstream.
    
    Fix the ZTE K5006-Z entry so that it actually matches anything
    
      commit f1b5c997 USB: option: add ZTE K5006-Z
    
    added a device specific entry assuming that the device would use
    class/subclass/proto == ff/ff/ff like other ZTE devices. It
    turns out that ZTE has started using vendor specific subclass
    and protocol codes:
    
    T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=19d2 ProdID=1018 Rev= 0.00
    S:  Manufacturer=ZTE,Incorporated
    S:  Product=ZTE LTE Technologies MSM
    S:  SerialNumber=MF821Vxxxxxxx
    C:* #Ifs= 5 Cfg#= 1 Atr=c0 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=86 Prot=10 Driver=(none)
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=05 Driver=(none)
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=(none)
    E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=00 Driver=qmi_wwan
    E:  Ad=85(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    We do not have any information on how ZTE intend to use these
    codes, but let us assume for now that the 3 sets matching
    serial functions in the K5006-Z always will identify a serial
    function in a ZTE device.
    
    Cc: Thomas Schäfer <tschaefer@t-online.de>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a559090fc00d465b8e96e839da61fd3e05b27bcf
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Fri Aug 31 20:41:29 2012 +0100

    staging: comedi: das08: Correct AI encoding for das08jr-16-ao
    
    commit e6391a182865efc896cb2a8d79e07b7ac2f45b48 upstream.
    
    The element of `das08_boards[]` for the 'das08jr-16-ao' board has the
    `ai_encoding` member set to `das08_encode12`.  It should be set to
    `das08_encode16` same as the 'das08jr/16' board.  After all, this board
    has 16-bit AI resolution.
    
    The description of the A/D LSB register at offset 0 seems incorrect in
    the user manual "cio-das08jr-16-ao.pdf" as it implies that the AI
    resolution is only 12 bits.  The diagrams of the A/D LSB and MSB
    registers show 15 data bits and a sign bit, which matches what the
    software expects for the `das08_encode16` AI encoding method.
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3dfef38737262a1d46231f19b4a9be235a20d2f
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Fri Aug 31 20:41:30 2012 +0100

    staging: comedi: das08: Correct AO output for das08jr-16-ao
    
    commit 61ed59ed09e6ad2b8395178ea5ad5f653bba08e3 upstream.
    
    Don't zero out bits 15..12 of the data value in `das08jr_ao_winsn()` as
    that knobbles the upper three-quarters of the output range for the
    'das08jr-16-ao' board.
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a272a3cbd65bd8bd3b5ced8fe14840269252062
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Mon Sep 3 16:39:38 2012 +0100

    staging: comedi: amplc_pci224: Fix PCI ref count
    
    commit cadf84bfeb80e216fde328d357fe856160157d2c upstream.
    
    When attaching a PCI device manually via the comedi driver `attach` hook
    (`pci224_attach()`) (called by the comedi core for the
    `COMEDI_DEVCONFIG` ioctl), its reference count is incremented in the
    `for_each_pci_dev` loop (in `pci224_find_pci_dev()`).  It is decremented
    when the `detach` hook (`pci224_detach()`) is called to detach the
    device.  However, when the PCI device is attached automatically via the
    `attach_pci` hook (`pci224_attach_pci()`, called at probe time via
    `comedi_pci_auto_config()`) it's reference count is not incremented so
    there will be an unmatched decrement when detaching the device.
    
    Increment the PCI device reference count in `pci224_attach_pci()` to
    correct the mismatch.
    
    Once support for manual configuration has been removed from this driver,
    the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d1405acad9e459eeb11644a752660accab5946d
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Sep 10 21:22:11 2012 +0200

    staging: r8712u: fix bug in r8712_recv_indicatepkt()
    
    commit abf02cfc179bb4bd30d05f582d61b3b8f429b813 upstream.
    
    64bit arches have a buggy r8712u driver, let's fix it.
    
    skb->tail must be set properly or network stack behavior is undefined.
    
    Addresses https://bugzilla.redhat.com/show_bug.cgi?id=847525
    Addresses https://bugzilla.kernel.org/show_bug.cgi?id=45071
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Dave Jones <davej@redhat.com>
    Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc6f2e80304f2d520fd2f6d57b643f1e4f077be9
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Wed Aug 29 23:08:21 2012 +0100

    staging: vt6656: [BUG] - Failed connection, incorrect endian.
    
    commit aa209eef3ce8419ff2926c2fa944dfbfb5afbacb upstream.
    
    Hi,
    
    This patch fixes a bug with driver failing to negotiate a connection.
    
    The bug was traced to commit
    203e4615ee9d9fa8d3506b9d0ef30095e4d5bc90
    staging: vt6656: removed custom definitions of Ethernet packet types
    
    In that patch, definitions in include/linux/if_ether.h replaced ones
    in tether.h which had both big and little endian definitions.
    
    include/linux/if_ether.h only refers to big endian values, cpu_to_be16
    should be used for the correct endian architectures.
    
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b1ad160f6932d0934fcab5b34bd51620b3fe23f
Author: Seth Jennings <sjenning@linux.vnet.ibm.com>
Date:   Wed Aug 29 16:58:45 2012 -0500

    staging: zcache: fix cleancache race condition with shrinker
    
    commit 6d7d9798ad5c97ee4e911dd070dc12dc5ae55bd0 upstream.
    
    This patch fixes a race condition that results in memory
    corruption when using cleancache.
    
    The race exists between the zcache shrinker handler,
    shrink_zcache_memory() and cleancache_get_page().
    
    In most cases, the shrinker will both evict a zbpg
    from its buddy list and flush it from tmem before a
    cleancache_get_page() occurs on that page. A subsequent
    cleancache_get_page() will fail in the tmem layer.
    
    In the rare case that two occur together and the
    cleancache_get_page() path gets through the tmem
    layer before the shrinker path can flush tmem,
    zbud_decompress() does a check to see if the zbpg is a
    "zombie", i.e. not on a buddy list, which means the shrinker
    is in the process of reclaiming it. If the zbpg is a zombie,
    zbud_decompress() returns -EINVAL.
    
    However, this return code is being ignored by the caller,
    zcache_pampd_get_data_and_free(), which results in the
    caller of cleancache_get_page() thinking that the page has
    been properly retrieved when it has not.
    
    This patch modifies zcache_pampd_get_data_and_free() to
    convey the failure up the stack so that the caller of
    cleancache_get_page() knows the page retrieval failed.
    
    This needs to be applied to stable trees as well.
    zcache-main.c was named zcache.c before v3.1, so
    I'm not sure how you want to handle trees earlier
    than that.
    
    Signed-off-by: Seth Jennings <sjenning@linux.vnet.ibm.com>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Reviewed-by: Minchan Kim <minchan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit def222114749513b41e047851a98bffdf6dfd2e2
Author: Christopher Brannon <chris@the-brannons.com>
Date:   Sat Jun 16 16:55:20 2012 -0500

    Staging: speakup: fix an improperly-declared variable.
    
    commit 4ea418b8b2fa8a70d0fcc8231b65e67b3a72984b upstream.
    
    A local static variable was declared as a pointer to a string
    constant.  We're assigning to the underlying memory, so it
    needs to be an array instead.
    
    Signed-off-by: Christopher Brannon <chris@the-brannons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd7e78f57986f831eb0530e6c191eef9982781c3
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Sep 20 07:44:11 2012 +0200

    ALSA: hda - Workaround for silent output on VAIO Z with ALC889
    
    commit e427c2375646789ecd0ccaef1a1e41458559ab2d upstream.
    
    On recent kernels, Realtek codec parser tries to optimize the routing
    aggressively and take the headphone output as primary at first.  This
    caused a regression on VAIO Z with ALC889, the silent output from the
    speaker.
    
    The problem seems that the speaker pin must be connected to the first
    DAC (0x02) on this machine by some reason although the codec itself
    advertises the flexible routing with any DACs.
    
    This patch adds a fix-up for choosing the speaker pin as the primary
    so that the right DAC is assigned on this device.
    
    Reported-and-tested-by: Adam Williamson <awilliam@redhat.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b536d48a7ac408ed9c448e524ad6de22dd1b466
Author: Matteo Frigo <athena@fftw.org>
Date:   Wed Sep 12 10:12:06 2012 -0400

    ALSA: ice1724: Use linear scale for AK4396 volume control.
    
    commit 3737e2be505d872bf2b3c1cd4151b2d2b413d7b5 upstream.
    
    The AK4396 DAC has a linear-scale attentuator, but
    sound/pci/ice1712/prodigy_hifi.c used a log scale instead, which is
    not quite right.  This patch restores the correct scale, borrowing
    from the ak4396 code in sound/pci/oxygen/oxygen.c.
    
    Signed-off-by: Matteo Frigo <athena@fftw.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31b03dea1f35abfc97d0a005b6652344d2a856c5
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Sep 10 09:39:31 2012 +0200

    ALSA: hda - Fix Oops at codec reset/reconfig
    
    commit 07dc59f0988cb54fd87bd373b3b27eb2401dd811 upstream.
    
    snd_hda_codec_reset() calls restore_pincfgs() where the codec is
    powered up again, which eventually tries to resume and initialize via
    the callbacks of the codec.  However, it's the place just after codec
    free callback, thus no codec callbacks should be called after that.
    On a codec like CS4206, it results in Oops due to the access in init
    callback.
    
    This patch fixes the issue by clearing the codec callbacks properly
    after freeing codec.
    
    Reported-by: Daniel J Blueman <daniel@quora.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea026e7f8bde9b0906137b06a70b22d706d3c0c5
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Sep 6 14:58:00 2012 +0200

    ALSA: usb-audio: Fix bogus error messages for delay accounting
    
    commit 1213a205f9ed27d97de3d5bed28fb085ef4853e2 upstream.
    
    The recent fix for the missing fine delayed time adjustment gives
    strange error messages at each start of the playback stream, such as
      delay: estimated 0, actual 352
      delay: estimated 353, actual 705
    
    These come from the sanity check in retire_playback_urb().  Before the
    stream is activated via start_endpoints(), a few silent packets have
    been already sent.  And at this point the delay account is still in
    the state as if the new packets are just queued, so the driver gets
    confused and spews the bogus error messages.
    
    For fixing the issue, we just need to check whether the received
    packet is valid, whether it's zero sized or not.
    
    Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffe018be7b6f3b423654d64980b1b1119bfc3fda
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Sep 6 10:10:11 2012 +0200

    ALSA: hda - Fix missing Master volume for STAC9200/925x
    
    commit ab548d2dba63ba947287965e525cc02a15d9853d upstream.
    
    With the commit [2faa3bf: ALSA: hda - Rewrite the mute-LED hook with
    vmaster hook in patch_sigmatel.c], the former Master volume control
    was converted to PCM.  This was supposed to be covered by the vmaster
    control.  But due to the lack of "PCM" slave definition, this didn't
    happen properly.  The patch fixes the missing entry.
    
    Reported-by: Andrew Shadura <bugzilla@tut.by>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3278d2dabeb899922faf4069861e150f72f28bc1
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Sat Aug 25 09:03:15 2012 +0100

    ARM: Fix ioremap() of address zero
    
    commit a849088aa1552b1a28eea3daff599ee22a734ae3 upstream.
    
    Murali Nalajala reports a regression that ioremapping address zero
    results in an oops dump:
    
    Unable to handle kernel paging request at virtual address fa200000
    pgd = d4f80000
    [fa200000] *pgd=00000000
    Internal error: Oops: 5 [#1] PREEMPT SMP ARM
    Modules linked in:
    CPU: 0    Tainted: G        W (3.4.0-g3b5f728-00009-g638207a #13)
    PC is at msm_pm_config_rst_vector_before_pc+0x8/0x30
    LR is at msm_pm_boot_config_before_pc+0x18/0x20
    pc : [<c0078f84>]    lr : [<c007903c>]    psr: a0000093
    sp : c0837ef0  ip : cfe00000  fp : 0000000d
    r10: da7efc17  r9 : 225c4278  r8 : 00000006
    r7 : 0003c000  r6 : c085c824  r5 : 00000001  r4 : fa101000
    r3 : fa200000  r2 : c095080c  r1 : 002250fc  r0 : 00000000
    Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment kernel
    Control: 10c5387d  Table: 25180059  DAC: 00000015
    [<c0078f84>] (msm_pm_config_rst_vector_before_pc+0x8/0x30) from [<c007903c>] (msm_pm_boot_config_before_pc+0x18/0x20)
    [<c007903c>] (msm_pm_boot_config_before_pc+0x18/0x20) from [<c007a55c>] (msm_pm_power_collapse+0x410/0xb04)
    [<c007a55c>] (msm_pm_power_collapse+0x410/0xb04) from [<c007b17c>] (arch_idle+0x294/0x3e0)
    [<c007b17c>] (arch_idle+0x294/0x3e0) from [<c000eed8>] (default_idle+0x18/0x2c)
    [<c000eed8>] (default_idle+0x18/0x2c) from [<c000f254>] (cpu_idle+0x90/0xe4)
    [<c000f254>] (cpu_idle+0x90/0xe4) from [<c057231c>] (rest_init+0x88/0xa0)
    [<c057231c>] (rest_init+0x88/0xa0) from [<c07ff890>] (start_kernel+0x3a8/0x40c)
    Code: c0704256 e12fff1e e59f2020 e5923000 (e5930000)
    
    This is caused by the 'reserved' entries which we insert (see
    19b52abe3c5d7 - ARM: 7438/1: fill possible PMD empty section gaps)
    which get matched for physical address zero.
    
    Resolve this by marking these reserved entries with a different flag.
    
    Tested-by: Murali Nalajala <mnalajal@codeaurora.org>
    Acked-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c7911680824e4aa89bf5247ffae0e38bf5c45bb
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date:   Mon Aug 20 09:39:22 2012 -0300

    ARM: clk-imx35: Fix SSI clock registration
    
    commit 48540058612786d365602f3324ed97f9071092de upstream.
    
    SSI block has two types of clock:
    
    ipg: bus clock, the clock needed for accessing registers.
    per: peripheral clock, the clock needed for generating the bit rate.
    
    Currently SSI driver only supports slave mode and only need to handle
    the ipg clock, because the peripheral clock comes from the master codec.
    
    Only register the ipg clock and do not register the peripheral clock for ssi.
    
    Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
    Tested-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8e2903a1a8da1565e6825cac6e8a7a6a8b0c4b6
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date:   Sun Aug 19 14:05:59 2012 -0300

    ARM: clk-imx25: Fix SSI clock registration
    
    commit 912bfe76528c287bc4812521b8d53366954b39a5 upstream.
    
    SSI block has two types of clock:
    
    ipg: bus clock, the clock needed for accessing registers.
    per: peripheral clock, the clock needed for generating the bit rate.
    
    Currently SSI driver only supports slave mode and only need to handle
    the ipg clock, because the peripheral clock comes from the master codec.
    
    Only register the ipg clock and do not register the peripheral clock for ssi.
    
    Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60d75eff5b41399b9a367874aef33d9f7355c50f
Author: Igor Grinberg <grinberg@compulab.co.il>
Date:   Tue Aug 28 01:26:14 2012 +0300

    ARM: OMAP: timer: obey the !CONFIG_OMAP_32K_TIMER
    
    commit 45caae74d238ef6583e9402cb8c550cc0b0f7dbd upstream.
    
    Currently, omap2_sync32k_clocksource_init() function initializes the 32K
    timer as the system clock source regardless of the CONFIG_OMAP_32K_TIMER
    setting.
    Fix this by providing a default implementation for
    !CONFIG_OMAP_32K_TIMER case.
    
    Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
    Reviewed-by: Paul Walmsley <paul@pwsan.com>
    Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c77ffffb6a2174d83430e4301098eec75a4e214
Author: Dae S. Kim <dae@velatum.com>
Date:   Fri Aug 31 02:00:51 2012 +0200

    Staging: Android alarm: IOCTL command encoding fix
    
    commit 6bd4a5d96c08dc2380f8053b1bd4f879f55cd3c9 upstream.
    
    Fixed a bug. Data was being written to user space using an IOCTL
    command encoded with _IOC_WRITE access mode.
    
    Signed-off-by: Dae S. Kim <dae@velatum.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7951bef55a24041c91377ee67ad06a361aea42d0
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Fri Sep 7 18:22:28 2012 +0100

    ARM: 7527/1: uaccess: explicitly check __user pointer when !CPU_USE_DOMAINS
    
    commit 8404663f81d212918ff85f493649a7991209fa04 upstream.
    
    The {get,put}_user macros don't perform range checking on the provided
    __user address when !CPU_HAS_DOMAINS.
    
    This patch reworks the out-of-line assembly accessors to check the user
    address against a specified limit, returning -EFAULT if is is out of
    range.
    
    [will: changed get_user register allocation to match put_user]
    [rmk: fixed building on older ARM architectures]
    
    Reported-by: Catalin Marinas <catalin.marinas@arm.com>
    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 c11bc85ae982aba3e1cb85a7e9ff6c4a53d5ea2c
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Sep 7 18:21:44 2012 +0100

    ARM: 7526/1: traps: send SIGILL if get_user fails on undef handling path
    
    commit 2b2040af0b64cd93e5d4df2494c4486cf604090d upstream.
    
    get_user may fail to load from the provided __user address due to an
    unhandled fault generated by the access.
    
    In the case of the undefined instruction trap, this results in failure
    to load the faulting instruction, in which case we should send SIGILL to
    the task rather than continue with potentially uninitialised data.
    
    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 c8dcc7a99a88d7e5249cd20ff0532098738d7a27
Author: David Brown <davidb@codeaurora.org>
Date:   Tue Sep 4 21:36:37 2012 +0100

    ARM: 7513/1: Make sure dtc is built before running it
    
    commit 70b0476a2394de4f4e32e0b67288d80ff71ca963 upstream.
    
    'make dtbs' in a clean tree will try running the dtc before actually
    building it.  Make these rules depend upon the scripts to build it.
    
    Signed-off-by: David Brown <davidb@codeaurora.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b8bc8a2d1e5f5fcd19c90aece2712bdd86b5c2d
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Aug 24 15:20:59 2012 +0100

    ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
    
    commit dbece45894d3ab1baac15a96dc4e1e8e23f64a93 upstream.
    
    When enabling the MMU for ARMv7 CPUs, the decompressor does not touch
    the ttbcr register, assuming that it will be zeroed (N == 0, EAE == 0).
    Given that only EAE is defined as 0 for non-secure copies of the
    register (and a bootloader such as kexec may leave it set to 1 anyway),
    we should ensure that we reset the register ourselves before turning on
    the MMU.
    
    This patch zeroes TTBCR.EAE and TTBCR.N prior to enabling the MMU for
    ARMv7 cores in the decompressor, configuring us exclusively for 32-bit
    translation tables via TTBR0.
    
    Acked-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Matthew Leach <matthew.leach@arm.com>
    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 868e5529c2686befc556cca687069bea4d426326
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Aug 16 18:55:44 2012 +0100

    ARM: 7496/1: hw_breakpoint: don't rely on dfsr to show watchpoint access type
    
    commit bf8801145c01ab600f8df66e8c879ac642fa5846 upstream.
    
    From ARM debug architecture v7.1 onwards, a watchpoint exception causes
    the DFAR to be updated with the faulting data address. However, DFSR.WnR
    takes an UNKNOWN value and therefore cannot be used in general to
    determine the access type that triggered the watchpoint.
    
    This patch forbids watchpoints without an overflow handler from
    specifying a specific access type (load/store). Those with overflow
    handlers must be able to handle false positives potentially triggered by
    a watchpoint of a different access type on the same address. For
    SIGTRAP-based handlers (i.e. ptrace), this should have no impact.
    
    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 613401671e4b54a5814c49c8c81917fcb3435292
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Wed Sep 5 17:09:14 2012 +0200

    target: simplify code around transport_get_sense_data
    
    commit 27a2709912ac19c755d34c79fe11994b0bf8082b upstream.
    
    The error conditions in transport_get_sense_data are superfluous
    and complicate the code unnecessarily:
    
    * SCF_TRANSPORT_TASK_SENSE is checked in the caller;
    
    * it's simply part of the invariants of dev->transport->get_sense_buffer
      that it must be there if transport_complete ever returns 1, and that
      it must not return NULL.  Besides, the entire callback will disappear
      with the next patch.
    
    * similarly in the caller we can expect that sense data is only sent
      for non-zero cmd->scsi_status.
    
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42740e446939b3e4c9b4798950371c87f483c6f6
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Thu Aug 16 15:33:10 2012 -0700

    target: Fix ->data_length re-assignment bug with SCSI overflow
    
    commit 4c054ba63ad47ef244cfcfa1cea38134620a5bae upstream.
    
    This patch fixes a long-standing bug with SCSI overflow handling
    where se_cmd->data_length was incorrectly being re-assigned to
    the larger CDB extracted allocation length, resulting in a number
    of fabric level errors that would end up causing a session reset
    in most cases.  So instead now:
    
     - Only re-assign se_cmd->data_length durining UNDERFLOW (to use the
       smaller value)
     - Use existing se_cmd->data_length for OVERFLOW (to use the smaller
       value)
    
    This fix has been tested with the following CDB to generate an
    SCSI overflow:
    
      sg_raw -r512 /dev/sdc 28 0 0 0 0 0 0 0 9 0
    
    Tested using iscsi-target, tcm_qla2xxx, loopback and tcm_vhost fabric
    ports.  Here is a bit more detail on each case:
    
     - iscsi-target: Bug with open-iscsi with overflow, sg_raw returns
                     -3584 bytes of data.
     - tcm_qla2xxx: Working as expected, returnins 512 bytes of data
     - loopback: sg_raw returns CHECK_CONDITION, from overflow rejection
                 in transport_generic_map_mem_to_cmd()
     - tcm_vhost: Same as loopback
    
    Reported-by: Roland Dreier <roland@purestorage.com>
    Cc: Roland Dreier <roland@purestorage.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Boaz Harrosh <bharrosh@panasas.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c1f9c2ac4d937c0be1dfa936431aedddea18b3a
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Thu Sep 13 12:00:56 2012 -0700

    eCryptfs: Copy up attributes of the lower target inode after rename
    
    commit 8335eafc2859e1a26282bef7c3d19f3d68868b8a upstream.
    
    After calling into the lower filesystem to do a rename, the lower target
    inode's attributes were not copied up to the eCryptfs target inode. This
    resulted in the eCryptfs target inode staying around, rather than being
    evicted, because i_nlink was not updated for the eCryptfs inode. This
    also meant that eCryptfs didn't do the final iput() on the lower target
    inode so it stayed around, as well. This would result in a failure to
    free up space occupied by the target file in the rename() operation.
    Both target inodes would eventually be evicted when the eCryptfs
    filesystem was unmounted.
    
    This patch calls fsstack_copy_attr_all() after the lower filesystem
    does its ->rename() so that important inode attributes, such as i_nlink,
    are updated at the eCryptfs layer. ecryptfs_evict_inode() is now called
    and eCryptfs can drop its final reference on the lower inode.
    
    http://launchpad.net/bugs/561129
    
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Tested-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f985249b885070551c839be0612cfaf0f1ad81c
Author: Amerigo Wang <amwang@redhat.com>
Date:   Sat Aug 18 07:02:20 2012 +0000

    netconsole: remove a redundant netconsole_target_put()
    
    commit 72d3eb13b5c0abe7d63efac41f39c5b644c7bbaa upstream.
    
    This netconsole_target_put() is obviously redundant, and it
    causes a kernel segfault when removing a bridge device which has
    netconsole running on it.
    
    This is caused by:
    
    	commit 8d8fc29d02a33e4bd5f4fa47823c1fd386346093
    	Author: Amerigo Wang <amwang@redhat.com>
    	Date:   Thu May 19 21:39:10 2011 +0000
    
    	    netpoll: disable netpoll when enslave a device
    
    Signed-off-by: Cong Wang <amwang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dcfbe9a59979e9e48dae79bd3525d10c71b9fe50
Author: Miklos Szeredi <mszeredi@suse.cz>
Date:   Mon Sep 17 22:31:38 2012 +0200

    vfs: dcache: use DCACHE_DENTRY_KILLED instead of DCACHE_DISCONNECTED in d_kill()
    
    commit b161dfa6937ae46d50adce8a7c6b12233e96e7bd upstream.
    
    IBM reported a soft lockup after applying the fix for the rename_lock
    deadlock.  Commit c83ce989cb5f ("VFS: Fix the nfs sillyrename regression
    in kernel 2.6.38") was found to be the culprit.
    
    The nfs sillyrename fix used DCACHE_DISCONNECTED to indicate that the
    dentry was killed.  This flag can be set on non-killed dentries too,
    which results in infinite retries when trying to traverse the dentry
    tree.
    
    This patch introduces a separate flag: DCACHE_DENTRY_KILLED, which is
    only set in d_kill() and makes try_to_ascend() test only this flag.
    
    IBM reported successful test results with this patch.
    
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a89e4f5934b734f1fa24eb0013a3a32158ee1a8b
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Sep 14 14:48:21 2012 -0700

    vfs: make O_PATH file descriptors usable for 'fstat()'
    
    commit 55815f70147dcfa3ead5738fd56d3574e2e3c1c2 upstream.
    
    We already use them for openat() and friends, but fstat() also wants to
    be able to use O_PATH file descriptors.  This should make it more
    directly comparable to the O_SEARCH of Solaris.
    
    Note that you could already do the same thing with "fstatat()" and an
    empty path, but just doing "fstat()" directly is simpler and faster, so
    there is no reason not to just allow it directly.
    
    See also commit 332a2e1244bd, which did the same thing for fchdir, for
    the same reasons.
    
    Reported-by: ольга крыжановская <olga.kryzhanovska@gmail.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 739b195387af0cea560925daa550b3ebca923642
Author: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Date:   Fri Sep 14 16:35:10 2012 -0500

    cciss: fix handling of protocol error
    
    commit 2453f5f992717251cfadab6184fbb3ec2f2e8b40 upstream.
    
    If a command completes with a status of CMD_PROTOCOL_ERR, this
    information should be conveyed to the SCSI mid layer, not dropped
    on the floor.  Unlike a similar bug in the hpsa driver, this bug
    only affects tape drives and CD and DVD ROM drives in the cciss
    driver, and to induce it, you have to disconnect (or damage) a
    cable, so it is not a very likely scenario (which would explain
    why the bug has gone undetected for the last 10 years.)
    
    Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 452310ee930ccdf7ddb267279e56f2472ec7d163
Author: Tejun Heo <tj@kernel.org>
Date:   Tue Sep 18 14:24:59 2012 -0700

    cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU
    
    commit 6889125b8b4e09c5e53e6ecab3433bed1ce198c9 upstream.
    
    powernowk8_target() runs off a per-cpu work item and if the
    cpufreq_policy->cpu is different from the current one, it migrates the
    kworker to the target CPU by manipulating current->cpus_allowed.  The
    function migrates the kworker back to the original CPU but this is
    still broken.  Workqueue concurrency management requires the kworkers
    to stay on the same CPU and powernowk8_target() ends up triggerring
    BUG_ON(rq != this_rq()) in try_to_wake_up_local() if it contends on
    fidvid_mutex and sleeps.
    
    It is unclear why this bug is being reported now.  Duncan says it
    appeared to be a regression of 3.6-rc1 and couldn't reproduce it on
    3.5.  Bisection seemed to point to 63d95a91 "workqueue: use @pool
    instead of @gcwq or @cpu where applicable" which is an non-functional
    change.  Given that the reproduce case sometimes took upto days to
    trigger, it's easy to be misled while bisecting.  Maybe something made
    contention on fidvid_mutex more likely?  I don't know.
    
    This patch fixes the bug by using work_on_cpu() instead if @pol->cpu
    isn't the same as the current one.  The code assumes that
    cpufreq_policy->cpu is kept online by the caller, which Rafael tells
    me is the case.
    
    stable: ed48ece27c ("workqueue: reimplement work_on_cpu() using
            system_wq") should be applied before this; otherwise, the
            behavior could be horrible.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Duncan <1i5t5.duncan@cox.net>
    Tested-by: Duncan <1i5t5.duncan@cox.net>
    Cc: Rafael J. Wysocki <rjw@sisk.pl>
    Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47301
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a88ff36aef1f343074151a58926c5290e6c82b1e
Author: Tejun Heo <tj@kernel.org>
Date:   Tue Sep 18 12:48:43 2012 -0700

    workqueue: reimplement work_on_cpu() using system_wq
    
    commit ed48ece27cd3d5ee0354c32bbaec0f3e1d4715c3 upstream.
    
    The existing work_on_cpu() implementation is hugely inefficient.  It
    creates a new kthread, execute that single function and then let the
    kthread die on each invocation.
    
    Now that system_wq can handle concurrent executions, there's no
    advantage of doing this.  Reimplement work_on_cpu() using system_wq
    which makes it simpler and way more efficient.
    
    stable: While this isn't a fix in itself, it's needed to fix a
            workqueue related bug in cpufreq/powernow-k8.  AFAICS, this
            shouldn't break other existing users.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Len Brown <lenb@kernel.org>
    Cc: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ae5c3271419d2f294b2caf00aed7ac1f50760a6
Author: Jesse Gross <jesse@nicira.com>
Date:   Fri May 25 11:29:30 2012 -0700

    openvswitch: Reset upper layer protocol info on internal devices.
    
    [ Upstream commit 7fe99e2d434eafeac0c57b279a77e5de39212636 ]
    
    It's possible that packets that are sent on internal devices (from
    the OVS perspective) have already traversed the local IP stack.
    After they go through the internal device, they will again travel
    through the IP stack which may get confused by the presence of
    existing information in the skb. The problem can be observed
    when switching between namespaces. This clears out that information
    to avoid problems but deliberately leaves other metadata alone.
    This is to provide maximum flexibility in chaining together OVS
    and other Linux components.
    
    Signed-off-by: Jesse Gross <jesse@nicira.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1c5f84b226548a62f9a78d491d777a8f1dbd5c6
Author: Jaccon Bastiaansen <jaccon.bastiaansen@gmail.com>
Date:   Mon Aug 27 11:53:51 2012 +0000

    cs89x0 : packet reception not working
    
    [ Upstream commit b72c200975a4ed579dbf3353019e19528745a29a ]
    
    The RxCFG register of the CS89x0 could be configured incorrectly
    (because of misplaced parentheses), resulting in the disabling
    of packet reception.
    
    Signed-off-by: Jaccon Bastiaansen <jaccon.bastiaansen@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06d3f370de6bf23d93629329255d3778641d6d02
Author: Yuval Mintz <yuvalmin@broadcom.com>
Date:   Sun Aug 26 00:35:45 2012 +0000

    bnx2x: fix 57840_MF pci id
    
    [ Upstream commit 5c879d2094946081af934739850c7260e8b25d3c ]
    
    Commit c3def943c7117d42caaed3478731ea7c3c87190e have added support for
    new pci ids of the 57840 board, while failing to change the obsolete value
    in 'pci_ids.h'.
    This patch does so, allowing the probe of such devices.
    
    Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
    Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7648ad12f80e2790b7479945538fd8850e76eae
Author: Francesco Ruggeri <fruggeri@aristanetworks.com>
Date:   Fri Aug 24 07:38:35 2012 +0000

    net: ipv4: ipmr_expire_timer causes crash when removing net namespace
    
    [ Upstream commit acbb219d5f53821b2d0080d047800410c0420ea1 ]
    
    When tearing down a net namespace, ipv4 mr_table structures are freed
    without first deactivating their timers. This can result in a crash in
    run_timer_softirq.
    This patch mimics the corresponding behaviour in ipv6.
    Locking and synchronization seem to be adequate.
    We are about to kfree mrt, so existing code should already make sure that
    no other references to mrt are pending or can be created by incoming traffic.
    The functions invoked here do not cause new references to mrt or other
    race conditions to be created.
    Invoking del_timer_sync guarantees that ipmr_expire_timer is inactive.
    Both ipmr_expire_process (whose completion we may have to wait in
    del_timer_sync) and mroute_clean_tables internally use mfc_unres_lock
    or other synchronizations when needed, and they both only modify mrt.
    
    Tested in Linux 3.4.8.
    
    Signed-off-by: Francesco Ruggeri <fruggeri@aristanetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25a29dec42e8c89e3de2e5d3a8f3e246f3640d06
Author: xeb@mail.ru <xeb@mail.ru>
Date:   Fri Aug 24 01:07:38 2012 +0000

    l2tp: avoid to use synchronize_rcu in tunnel free function
    
    [ Upstream commit 99469c32f79a32d8481f87be0d3c66dad286f4ec ]
    
    Avoid to use synchronize_rcu in l2tp_tunnel_free because context may be
    atomic.
    
    Signed-off-by: Dmitry Kozlov <xeb@mail.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 440de22d93f91d12eb351692b64a349a80668e91
Author: Claudiu Manoil <claudiu.manoil@freescale.com>
Date:   Thu Aug 23 21:46:25 2012 +0000

    gianfar: fix default tx vlan offload feature flag
    
    [ Upstream commit e2c53be223aca36cf93eb6a0f6bafa079e78f52b ]
    
    Commit -
    "b852b72 gianfar: fix bug caused by
    87c288c6e9aa31720b72e2bc2d665e24e1653c3e"
    disables by default (on mac init) the hw vlan tag insertion.
    The "features" flags were not updated to reflect this, and
    "ethtool -K" shows tx-vlan-offload to be "on" by default.
    
    Cc: Sebastian Poehn <sebastian.poehn@belden.com>
    Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6bd493b9fa829986c9221e0ea507ff53ce9e068
Author: Ben Hutchings <bhutchings@solarflare.com>
Date:   Wed Aug 15 18:09:15 2012 +0100

    sfc: Fix reporting of IPv4 full filters through ethtool
    
    [ Upstream commit ac70b2e9a13423b5efa0178e081936ce6979aea5 ]
    
    ETHTOOL_GRXCLSRULE returns filters for a TCP/IPv4 or UDP/IPv4 4-tuple
    with source and destination swapped.
    
    Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d7b926e92f37be1a45ada2c3bdce9970a53cb93
Author: Yuchung Cheng <ycheng@google.com>
Date:   Thu Aug 23 07:05:17 2012 +0000

    tcp: fix cwnd reduction for non-sack recovery
    
    [ Upstream commit 7c4a56fec379ac0d7754e0d4da6a7361f1a4fe64 ]
    
    The cwnd reduction in fast recovery is based on the number of packets
    newly delivered per ACK. For non-sack connections every DUPACK
    signifies a packet has been delivered, but the sender mistakenly
    skips counting them for cwnd reduction.
    
    The fix is to compute newly_acked_sacked after DUPACKs are accounted
    in sacked_out for non-sack connections.
    
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Acked-by: Nandita Dukkipati <nanditad@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2dfd8abf6c1f5ec34730dc72f2c4a4f31c6b8dc6
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Aug 23 02:09:11 2012 +0000

    netlink: fix possible spoofing from non-root processes
    
    [ Upstream commit 20e1db19db5d6b9e4e83021595eab0dc8f107bef ]
    
    Non-root user-space processes can send Netlink messages to other
    processes that are well-known for being subscribed to Netlink
    asynchronous notifications. This allows ilegitimate non-root
    process to send forged messages to Netlink subscribers.
    
    The userspace process usually verifies the legitimate origin in
    two ways:
    
    a) Socket credentials. If UID != 0, then the message comes from
       some ilegitimate process and the message needs to be dropped.
    
    b) Netlink portID. In general, portID == 0 means that the origin
       of the messages comes from the kernel. Thus, discarding any
       message not coming from the kernel.
    
    However, ctnetlink sets the portID in event messages that has
    been triggered by some user-space process, eg. conntrack utility.
    So other processes subscribed to ctnetlink events, eg. conntrackd,
    know that the event was triggered by some user-space action.
    
    Neither of the two ways to discard ilegitimate messages coming
    from non-root processes can help for ctnetlink.
    
    This patch adds capability validation in case that dst_pid is set
    in netlink_sendmsg(). This approach is aggressive since existing
    applications using any Netlink bus to deliver messages between
    two user-space processes will break. Note that the exception is
    NETLINK_USERSOCK, since it is reserved for netlink-to-netlink
    userspace communication.
    
    Still, if anyone wants that his Netlink bus allows netlink-to-netlink
    userspace, then they can set NL_NONROOT_SEND. However, by default,
    I don't think it makes sense to allow to use NETLINK_ROUTE to
    communicate two processes that are sending no matter what information
    that is not related to link/neighbouring/routing. They should be using
    NETLINK_USERSOCK instead for that.
    
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d34ab836a0130db7643b55eb8713726ef704b52
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Aug 21 06:21:17 2012 +0000

    af_netlink: force credentials passing [CVE-2012-3520]
    
    [ Upstream commit e0e3cea46d31d23dc40df0a49a7a2c04fe8edfea ]
    
    Pablo Neira Ayuso discovered that avahi and
    potentially NetworkManager accept spoofed Netlink messages because of a
    kernel bug.  The kernel passes all-zero SCM_CREDENTIALS ancillary data
    to the receiver if the sender did not provide such data, instead of not
    including any such data at all or including the correct data from the
    peer (as it is the case with AF_UNIX).
    
    This bug was introduced in commit 16e572626961
    (af_unix: dont send SCM_CREDENTIALS by default)
    
    This patch forces passing credentials for netlink, as
    before the regression.
    
    Another fix would be to not add SCM_CREDENTIALS in
    netlink messages if not provided by the sender, but it
    might break some programs.
    
    With help from Florian Weimer & Petr Matousek
    
    This issue is designated as CVE-2012-3520
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Petr Matousek <pmatouse@redhat.com>
    Cc: Florian Weimer <fweimer@redhat.com>
    Cc: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c182b9556632ce565dc7ecbb49759334628f75bb
Author: Eric Leblond <eric@regit.org>
Date:   Thu Aug 16 22:02:58 2012 +0000

    af_packet: don't emit packet on orig fanout group
    
    [ Upstream commit c0de08d04215031d68fa13af36f347a6cfa252ca ]
    
    If a packet is emitted on one socket in one group of fanout sockets,
    it is transmitted again. It is thus read again on one of the sockets
    of the fanout group. This result in a loop for software which
    generate packets when receiving one.
    This retransmission is not the intended behavior: a fanout group
    must behave like a single socket. The packet should not be
    transmitted on a socket if it originates from a socket belonging
    to the same fanout group.
    
    This patch fixes the issue by changing the transmission check to
    take fanout group info account.
    
    Reported-by: Aleksandr Kotov <a1k@mail.ru>
    Signed-off-by: Eric Leblond <eric@regit.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8c8c1837a00c6da2522add7297af65166a23306
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:57 2012 +0000

    net: fix info leak in compat dev_ifconf()
    
    [ Upstream commit 43da5f2e0d0c69ded3d51907d9552310a6b545e8 ]
    
    The implementation of dev_ifconf() for the compat ioctl interface uses
    an intermediate ifc structure allocated in userland for the duration of
    the syscall. Though, it fails to initialize the padding bytes inserted
    for alignment and that for leaks four bytes of kernel stack. Add an
    explicit memset(0) before filling the structure to avoid the info leak.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit deec7451985732043ec92eb3925ba4f08df8a5d9
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:56 2012 +0000

    ipvs: fix info leak in getsockopt(IP_VS_SO_GET_TIMEOUT)
    
    [ Upstream commit 2d8a041b7bfe1097af21441cb77d6af95f4f4680 ]
    
    If at least one of CONFIG_IP_VS_PROTO_TCP or CONFIG_IP_VS_PROTO_UDP is
    not set, __ip_vs_get_timeouts() does not fully initialize the structure
    that gets copied to userland and that for leaks up to 12 bytes of kernel
    stack. Add an explicit memset(0) before passing the structure to
    __ip_vs_get_timeouts() to avoid the info leak.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Wensong Zhang <wensong@linux-vs.org>
    Cc: Simon Horman <horms@verge.net.au>
    Cc: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 303490bccf35e44a4ea722e272d97843e71018e7
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:55 2012 +0000

    dccp: fix info leak via getsockopt(DCCP_SOCKOPT_CCID_TX_INFO)
    
    [ Upstream commit 7b07f8eb75aa3097cdfd4f6eac3da49db787381d ]
    
    The CCID3 code fails to initialize the trailing padding bytes of struct
    tfrc_tx_info added for alignment on 64 bit architectures. It that for
    potentially leaks four bytes kernel stack via the getsockopt() syscall.
    Add an explicit memset(0) before filling the structure to avoid the
    info leak.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f89763e8240edf8014e51513c9aba649f878c1b
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:53 2012 +0000

    llc: fix info leak via getsockname()
    
    [ Upstream commit 3592aaeb80290bda0f2cf0b5456c97bfc638b192 ]
    
    The LLC code wrongly returns 0, i.e. "success", when the socket is
    zapped. Together with the uninitialized uaddrlen pointer argument from
    sys_getsockname this leads to an arbitrary memory leak of up to 128
    bytes kernel stack via the getsockname() syscall.
    
    Return an error instead when the socket is zapped to prevent the info
    leak. Also remove the unnecessary memset(0). We don't directly write to
    the memory pointed by uaddr but memcpy() a local structure at the end of
    the function that is properly initialized.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e0a12a954e7171a68ef653cfa618d579446f9e2
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:52 2012 +0000

    l2tp: fix info leak via getsockname()
    
    [ Upstream commit 04d4fbca1017c11381e7d82acea21dd741e748bc ]
    
    The L2TP code for IPv6 fails to initialize the l2tp_unused member of
    struct sockaddr_l2tpip6 and that for leaks two bytes kernel stack via
    the getsockname() syscall. Initialize l2tp_unused with 0 to avoid the
    info leak.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: James Chapman <jchapman@katalix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f6904ae94cb070bc8339bc27a75cf8bc76cca03
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:51 2012 +0000

    Bluetooth: L2CAP - Fix info leak via getsockname()
    
    [ Upstream commit 792039c73cf176c8e39a6e8beef2c94ff46522ed ]
    
    The L2CAP code fails to initialize the l2_bdaddr_type member of struct
    sockaddr_l2 and the padding byte added for alignment. It that for leaks
    two bytes kernel stack via the getsockname() syscall. Add an explicit
    memset(0) before filling the structure to avoid the info leak.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b84eed8535a609ac3e62ef5c7baa7900592ec29
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:50 2012 +0000

    Bluetooth: RFCOMM - Fix info leak via getsockname()
    
    [ Upstream commit 9344a972961d1a6d2c04d9008b13617bcb6ec2ef ]
    
    The RFCOMM code fails to initialize the trailing padding byte of struct
    sockaddr_rc added for alignment. It that for leaks one byte kernel stack
    via the getsockname() syscall. Add an explicit memset(0) before filling
    the structure to avoid the info leak.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a194d08d452a87b194f9d61b30f2bd87d2cb1836
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:49 2012 +0000

    Bluetooth: RFCOMM - Fix info leak in ioctl(RFCOMMGETDEVLIST)
    
    [ Upstream commit f9432c5ec8b1e9a09b9b0e5569e3c73db8de432a ]
    
    The RFCOMM code fails to initialize the two padding bytes of struct
    rfcomm_dev_list_req inserted for alignment before copying it to
    userland. Additionally there are two padding bytes in each instance of
    struct rfcomm_dev_info. The ioctl() that for disclosures two bytes plus
    dev_num times two bytes uninitialized kernel heap memory.
    
    Allocate the memory using kzalloc() to fix this issue.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 352e3a79d7885339ea18c4bad77d4508616fa61c
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:48 2012 +0000

    Bluetooth: RFCOMM - Fix info leak in getsockopt(BT_SECURITY)
    
    [ Upstream commit 9ad2de43f1aee7e7274a4e0d41465489299e344b ]
    
    The RFCOMM code fails to initialize the key_size member of struct
    bt_security before copying it to userland -- that for leaking one
    byte kernel stack. Initialize key_size with 0 to avoid the info
    leak.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7b7aa589ccc3eed017f3b01f2f83004d47bdd85
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:47 2012 +0000

    Bluetooth: HCI - Fix info leak via getsockname()
    
    [ Upstream commit 3f68ba07b1da811bf383b4b701b129bfcb2e4988 ]
    
    The HCI code fails to initialize the hci_channel member of struct
    sockaddr_hci and that for leaks two bytes kernel stack via the
    getsockname() syscall. Initialize hci_channel with 0 to avoid the
    info leak.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 054a7f491ba6d54f5dec06546a628eacbef63592
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:46 2012 +0000

    Bluetooth: HCI - Fix info leak in getsockopt(HCI_FILTER)
    
    [ Upstream commit e15ca9a0ef9a86f0477530b0f44a725d67f889ee ]
    
    The HCI code fails to initialize the two padding bytes of struct
    hci_ufilter before copying it to userland -- that for leaking two
    bytes kernel stack. Add an explicit memset(0) before filling the
    structure to avoid the info leak.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b74fc6398bae63b2051c8e047399ef7d4215545
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:45 2012 +0000

    atm: fix info leak via getsockname()
    
    [ Upstream commit 3c0c5cfdcd4d69ffc4b9c0907cec99039f30a50a ]
    
    The ATM code fails to initialize the two padding bytes of struct
    sockaddr_atmpvc inserted for alignment. Add an explicit memset(0)
    before filling the structure to avoid the info leak.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd94f3759a698eea2c27c2b3c2df931ad94a619a
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:44 2012 +0000

    atm: fix info leak in getsockopt(SO_ATMPVC)
    
    [ Upstream commit e862f1a9b7df4e8196ebec45ac62295138aa3fc2 ]
    
    The ATM code fails to initialize the two padding bytes of struct
    sockaddr_atmpvc inserted for alignment. Add an explicit memset(0)
    before filling the structure to avoid the info leak.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 754c665f51b31b43c2399f693b3a54e47cbcef7b
Author: Ben Hutchings <bhutchings@solarflare.com>
Date:   Tue Aug 14 08:54:51 2012 +0000

    ipv6: addrconf: Avoid calling netdevice notifiers with RCU read-side lock
    
    [ Upstream commit 4acd4945cd1e1f92b20d14e349c6c6a52acbd42d ]
    
    Cong Wang reports that lockdep detected suspicious RCU usage while
    enabling IPV6 forwarding:
    
     [ 1123.310275] ===============================
     [ 1123.442202] [ INFO: suspicious RCU usage. ]
     [ 1123.558207] 3.6.0-rc1+ #109 Not tainted
     [ 1123.665204] -------------------------------
     [ 1123.768254] include/linux/rcupdate.h:430 Illegal context switch in RCU read-side critical section!
     [ 1123.992320]
     [ 1123.992320] other info that might help us debug this:
     [ 1123.992320]
     [ 1124.307382]
     [ 1124.307382] rcu_scheduler_active = 1, debug_locks = 0
     [ 1124.522220] 2 locks held by sysctl/5710:
     [ 1124.648364]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81768498>] rtnl_trylock+0x15/0x17
     [ 1124.882211]  #1:  (rcu_read_lock){.+.+.+}, at: [<ffffffff81871df8>] rcu_lock_acquire+0x0/0x29
     [ 1125.085209]
     [ 1125.085209] stack backtrace:
     [ 1125.332213] Pid: 5710, comm: sysctl Not tainted 3.6.0-rc1+ #109
     [ 1125.441291] Call Trace:
     [ 1125.545281]  [<ffffffff8109d915>] lockdep_rcu_suspicious+0x109/0x112
     [ 1125.667212]  [<ffffffff8107c240>] rcu_preempt_sleep_check+0x45/0x47
     [ 1125.781838]  [<ffffffff8107c260>] __might_sleep+0x1e/0x19b
    [...]
     [ 1127.445223]  [<ffffffff81757ac5>] call_netdevice_notifiers+0x4a/0x4f
    [...]
     [ 1127.772188]  [<ffffffff8175e125>] dev_disable_lro+0x32/0x6b
     [ 1127.885174]  [<ffffffff81872d26>] dev_forward_change+0x30/0xcb
     [ 1128.013214]  [<ffffffff818738c4>] addrconf_forward_change+0x85/0xc5
    [...]
    
    addrconf_forward_change() uses RCU iteration over the netdev list,
    which is unnecessary since it already holds the RTNL lock.  We also
    cannot reasonably require netdevice notifier functions not to sleep.
    
    Reported-by: Cong Wang <amwang@redhat.com>
    Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 464485ee5310a8cb7265bef3002769e0871accbb
Author: danborkmann@iogearbox.net <danborkmann@iogearbox.net>
Date:   Fri Aug 10 22:48:54 2012 +0000

    af_packet: remove BUG statement in tpacket_destruct_skb
    
    [ Upstream commit 7f5c3e3a80e6654cf48dfba7cf94f88c6b505467 ]
    
    Here's a quote of the comment about the BUG macro from asm-generic/bug.h:
    
     Don't use BUG() or BUG_ON() unless there's really no way out; one
     example might be detecting data structure corruption in the middle
     of an operation that can't be backed out of.  If the (sub)system
     can somehow continue operating, perhaps with reduced functionality,
     it's probably not BUG-worthy.
    
     If you're tempted to BUG(), think again:  is completely giving up
     really the *only* solution?  There are usually better options, where
     users don't need to reboot ASAP and can mostly shut down cleanly.
    
    In our case, the status flag of a ring buffer slot is managed from both sides,
    the kernel space and the user space. This means that even though the kernel
    side might work as expected, the user space screws up and changes this flag
    right between the send(2) is triggered when the flag is changed to
    TP_STATUS_SENDING and a given skb is destructed after some time. Then, this
    will hit the BUG macro. As David suggested, the best solution is to simply
    remove this statement since it cannot be used for kernel side internal
    consistency checks. I've tested it and the system still behaves /stable/ in
    this case, so in accordance with the above comment, we should rather remove it.
    
    Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5db88321043909060745304c1e485a6a2839d31
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Wed Aug 8 00:33:25 2012 +0000

    net/core: Fix potential memory leak in dev_set_alias()
    
    [ Upstream commit 7364e445f62825758fa61195d237a5b8ecdd06ec ]
    
    Do not leak memory by updating pointer with potentially NULL realloc return value.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c939ce5216a7f4a604985c6b20ab92081b19848
Author: Gao feng <gaofeng@cn.fujitsu.com>
Date:   Tue Aug 7 00:23:11 2012 +0000

    pptp: lookup route with the proper net namespace
    
    [ Upstream commit 08252b32311c3fa84219ad794d640af7399b5485 ]
    
    pptp always use init_net as the net namespace to lookup
    route, this will cause route lookup failed in container.
    
    because we already set the correct net namespace to struct
    sock in pptp_create,so fix this by using sock_net(sk) to
    replace &init_net.
    
    Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e6c806a75a3d41b9eeca6b88e9e86d300a8badc
Author: Wu Fengguang <fengguang.wu@intel.com>
Date:   Thu Aug 2 23:10:01 2012 +0000

    isdnloop: fix and simplify isdnloop_init()
    
    [ Upstream commit 77f00f6324cb97cf1df6f9c4aaeea6ada23abdb2 ]
    
    Fix a buffer overflow bug by removing the revision and printk.
    
    [   22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
    [   22.097508] isdnloop: (loop0) virtual card added
    [   22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972
    [   22.174400]
    [   22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb1-dirty #129
    [   22.624071] Call Trace:
    [   22.720558]  [<ffffffff832448c3>] ? CallcNew+0x56/0x56
    [   22.815248]  [<ffffffff8222b623>] panic+0x110/0x329
    [   22.914330]  [<ffffffff83244972>] ? isdnloop_init+0xaf/0xb1
    [   23.014800]  [<ffffffff832448c3>] ? CallcNew+0x56/0x56
    [   23.090763]  [<ffffffff8108e24b>] __stack_chk_fail+0x2b/0x30
    [   23.185748]  [<ffffffff83244972>] isdnloop_init+0xaf/0xb1
    
    Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1568974b371812e0eaab98ed39ab864715adb76
Author: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Date:   Fri Aug 3 19:57:52 2012 +0900

    net_sched: gact: Fix potential panic in tcf_gact().
    
    [ Upstream commit 696ecdc10622d86541f2e35cc16e15b6b3b1b67e ]
    
    gact_rand array is accessed by gact->tcfg_ptype whose value
    is assumed to less than MAX_RAND, but any range checks are
    not performed.
    
    So add a check in tcf_gact_init(). And in tcf_gact(), we can
    reduce a branch.
    
    Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b541db6330465eae0032d46d7d67ca7e0e1047e2
Author: Ben Hutchings <bhutchings@solarflare.com>
Date:   Mon Jul 30 16:11:42 2012 +0000

    tcp: Apply device TSO segment limit earlier
    
    [ Upstream commit 1485348d2424e1131ea42efc033cbd9366462b01 ]
    
    Cache the device gso_max_segs in sock::sk_gso_max_segs and use it to
    limit the size of TSO skbs.  This avoids the need to fall back to
    software GSO for local TCP senders.
    
    Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 867079ce16beefdd834b6f0182def0277f52a2a7
Author: Ben Hutchings <bhutchings@solarflare.com>
Date:   Mon Jul 30 15:57:44 2012 +0000

    sfc: Fix maximum number of TSO segments and minimum TX queue size
    
    [ Upstream commit 7e6d06f0de3f74ca929441add094518ae332257c ]
    
    
    Currently an skb requiring TSO may not fit within a minimum-size TX
    queue.  The TX queue selected for the skb may stall and trigger the TX
    watchdog repeatedly (since the problem skb will be retried after the
    TX reset).  This issue is designated as CVE-2012-3412.
    
    Set the maximum number of TSO segments for our devices to 100.  This
    should make no difference to behaviour unless the actual MSS is less
    than about 700.  Increase the minimum TX queue size accordingly to
    allow for 2 worst-case skbs, so that there will definitely be space
    to add an skb after we wake a queue.
    
    To avoid invalidating existing configurations, change
    efx_ethtool_set_ringparam() to fix up values that are too small rather
    than returning -EINVAL.
    
    Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 525e07b8b6f18aec949c9f68672a0a3e3d8c38b1
Author: Ben Hutchings <bhutchings@solarflare.com>
Date:   Mon Jul 30 15:57:00 2012 +0000

    net: Allow driver to limit number of GSO segments per skb
    
    [ Upstream commit 30b678d844af3305cda5953467005cebb5d7b687 ]
    
    A peer (or local user) may cause TCP to use a nominal MSS of as little
    as 88 (actual MSS of 76 with timestamps).  Given that we have a
    sufficiently prodigious local sender and the peer ACKs quickly enough,
    it is nevertheless possible to grow the window for such a connection
    to the point that we will try to send just under 64K at once.  This
    results in a single skb that expands to 861 segments.
    
    In some drivers with TSO support, such an skb will require hundreds of
    DMA descriptors; a substantial fraction of a TX ring or even more than
    a full ring.  The TX queue selected for the skb may stall and trigger
    the TX watchdog repeatedly (since the problem skb will be retried
    after the TX reset).  This particularly affects sfc, for which the
    issue is designated as CVE-2012-3412.
    
    Therefore:
    1. Add the field net_device::gso_max_segs holding the device-specific
       limit.
    2. In netif_skb_features(), if the number of segments is too high then
       mask out GSO features to force fall back to software GSO.
    
    Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a67d241014549fbfa31825e2eb99f9df0d8d13e
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Jul 29 20:52:21 2012 +0000

    codel: refine one condition to avoid a nul rec_inv_sqrt
    
    [ Upstream commit 2359a47671fc4fb0fe5e9945f76c2cb10792c0f8 ]
    
    One condition before codel_Newton_step() was not good if
    we never left the dropping state for a flow. As a result
    rec_inv_sqrt was 0, instead of the ~0 initial value.
    
    codel control law was then set to a very aggressive mode, dropping
    many packets before reaching 'target' and recovering from this problem.
    
    To keep codel_vars_init() as efficient as possible, refine
    the condition to make sure rec_inv_sqrt initial value is correct
    
    Many thanks to Anton Mich for discovering the issue and suggesting
    a fix.
    
    Reported-by: Anton Mich <lp2s1h@gmail.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>