commit 2884d4230867c8a46cf701214051e923301e7429
Author: Robert Love <robert.w.love@intel.com>
Date:   Wed Jun 19 01:56:54 2013 +0000

    fcoe: Use correct API to set vlan tag for FCoE Ethertype skbs
    
    fcoe_xmit was coded such that it would skip the vlan net device/layer
    and instead set some vlan flags and transmit on the real net device.
    The real net device has code that would add the vlan tag for fcoe skbs.
    This avoids some extra processing for data frames and provides a small
    performance improvement.
    
    Since fcoe_xmit was not using the vlan net device, __vlan_put_tag
    within the real net device's xmit routine was ultimately being
    called to set the vlan tag.
    
    With the below change the behavior of __vlan_put_tag changed slightly,
    it now sets the skb->protocol = vlan_proto. vlan_proto was not a field
    being set by fcoe_xmit, so the skb->protocol is now not being set to
    ETH_P_8021Q, as it should be.
    
    This patch converts fcoe_xmit to use the vlan_put_tag routine which
    will tag the skb and fcoe will continue to transmit fcoe skbs on the
    real net device.
    
    For reference, the below change was the one that altered the
    __vlan_put_tag behavior.
    
      commit 86a9bad3ab6b6f858fd4443b48738cabbb6d094c
      Author: Patrick McHardy <kaber@trash.net>
      Date:   Fri Apr 19 02:04:30 2013 +0000
    
          net: vlan: add protocol argument to packet tagging functions
    
          Add a protocol argument to the VLAN packet tagging functions. In case of HW
          tagging, we need that protocol available in the ndo_start_xmit functions,
          so it is stored in a new field in the skb. The new field fits into a hole
          (on 64 bit) and doesn't increase the sks's size.
    
    Signed-off-by: Robert Love <robert.w.love@intel.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: John Fastabend <john.r.fastabend@intel.com>

commit b37e161388ac3980d5dfb73050e85874b84253eb
Author: Rojhalat Ibrahim <imr@rtschenk.de>
Date:   Mon Jun 17 16:02:41 2013 +0200

    powerpc/pci: Fix boot panic on mpc83xx (regression)
    
    The following commit caused a fatal oops when booting on mpc83xx with
    a non-express PCI bus (regardless of whether a PCI device is present):
    
    commit 50d8f87d2b39313dae9d0a2d9b23d377328f2f7b
    Author: Rojhalat Ibrahim <imr@rtschenk.de>
    Date:   Mon Apr 8 10:15:28 2013 +0200
    
        powerpc/fsl-pci Make PCIe hotplug work with Freescale PCIe controllers
    
        Up to now the PCIe link status on Freescale PCIe controllers was only
        checked once at boot time. So hotplug did not work. With this patch the
        link status is checked on every config read. PCIe devices not present at
        boot time are found after doing 'echo 1 >/sys/bus/pci/rescan'.
    
        Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de>
        Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
    
    This patch fixes the issue by calling setup_indirect_pci for all device types.
    fsl_indirect_read_config is now only used for booke/86xx PCIe controllers.
    
    Reported-by: Michael Guntsche <mike@it-loops.com>
    Cc: Scott Wood <scottwood@freescale.com>
    Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de>
    Signed-off-by: Scott Wood <scottwood@freescale.com>

commit eda4ddf7e3a2245888e8c45c566fd514cdd5abbb
Author: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Date:   Fri Jun 21 13:21:30 2013 +0200

    s390/ipl: Fix FCP WWPN and LUN format strings for read
    
    The following git commit changed the behavior of sscanf:
    
    commit 53809751ac230a3611b5cdd375f3389f3207d471
    Author: Jan Beulich <JBeulich@suse.com>
    Date:   Mon Dec 17 16:01:31 2012 -0800
        sscanf: don't ignore field widths for numeric conversions
    
    This broke the WWPN and LUN sysfs attributes for s390 reipl and dump
    on panic.
    
    Example:
    
    $ echo 0x0123456701234567 > /sys/firmware/reipl/fcp/wwpn
    $ cat /sys/firmware/reipl/fcp/wwpn
    0x0001234567012345
    
    So fix this and use format strings that work also with the
    new sscanf implementation:
    
    $ echo 0x012345670123456789 > /sys/firmware/reipl/fcp/wwpn
    $ cat /sys/firmware/reipl/fcp/wwpn
    0x0123456701234567
    
    Cc: stable@vger.kernel.org # 3.8+
    Reviewed-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit acdb37c361dc87e165889a504e291c1e82ae133c
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sat Jun 22 19:44:08 2013 -0700

    fs: fix new splice.c kernel-doc warning
    
    Fix new kernel-doc warning in fs/splice.c:
    
      Warning(fs/splice.c:1298): No description found for parameter 'opos'
    
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 9e895ace5d82df8929b16f58e9f515f6d54ab82d
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Jun 22 09:47:31 2013 -1000

    Linux 3.10-rc7

commit 945fb136dfcb5291b4fb2abd4fd1edf790de44ff
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Jun 22 11:01:38 2013 +0400

    aout32 coredump compat fix
    
    dump_seek() does SEEK_CUR, not SEEK_SET; native binfmt_aout
    handles it correctly (seeks by PAGE_SIZE - sizeof(struct user),
    getting the current position to PAGE_SIZE), compat one seeks
    by PAGE_SIZE and ends up at PAGE_SIZE + already written...
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

commit cc0ee9873c6afafb387379ca1df25da78a08c603
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Thu Jun 20 17:44:22 2013 +0300

    spi/pxa2xx: fix memory corruption due to wrong size used in devm_kzalloc()
    
    ACPI part of the driver accidentally used sizeof(*ssp) instead of the
    correct sizeof(*pdata). This leads to nasty memory corruptions like the one
    below:
    
        BUG: unable to handle kernel paging request at 0000000749fd30b8
        IP: [<ffffffff813fe8a1>] __list_del_entry+0x31/0xd0
        PGD 0
        Oops: 0000 [#1] PREEMPT SMP
        Modules linked in:
        CPU: 0 PID: 30 Comm: kworker/0:1 Not tainted 3.10.0-rc6v3.10-rc6_sdhci_modprobe+ #443
        task: ffff8801483a0940 ti: ffff88014839e000 task.ti: ffff88014839e000
        RIP: 0010:[<ffffffff813fe8a1>]  [<ffffffff813fe8a1>] __list_del_entry+0x31/0xd0
        RSP: 0000:ffff88014839fde8  EFLAGS: 00010046
        RAX: ffff880149fd30b0 RBX: ffff880149fd3040 RCX: dead000000200200
        RDX: 0000000749fd30b0 RSI: ffff880149fd3058 RDI: ffff88014834d640
        RBP: ffff88014839fde8 R08: ffff88014834d640 R09: 0000000000000001
        R10: ffff8801483a0940 R11: 0000000000000001 R12: ffff880149fd3040
        R13: ffffffff810e0b30 R14: ffff8801483a0940 R15: ffff88014834d640
        FS:  0000000000000000(0000) GS:ffff880149e00000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000000000000168 CR3: 0000000001e0b000 CR4: 00000000001407f0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
        Stack:
         ffff88014839fe48 ffffffff810e0baf ffffffff81120abd ffff88014839fe20
         ffff8801483a0940 ffff8801483a0940 ffff8801483a0940 ffff8801486b1c90
         ffff88014834d640 ffffffff810e0b30 0000000000000000 0000000000000000
        Call Trace:
         [<ffffffff810e0baf>] worker_thread+0x7f/0x390
         [<ffffffff81120abd>] ? trace_hardirqs_on+0xd/0x10
         [<ffffffff810e0b30>] ? manage_workers.isra.22+0x2b0/0x2b0
         [<ffffffff810e6c09>] kthread+0xd9/0xe0
         [<ffffffff810f93df>] ? local_clock+0x3f/0x50
         [<ffffffff810e6b30>] ? kthread_create_on_node+0x110/0x110
         [<ffffffff818c5dec>] ret_from_fork+0x7c/0xb0
         [<ffffffff810e6b30>] ? kthread_create_on_node+0x110/0x110
    
    Fix this by using the right structure size in devm_kzalloc().
    
    Reported-by: Jerome Blin <jerome.blin@intel.com>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Cc: stable@vger.kernel.org # 3.9+

commit b8cb62f82103083a6e8fa5470bfe634a2c06514d
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Jun 16 21:27:12 2013 +0100

    x86/efi: Fix dummy variable buffer allocation
    
    1. Check for allocation failure
    2. Clear the buffer contents, as they may actually be written to flash
    3. Don't leak the buffer
    
    Compile-tested only.
    
    [ Tested successfully on my buggy ASUS machine - Matt ]
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: stable@vger.kernel.org
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>

commit 58807a524782744aed5fb7b8fefac7134721331a
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Thu Jun 20 16:36:17 2013 -0700

    iscsi-target: Remove left over v3.10-rc debug printks
    
    Reported-by: Andy Grover <agrover@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 58bd0c69ffa27ea2309959836811e88004d73720
Author: Andy Grover <agrover@redhat.com>
Date:   Wed May 29 12:05:59 2013 -0700

    target/iscsi: Fix op=disable + error handling cases in np_store_iser
    
    Writing 0 when iser was not previously enabled, so succeed but do
    nothing so that user-space code doesn't need a try: catch block
    when ib_isert logic is not available.
    
    Also, return actual error from add_network_portal using PTR_ERR
    during op=enable failure.
    
    Signed-off-by: Andy Grover <agrover@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 8444d5c69549aa0f0b574cc608742d4669e1cc01
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Wed Jun 19 10:02:28 2013 -0400

    drm/radeon: update lockup tracking when scheduling in empty ring
    
    There might be issue with lockup detection when scheduling on an
    empty ring that have been sitting idle for a while. Thus update
    the lockup tracking data when scheduling new work in an empty ring.
    
    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    Tested-by: Andy Lutomirski <luto@amacapital.net>
    Cc: stable@vger.kernel.org
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit 7995bd287134f6c8f80d94bebe7396f05a9bc42b
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu Jun 20 18:58:36 2013 +0400

    splice: don't pass the address of ->f_pos to methods
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

commit bb69ee27b96110c509d5b92c9ee541d81a821706
Author: Mauro Carvalho Chehab <mchehab@redhat.com>
Date:   Thu Jun 20 10:35:53 2013 -0300

    [media] Fix build when drivers are builtin and frontend modules
    
    There are a large number of reports that the media build is
    not compiling when some drivers are compiled as builtin, while
    the needed frontends are compiled as module.
    
    On the last one of such reports:
    	From: kbuild test robot <fengguang.wu@intel.com>
    	Subject: saa7134-dvb.c:undefined reference to `zl10039_attach'
    
    The .config file has:
    
    	CONFIG_VIDEO_SAA7134=y
    	CONFIG_VIDEO_SAA7134_DVB=y
    	# CONFIG_MEDIA_ATTACH is not set
    	CONFIG_DVB_ZL10039=m
    
    And it produces all those errors:
    
       drivers/built-in.o: In function `set_type':
       tuner-core.c:(.text+0x2f263e): undefined reference to `tea5767_attach'
       tuner-core.c:(.text+0x2f273e): undefined reference to `tda9887_attach'
       drivers/built-in.o: In function `tuner_probe':
       tuner-core.c:(.text+0x2f2d20): undefined reference to `tea5767_autodetection'
       drivers/built-in.o: In function `av7110_attach':
       av7110.c:(.text+0x330bda): undefined reference to `ves1x93_attach'
       av7110.c:(.text+0x330bf7): undefined reference to `stv0299_attach'
       av7110.c:(.text+0x330c63): undefined reference to `tda8083_attach'
       av7110.c:(.text+0x330d09): undefined reference to `ves1x93_attach'
       av7110.c:(.text+0x330d33): undefined reference to `tda8083_attach'
       av7110.c:(.text+0x330d5d): undefined reference to `stv0297_attach'
       av7110.c:(.text+0x330dbe): undefined reference to `stv0299_attach'
       drivers/built-in.o: In function `tuner_attach_dtt7520x':
       ngene-cards.c:(.text+0x3381cb): undefined reference to `dvb_pll_attach'
       drivers/built-in.o: In function `demod_attach_lg330x':
       ngene-cards.c:(.text+0x33828a): undefined reference to `lgdt330x_attach'
       drivers/built-in.o: In function `demod_attach_stv0900':
       ngene-cards.c:(.text+0x3383d5): undefined reference to `stv090x_attach'
       drivers/built-in.o: In function `cineS2_probe':
       ngene-cards.c:(.text+0x338b7f): undefined reference to `drxk_attach'
       drivers/built-in.o: In function `configure_tda827x_fe':
       saa7134-dvb.c:(.text+0x346ae7): undefined reference to `tda10046_attach'
       drivers/built-in.o: In function `dvb_init':
       saa7134-dvb.c:(.text+0x347283): undefined reference to `mt352_attach'
       saa7134-dvb.c:(.text+0x3472cd): undefined reference to `mt352_attach'
       saa7134-dvb.c:(.text+0x34731c): undefined reference to `tda10046_attach'
       saa7134-dvb.c:(.text+0x34733c): undefined reference to `tda10046_attach'
       saa7134-dvb.c:(.text+0x34735c): undefined reference to `tda10046_attach'
       saa7134-dvb.c:(.text+0x347378): undefined reference to `tda10046_attach'
       saa7134-dvb.c:(.text+0x3473db): undefined reference to `tda10046_attach'
       drivers/built-in.o:saa7134-dvb.c:(.text+0x347502): more undefined references to `tda10046_attach' follow
       drivers/built-in.o: In function `dvb_init':
       saa7134-dvb.c:(.text+0x347812): undefined reference to `mt352_attach'
       saa7134-dvb.c:(.text+0x347951): undefined reference to `mt312_attach'
       saa7134-dvb.c:(.text+0x3479a9): undefined reference to `mt312_attach'
    >> saa7134-dvb.c:(.text+0x3479c1): undefined reference to `zl10039_attach'
    
    This is happening because a builtin module can't use directly a symbol
    found on a module. By enabling CONFIG_MEDIA_ATTACH, the configuration
    becomes valid, as dvb_attach() macro loads the module if needed, making
    the symbol available to the builtin module.
    
    While this bug started to appear after the patches that use IS_DEFINED
    macro (like changeset 7b34be71db533f3e0cf93d53cf62d036cdb5418a), this
    bug is a way ancient than that.
    
    The thing is that, before the IS_DEFINED() patches, the logic used to be:
    
           && defined(MODULE))
    struct dvb_frontend *zl10039_attach(struct dvb_frontend *fe,
    					u8 i2c_addr,
    					struct i2c_adapter *i2c);
    static inline struct dvb_frontend *zl10039_attach(struct dvb_frontend *fe,
    					u8 i2c_addr,
    					struct i2c_adapter *i2c)
    {
    	printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
    	return NULL;
    }
    
    The above code, with the .config file used, was evoluting to FALSE
    (instead of TRUE as it should be, as CONFIG_DVB_ZL10039 is 'm'),
    and were adding the static inline code at saa7134-dvb, instead
    of the external call. So, while it weren't producing any compilation
    error, the code weren't working either.
    
    So, as the overhead for using CONFIG_MEDIA_ATTACH is minimal, just
    enable it, if MODULES is defined.
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 8b6fd652641e5ab1892d092e73e83d49291ed638
Author: Shawn Guo <shawn.guo@linaro.org>
Date:   Wed Jun 12 19:30:27 2013 +0800

    irqchip: gic: call gic_cpu_init() as well in CPU_STARTING_FROZEN case
    
    Commit c011470 (irqchip: gic: Perform the gic_secondary_init() call via
    CPU notifier) moves gic_secondary_init() that used to be called in
    .smp_secondary_init hook into a notifier call.  But it changes the
    system behavior a little bit.  Before the commit, gic_cpu_init()
    is called not only when kernel brings up the secondary cores but also
    when system resuming procedure hot-plugs the cores back to kernel.
    While after the commit, the function will not be called in the latter
    case, where the 'action' will not be CPU_STARTING but
    CPU_STARTING_FROZEN.  This behavior difference at least causes the
    following suspend/resume regression on imx6q.
    
    $ echo mem > /sys/power/state
    PM: Syncing filesystems ... done.
    PM: Preparing system for mem sleep
    mmc1: card e624 removed
    Freezing user space processes ... (elapsed 0.01 seconds) done.
    Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
    PM: Entering mem sleep
    PM: suspend of devices complete after 5.930 msecs
    PM: suspend devices took 0.010 seconds
    PM: late suspend of devices complete after 0.343 msecs
    PM: noirq suspend of devices complete after 0.828 msecs
    Disabling non-boot CPUs ...
    CPU1: shutdown
    CPU2: shutdown
    CPU3: shutdown
    Enabling non-boot CPUs ...
    CPU1: Booted secondary processor
    INFO: rcu_sched detected stalls on CPUs/tasks: { 1 2 3} (detected by 0, t=2102 jiffies, g=4294967169, c=4294967168, q=17)
    Task dump for CPU 1:
    swapper/1       R running      0     0      1 0x00000000
    Backtrace:
    [<bf895ff4>] (0xbf895ff4) from [<00000000>] (  (null))
    Backtrace aborted due to bad frame pointer <8007ccdc>
    Task dump for CPU 2:
    swapper/2       R running      0     0      1 0x00000000
    Backtrace:
    [<8075dbdc>] (0x8075dbdc) from [<00000000>] (  (null))
    Backtrace aborted due to bad frame pointer <00000002>
    Task dump for CPU 3:
    swapper/3       R running      0     0      1 0x00000000
    Backtrace:
    [<8075dbdc>] (0x8075dbdc) from [<00000000>] (  (null))
    
    Fix the regression by checking 'action' being CPU_STARTING_FROZEN to
    have gic_cpu_init() called for secondary cores when system resumes.
    
    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Tested-by: Joseph Lo <josephl@nvidia.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>

commit b52e0a7c4e4100f8683af508664e60e1603070f9
Author: Michel Lespinasse <walken@google.com>
Date:   Thu Jun 6 04:41:15 2013 -0700

    x86: Fix trigger_all_cpu_backtrace() implementation
    
    The following change fixes the x86 implementation of
    trigger_all_cpu_backtrace(), which was previously (accidentally,
    as far as I can tell) disabled to always return false as on
    architectures that do not implement this function.
    
    trigger_all_cpu_backtrace(), as defined in include/linux/nmi.h,
    should call arch_trigger_all_cpu_backtrace() if available, or
    return false if the underlying arch doesn't implement this
    function.
    
    x86 did provide a suitable arch_trigger_all_cpu_backtrace()
    implementation, but it wasn't actually being used because it was
    declared in asm/nmi.h, which linux/nmi.h doesn't include. Also,
    linux/nmi.h couldn't easily be fixed by including asm/nmi.h,
    because that file is not available on all architectures.
    
    I am proposing to fix this by moving the x86 definition of
    arch_trigger_all_cpu_backtrace() to asm/irq.h.
    
    Tested via: echo l > /proc/sysrq-trigger
    
    Before the change, this uses a fallback implementation which
    shows backtraces on active CPUs (using
    smp_call_function_interrupt() )
    
    After the change, this shows NMI backtraces on all CPUs
    
    Signed-off-by: Michel Lespinasse <walken@google.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: http://lkml.kernel.org/r/1370518875-1346-1-git-send-email-walken@google.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit abc41254181e901ef5eda2c884ca6cd88a186b6d
Author: Jed Davis <jld@mozilla.com>
Date:   Thu Jun 20 04:07:14 2013 +0100

    perf: arm64: Record the user-mode PC in the call chain.
    
    With this change, we no longer lose the innermost entry in the user-mode
    part of the call chain.  See also the x86 port, which includes the ip,
    and the corresponding change in arch/arm.
    
    Signed-off-by: Jed Davis <jld@mozilla.com>
    Acked-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

commit 5f63adbb4cb9f952a8daee97f89c8811da5fd68a
Author: Mauro Carvalho Chehab <mchehab@redhat.com>
Date:   Thu Jun 20 05:46:00 2013 -0300

    [media] s5p makefiles: don't override other selections on obj-[ym]
    
    The $obj-m/$obj-y vars should be adding new modules to build, not
    overriding it. So, it should never use
    	$obj-y := foo.o
    instead, it should use:
    	$obj-y += foo.o
    
    Failing to do that is very bad, as it will suppress needed modules.
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 8bbd9f04b7d982d1c6aeb5c08f5983b3d0b9e2fe
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Date:   Wed Jun 19 12:04:26 2013 +0530

    powerpc: Fix bad pmd error with book3E config
    
    Book3E uses the hugepd at PMD level and don't encode pte directly
    at the pmd level. So it will find the lower bits of pmd set
    and the pmd_bad check throws error. Infact the current code
    will never take the free_hugepd_range call at all because it will
    clear the pmd if it find a hugepd pointer. Fix this by clearing
    bad pmd only if it is not a hugepd pointer.
    
    This is regression introduced by e2b3d202d1dba8f3546ed28224ce485bc50010be
    "powerpc: Switch 16GB and 16MB explicit hugepages to a different page table format"
    
    Reported-by: Scott Wood <scottwood@freescale.com>
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit 35a2fbc941accd0e9f1bfadd669311786118d874
Author: Anders Hammarquist <iko@iko.pp.se>
Date:   Wed Jun 19 01:45:48 2013 +0200

    USB: serial: ti_usb_3410_5052: new device id for Abbot strip port cable
    
    Add product id for Abbott strip port cable for Precision meter which
    uses the TI 3410 chip.
    
    Signed-off-by: Anders Hammarquist <iko@iko.pp.se>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9e95fc65ededbec083aa91b4faa58ad992c0891
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Jun 19 00:45:34 2013 +0200

    ACPI / LPSS: Power up LPSS devices during enumeration
    
    Commit 7cd8407 (ACPI / PM: Do not execute _PS0 for devices without
    _PSC during initialization) introduced a regression on some systems
    with Intel Lynxpoint Low-Power Subsystem (LPSS) where some devices
    need to be powered up during initialization, but their device objects
    in the ACPI namespace have _PS0 and _PS3 only (without _PSC or power
    resources).
    
    To work around this problem, make the ACPI LPSS driver power up
    devices it knows about by using a new helper function
    acpi_device_fix_up_power() that does all of the necessary
    sanity checks and calls acpi_dev_pm_explicit_set() to put the
    device into D0.
    
    Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit 6ee22e9d59151550a55d370b14109bdae8b58bda
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Jun 19 00:44:45 2013 +0200

    ACPI / PM: Fix error code path for power resources initialization
    
    Commit 781d737 (ACPI: Drop power resources driver) introduced a
    bug in the power resources initialization error code path causing
    a NULL pointer to be referenced in acpi_release_power_resource()
    if there's an error triggering a jump to the 'err' label in
    acpi_add_power_resource().  This happens because the list_node
    field of struct acpi_power_resource has not been initialized yet
    at this point and doing a list_del() on it is a bad idea.
    
    To prevent this problem from occuring, initialize the list_node
    field of struct acpi_power_resource upfront.
    
    Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Tested-by: Lan Tianyu <tianyu.lan@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: 3.9+ <stable@vger.kernel.org>
    Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>

commit 8112006f41fd76ddf4988f8ddd904563db85613c
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Sun Jun 16 00:38:30 2013 +0200

    ACPI / dock: Take ACPI scan lock in write_undock()
    
    Since commit 3757b94 (ACPI / hotplug: Fix concurrency issues and
    memory leaks) acpi_bus_scan() and acpi_bus_trim() must always be
    called under acpi_scan_lock, but currently the following scenario
    violating that requirement is possible:
    
     write_undock()
      handle_eject_request()
       hotplug_dock_devices()
        dock_remove_acpi_device()
         acpi_bus_trim()
    
    Fix that by making write_undock() acquire acpi_scan_lock before
    calling handle_eject_request() as appropriate (begin_undock() is
    under the lock too in analogy with acpi_dock_deferred_cb()).
    
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: 3.9+ <stable@vger.kernel.org>
    Acked-by: Toshi Kani <toshi.kani@hp.com>

commit 204ebc0aa30a7115f300cac39fbb7eeb66524881
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Mon May 20 15:41:45 2013 +0000

    ACPI / resources: call acpi_get_override_irq() only for legacy IRQ resources
    
    acpi_get_override_irq() was added because there was a problem with
    buggy BIOSes passing wrong IRQ() resource for the RTC IRQ.  The
    commit that added the workaround was 61fd47e0c8476 (ACPI: fix two
    IRQ8 issues in IOAPIC mode).
    
    With ACPI 5 enumerated devices there are typically one or more
    extended IRQ resources per device (and these IRQs can be shared).
    However, the acpi_get_override_irq() workaround forces all IRQs in
    range 0 - 15 (the legacy ISA IRQs) to be edge triggered, active high
    as can be seen from the dmesg below:
    
    	ACPI: IRQ 6 override to edge, high
    	ACPI: IRQ 7 override to edge, high
    	ACPI: IRQ 7 override to edge, high
    	ACPI: IRQ 13 override to edge, high
    
    Also /proc/interrupts for the I2C controllers (INT33C2 and INT33C3) shows
    the same thing:
    
    	7:          4          0          0          0   IO-APIC-edge INT33C2:00, INT33C3:00
    
    The _CSR method for INT33C2 (and INT33C3) device returns following
    resource:
    
    	Interrupt (ResourceConsumer, Level, ActiveLow, Shared,,, )
    	{
    		0x00000007,
    	}
    
    which states that this is supposed to be level triggered, active low,
    shared IRQ instead.
    
    Fix this by making sure that acpi_get_override_irq() gets only called
    when we are dealing with legacy IRQ() or IRQNoFlags() descriptors.
    
    While we are there, correct pr_warning() to print the right triggering
    value.
    
    This change turns out to be necessary to make DMA work correctly on
    systems based on the Intel Lynxpoint PCH (Platform Controller Hub).
    
    [rjw: Changelog]
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Cc: 3.9+ <stable@vger.kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit 949785996ec2250fa958fc3a924e5186e9a8fa2c
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Wed Jun 19 11:15:26 2013 -0400

    x86: Fix section mismatch on load_ucode_ap
    
    We are in the process of removing all the __cpuinit annotations.
    While working on making that change, an existing problem was
    made evident:
    
      WARNING: arch/x86/kernel/built-in.o(.text+0x198f2): Section mismatch
      in reference from the function cpu_init() to the function
      .init.text:load_ucode_ap()   The function cpu_init() references
      the function __init load_ucode_ap().  This is often because cpu_init
      lacks a __init annotation or the annotation of load_ucode_ap is wrong.
    
    This now appears because in my working tree, cpu_init() is no longer
    tagged as __cpuinit, and so the audit picks up the mismatch.  The 2nd
    hypothesis from the audit is the correct one, as there was an incorrect
    __init tag on the prototype in the header (but __cpuinit was used on
    the function itself.)
    
    The audit is telling us that the prototype's __init annotation took
    effect and the function did land in the .init.text section.  Checking
    with objdump on a mainline tree that still has __cpuinit shows that
    the __cpuinit on the function takes precedence over the __init on the
    prototype, but that won't be true once we make __cpuinit a no-op.
    
    Even though we are removing __cpuinit, we temporarily align both
    the function and the prototype on __cpuinit so that the changeset
    can be applied to stable trees  if desired.
    
    [ hpa: build fix only, no object code change ]
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: stable <stable@vger.kernel.org> # 3.9+
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Link: http://lkml.kernel.org/r/1371654926-11729-1-git-send-email-paul.gortmaker@windriver.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

commit c0691143dfe1d42ec9bd89de5921ccb6a27ea1b3
Author: David Daney <david.daney@cavium.com>
Date:   Mon Jun 17 08:46:07 2013 -0700

    mn10300: Fix include dependency in irqflags.h et al.
    
    We need to pick up the definition of raw_smp_processor_id() from
    asm/smp.h.  For the !SMP case, we need to supply a definition of
    raw_smp_processor_id().
    
    Because of the include dependencies we cannot use smp_call_func_t in
    asm/smp.h, but we do need linux/thread_info.h
    
    Signed-off-by: David Daney <david.daney@cavium.com>
    Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Acked-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 418a133b714352c35f050d59857f95f769d552d2
Author: James Hogan <james.hogan@imgtec.com>
Date:   Fri Jun 14 10:31:01 2013 +0100

    metag: fix mm/hugetlb.c build breakage
    
    Commit 106c992a5ebe ("mm/hugetlb: add more arch-defined huge_pte
    functions") added an include of <asm-generic/hugetlb.h> to each
    architecture's <asm/hugetlb.h> (except s390).  Unfortunately metag was
    missed which resulted in build errors when hugetlbfs is enabled (see
    below).
    
    Add the include for metag too to fix the build errors:
    
      mm/hugetlb.c In function 'make_huge_pte':
      mm/hugetlb.c +2250 : error: implicit declaration of function 'huge_pte_mkwrite'
      mm/hugetlb.c +2250 : error: implicit declaration of function 'huge_pte_mkdirty'
      ...
    
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 35b03aec919c952e67b0b093638e0d79b468f9bc
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date:   Wed Jun 19 09:16:54 2013 +0200

    s390/mem_detect: fix memory hole handling
    
    With git commit 996b4a7d "s390/mem_detect: remove artificial kdump
    memory types" the memory detection code got simplified.
    As a side effect the array that describes memory chunks may now
    contain empty (zeroed) entries.
    All call sites can handle this except for
    
    drivers/s390/char/zcore.c::zcore_memmap_open
    
    which has a really odd user space interface. The easiest fix is to
    change the memory hole handling code, so that no empty entries exist
    before the last valid entry is reached.
    
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit 722a860ecb29aa34ec6f7d7f32b949209e86a2f3
Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
Date:   Fri Jun 14 10:44:30 2013 -0300

    [media] exynos4-is: Fix FIMC-IS clocks initialization
    
    The ISP clock register content is not preserved over the ISP power domain
    off/on cycle. Instead of setting the clock frequencies once at probe time
    the clock rates set up is moved to the runtime_resume handler, which is
    invoked after the related power domain is already enabled, ensuring the
    clocks are properly configured when the device is actively used.
    This fixes the FIMC-IS malfunctions and STREAM ON timeout errors accuring
    on some boards:
    [ 59.860000] fimc_is_general_irq_handler:583 ISR_NDONE: 5: 0x800003e8, IS_ERROR_UNKNOWN
    [ 59.860000] fimc_is_general_irq_handler:586 IS_ERROR_TIME_OUT
    
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 29bb9e5a75684106a37593ad75ec75ff8312731b
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Fri May 24 15:23:40 2013 -0400

    tracing/context-tracking: Add preempt_schedule_context() for tracing
    
    Dave Jones hit the following bug report:
    
     ===============================
     [ INFO: suspicious RCU usage. ]
     3.10.0-rc2+ #1 Not tainted
     -------------------------------
     include/linux/rcupdate.h:771 rcu_read_lock() used illegally while idle!
     other info that might help us debug this:
     RCU used illegally from idle CPU! rcu_scheduler_active = 1, debug_locks = 0
     RCU used illegally from extended quiescent state!
     2 locks held by cc1/63645:
      #0:  (&rq->lock){-.-.-.}, at: [<ffffffff816b39fd>] __schedule+0xed/0x9b0
      #1:  (rcu_read_lock){.+.+..}, at: [<ffffffff8109d645>] cpuacct_charge+0x5/0x1f0
    
     CPU: 1 PID: 63645 Comm: cc1 Not tainted 3.10.0-rc2+ #1 [loadavg: 40.57 27.55 13.39 25/277 64369]
     Hardware name: Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H, BIOS F12a 04/23/2010
      0000000000000000 ffff88010f78fcf8 ffffffff816ae383 ffff88010f78fd28
      ffffffff810b698d ffff88011c092548 000000000023d073 ffff88011c092500
      0000000000000001 ffff88010f78fd60 ffffffff8109d7c5 ffffffff8109d645
     Call Trace:
      [<ffffffff816ae383>] dump_stack+0x19/0x1b
      [<ffffffff810b698d>] lockdep_rcu_suspicious+0xfd/0x130
      [<ffffffff8109d7c5>] cpuacct_charge+0x185/0x1f0
      [<ffffffff8109d645>] ? cpuacct_charge+0x5/0x1f0
      [<ffffffff8108dffc>] update_curr+0xec/0x240
      [<ffffffff8108f528>] put_prev_task_fair+0x228/0x480
      [<ffffffff816b3a71>] __schedule+0x161/0x9b0
      [<ffffffff816b4721>] preempt_schedule+0x51/0x80
      [<ffffffff816b4800>] ? __cond_resched_softirq+0x60/0x60
      [<ffffffff816b6824>] ? retint_careful+0x12/0x2e
      [<ffffffff810ff3cc>] ftrace_ops_control_func+0x1dc/0x210
      [<ffffffff816be280>] ftrace_call+0x5/0x2f
      [<ffffffff816b681d>] ? retint_careful+0xb/0x2e
      [<ffffffff816b4805>] ? schedule_user+0x5/0x70
      [<ffffffff816b4805>] ? schedule_user+0x5/0x70
      [<ffffffff816b6824>] ? retint_careful+0x12/0x2e
     ------------[ cut here ]------------
    
    What happened was that the function tracer traced the schedule_user() code
    that tells RCU that the system is coming back from userspace, and to
    add the CPU back to the RCU monitoring.
    
    Because the function tracer does a preempt_disable/enable_notrace() calls
    the preempt_enable_notrace() checks the NEED_RESCHED flag. If it is set,
    then preempt_schedule() is called. But this is called before the user_exit()
    function can inform the kernel that the CPU is no longer in user mode and
    needs to be accounted for by RCU.
    
    The fix is to create a new preempt_schedule_context() that checks if
    the kernel is still in user mode and if so to switch it to kernel mode
    before calling schedule. It also switches back to user mode coming back
    from schedule in need be.
    
    The only user of this currently is the preempt_enable_notrace(), which is
    only used by the tracing subsystem.
    
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1369423420.6828.226.camel@gandalf.local.home
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit 873b4c65b519fd769940eb281f77848227d4e5c1
Author: Vincent Guittot <vincent.guittot@linaro.org>
Date:   Wed Jun 5 10:13:11 2013 +0200

    sched: Fix clear NOHZ_BALANCE_KICK
    
    I have faced a sequence where the Idle Load Balance was sometime not
    triggered for a while on my platform, in the following scenario:
    
     CPU 0 and CPU 1 are running tasks and CPU 2 is idle
    
     CPU 1 kicks the Idle Load Balance
     CPU 1 selects CPU 2 as the new Idle Load Balancer
     CPU 2 sets NOHZ_BALANCE_KICK for CPU 2
     CPU 2 sends a reschedule IPI to CPU 2
    
     While CPU 3 wakes up, CPU 0 or CPU 1 migrates a waking up task A on CPU 2
    
     CPU 2 finally wakes up, runs task A and discards the Idle Load Balance
           task A quickly goes back to sleep (before a tick occurs on CPU 2)
     CPU 2 goes back to idle with NOHZ_BALANCE_KICK set
    
    Whenever CPU 2 will be selected as the ILB, no reschedule IPI will be sent
    because NOHZ_BALANCE_KICK is already set and no Idle Load Balance will be
    performed.
    
    We must wait for the sched softirq to be raised on CPU 2 thanks to another
    part the kernel to come back to clear NOHZ_BALANCE_KICK.
    
    The proposed solution clears NOHZ_BALANCE_KICK in schedule_ipi if
    we can't raise the sched_softirq for the Idle Load Balance.
    
    Change since V1:
    
    - move the clear of NOHZ_BALANCE_KICK in got_nohz_idle_kick if the ILB
      can't run on this CPU (as suggested by Peter)
    
    Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1370419991-13870-1-git-send-email-vincent.guittot@linaro.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit f1a527899ef0a8a241eb3bea619eb2e29d797f44
Author: Stephane Eranian <eranian@google.com>
Date:   Fri Jun 7 23:22:10 2013 +0200

    perf/x86: Fix broken PEBS-LL support on SNB-EP/IVB-EP
    
    This patch fixes broken support of PEBS-LL on SNB-EP/IVB-EP.
    For some reason, the LDLAT extra reg definition for snb_ep
    showed up as duplicate in the snb table.
    
    This patch moves the definition of LDLAT back into the
    snb_ep table.
    
    Thanks to Don Zickus for tracking this one down.
    
    Signed-off-by: Stephane Eranian <eranian@google.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/20130607212210.GA11849@quad
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit 9bb5d40cd93c9dd4be74834b1dcb1ba03629716b
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Jun 4 10:44:21 2013 +0200

    perf: Fix mmap() accounting hole
    
    Vince's fuzzer once again found holes. This time it spotted a leak in
    the locked page accounting.
    
    When an event had redirected output and its close() was the last
    reference to the buffer we didn't have a vm context to undo accounting.
    
    Change the code to destroy the buffer on the last munmap() and detach
    all redirected events at that time. This provides us the right context
    to undo the vm accounting.
    
    Reported-and-tested-by: Vince Weaver <vincent.weaver@maine.edu>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/20130604084421.GI8923@twins.programming.kicks-ass.net
    Cc: <stable@kernel.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit 07868fc6aaf57847b0f3a3d53086b7556eb83f4a
Author: Igor Mammedov <imammedo@redhat.com>
Date:   Mon Jun 10 18:31:11 2013 +0200

    x86: kvmclock: zero initialize pvclock shared memory area
    
    kernel might hung in pvclock_clocksource_read() due to
    uninitialized memory might contain odd version value in
    following cycle:
    
            do {
                    version = __pvclock_read_cycles(src, &ret, &flags);
            } while ((src->version & 1) || version != src->version);
    
    if secondary kvmclock is accessed before it's registered with kvm.
    
    Clear garbage in pvclock shared memory area right after it's
    allocated to avoid this issue.
    
    Ref: https://bugzilla.kernel.org/show_bug.cgi?id=59521
    Signed-off-by: Igor Mammedov <imammedo@redhat.com>
    [See BZ for analysis.  We may want a different fix for 3.11, but
     this is the safest for now - Paolo]
    Cc: <stable@vger.kernel.org> # 3.8
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit f8941fbe204fa2fb51e7acd8bfd0f51225fe03b4
Author: Scott Wood <scottwood@freescale.com>
Date:   Tue Jun 11 11:38:31 2013 -0500

    kvm/ppc/booke: Delay kvmppc_lazy_ee_enable
    
    kwmppc_lazy_ee_enable() should be called as late as possible,
    or else we get things like WARN_ON(preemptible()) in enable_kernel_fp()
    in configurations where preemptible() works.
    
    Note that book3s_pr already waits until just before __kvmppc_vcpu_run
    to call kvmppc_lazy_ee_enable().
    
    Signed-off-by: Scott Wood <scottwood@freescale.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit 23a01138efe216f8084cfaa74b0b90dd4b097441
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date:   Tue Jun 18 09:05:36 2013 -0500

    sparc: tsb must be flushed before tlb
    
    This fixes a race where a cpu may re-load a tlb from a stale tsb right
    after it has been flushed by a remote function call.
    
    I still see some instability when stressing the system with parallel
    kernel builds while creating memory pressure by writing to
    /proc/sys/vm/nr_hugepages, but this patch improves the stability
    significantly.
    
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Acked-by: Bob Picco <bob.picco@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit f670758f5b829169562e1016a72af0c59360a541
Author: Tushar Behera <tushar.behera@linaro.org>
Date:   Mon Jun 17 14:37:44 2013 +0530

    sparc,leon: Convert to use devm_ioremap_resource
    
    Commit 75096579c3ac ("lib: devres: Introduce devm_ioremap_resource()")
    introduced devm_ioremap_resource() and deprecated the use of
    devm_request_and_ioremap().
    
    While at it, also remove the error message as devm_ioremap_resource()
    also prints similar error message.
    
    Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
    CC: sparclinux@vger.kernel.org
    CC: "David S. Miller" <davem@davemloft.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 771a37ff4d80b80db3b0df3e7696f14b298c67b7
Author: bob picco <bpicco@meloft.net>
Date:   Tue Jun 11 14:54:51 2013 -0400

    sparc64 address-congruence property
    
    The Machine Description (MD) property "address-congruence-offset" is
    optional. According to the MD specification the value is assumed 0UL when
    not present. This caused early boot failure on T5.
    
    Signed-off-by: Bob Picco <bob.picco@oracle.com>
    CC: sparclinux@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit d72ee6be58b7c99a6e8da6584106c5958dae2bf8
Author: Andreas Larsson <andreas@gaisler.com>
Date:   Mon Jun 10 08:56:41 2013 +0200

    sparc32, leon: Enable interrupts before going idle to avoid getting stuck
    
    This enables interrupts for Leon before having the CPU enter power-down mode.
    
    Commit 87fa05aeb3a5e8e21b1a5510eef6983650eff092, "sparc: Use generic idle loop",
    gets the CPU stuck on idle for Leon systems. On Leon, disabling interrupts and
    powering down the processor will get the processor stuck waiting for an
    interrupt that will never be reacted to.
    
    Signed-off-by: Andreas Larsson <andreas@gaisler.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 1ffbc51a0d00e52983c70aa7c8dbc7b621d6287d
Author: Andreas Larsson <andreas@gaisler.com>
Date:   Mon Jun 10 08:53:28 2013 +0200

    sparc32, leon: Remove separate "ticker" timer for SMP
    
    This reduces the need from two timers to one timer.
    
    Moreover, without this patch, when the "ticker" timer triggers timer_cs_read via
    tick_periodic it reads the value of the usual timer it can get an wrapped timer
    value without timer_cs_internal_counter having been updated leading to the clock
    going backwards. This effectively hangs one cpu that gets stuck in
    update_wall_time with an offset slightly smaller than 0xffffffffffffffff.
    
    Signed-off-by: Andreas Larsson <andreas@gaisler.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 117a0c5fc9c2d06045bd217385b2b39ea426b5a6
Author: Zhao Hongjiang <zhaohongjiang@huawei.com>
Date:   Sun Jun 9 16:57:58 2013 +0800

    sparc: kernel: using strlcpy() instead of strcpy()
    
    'boot_command_line' and 'full_boot_str' has a fix length, 'cmdline_p' and
    'boot_command' maybe larger than them. So use strlcpy() instead of strcpy()
    to avoid memory overflow.
    
    Signed-off-by: Zhao Hongjiang <zhaohongjiang@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 242ece22f0bd90e237365e51c5bd90a21693d6c3
Author: Chen Gang <gang.chen@asianux.com>
Date:   Thu May 30 11:35:22 2013 +0800

    arch: sparc: prom: looping issue, need additional length check in the outside looping
    
    When "cp >= barg_buf + BARG_LEN-2", it breaks internel looping 'while',
    but outside loop 'for' still has effect, so "*cp++ = ' '" will continue
    repeating which may cause memory overflow.
    
    So need additional length check for it in the outside looping.
    
    Also beautify the related code which found by "./scripts/checkpatch.pl"
    
    Signed-off-by: Chen Gang <gang.chen@asianux.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit dbebe0da64d0738a21221a7f9d29510b9f29d908
Author: Denis Efremov <yefremov.denis@gmail.com>
Date:   Thu May 9 14:36:54 2013 +0400

    sparc: remove inline marking of EXPORT_SYMBOL functions
    
    EXPORT_SYMBOL and inline directives are contradictory to each other.
    The patch fixes this inconsistency.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Denis Efremov <yefremov.denis@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit ccd847b2c101a7e5772d0463ac76f7c18732675a
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Tue May 7 11:55:55 2013 +0200

    sparc: Switch to asm-generic/linkage.h
    
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit c9036e9f3b2b77f678572260e1ef1075fcb08c36
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Wed Jun 19 12:35:42 2013 +0400

    mconsole: we'd better initialize pos before passing it to vfs_read()...
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

commit 4026099a3118a1e038c48f3f85203a674938025b
Author: Sebastian Ott <sebott@linux.vnet.ibm.com>
Date:   Tue Jun 18 17:38:31 2013 +0200

    s390/dma: support debug_dma_mapping_error
    
    Without this patch drivers will get blamed (CONFIG_DMA_API_DEBUG=y)
    for not calling dma_mapping_error (even if they do).
    
    Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
    Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit 73e5a848426fae8e7f1f685389aa61d7a98e7c36
Author: Sebastian Ott <sebott@linux.vnet.ibm.com>
Date:   Tue Jun 18 17:32:26 2013 +0200

    s390/dma: fix mapping_error detection
    
    The map_page implementation of s390 returns DMA_ERROR_CODE in an error
    situation. Correctly test if a mapping was erroneous (DMA_ERROR_CODE is
    defined as ~0).
    
    Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
    Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit 690cec8e70c211d1f5f6e520b21a68d0306173b6
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Fri Jun 14 01:18:44 2013 +0100

    s390/irq: Only define synchronize_irq() on SMP
    
    In uniprocessor configurations, synchronize_irq() is defined in
    <linux/hardirq.h> as a macro, and this function definition fails to
    compile.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: stable@vger.kernel.org # 3.9
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit be66227151c0cd4da536098c3ee07809101c6faa
Author: Shawn Joseph <jms.576@gmail.com>
Date:   Tue Jun 18 23:07:45 2013 -0700

    Input: xpad - fix for "Mad Catz Street Fighter IV FightPad" controllers
    
    Added MAP_TRIGGERS_TO_BUTTONS for Mad Catz Street Fighter IV FightPad
    device. This controller model was already supported by the xpad
    driver, but none of the buttons work correctly without this change.
    
    Tested on kernel version 3.9.5.
    
    Signed-off-by: Shawn Joseph <jms.576@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

commit 7d753b0d387073be243f7ff52cc84dfa1391c1e7
Author: Ping Cheng <pinglinux@gmail.com>
Date:   Tue Jun 18 23:14:25 2013 -0700

    Input: wacom - add a new stylus (0x100802) for Intuos5 and Cintiqs
    
    Signed-off-by: Ping Cheng <pingc@wacom.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

commit ebc0bad4a05ad63979e8bc115cea3b8abdf814c7
Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date:   Wed Jun 19 03:14:20 2013 +0200

    drm/prime: Honor requested file flags when exporting a buffer
    
    The DRM PRIME API passes file flags to the driver for the exported
    buffer. Honor them instead of hardcoding 0600.
    
    Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dave Airlie <airlied@redhat.com>

commit d1603990ea626668c78527376d9ec084d634202d
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Tue Jun 18 12:33:40 2013 -0700

    x86: fix build error and kconfig for ia32_emulation and binfmt
    
    Fix kconfig warning and build errors on x86_64 by selecting BINFMT_ELF
    when COMPAT_BINFMT_ELF is being selected.
    
    warning: (IA32_EMULATION) selects COMPAT_BINFMT_ELF which has unmet direct dependencies (COMPAT && BINFMT_ELF)
    
    fs/built-in.o: In function `elf_core_dump':
    compat_binfmt_elf.c:(.text+0x3e093): undefined reference to `elf_core_extra_phdrs'
    compat_binfmt_elf.c:(.text+0x3ebcd): undefined reference to `elf_core_extra_data_size'
    compat_binfmt_elf.c:(.text+0x3eddd): undefined reference to `elf_core_write_extra_phdrs'
    compat_binfmt_elf.c:(.text+0x3f004): undefined reference to `elf_core_write_extra_data'
    
    [ hpa: This was sent to me for -next but it is a low risk build fix ]
    
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Link: http://lkml.kernel.org/r/51C0B614.5000708@infradead.org
    Cc: <stable@vger.kernel.org>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

commit d65ea48dc61ffdf6cd7f25b4c319bbd68015e018
Author: John David Anglin <dave.anglin@bell.net>
Date:   Sun Jun 2 12:21:48 2013 -0400

    parisc: Use unshadowed index register for flush instructions in flush_dcache_page_asm and flush_icache_page_asm
    
    The comment at the start of pacache.S states that the base and index
    registers used for fdc,fic, and pdc instructions should not use shadowed
    registers. Although this is probably unnecessary for tmpalias flushes,
    there is also no reason not to comply.
    
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>

commit 2cc7138f4347df939ce03f313e3d87794bab36f8
Author: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Date:   Fri Jun 14 09:05:41 2013 +0200

    parisc: provide pci_mmap_page_range() for parisc
    
    pci_mmap_page_range() is needed for X11-server support on C8000 with ATI
    FireGL card.
    
    Signed-off-by Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Helge Deller <deller@gmx.de>

commit 9a66d1869d90f13fbaf83dcce5b1aeec86fbc699
Author: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Date:   Sun Jun 9 23:00:21 2013 +0200

    parisc: fix serial ports on C8000 workstation
    
    The C8000 workstation (64 bit kernel only) has a somewhat different
    serial port configuration than other models.
    Thomas Bogendoerfer sent a patch to fix this in September 2010, which
    was now minimally modified by me.
    
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Helge Deller <deller@gmx.de>

commit 91ea8207168793b365322be3c90a4ee9e8b03ed4
Author: Helge Deller <deller@gmx.de>
Date:   Wed Jun 5 20:50:01 2013 +0000

    parisc: fix kernel BUG at arch/parisc/include/asm/mmzone.h:50 (part 2)
    
    Make sure that we really return -1 (instead of 0x00ff) as node id for
    page frame numbers which are not physically available.
    
    This finally fixes the kernel panic when running
    cat /proc/kpageflags /proc/kpagecount.
    
    Theoretically this patch now limits the number of physical memory ranges
    to 127 instead of 254, but currently we have MAX_PHYSMEM_RANGES
    hardcoded to 8 which is sufficient for all existing parisc machines.
    
    Signed-off-by: Helge Deller <deller@gmx.de>

commit 5548f98c46538d1da04eff179a52e50537d11465
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Tue Jun 18 17:29:44 2013 +0300

    spi/pxa2xx: use GFP_ATOMIC in sg table allocation
    
    pxa2xx_spi_map_dma_buffer() gets called in tasklet context so we can't
    sleep when we allocate a new sg table. Use GFP_ATOMIC here instead.
    
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Cc: stable@vger.kernel.org

commit 875979368eb4cfecff9f0e97625b90cc6009269d
Author: Ming Lei <ming.lei@canonical.com>
Date:   Sat Jun 15 16:36:38 2013 +0800

    firmware loader: fix use-after-free by double abort
    
    fw_priv->buf is accessed in both request_firmware_load() and
    writing to sysfs file of 'loading' context, but not protected
    by 'fw_lock' entirely. The patch makes sure that access on
    'fw_priv->buf' is protected by the lock.
    
    So fixes the double abort problem reported by nirinA raseliarison:
    
    	http://lkml.org/lkml/2013/6/14/188
    
    Reported-and-tested-by: nirinA raseliarison <nirina.raseliarison@gmail.com>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Cc: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable <stable@vger.kernel.org> # 3.9
    Signed-off-by: Ming Lei <ming.lei@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 035978beaf79e3bd0c4f6308e8c8ce5067e26b9d
Author: George Spelvin <linux@horizon.com>
Date:   Mon Jun 17 01:45:50 2013 -0400

    usb: phy: Improve Kconfig help for CONFIG_USB_PHY
    
    The previous text confused users by not describing the very common
    (e.g. x86 PC) sitations where no PHY driver is necessary.
    
    Signed-off-by: George Spelvin <linux@horizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0541881502a1276149889fe468662ff6a8fc8f6d
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Thu Jun 13 13:17:02 2013 -0700

    range: Do not add new blank slot with add_range_with_merge
    
    Joshua reported: Commit cd7b304dfaf1 (x86, range: fix missing merge
    during add range) broke mtrr cleanup on his setup in 3.9.5.
    corresponding commit in upstream is fbe06b7bae7c.
    
    The reason is add_range_with_merge could generate blank spot.
    
    We could avoid that by searching new expanded start/end, that
    new range should include all connected ranges in range array.
    At last add the new expanded start/end to the range array.
    Also move up left array so do not add new blank slot in the
    range array.
    
    -v2: move left array to avoid enhance add_range()
    -v3: include fix from Joshua about memmove declaring when
         DYN_DEBUG is used.
    
    Reported-by: Joshua Covington <joshuacov@googlemail.com>
    Tested-by: Joshua Covington <joshuacov@googlemail.com>
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Link: http://lkml.kernel.org/r/1371154622-8929-3-git-send-email-yinghai@kernel.org
    Cc: <stable@vger.kernel.org> v3.9
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

commit d8d386c10630d8f7837700f4c466443d49e12cc0
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Thu Jun 13 13:17:01 2013 -0700

    x86, mtrr: Fix original mtrr range get for mtrr_cleanup
    
    Joshua reported: Commit cd7b304dfaf1 (x86, range: fix missing merge
    during add range) broke mtrr cleanup on his setup in 3.9.5.
    corresponding commit in upstream is fbe06b7bae7c.
    
      *BAD*gran_size: 64K chunk_size: 16M num_reg: 6 lose cover RAM: -0G
    
    https://bugzilla.kernel.org/show_bug.cgi?id=59491
    
    So it rejects new var mtrr layout.
    
    It turns out we have some problem with initial mtrr range retrieval.
    The current sequence is:
    	x86_get_mtrr_mem_range
    		==> bunchs of add_range_with_merge
    		==> bunchs of subract_range
    		==> clean_sort_range
    	add_range_with_merge for [0,1M)
    	sort_range()
    
    add_range_with_merge could have blank slots, so we can not just
    sort only, that will have final result have extra blank slot in head.
    
    So move that calling add_range_with_merge for [0,1M), with that we
    could avoid extra clean_sort_range calling.
    
    Reported-by: Joshua Covington <joshuacov@googlemail.com>
    Tested-by: Joshua Covington <joshuacov@googlemail.com>
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Link: http://lkml.kernel.org/r/1371154622-8929-2-git-send-email-yinghai@kernel.org
    Cc: <stable@vger.kernel.org> v3.9
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

commit 764bcbc5a6d7a2f3e75c9f0e4caa984e2926e346
Author: Zhanghaoyu (A) <haoyu.zhang@huawei.com>
Date:   Fri Jun 14 07:36:13 2013 +0000

    KVM: x86: remove vcpu's CPL check in host-invoked XCR set
    
    __kvm_set_xcr function does the CPL check when set xcr. __kvm_set_xcr is
    called in two flows, one is invoked by guest, call stack shown as below,
    
      handle_xsetbv(or xsetbv_interception)
        kvm_set_xcr
          __kvm_set_xcr
    
    the other one is invoked by host, for example during system reset:
    
      kvm_arch_vcpu_ioctl
        kvm_vcpu_ioctl_x86_set_xcrs
          __kvm_set_xcr
    
    The former does need the CPL check, but the latter does not.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Zhang Haoyu <haoyu.zhang@huawei.com>
    [Tweaks to commit message. - Paolo]
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit 14c14414d157ea851119c96c61a17306a2b4a035
Author: Maxim Patlasov <MPatlasov@parallels.com>
Date:   Thu Jun 13 12:16:39 2013 +0400

    fuse: hold i_mutex in fuse_file_fallocate()
    
    Changing size of a file on server and local update (fuse_write_update_size)
    should be always protected by inode->i_mutex. Otherwise a race like this is
    possible:
    
    1. Process 'A' calls fallocate(2) to extend file (~FALLOC_FL_KEEP_SIZE).
    fuse_file_fallocate() sends FUSE_FALLOCATE request to the server.
    2. Process 'B' calls ftruncate(2) shrinking the file. fuse_do_setattr()
    sends shrinking FUSE_SETATTR request to the server and updates local i_size
    by i_size_write(inode, outarg.attr.size).
    3. Process 'A' resumes execution of fuse_file_fallocate() and calls
    fuse_write_update_size(inode, offset + length). But 'offset + length' was
    obsoleted by ftruncate from previous step.
    
    Changed in v2 (thanks Brian and Anand for suggestions):
     - made relation between mutex_lock() and fuse_set_nowrite(inode) more
       explicit and clear.
     - updated patch description to use ftruncate(2) in example
    
    Signed-off-by: Maxim V. Patlasov <MPatlasov@parallels.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>

commit f75773103d24faaa75323597c2804edfb4a48a52
Author: David Daney <ddaney@caviumnetworks.com>
Date:   Sun Jun 16 13:06:28 2013 -0700

    [IA64] Fix include dependency in asm/irqflags.h
    
    asm/kregs.h isn't always included first, so we need an explicit include.
    
    [Fix build breakage introduced by f21afc25f9ed45b8ffe200d0f071b0caec3ed2ef
     smp.h: Use local_irq_{save,restore}() in !SMP version of on_each_cpu().]
    
    Signed-off-by: David Daney <david.daney@cavium.com>
    Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Tony Luck <tony.luck@intel.com>

commit 19ab428f4b7988ef3ac727c680efc193ef53ce14
Author: Stephen Warren <swarren@nvidia.com>
Date:   Fri Jun 14 16:14:14 2013 +0100

    ARM: 7759/1: decouple CPU offlining from reboot/shutdown
    
    Add comments to machine_shutdown()/halt()/power_off()/restart() that
    describe their purpose and/or requirements re: CPUs being active/not.
    
    In machine_shutdown(), replace the call to smp_send_stop() with a call to
    disable_nonboot_cpus(). This completely disables all but one CPU, thus
    satisfying the requirement that only a single CPU be active for kexec.
    Adjust Kconfig dependencies for this change.
    
    In machine_halt()/power_off()/restart(), call smp_send_stop() directly,
    rather than via machine_shutdown(); these functions don't need to
    completely de-activate all CPUs using hotplug, but rather just quiesce
    them.
    
    Remove smp_kill_cpus(), and its call from smp_send_stop().
    smp_kill_cpus() was indirectly calling smp_ops.cpu_kill() without calling
    smp_ops.cpu_die() on the target CPUs first. At least some implementations
    of smp_ops had issues with this; it caused cpu_kill() to hang on Tegra,
    for example. Since smp_send_stop() is only used for shutdown, halt, and
    power-off, there is no need to attempt any kind of CPU hotplug here.
    
    Adjust Kconfig to reflect that machine_shutdown() (and hence kexec)
    relies upon disable_nonboot_cpus(). However, this alone doesn't guarantee
    that hotplug will work, or even that hotplug is implemented for a
    particular piece of HW that a multi-platform zImage runs on. Hence, add
    error-checking to machine_kexec() to determine whether it did work.
    
    Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Stephen Warren <swarren@nvidia.com>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Tested-by:  Zhangfei Gao <zhangfei.gao@gmail.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit 7c61c3d8f44d5d822f758754287af644307b4af9
Author: Peter Hurley <peter@hurleysoftware.com>
Date:   Thu Jun 13 15:56:37 2013 -0400

    tty: Fix transient pty write() EIO
    
    Commit 699390354da6c258b65bf8fa79cfd5feaede50b6
    ('pty: Ignore slave pty close() if never successfully opened')
    introduced a bug with ptys whereby a write() in parallel with an
    open() on an existing pty could mistakenly indicate an I/O error.
    
    Only indicate an I/O error if the condition on open() actually exists.
    
    Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
    Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
    Tested-by: Mikael Pettersson <mikpe@it.uu.se>
    Cc: stable <stable@vger.kernel.org> # 3.9
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef223fb3d1d61c2a95a89cdc02f8e86dac96ddc3
Author: Ross Lagerwall <rosslagerwall@gmail.com>
Date:   Fri Jun 14 23:24:25 2013 +0100

    tty/vt: Return EBUSY if deallocating VT1 and it is busy
    
    Commit 421b40a6286e ("tty/vt: Fix vc_deallocate() lock order") changed
    the behavior when deallocating VT 1.  Previously if trying to
    deallocate VT1 and it is busy, we would return EBUSY.  The commit
    changed this to return 0 (success).
    
    This commit restores the old behavior.
    
    Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com>
    Tested-by: Mikael Pettersson <mikpe@it.uu.se>
    Acked-by: Peter Hurley <peter@hurleysoftware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a908eb9936ba06678720226feed891d01827066f
Author: Gianluca Gennari <gennarone@gmail.com>
Date:   Sun Jun 2 17:24:24 2013 -0300

    [media] rtl28xxu: fix buffer overflow when probing Rafael Micro r820t tuner
    
    As suggested by Antti, this patch replaces:
    https://patchwork.kernel.org/patch/2649861/
    The buffer overflow is fixed by reading only the r820t ID register.
    
    Signed-off-by: Gianluca Gennari <gennarone@gmail.com>
    Acked-by: Antti Palosaari <crope@iki.fi>
    Reviewed-by: Antti Palosaari <crope@iki.fi>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 0abb6aeacc20822cd7baee82fd3b61169ca3f32e
Author: Padmavathi Venna <padma.v@samsung.com>
Date:   Wed Jun 12 13:53:44 2013 +0530

    ARM: dts: Correct the base address of pinctrl_3 on Exynos5250
    
    This patch corrects the base address of pinctrl_3 on Exynos5250
    platform.
    
    Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
    Acked-by: Kukjin Kim <kgene.kim@samsung.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>

commit 69f91ff8c93c778cb65b71d9b2d95ff62956354f
Author: Magnus Damm <damm@opensource.se>
Date:   Wed Jun 12 10:56:43 2013 +0100

    ARM: 7756/1: zImage/virt: remove hyp-stub.S during distclean
    
    Make sure hyp-stub.S gets removed during make distclean,
    this left over file was introduced in commit:
    
    424e599 ARM: zImage/virt: hyp mode entry support for the zImage loader
    
    Signed-off-by: Magnus Damm <damm@opensource.se>
    Acked-by: Dave Martin <dave.martin@linaro.org>
    Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit 1bc39742aab09248169ef9d3727c9def3528b3f3
Author: Simon Baatz <gmbnomis@gmail.com>
Date:   Mon Jun 10 21:10:12 2013 +0100

    ARM: 7755/1: handle user space mapped pages in flush_kernel_dcache_page
    
    Commit f8b63c1 made flush_kernel_dcache_page a no-op assuming that
    the pages it needs to handle are kernel mapped only.  However, for
    example when doing direct I/O, pages with user space mappings may
    occur.
    
    Thus, continue to do lazy flushing if there are no user space
    mappings.  Otherwise, flush the kernel cache lines directly.
    
    Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Cc: <stable@vger.kernel.org> # 3.2+
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit 049be07053ebbf0ee8543caea23ae7bdf0765bb2
Author: Gregory CLEMENT <gregory.clement@free-electrons.com>
Date:   Mon Jun 10 18:05:51 2013 +0100

    ARM: 7754/1: Fix the CPU ID and the mask associated to the PJ4B
    
    This commit fixes the ID and mask for the PJ4B which was too
    restrictive and didn't match the CPU of the Armada 370 SoC.
    
    Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
    Reviewed-by: Will Deacon <will.deacon@arm.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit 37468b30a3948bbbdf9d664678f611510d987e65
Author: Po-Yu Chuang <ratbert.chuang@gmail.com>
Date:   Fri Jun 7 12:15:45 2013 +0100

    ARM: 7753/1: map_init_section flushes incorrect pmd
    
    This bug was introduced in commit e651eab0.
    Some v4/v5 platforms failed to boot due to this.
    
    Signed-off-by: Po-Yu Chuang <ratbert.chuang@gmail.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit 691557941af4c12bd307ad81a4d9fa9c7743ac28
Author: Jon Medhurst <tixy@linaro.org>
Date:   Fri Jun 7 10:35:35 2013 +0100

    ARM: 7752/1: errata: LoUIS bit field in CLIDR register is incorrect
    
    On Cortex-A9 before version r1p0, the LoUIS bit field of the CLIDR
    register returns zero when it should return one. This leads to cache
    maintenance operations which rely on this value to not function as
    intended, causing data corruption.
    
    The workaround for this errata is to detect affected CPUs and correct
    the LoUIS value read.
    
    Acked-by: Will Deacon <will.deacon@arm.com>
    Acked-by: Nicolas Pitre <nico@linaro.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Jon Medhurst <tixy@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit e32aa85ab49203104019025eba83f03f88a3a0e3
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Mon Jun 17 11:04:02 2013 +0200

    ALSA: hda - Add models for Dell headset jacks
    
    These headset jacks keep coming in on more and more platforms, and
    it's possible I don't catch them all. Make it easier to test and
    verify by making models.
    
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 36691e1be6ec551eef4a5225f126a281f8c051c2
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jun 17 10:25:02 2013 +0200

    ALSA: usb-audio: Fix invalid volume resolution for Logitech HD Webcam c310
    
    Just like the previous fix for LogitechHD Webcam c270 in commit
    11e7064f35bb87da8f427d1aa4bbd8b7473a3993, c310 model also requires the
    same workaround for avoiding the kernel warning.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59741
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 6ab982e8cf8e5760da407ccdc4abc815bea23179
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jun 17 10:19:49 2013 +0200

    ALSA: hda - Fix pin configurations for MacBook Air 4,2
    
    MacBook Air 4,2 requires the whole default pin configuration table to
    be overridden by the driver, as usual, as Apple's machines don't set
    up properly after boot.  Otherwise mic won't work, and other ill
    effect may happen.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59381
    Reported-and-tested-by: Peter John Hartman <peterjohnhartman@gmail.com>
    Cc: <stable@vger.kernel.org> [v3.9+]
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 342cda29343a6272c630f94ed56810a76740251b
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Sat Jun 15 11:21:09 2013 +0200

    ALSA: usb-audio: work around Android accessory firmware bug
    
    When the Android firmware enables the audio interfaces in accessory
    mode, it always declares in the control interface's baInterfaceNr array
    that interfaces 0 and 1 belong to the audio function.  However, the
    accessory interface itself, if also enabled, already is at index 0 and
    shifts the actual audio interface numbers to 1 and 2, which prevents the
    PCM streaming interface from being seen by the host driver.
    
    To get the PCM interface interface to work, detect when the descriptors
    point to the (for this driver useless) accessory interface, and redirect
    to the correct one.
    
    Reported-by: Jeremy Rosen <jeremy.rosen@openwide.fr>
    Tested-by: Jeremy Rosen <jeremy.rosen@openwide.fr>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit d81bf8cf549f7a6656a64924672a42c101d17026
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Tue Jun 11 11:06:48 2013 +0200

    ALSA: hda - Headset mic support for three more machines
    
    They need these quirks to have headset mic support.
    
    BugLink: https://bugs.launchpad.net/bugs/1189363
    Tested-by: Shawn Wang <shawn.wang@canonical.com>
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit ff49fad1d9bf2c49f52817b04cde8e4412434637
Author: Jay Agarwal <jagarwal@nvidia.com>
Date:   Wed Jun 12 12:43:43 2013 +0530

    ARM: tegra30: clocks: Fix pciex clock registration
    
    Registering pciex as peripheral clock instead of fixed clock
    as tegra_perih_reset_assert(deassert) api of this clock api
    gives warning and ultimately does not succeed to assert(deassert)
    
    Signed-off-by: Jay Agarwal <jagarwal@nvidia.com>
    Acked-by: Stephen Warren <swarren@nvidia.com>
    Signed-off-by: Mike Turquette <mturquette@linaro.org>

commit 8177a9d79c0e942dcac3312f15585d0344d505a5
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date:   Sun Jun 16 18:06:06 2013 +0100

    lseek(fd, n, SEEK_END) does *not* go to eof - n
    
    When you copy some code, you are supposed to read it.  If nothing else,
    there's a chance to spot and fix an obvious bug instead of sharing it...
    
    X-Song: "I Got It From Agnes", by Tom Lehrer
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    [ Tom Lehrer? You're dating yourself, Al ]
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 7d132055814ef17a6c7b69f342244c410a5e000f
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Jun 15 11:51:07 2013 -1000

    Linux 3.10-rc6

commit 3cb3f839d306443f3d1e79b0bde1a2ad2c12b555
Author: Chris Metcalf <cmetcalf@tilera.com>
Date:   Sat Jun 15 16:47:47 2013 -0400

    tilepro: work around module link error with gcc 4.7
    
    gcc 4.7.x is emitting calls to __ffsdi2 where previously
    it used to inline the appropriate ctz instructions.
    While this needs to be fixed in gcc, it's also easy to avoid
    having it cause build failures when building with those
    compilers by exporting __ffsdi2 to modules.
    
    Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
    Cc: stable@kernel.org

commit f21afc25f9ed45b8ffe200d0f071b0caec3ed2ef
Author: David Daney <david.daney@cavium.com>
Date:   Fri Jun 14 11:13:59 2013 -0700

    smp.h: Use local_irq_{save,restore}() in !SMP version of on_each_cpu().
    
    Thanks to commit f91eb62f71b3 ("init: scream bloody murder if interrupts
    are enabled too early"), "bloody murder" is now being screamed.
    
    With a MIPS OCTEON config, we use on_each_cpu() in our
    irq_chip.irq_bus_sync_unlock() function.  This gets called in early as a
    result of the time_init() call.  Because the !SMP version of
    on_each_cpu() unconditionally enables irqs, we get:
    
        WARNING: at init/main.c:560 start_kernel+0x250/0x410()
        Interrupts were enabled early
        CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0-rc5-Cavium-Octeon+ #801
        Call Trace:
          show_stack+0x68/0x80
          warn_slowpath_common+0x78/0xb0
          warn_slowpath_fmt+0x38/0x48
          start_kernel+0x250/0x410
    
    Suggested fix: Do what we already do in the SMP version of
    on_each_cpu(), and use local_irq_save/local_irq_restore.  Because we
    need a flags variable, make it a static inline to avoid name space
    issues.
    
    [ Change from v1: Convert on_each_cpu to a static inline function, add
      #include <linux/irqflags.h> to avoid build breakage on some files.
    
      on_each_cpu_mask() and on_each_cpu_cond() suffer the same problem as
      on_each_cpu(), but they are not causing !SMP bugs for me, so I will
      defer changing them to a less urgent patch. ]
    
    Signed-off-by: David Daney <david.daney@cavium.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 230b3034793247f61e6a0b08c44cf415f6d92981
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Sat Jun 15 12:13:40 2013 +1000

    powerpc: Fix missing/delayed calls to irq_work
    
    When replaying interrupts (as a result of the interrupt occurring
    while soft-disabled), in the case of the decrementer, we are exclusively
    testing for a pending timer target. However we also use decrementer
    interrupts to trigger the new "irq_work", which in this case would
    be missed.
    
    This change the logic to force a replay in both cases of a timer
    boundary reached and a decrementer interrupt having actually occurred
    while disabled. The former test is still useful to catch cases where
    a CPU having been hard-disabled for a long time completely misses the
    interrupt due to a decrementer rollover.
    
    CC: <stable@vger.kernel.org> [v3.4+]
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Tested-by: Steven Rostedt <rostedt@goodmis.org>

commit bf593907f7236e95698a76b7c7a2bbf8b1165327
Author: Paul Mackerras <paulus@samba.org>
Date:   Fri Jun 14 20:07:41 2013 +1000

    powerpc: Fix emulation of illegal instructions on PowerNV platform
    
    Normally, the kernel emulates a few instructions that are unimplemented
    on some processors (e.g. the old dcba instruction), or privileged (e.g.
    mfpvr).  The emulation of unimplemented instructions is currently not
    working on the PowerNV platform.  The reason is that on these machines,
    unimplemented and illegal instructions cause a hypervisor emulation
    assist interrupt, rather than a program interrupt as on older CPUs.
    Our vector for the emulation assist interrupt just calls
    program_check_exception() directly, without setting the bit in SRR1
    that indicates an illegal instruction interrupt.  This fixes it by
    making the emulation assist interrupt set that bit before calling
    program_check_interrupt().  With this, old programs that use no-longer
    implemented instructions such as dcba now work again.
    
    CC: <stable@vger.kernel.org>
    Signed-off-by: Paul Mackerras <paulus@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit 0e37739b1c96d65e6433998454985de994383019
Author: Michael Ellerman <michael@ellerman.id.au>
Date:   Thu Jun 13 21:04:56 2013 +1000

    powerpc: Fix stack overflow crash in resume_kernel when ftracing
    
    It's possible for us to crash when running with ftrace enabled, eg:
    
      Bad kernel stack pointer bffffd12 at c00000000000a454
      cpu 0x3: Vector: 300 (Data Access) at [c00000000ffe3d40]
          pc: c00000000000a454: resume_kernel+0x34/0x60
          lr: c00000000000335c: performance_monitor_common+0x15c/0x180
          sp: bffffd12
         msr: 8000000000001032
         dar: bffffd12
       dsisr: 42000000
    
    If we look at current's stack (paca->__current->stack) we see it is
    equal to c0000002ecab0000. Our stack is 16K, and comparing to
    paca->kstack (c0000002ecab3e30) we can see that we have overflowed our
    kernel stack. This leads to us writing over our struct thread_info, and
    in this case we have corrupted thread_info->flags and set
    _TIF_EMULATE_STACK_STORE.
    
    Dumping the stack we see:
    
      3:mon> t c0000002ecab0000
      [c0000002ecab0000] c00000000002131c .performance_monitor_exception+0x5c/0x70
      [c0000002ecab0080] c00000000000335c performance_monitor_common+0x15c/0x180
      --- Exception: f01 (Performance Monitor) at c0000000000fb2ec .trace_hardirqs_off+0x1c/0x30
      [c0000002ecab0370] c00000000016fdb0 .trace_graph_entry+0xb0/0x280 (unreliable)
      [c0000002ecab0410] c00000000003d038 .prepare_ftrace_return+0x98/0x130
      [c0000002ecab04b0] c00000000000a920 .ftrace_graph_caller+0x14/0x28
      [c0000002ecab0520] c0000000000d6b58 .idle_cpu+0x18/0x90
      [c0000002ecab05a0] c00000000000a934 .return_to_handler+0x0/0x34
      [c0000002ecab0620] c00000000001e660 .timer_interrupt+0x160/0x300
      [c0000002ecab06d0] c0000000000025dc decrementer_common+0x15c/0x180
      --- Exception: 901 (Decrementer) at c0000000000104d4 .arch_local_irq_restore+0x74/0xa0
      [c0000002ecab09c0] c0000000000fe044 .trace_hardirqs_on+0x14/0x30 (unreliable)
      [c0000002ecab0fb0] c00000000016fe3c .trace_graph_entry+0x13c/0x280
      [c0000002ecab1050] c00000000003d038 .prepare_ftrace_return+0x98/0x130
      [c0000002ecab10f0] c00000000000a920 .ftrace_graph_caller+0x14/0x28
      [c0000002ecab1160] c0000000000161f0 .__ppc64_runlatch_on+0x10/0x40
      [c0000002ecab11d0] c00000000000a934 .return_to_handler+0x0/0x34
      --- Exception: 901 (Decrementer) at c0000000000104d4 .arch_local_irq_restore+0x74/0xa0
    
      ... and so on
    
    __ppc64_runlatch_on() is called from RUNLATCH_ON in the exception entry
    path. At that point the irq state is not consistent, ie. interrupts are
    hard disabled (by the exception entry), but the paca soft-enabled flag
    may be out of sync.
    
    This leads to the local_irq_restore() in trace_graph_entry() actually
    enabling interrupts, which we do not want. Because we have not yet
    reprogrammed the decrementer we immediately take another decrementer
    exception, and recurse.
    
    The fix is twofold. Firstly make sure we call DISABLE_INTS before
    calling RUNLATCH_ON. The badly named DISABLE_INTS actually reconciles
    the irq state in the paca with the hardware, making it safe again to
    call local_irq_save/restore().
    
    Although that should be sufficient to fix the bug, we also mark the
    runlatch routines as notrace. They are called very early in the
    exception entry and we are asking for trouble tracing them. They are
    also fairly uninteresting and tracing them just adds unnecessary
    overhead.
    
    [ This regression was introduced by fe1952fc0afb9a2e4c79f103c08aef5d13db1873
      "powerpc: Rework runlatch code" by myself --BenH
    ]
    
    CC: <stable@vger.kernel.org> [v3.4+]
    Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit dd6c5cd8fedddc9605209098e2fa4e82c7af22aa
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Wed Jun 5 14:07:08 2013 -0400

    snd_pcm_link(): fix a leak...
    
    in case when snd_pcm_stream_linked(substream) is true, we end up leaking
    group.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

commit 05252901199d886a68830befb135d1723730ca86
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu Jun 6 19:33:47 2013 -0400

    use can_lookup() instead of direct checks of ->i_op->lookup
    
    a couple of places got missed back when Linus has introduced that one...
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

commit 8aac62706adaaf0fab02c4327761561c8bda9448
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Fri Jun 14 21:09:49 2013 +0200

    move exit_task_namespaces() outside of exit_notify()
    
    exit_notify() does exit_task_namespaces() after
    forget_original_parent(). This was needed to ensure that ->nsproxy
    can't be cleared prematurely, an exiting child we are going to
    reparent can do do_notify_parent() and use the parent's (ours) pid_ns.
    
    However, after 32084504 "pidns: use task_active_pid_ns in
    do_notify_parent" ->nsproxy != NULL is no longer needed, we rely
    on task_active_pid_ns().
    
    Move exit_task_namespaces() from exit_notify() to do_exit(), after
    exit_fs() and before exit_task_work().
    
    This solves the problem reported by Andrey, free_ipc_ns()->shm_destroy()
    does fput() which needs task_work_add().
    
    Note: this particular problem can be fixed if we change fput(), and
    that change makes sense anyway. But there is another reason to move
    the callsite. The original reason for exit_task_namespaces() from
    the middle of exit_notify() was subtle and it has already gone away,
    now this looks confusing. And this allows us do simplify exit_notify(),
    we can avoid unlock/lock(tasklist) and we can use ->exit_state instead
    of PF_EXITING in forget_original_parent().
    
    Reported-by: Andrey Vagin <avagin@openvz.org>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Acked-by: Andrey Vagin <avagin@openvz.org>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

commit e7b2c4069252732d52f1de6d1f7c82d99a156659
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Fri Jun 14 21:09:47 2013 +0200

    fput: task_work_add() can fail if the caller has passed exit_task_work()
    
    fput() assumes that it can't be called after exit_task_work() but
    this is not true, for example free_ipc_ns()->shm_destroy() can do
    this. In this case fput() silently leaks the file.
    
    Change it to fallback to delayed_fput_work if task_work_add() fails.
    The patch looks complicated but it is not, it changes the code from
    
    	if (PF_KTHREAD) {
    		schedule_work(...);
    		return;
    	}
    	task_work_add(...)
    
    to
    	if (!PF_KTHREAD) {
    		if (!task_work_add(...))
    			return;
    		/* fallback */
    	}
    	schedule_work(...);
    
    As for shm_destroy() in particular, we could make another fix but I
    think this change makes sense anyway. There could be another similar
    user, it is not safe to assume that task_work_add() can't fail.
    
    Reported-by: Andrey Vagin <avagin@openvz.org>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

commit c139b1ee4e36374af705660af6172d7477352792
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Jun 7 10:04:54 2013 -0400

    drm/radeon: fix UVD on big endian
    
    This fixes the kernel side so that the ring should come
    up and ring and IB tests should work.  The userspace
    UVD drivers will also need big endian fixes.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit 29ce3785b22da47c49f4ef6e14b9014fa5dee261
Author: James Bottomley <JBottomley@Parallels.com>
Date:   Wed May 8 14:05:34 2013 -0700

    idle: Enable interrupts in the weak arch_cpu_idle() implementation
    
    PARISC bootup triggers the warning at kernel/cpu/idle.c:96. That's
    caused by the weak arch_cpu_idle() implementation, which is provided
    to avoid that architectures implement idle_poll over and over.
    
    The switchover to polling mode happens in the first call of the weak
    arch_cpu_idle() implementation, but that code fails to reenable
    interrupts and therefor triggers the warning.
    
    Fix this by enabling interrupts in the weak arch_cpu_idle() code.
    
    [ tglx: Made the changelog match the patch ]
    
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Link: http://lkml.kernel.org/r/1371236142.2726.43.camel@dabdike
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

commit d302cf1d316dca5f567e89872cf5d475c9a55f74
Author: Dave Chinner <dchinner@redhat.com>
Date:   Wed Jun 12 12:19:06 2013 +1000

    xfs: don't shutdown log recovery on validation errors
    
    Unfortunately, we cannot guarantee that items logged multiple times
    and replayed by log recovery do not take objects back in time. When
    they are taken back in time, the go into an intermediate state which
    is corrupt, and hence verification that occurs on this intermediate
    state causes log recovery to abort with a corruption shutdown.
    
    Instead of causing a shutdown and unmountable filesystem, don't
    verify post-recovery items before they are written to disk. This is
    less than optimal, but there is no way to detect this issue for
    non-CRC filesystems If log recovery successfully completes, this
    will be undone and the object will be consistent by subsequent
    transactions that are replayed, so in most cases we don't need to
    take drastic action.
    
    For CRC enabled filesystems, leave the verifiers in place - we need
    to call them to recalculate the CRCs on the objects anyway. This
    recovery problem can be solved for such filesystems - we have a LSN
    stamped in all metadata at writeback time that we can to determine
    whether the item should be replayed or not. This is a separate piece
    of work, so is not addressed by this patch.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit 9222a9cf86c0d64ffbedf567412b55da18763aa3)

commit 088c9f67c3f53339d2bc20b42a9cb904901fdc5d
Author: Dave Chinner <dchinner@redhat.com>
Date:   Wed Jun 12 12:19:08 2013 +1000

    xfs: ensure btree root split sets blkno correctly
    
    For CRC enabled filesystems, the BMBT is rooted in an inode, so it
    passes through a different code path on root splits than the
    freespace and inode btrees. This is much less traversed by xfstests
    than the other trees. When testing on a 1k block size filesystem,
    I've been seeing ASSERT failures in generic/234 like:
    
    XFS: Assertion failed: cur->bc_btnum != XFS_BTNUM_BMAP || cur->bc_private.b.allocated == 0, file: fs/xfs/xfs_btree.c, line: 317
    
    which are generally preceded by a lblock check failure. I noticed
    this in the bmbt stats:
    
    $ pminfo -f xfs.btree.block_map
    
    xfs.btree.block_map.lookup
        value 39135
    
    xfs.btree.block_map.compare
        value 268432
    
    xfs.btree.block_map.insrec
        value 15786
    
    xfs.btree.block_map.delrec
        value 13884
    
    xfs.btree.block_map.newroot
        value 2
    
    xfs.btree.block_map.killroot
        value 0
    .....
    
    Very little coverage of root splits and merges. Indeed, on a 4k
    filesystem, block_map.newroot and block_map.killroot are both zero.
    i.e. the code is not exercised at all, and it's the only generic
    btree infrastructure operation that is not exercised by a default run
    of xfstests.
    
    Turns out that on a 1k filesystem, generic/234 accounts for one of
    those two root splits, and that is somewhat of a smoking gun. In
    fact, it's the same problem we saw in the directory/attr code where
    headers are memcpy()d from one block to another without updating the
    self describing metadata.
    
    Simple fix - when copying the header out of the root block, make
    sure the block number is updated correctly.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit ade1335afef556df6538eb02e8c0dc91fbd9cc37)

commit 5170711df79b284cf95b3924322e8ac4c0fd6c76
Author: Dave Chinner <dchinner@redhat.com>
Date:   Wed Jun 12 12:19:07 2013 +1000

    xfs: fix implicit padding in directory and attr CRC formats
    
    Michael L. Semon has been testing CRC patches on a 32 bit system and
    been seeing assert failures in the directory code from xfs/080.
    Thanks to Michael's heroic efforts with printk debugging, we found
    that the problem was that the last free space being left in the
    directory structure was too small to fit a unused tag structure and
    it was being corrupted and attempting to log a region out of bounds.
    Hence the assert failure looked something like:
    
    .....
    #5 calling xfs_dir2_data_log_unused() 36 32
    #1 4092 4095 4096
    #2 8182 8183 4096
    XFS: Assertion failed: first <= last && last < BBTOB(bp->b_length), file: fs/xfs/xfs_trans_buf.c, line: 568
    
    Where #1 showed the first region of the dup being logged (i.e. the
    last 4 bytes of a directory buffer) and #2 shows the corrupt values
    being calculated from the length of the dup entry which overflowed
    the size of the buffer.
    
    It turns out that the problem was not in the logging code, nor in
    the freespace handling code. It is an initial condition bug that
    only shows up on 32 bit systems. When a new buffer is initialised,
    where's the freespace that is set up:
    
    [  172.316249] calling xfs_dir2_leaf_addname() from xfs_dir_createname()
    [  172.316346] #9 calling xfs_dir2_data_log_unused()
    [  172.316351] #1 calling xfs_trans_log_buf() 60 63 4096
    [  172.316353] #2 calling xfs_trans_log_buf() 4094 4095 4096
    
    Note the offset of the first region being logged? It's 60 bytes into
    the buffer. Once I saw that, I pretty much knew that the bug was
    going to be caused by this.
    
    Essentially, all direct entries are rounded to 8 bytes in length,
    and all entries start with an 8 byte alignment. This means that we
    can decode inplace as variables are naturally aligned. With the
    directory data supposedly starting on a 8 byte boundary, and all
    entries padded to 8 bytes, the minimum freespace in a directory
    block is supposed to be 8 bytes, which is large enough to fit a
    unused data entry structure (6 bytes in size). The fact we only have
    4 bytes of free space indicates a directory data block alignment
    problem.
    
    And what do you know - there's an implicit hole in the directory
    data block header for the CRC format, which means the header is 60
    byte on 32 bit intel systems and 64 bytes on 64 bit systems. Needs
    padding. And while looking at the structures, I found the same
    problem in the attr leaf header. Fix them both.
    
    Note that this only affects 32 bit systems with CRCs enabled.
    Everything else is just fine. Note that CRC enabled filesystems created
    before this fix on such systems will not be readable with this fix
    applied.
    
    Reported-by: Michael L. Semon <mlsemon35@gmail.com>
    Debugged-by: Michael L. Semon <mlsemon35@gmail.com>
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit 8a1fd2950e1fe267e11fc8c85dcaa6b023b51b60)

commit 47ad2fcba9ddd0630acccb13c71f19a818947751
Author: Dave Chinner <dchinner@redhat.com>
Date:   Mon May 27 16:38:19 2013 +1000

    xfs: don't emit v5 superblock warnings on write
    
    We write the superblock every 30s or so which results in the
    verifier being called. Right now that results in this output
    every 30s:
    
    XFS (vda): Version 5 superblock detected. This kernel has EXPERIMENTAL support enabled!
    Use of these features in this kernel is at your own risk!
    
    And spamming the logs.
    
    We don't need to check for whether we support v5 superblocks or
    whether there are feature bits we don't support set as these are
    only relevant when we first mount the filesytem. i.e. on superblock
    read. Hence for the write verification we can just skip all the
    checks (and hence verbose output) altogether.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit 34510185abeaa5be9b178a41c0a03d30aec3db7e)

commit b5aff3d2747bea08b386edd070941a45611ffe51
Author: Roland Dreier <roland@purestorage.com>
Date:   Wed Jun 5 09:54:17 2013 -0700

    tcm_qla2xxx: Fix residual for underrun commands that fail
    
    Suppose an initiator sends a DATA IN command with an allocation length
    shorter than the FC transfer length -- we get a target message like
    
        TARGET_CORE[qla2xxx]: Expected Transfer Length: 256 does not match SCSI CDB Length: 0 for SAM Opcode: 0x12
    
    In that case, the target core adjusts the data_length and sets
    se_cmd->residual_count for the underrun.  But now suppose that command
    fails and we end up in tcm_qla2xxx_queue_status() -- that function
    unconditionally overwrites residual_count with the already adjusted
    data_length, and the initiator will burp with a message like
    
        qla2xxx [0000:00:06.0]-301d:0: Dropped frame(s) detected (0x100 of 0x100 bytes).
    
    Fix this by adding on to the existing underflow residual count instead.
    
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Cc: Giridhar Malavali <giridhar.malavali@qlogic.com>
    Cc: Chad Dupuis <chad.dupuis@qlogic.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 574780fd5e6ec52bd43e0bdb777a19e4c4c6aa9c
Author: Jörn Engel <joern@logfs.org>
Date:   Thu May 30 16:36:51 2013 -0400

    target/iscsi: don't corrupt bh_count in iscsit_stop_time2retain_timer()
    
    Here is a fun one.  Bug seems to have been introduced by commit 140854cb,
    almost two years ago.  I have no idea why we only started seeing it now,
    but we did.
    
    Rough callgraph:
    core_tpg_set_initiator_node_queue_depth()
    `-> spin_lock_irqsave(&tpg->session_lock, flags);
    `-> lio_tpg_shutdown_session()
        `-> iscsit_stop_time2retain_timer()
            `-> spin_unlock_bh(&se_tpg->session_lock);
            `-> spin_lock_bh(&se_tpg->session_lock);
    `-> spin_unlock_irqrestore(&tpg->session_lock, flags);
    
    core_tpg_set_initiator_node_queue_depth() used to call spin_lock_bh(),
    but 140854cb changed that to spin_lock_irqsave().  However,
    lio_tpg_shutdown_session() still claims to be called with spin_lock_bh()
    held, as does iscsit_stop_time2retain_timer():
     *      Called with spin_lock_bh(&struct se_portal_group->session_lock) held
    
    Stale documentation is mostly annoying, but in this case the dropping
    the lock with the _bh variant is plain wrong.  It is also wrong to drop
    locks two functions below the lock-holder, but I will ignore that bit
    for now.
    
    After some more locking and unlocking we eventually hit this backtrace:
    ------------[ cut here ]------------
    WARNING: at kernel/softirq.c:159 local_bh_enable_ip+0xe8/0x100()
    Pid: 24645, comm: lio_helper.py Tainted: G           O 3.6.11+
    Call Trace:
     [<ffffffff8103e5ff>] warn_slowpath_common+0x7f/0xc0
     [<ffffffffa040ae37>] ? iscsit_inc_conn_usage_count+0x37/0x50 [iscsi_target_mod]
     [<ffffffff8103e65a>] warn_slowpath_null+0x1a/0x20
     [<ffffffff810472f8>] local_bh_enable_ip+0xe8/0x100
     [<ffffffff815b8365>] _raw_spin_unlock_bh+0x15/0x20
     [<ffffffffa040ae37>] iscsit_inc_conn_usage_count+0x37/0x50 [iscsi_target_mod]
     [<ffffffffa041149a>] iscsit_stop_session+0xfa/0x1c0 [iscsi_target_mod]
     [<ffffffffa0417fab>] lio_tpg_shutdown_session+0x7b/0x90 [iscsi_target_mod]
     [<ffffffffa033ede4>] core_tpg_set_initiator_node_queue_depth+0xe4/0x290 [target_core_mod]
     [<ffffffffa0409032>] iscsit_tpg_set_initiator_node_queue_depth+0x12/0x20 [iscsi_target_mod]
     [<ffffffffa0415c29>] lio_target_nacl_store_cmdsn_depth+0xa9/0x180 [iscsi_target_mod]
     [<ffffffffa0331b49>] target_fabric_nacl_base_attr_store+0x39/0x40 [target_core_mod]
     [<ffffffff811b857d>] configfs_write_file+0xbd/0x120
     [<ffffffff81148f36>] vfs_write+0xc6/0x180
     [<ffffffff81149251>] sys_write+0x51/0x90
     [<ffffffff815c0969>] system_call_fastpath+0x16/0x1b
    ---[ end trace 3747632b9b164652 ]---
    
    As a pure band-aid, this patch drops the _bh.
    
    Signed-off-by: Joern Engel <joern@logfs.org>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 42f132febff3b7b42c6c9dbfc151f29233be3132
Author: Tomas Winkler <tomas.winkler@intel.com>
Date:   Wed Jun 5 10:51:13 2013 +0300

    mei: me: clear interrupts on the resume path
    
    We need to clear pending interrupts on the resume
    path. This brings the device into defined state
    before starting the reset flow
    
    This should solve suspend/resume issues:
    
    mei_me : wait hw ready failed. status = 0x0
    mei_me : version message write failed
    
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2753ff53d4158dbb394b3a2064001283fa9a8701
Author: Tomas Winkler <tomas.winkler@intel.com>
Date:   Mon Jun 10 10:10:26 2013 +0300

    mei: nfc: fix nfc device freeing
    
    The nfc_dev is a static variable and is not cleaned properly upon reset
    mainly ndev->cl and ndev->cl_info are not set to NULL after freeing which
    
    mei_stop:198: mei_me 0000:00:16.0: stopping the device.
    [  404.253427] general protection fault: 0000 [#2] SMP
    [  404.253437] Modules linked in: mei_me(-) binfmt_misc snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device edd af_packet cpufreq_conservative cpufreq_userspace cpufreq_powersave fuse loop dm_mod hid_generic usbhid hid coretemp acpi_cpufreq mperf kvm_intel kvm crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw gf128mul snd_hda_codec_hdmi glue_helper aes_x86_64 e1000e snd_hda_intel snd_hda_codec ehci_pci iTCO_wdt iTCO_vendor_support ehci_hcd snd_hwdep xhci_hcd snd_pcm usbcore ptp mei sg microcode snd_timer pps_core i2c_i801 snd pcspkr battery rtc_cmos lpc_ich mfd_core soundcore usb_common snd_page_alloc ac ext3 jbd mbcache drm_kms_helper drm intel_agp i2c_algo_bit intel_gtt i2c_core sd_mod crc_t10dif thermal fan video button processor thermal_sys hwmon ahci libahci libata scsi_mod [last unloaded: mei_me]
    [  404.253591] CPU: 0 PID: 5551 Comm: modprobe Tainted: G      D W    3.10.0-rc3 #1
    [  404.253611] task: ffff880143cd8300 ti: ffff880144a2a000 task.ti: ffff880144a2a000
    [  404.253619] RIP: 0010:[<ffffffff81334e5d>]  [<ffffffff81334e5d>] device_del+0x1d/0x1d0
    [  404.253638] RSP: 0018:ffff880144a2bcf8  EFLAGS: 00010206
    [  404.253645] RAX: 2020302e30202030 RBX: ffff880144fdb000 RCX: 0000000000000086
    [  404.253652] RDX: 0000000000000001 RSI: 0000000000000086 RDI: ffff880144fdb000
    [  404.253659] RBP: ffff880144a2bd18 R08: 0000000000000651 R09: 0000000000000006
    [  404.253666] R10: 0000000000000651 R11: 0000000000000006 R12: ffff880144fdb000
    [  404.253673] R13: ffff880149371098 R14: ffff880144482c00 R15: ffffffffa04710e0
    [  404.253681] FS:  00007f251c59a700(0000) GS:ffff88014e200000(0000) knlGS:0000000000000000
    [  404.253689] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  404.253696] CR2: ffffffffff600400 CR3: 0000000145319000 CR4: 00000000001407f0
    [  404.253703] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  404.253710] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  404.253716] Stack:
    [  404.253720]  ffff880144fdb000 ffff880143ffe000 ffff880149371098 ffffffffa0471000
    [  404.253732]  ffff880144a2bd38 ffffffff8133502d ffff88014e20cf48 ffff880143ffe1d8
    [  404.253744]  ffff880144a2bd48 ffffffffa02a4749 ffff880144a2bd58 ffffffffa02a4ba1
    [  404.253755] Call Trace:
    [  404.253766]  [<ffffffff8133502d>] device_unregister+0x1d/0x60
    [  404.253787]  [<ffffffffa02a4749>] mei_cl_remove_device+0x9/0x10 [mei]
    [  404.253804]  [<ffffffffa02a4ba1>] mei_nfc_host_exit+0x21/0x30 [mei]
    [  404.253819]  [<ffffffffa029c2dd>] mei_stop+0x3d/0x90 [mei]
    [  404.253830]  [<ffffffffa046e220>] mei_me_remove+0x60/0xe0 [mei_me]
    [  404.253843]  [<ffffffff81278f37>] pci_device_remove+0x37/0xb0
    [  404.253855]  [<ffffffff81337c68>] __device_release_driver+0x98/0x100
    [  404.253865]  [<ffffffff81337d80>] driver_detach+0xb0/0xc0
    [  404.253876]  [<ffffffff81336b4f>] bus_remove_driver+0x8f/0x120
    [  404.253891]  [<ffffffff81075990>] ? try_to_wake_up+0x2b0/0x2b0
    [  404.253903]  [<ffffffff81338a48>] driver_unregister+0x58/0x90
    [  404.253913]  [<ffffffff8127906b>] pci_unregister_driver+0x2b/0xb0
    [  404.253924]  [<ffffffffa046f244>] mei_me_driver_exit+0x10/0xdcc [mei_me]
    [  404.253936]  [<ffffffff810a50d8>] SyS_delete_module+0x198/0x2b0
    [  404.253949]  [<ffffffff814850d9>] ? do_page_fault+0x9/0x10
    [  404.253961]  [<ffffffff81489692>] system_call_fastpath+0x16/0x1b
    [  404.253967] Code: 41 5c 41 5d 41 5e 41 5f c9 c3 0f 1f 40 00 55 48 89 e5 41 56 41 55 41 54 49 89 fc 53 48 8b 87 88 00 00 00 4c 8b 37 48 85 c0 74 18 <48> 8b 78 78 4c 89 e2 be 02 00 00 00 48 81 c7 f8 00 00 00 e8 3b
    [  404.254048] RIP  [<ffffffff81334e5d>] device_del+0x1d/0x1d0
    
    Cc: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e85b364481af75e84228cd8704bd490493818a2
Author: Samuel Ortiz <sameo@linux.intel.com>
Date:   Mon Jun 10 10:10:25 2013 +0300

    mei: init: Flush scheduled work before resetting the device
    
    Flushing pending work items before resetting the device makes more
    sense than doing so afterwards. Some of them, like e.g. the NFC
    initialization one, find themselves with client IDs changed after
    the reset, eventually leading to trigger a client.c:mei_me_cl_by_id()
    warning after a few modprobe/rmmod cycles.
    
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5c7774d7eb4397891edca9ebdf750ba90977a69
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Wed Jun 12 14:26:44 2013 -0400

    sctp: fully initialize sctp_outq in sctp_outq_init
    
    In commit 2f94aabd9f6c925d77aecb3ff020f1cc12ed8f86
    (refactor sctp_outq_teardown to insure proper re-initalization)
    we modified sctp_outq_teardown to use sctp_outq_init to fully re-initalize the
    outq structure.  Steve West recently asked me why I removed the q->error = 0
    initalization from sctp_outq_teardown.  I did so because I was operating under
    the impression that sctp_outq_init would properly initalize that value for us,
    but it doesn't.  sctp_outq_init operates under the assumption that the outq
    struct is all 0's (as it is when called from sctp_association_init), but using
    it in __sctp_outq_teardown violates that assumption. We should do a memset in
    sctp_outq_init to ensure that the entire structure is in a known state there
    instead.
    
    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    Reported-by: "West, Steve (NSN - US/Fort Worth)" <steve.west@nsn.com>
    CC: Vlad Yasevich <vyasevich@gmail.com>
    CC: netdev@vger.kernel.org
    CC: davem@davemloft.net
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit aaf9522d62d18626a60f7f2080671d853d9e8681
Author: Benjamin Poirier <bpoirier@suse.de>
Date:   Thu Jun 13 09:09:47 2013 -0400

    netiucv: Hold rtnl between name allocation and device registration.
    
    fixes a race condition between concurrent initializations of netiucv devices
    that try to use the same name.
    
    sysfs: cannot create duplicate filename '/devices/iucv/netiucv2'
    [...]
    Call Trace:
    ([<00000000002edea4>] sysfs_add_one+0xb0/0xdc)
     [<00000000002eecd4>] create_dir+0x80/0xfc
     [<00000000002eee38>] sysfs_create_dir+0xe8/0x118
     [<00000000003835a8>] kobject_add_internal+0x120/0x2d0
     [<00000000003839d6>] kobject_add+0x62/0x9c
     [<00000000003d9564>] device_add+0xcc/0x510
     [<000003e00212c7b4>] netiucv_register_device+0xc0/0x1ec [netiucv]
    
    Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
    Tested-by: Ursula Braun <braunu@de.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit c9bfbb31af7c8428267b34eb9706a621ac219a28
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Thu Jun 13 15:31:28 2013 -0400

    tulip: Properly check dma mapping result
    
    Tulip throws an error when dma debugging is enabled, as it doesn't properly
    check dma mapping results with dma_mapping_error() durring tx ring refills.
    
    Easy fix, just add it in, and drop the frame if the mapping is bad
    
    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    CC: Grant Grundler <grundler@parisc-linux.org>
    CC: "David S. Miller" <davem@davemloft.net>
    Reviewed-by: Grant Grundler <grundler@parisc-linux.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 706b78f37fbed8d81b6061359f28a315fb9b1d73
Author: Grant Likely <grant.likely@linaro.org>
Date:   Thu Jun 13 12:57:44 2013 +0100

    dtc: ensure #line directives don't consume data from the next line
    
    Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS}
    could match line-break characters. If the #line directive did not contain
    the optional flags field at the end, this could cause any integer data on
    the next line to be consumed as part of the #line directive parsing. This
    could cause syntax errors (i.e. #line parsing consuming the leading 0
    from a hex literal 0x1234, leaving x1234 to be parsed as cell data,
    which is a syntax error), or invalid compilation results (i.e. simply
    consuming literal 1234 as part of the #line processing, thus removing it
    from the cell data).
    
    Fix this by replacing {WS} with [ \t] so that it can't match line-breaks.
    
    Convert all instances of {WS}, even though the other instances should be
    irrelevant for any well-formed #line directive. This is done for
    consistency and ultimate safety.
    
    [Cherry picked from DTC commit a1ee6f068e1c8dbc62873645037a353d7852d5cc]
    
    Reported-by: Ian Campbell <Ian.Campbell@citrix.com>
    Signed-off-by: Stephen Warren <swarren@nvidia.com>
    Acked-by: David Gibson <david@gibson.dropbear.id.au>
    Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

commit 2a6a08ca5e3561e17346f8f87ce8dc88c0a8e42d
Author: Grant Likely <grant.likely@linaro.org>
Date:   Thu Jun 13 13:00:43 2013 +0100

    dtc: Update generated files to output from Bison 2.5
    
    This patch merely updates the generated dtc parser and lexer files to
    the output generated by Bison 2.5. The previous versions were generated
    from version 2.4.1. The only reason for this commit is to minimize the
    diff on the next commit which fixes a bug in the DTC #line directive
    parsing. Otherwise the Bison changes would be intermingled with the
    functional changes.
    
    Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

commit d25d86949b6799c35d78f4910498c2b65a3f0841
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Wed Jun 12 15:39:04 2013 +1000

    of: Fix locking vs. interrupts
    
    The OF code uses irqsafe locks everywhere except in a handful of functions
    for no obvious reasons. Since the conversion from the old rwlocks, this
    now triggers lockdep warnings when used at interrupt time. At least one
    driver (ibmvscsi) seems to be doing that from softirq context.
    
    This converts the few non-irqsafe locks into irqsafe ones, making them
    consistent with the rest of the code.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Grant Likely <grant.likely@linaro.org>

commit b0a4d8b3cf199e7277f659663ac3a3580e9967bb
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Fri May 31 11:14:20 2013 +0100

    kbuild: make sure we clean up DTB temporary files
    
    Various temporary files used when building DTB files were not suffixed with
    .tmp and therefore were not cleaned up by "make clean".
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Reviewed-by: Stephen Warren <swarren@nvidia.com>
    Tested-by: Stephen Warren <swarren@nvidia.com>
    Signed-off-by: Grant Likely <grant.likely@linaro.org>

commit b844db31874e3b1c3b86c65024ac7bed9f77ee42
Author: Josh Triplett <josh@joshtriplett.org>
Date:   Wed Jun 12 17:26:37 2013 -0700

    turbostat: Increase output buffer size to accommodate C8-C10
    
    On platforms with C8-C10 support, the additional C-states cause
    turbostat to overrun its output buffer of 128 bytes per CPU.  Increase
    this to 256 bytes per CPU.
    
    [ As a bugfix, this should go into 3.10; however, since the C8-C10
      support didn't go in until after 3.9, this need not go into any stable
      kernel. ]
    
    Signed-off-by: Josh Triplett <josh@joshtriplett.org>
    Cc: Len Brown <len.brown@intel.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 3a96d5cd7bdce45d5dded75c3a62d4fb98050280
Author: Josh Durgin <josh.durgin@inktank.com>
Date:   Wed Jun 12 19:15:06 2013 -0700

    rbd: use the correct length for format 2 object names
    
    Format 2 objects use 16 characters for the object name suffix to be
    able to express the full 64-bit range of object numbers. Format 1
    images only use 12 characters for this. Using 12-character names for
    format 2 caused userspace and kernel rbd clients to read differently
    named objects, which made an image written by one client look empty to
    the other client.
    
    CC: stable@vger.kernel.org  # 3.9+
    Reported-by: Chris Dunlop <chris@onthe.net.au>
    Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
    Reviewed-by: Sage Weil <sage@inktank.com>

commit dd019897358b815f7828dab90b51d51df4d3658d
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Thu Jun 13 10:15:45 2013 +0900

    net: sh_eth: fix incorrect RX length error if R8A7740
    
    This patch fixes an issue that the driver increments the "RX length error"
    on every buffer in sh_eth_rx() if the R8A7740.
    This patch also adds a description about the Receive Frame Status bits.
    
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit d3b6f6141831b6e2d414edea6cc7af5b9bc6fac2
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Fri Jun 7 13:26:05 2013 -0700

    ip_tunnel: remove __net_init/exit from exported functions
    
    If CONFIG_NET_NS is not set then __net_init is the same as __init and
    __net_exit is the same as __exit. These functions will be removed from
    memory after the module loads or is removed. Functions that are exported
    for use by other functions should never be labeled for removal.
    
    Bug introduced by commit c54419321455631079c
    ("GRE: Refactor GRE tunneling code.")
    
    Reported-by: Steinar H. Gunderson <sgunderson@bigfoot.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit cc60ab0a8b5b62ea6b5cc1c6397adb5b4bd41271
Author: Mugunthan V N <mugunthanvnm@ti.com>
Date:   Tue Jun 11 15:32:05 2013 +0530

    drivers: net: davinci_mdio: restore mdio clk divider in mdio resume
    
    During suspend resume cycle all the register data is lost, so MDIO
    clock divier value gets reset. This patch restores the clock divider
    value.
    
    Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 5033ec3e3f923a371c28f0c3df45905a9dd9c457
Author: Mugunthan V N <mugunthanvnm@ti.com>
Date:   Tue Jun 11 15:32:04 2013 +0530

    drivers: net: davinci_mdio: moving mdio resume earlier than cpsw ethernet driver
    
    MDIO driver should resume before CPSW ethernet driver so that CPSW connect
    to the phy and start tx/rx ethernet packets, changing the suspend/resume
    apis with suspend_late/resume_early.
    
    Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit baafc77b32f647daa7c45825f7af8cdd55d00817
Author: Saurabh Mohan <saurabh@vyatta.com>
Date:   Mon Jun 10 17:45:10 2013 -0700

    net/ipv4: ip_vti clear skb cb before tunneling.
    
    If users apply shaper to vti tunnel then it will cause a kernel crash. The
    problem seems to be due to the vti_tunnel_xmit function not clearing
    skb->opt field before passing the packet to xfrm tunneling code.
    
    Signed-off-by: Saurabh Mohan <saurabh@vyatta.com>
    Acked-by: Stephen Hemminger <stephen@networkplumber.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit df465abfe06f7dc4f33f4a96d17f096e9e8ac917
Author: Nithin Sujir <nsujir@broadcom.com>
Date:   Wed Jun 12 11:08:59 2013 -0700

    tg3: Wait for boot code to finish after power on
    
    Some systems that don't need wake-on-lan may choose to power down the
    chip on system standby. Upon resume, the power on causes the boot code
    to startup and initialize the hardware. On one new platform, this is
    causing the device to go into a bad state due to a race between the
    driver and boot code, once every several hundred resumes. The same race
    exists on open since we come up from a power on.
    
    This patch adds a wait for boot code signature at the beginning of
    tg3_init_hw() which is common to both cases. If there has not been a
    power-off or the boot code has already completed, the signature will be
    present and poll_fw() returns immediately. Also return immediately if
    the device does not have firmware.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
    Signed-off-by: Michael Chan <mchan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit a6f79d0f26704214b5b702bbac525cb72997f984
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Wed Jun 12 16:07:36 2013 +0200

    l2tp: Fix sendmsg() return value
    
    PPPoL2TP sockets should comply with the standard send*() return values
    (i.e. return number of bytes sent instead of 0 upon success).
    
    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 55b92b7a11690bc377b5d373872a6b650ae88e64
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Wed Jun 12 16:07:23 2013 +0200

    l2tp: Fix PPP header erasure and memory leak
    
    Copy user data after PPP framing header. This prevents erasure of the
    added PPP header and avoids leaking two bytes of uninitialised memory
    at the end of skb's data buffer.
    
    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 4f5474e7fd68988cb11373fc698bf10b35b49e31
Author: Nikolay Aleksandrov <nikolay@redhat.com>
Date:   Wed Jun 12 00:07:02 2013 +0200

    bonding: fix igmp_retrans type and two related races
    
    First the type of igmp_retrans (which is the actual counter of
    igmp_resend parameter) is changed to u8 to be able to store values up
    to 255 (as per documentation). There are two races that were hidden
    there and which are easy to trigger after the previous fix, the first is
    between bond_resend_igmp_join_requests and bond_change_active_slave
    where igmp_retrans is set and can be altered by the periodic. The second
    race condition is between multiple running instances of the periodic
    (upon execution it can be scheduled again for immediate execution which
    can cause the counter to go < 0 which in the unsigned case leads to
    unnecessary igmp retransmissions).
    Since in bond_change_active_slave bond->lock is held for reading and
    curr_slave_lock for writing, we use curr_slave_lock for mutual
    exclusion. We can't drop them as there're cases where RTNL is not held
    when bond_change_active_slave is called. RCU is unlocked in
    bond_resend_igmp_join_requests before getting curr_slave_lock since we
    don't need it there and it's pointless to delay.
    The decrement is moved inside the "if" block because if we decrement
    unconditionally there's still a possibility for a race condition although
    it is much more difficult to hit (many changes have to happen in
    a very short period in order to trigger) which in the case of 3 parallel
    running instances of this function and igmp_retrans == 1
    (with check bond->igmp_retrans-- > 1) is:
    f1 passes, doesn't re-schedule, but decrements - igmp_retrans = 0
    f2 then passes, doesn't re-schedule, but decrements - igmp_retrans = 255
    f3 does the unnecessary retransmissions.
    
    Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
    Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit b8fad459f9cc8417b74f71c6c229eef7412163d1
Author: Nikolay Aleksandrov <nikolay@redhat.com>
Date:   Wed Jun 12 00:07:01 2013 +0200

    bonding: reset master mac on first enslave failure
    
    If the bond device is supposed to get the first slave's MAC address and
    the first enslavement fails then we need to reset the master's MAC
    otherwise it will stay the same as the failed slave device. We do it
    after err_undo_flags since that is the first place where the MAC can be
    changed and we check if it should've been the first slave and if the
    bond's MAC was set to it because that err place is used by multiple
    locations prior to changing the master's MAC address.
    
    Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
    Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 2dc85bf323515e59e15dfa858d1472bb25cad0fe
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Wed Jun 12 16:02:27 2013 +0200

    packet: packet_getname_spkt: make sure string is always 0-terminated
    
    uaddr->sa_data is exactly of size 14, which is hard-coded here and
    passed as a size argument to strncpy(). A device name can be of size
    IFNAMSIZ (== 16), meaning we might leave the destination string
    unterminated. Thus, use strlcpy() and also sizeof() while we're
    at it. We need to memset the data area beforehand, since strlcpy
    does not padd the remaining buffer with zeroes for user space, so
    that we do not possibly leak anything.
    
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 631f24a2febb228f82604dc5330091e8080cd8ae
Author: Dinh Nguyen <dinguyen@altera.com>
Date:   Wed Jun 12 11:05:03 2013 -0500

    net: ethernet: stmicro: stmmac: Fix compile error when STMMAC_XMIT_DEBUG used
    
    drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function:
    stmmac_xmit drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1902:74:
    error: expected ) before __func__
    
    Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
    Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
    CC: David S. Miller <davem@davemloft.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 0c5fed09ab0feedd43c362b1c7fff67fdbf9548f
Author: Somnath Kotur <somnath.kotur@emulex.com>
Date:   Tue Jun 11 17:18:22 2013 +0530

    be2net: Fix 32-bit DMA Mask handling
    
    Fix to set the coherent DMA mask only if dma_set_mask() succeeded, and to
    error out if either fails.
    
    Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 94f950c4060cd9b1989c565284beb159b9705a50
Author: Jan Beulich <JBeulich@suse.com>
Date:   Tue Jun 11 11:00:34 2013 +0100

    xen-netback: don't de-reference vif pointer after having called xenvif_put()
    
    When putting vif-s on the rx notify list, calling xenvif_put() must be
    deferred until after the removal from the list and the issuing of the
    notification, as both operations dereference the pointer.
    
    Changing this got me to notice that the "irq" variable was effectively
    unused (and was of too narrow type anyway).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 99ffc3e74fb0d9d321d2f19c6021e0dbaff2f4b2
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Thu Jun 13 10:07:29 2013 +0300

    macvlan: don't touch promisc without passthrough
    
    commit df8ef8f3aaa6692970a436204c4429210addb23a
    "macvlan: add FDB bridge ops and macvlan flags"
    added a way to control NOPROMISC macvlan flag through netlink.
    
    However, with a non passthrough device we never set promisc on open,
    even if NOPROMISC is off.  As a result:
    
    If userspace clears NOPROMISC on open, then does not clear it on a
    netlink command, promisc counter is not decremented on stop and there
    will be no way to clear it once macvlan is detached.
    
    If userspace does not clear NOPROMISC on open, then sets NOPROMISC on a
    netlink command, promisc counter will be decremented from 0 and overflow
    to fffffffff with no way to clear promisc.
    
    To fix, simply ignore NOPROMISC flag in a netlink command for
    non-passthrough devices, same as we do at open/close.
    
    Since we touch this code anyway - check dev_set_promiscuity return code
    and pass it to users (though an error here is unlikely).
    
    Cc: "David S. Miller" <davem@davemloft.net>
    Reviewed-by: John Fastabend <john.r.fastabend@intel.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 907985f48bc60818e291c631249f9bc84c83a06f
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Mon Jun 10 15:18:00 2013 -0400

    slab: prevent warnings when allocating with __GFP_NOWARN
    
    Sasha Levin noticed that the warning introduced by commit 6286ae9
    ("slab: Return NULL for oversized allocations) is being triggered:
    
      WARNING: CPU: 15 PID: 21519 at mm/slab_common.c:376 kmalloc_slab+0x2f/0xb0()
      can: request_module (can-proto-4) failed.
      mpoa: proc_mpc_write: could not parse ''
      Modules linked in:
      CPU: 15 PID: 21519 Comm: trinity-child15 Tainted: G W    3.10.0-rc4-next-20130607-sasha-00011-gcd78395-dirty #2
       0000000000000009 ffff880020a95e30 ffffffff83ff4041 0000000000000000
       ffff880020a95e68 ffffffff8111fe12 fffffffffffffff0 00000000000082d0
       0000000000080000 0000000000080000 0000000001400000 ffff880020a95e78
      Call Trace:
       [<ffffffff83ff4041>] dump_stack+0x4e/0x82
       [<ffffffff8111fe12>] warn_slowpath_common+0x82/0xb0
       [<ffffffff8111fe55>] warn_slowpath_null+0x15/0x20
       [<ffffffff81243dcf>] kmalloc_slab+0x2f/0xb0
       [<ffffffff81278d54>] __kmalloc+0x24/0x4b0
       [<ffffffff8196ffe3>] ? security_capable+0x13/0x20
       [<ffffffff812a26b7>] ? pipe_fcntl+0x107/0x210
       [<ffffffff812a26b7>] pipe_fcntl+0x107/0x210
       [<ffffffff812b7ea0>] ? fget_raw_light+0x130/0x3f0
       [<ffffffff812aa5fb>] SyS_fcntl+0x60b/0x6a0
       [<ffffffff8403ca98>] tracesys+0xe1/0xe6
    
    Andrew Morton writes:
    
      __GFP_NOWARN is frequently used by kernel code to probe for "how big
      an allocation can I get".  That's a bit lame, but it's used on slow
      paths and is pretty simple.
    
    However, SLAB would still spew a warning when a big allocation happens
    if the __GFP_NOWARN flag is _not_ set to expose kernel bugs.
    
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
    [ penberg@kernel.org: improve changelog ]
    Signed-off-by: Pekka Enberg <penberg@kernel.org>

commit fe6510b5d6349a8999b83ef7c5671e5a561b803a
Author: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Date:   Tue Jun 11 22:25:22 2013 +0300

    crypto: aesni_intel - fix accessing of unaligned memory
    
    The new XTS code for aesni_intel uses input buffers directly as memory operands
    for pxor instructions, which causes crash if those buffers are not aligned to
    16 bytes.
    
    Patch changes XTS code to handle unaligned memory correctly, by loading memory
    with movdqu instead.
    
    Reported-by: Dave Jones <davej@redhat.com>
    Tested-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

commit 5026d7a9b2f3eb1f9bda66c18ac6bc3036ec9020
Author: H. Peter Anvin <hpa@zytor.com>
Date:   Wed Jun 12 07:37:43 2013 -0700

    md/raid1,5,10: Disable WRITE SAME until a recovery strategy is in place
    
    There are cases where the kernel will believe that the WRITE SAME
    command is supported by a block device which does not, in fact,
    support WRITE SAME.  This currently happens for SATA drivers behind a
    SAS controller, but there are probably a hundred other ways that can
    happen, including drive firmware bugs.
    
    After receiving an error for WRITE SAME the block layer will retry the
    request as a plain write of zeroes, but mdraid will consider the
    failure as fatal and consider the drive failed.  This has the effect
    that all the mirrors containing a specific set of data are each
    offlined in very rapid succession resulting in data loss.
    
    However, just bouncing the request back up to the block layer isn't
    ideal either, because the whole initial request-retry sequence should
    be inside the write bitmap fence, which probably means that md needs
    to do its own conversion of WRITE SAME to write zero.
    
    Until the failure scenario has been sorted out, disable WRITE SAME for
    raid1, raid5, and raid10.
    
    [neilb: added raid5]
    
    This patch is appropriate for any -stable since 3.7 when write_same
    support was added.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: NeilBrown <neilb@suse.de>

commit e2d59925221cd562e07fee38ec8839f7209ae603
Author: NeilBrown <neilb@suse.de>
Date:   Wed Jun 12 11:01:22 2013 +1000

    md/raid1,raid10: use freeze_array in place of raise_barrier in various places.
    
    Various places in raid1 and raid10 are calling raise_barrier when they
    really should call freeze_array.
    The former is only intended to be called from "make_request".
    The later has extra checks for 'nr_queued' and makes a call to
    flush_pending_writes(), so it is safe to call it from within the
    management thread.
    
    Using raise_barrier will sometimes deadlock.  Using freeze_array
    should not.
    
    As 'freeze_array' currently expects one request to be pending (in
    handle_read_error - the only previous caller), we need to pass
    it the number of pending requests (extra) to ignore.
    
    The deadlock was made particularly noticeable by commits
    050b66152f87c7 (raid10) and 6b740b8d79252f13 (raid1) which
    appeared in 3.4, so the fix is appropriate for any -stable
    kernel since then.
    
    This patch probably won't apply directly to some early kernels and
    will need to be applied by hand.
    
    Cc: stable@vger.kernel.org
    Reported-by: Alexander Lyakas <alex.bolshoy@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>

commit 3056e3aec8d8ba61a0710fb78b2d562600aa2ea7
Author: Alex Lyakas <alex@zadarastorage.com>
Date:   Tue Jun 4 20:42:21 2013 +0300

    md/raid1: consider WRITE as successful only if at least one non-Faulty and non-rebuilding drive completed it.
    
    Without that fix, the following scenario could happen:
    
    - RAID1 with drives A and B; drive B was freshly-added and is rebuilding
    - Drive A fails
    - WRITE request arrives to the array. It is failed by drive A, so
    r1_bio is marked as R1BIO_WriteError, but the rebuilding drive B
    succeeds in writing it, so the same r1_bio is marked as
    R1BIO_Uptodate.
    - r1_bio arrives to handle_write_finished, badblocks are disabled,
    md_error()->error() does nothing because we don't fail the last drive
    of raid1
    - raid_end_bio_io()  calls call_bio_endio()
    - As a result, in call_bio_endio():
            if (!test_bit(R1BIO_Uptodate, &r1_bio->state))
                    clear_bit(BIO_UPTODATE, &bio->bi_flags);
    this code doesn't clear the BIO_UPTODATE flag, and the whole master
    WRITE succeeds, back to the upper layer.
    
    So we returned success to the upper layer, even though we had written
    the data onto the rebuilding drive only. But when we want to read the
    data back, we would not read from the rebuilding drive, so this data
    is lost.
    
    [neilb - applied identical change to raid10 as well]
    
    This bug can result in lost data, so it is suitable for any
    -stable kernel.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Alex Lyakas <alex@zadarastorage.com>
    Signed-off-by: NeilBrown <neilb@suse.de>

commit 6b6204ee92adb53bfd6a77cb5679282ec3820c4b
Author: NeilBrown <neilb@suse.de>
Date:   Thu May 9 09:48:30 2013 +1000

    md: md_stop_writes() should always freeze recovery.
    
    __md_stop_writes() will currently sometimes freeze recovery.
    So any caller must be ready for that to happen, and indeed they are.
    
    However if __md_stop_writes() doesn't freeze_recovery, then
    a recovery could start before mddev_suspend() is called, which
    could be awkward.  This can particularly cause problems or dm-raid.
    
    So change __md_stop_writes() to always freeze recovery.  This is safe
    and more predicatable.
    
    Reported-by: Brassow Jonathan <jbrassow@redhat.com>
    Tested-by: Brassow Jonathan <jbrassow@redhat.com>
    Signed-off-by: NeilBrown <neilb@suse.de>

commit c2853c8df57f49620d26f317d7d43347c29bfc2e
Author: Alex Shi <alex.shi@intel.com>
Date:   Wed Jun 12 14:05:10 2013 -0700

    include/linux/math64.h: add div64_ul()
    
    There is div64_long() to handle the s64/long division, but no mocro do
    u64/ul division.  It is necessary in some scenarios, so add this
    function.
    
    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Alex Shi <alex.shi@intel.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 89dc991f0f5272c307c746fdd57d0bff382b1ba2
Author: Johannes Weiner <hannes@cmpxchg.org>
Date:   Wed Jun 12 14:05:09 2013 -0700

    mm: memcontrol: fix lockless reclaim hierarchy iterator
    
    The lockless reclaim hierarchy iterator currently has a misplaced
    barrier that can lead to use-after-free crashes.
    
    The reclaim hierarchy iterator consist of a sequence count and a
    position pointer that are read and written locklessly, with memory
    barriers enforcing ordering.
    
    The write side sets the position pointer first, then updates the
    sequence count to "publish" the new position.  Likewise, the read side
    must read the sequence count first, then the position.  If the sequence
    count is up to date, it's guaranteed that the position is up to date as
    well:
    
      writer:                         reader:
      iter->position = position       if iter->sequence == expected:
      smp_wmb()                           smp_rmb()
      iter->sequence = sequence           position = iter->position
    
    However, the read side barrier is currently misplaced, which can lead to
    dereferencing stale position pointers that no longer point to valid
    memory.  Fix this.
    
    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Reported-by: Tejun Heo <tj@kernel.org>
    Reviewed-by: Tejun Heo <tj@kernel.org>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: Glauber Costa <glommer@parallels.com>
    Cc: <stable@kernel.org>		[3.10+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 7b57976da48e60b66fdbb9e97f5711b5382a49d7
Author: Akinobu Mita <akinobu.mita@gmail.com>
Date:   Wed Jun 12 14:05:08 2013 -0700

    frontswap: fix incorrect zeroing and allocation size for frontswap_map
    
    The bitmap accessed by bitops must have enough size to hold the required
    numbers of bits rounded up to a multiple of BITS_PER_LONG.  And the
    bitmap must not be zeroed by memset() if the number of bits cleared is
    not a multiple of BITS_PER_LONG.
    
    This fixes incorrect zeroing and allocation size for frontswap_map.  The
    incorrect zeroing part doesn't cause any problem because frontswap_map
    is freed just after zeroing.  But the wrongly calculated allocation size
    may cause the problem.
    
    For 32bit systems, the allocation size of frontswap_map is about twice
    as large as required size.  For 64bit systems, the allocation size is
    smaller than requeired if the number of bits is not a multiple of
    BITS_PER_LONG.
    
    Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 736f3203a06eafd0944103775a98584082744c6b
Author: Chen Gang <gang.chen@asianux.com>
Date:   Wed Jun 12 14:05:07 2013 -0700

    kernel/audit_tree.c:audit_add_tree_rule(): protect `rule' from kill_rules()
    
    audit_add_tree_rule() must set 'rule->tree = NULL;' firstly, to protect
    the rule itself freed in kill_rules().
    
    The reason is when it is killed, the 'rule' itself may have already
    released, we should not access it.  one example: we add a rule to an
    inode, just at the same time the other task is deleting this inode.
    
    The work flow for adding a rule:
    
        audit_receive() -> (need audit_cmd_mutex lock)
          audit_receive_skb() ->
            audit_receive_msg() ->
              audit_receive_filter() ->
                audit_add_rule() ->
                  audit_add_tree_rule() -> (need audit_filter_mutex lock)
                    ...
                    unlock audit_filter_mutex
                    get_tree()
                    ...
                    iterate_mounts() -> (iterate all related inodes)
                      tag_mount() ->
                        tag_trunk() ->
                          create_trunk() -> (assume it is 1st rule)
                            fsnotify_add_mark() ->
                              fsnotify_add_inode_mark() ->  (add mark to inode->i_fsnotify_marks)
                            ...
                            get_tree(); (each inode will get one)
                    ...
                    lock audit_filter_mutex
    
    The work flow for deleting an inode:
    
        __destroy_inode() ->
         fsnotify_inode_delete() ->
           __fsnotify_inode_delete() ->
            fsnotify_clear_marks_by_inode() ->  (get mark from inode->i_fsnotify_marks)
              fsnotify_destroy_mark() ->
               fsnotify_destroy_mark_locked() ->
                 audit_tree_freeing_mark() ->
                   evict_chunk() ->
                     ...
                     tree->goner = 1
                     ...
                     kill_rules() ->   (assume current->audit_context == NULL)
                       call_rcu() ->   (rule->tree != NULL)
                         audit_free_rule_rcu() ->
                           audit_free_rule()
                     ...
                     audit_schedule_prune() ->  (assume current->audit_context == NULL)
                       kthread_run() ->    (need audit_cmd_mutex and audit_filter_mutex lock)
                         prune_one() ->    (delete it from prue_list)
                           put_tree(); (match the original get_tree above)
    
    Signed-off-by: Chen Gang <gang.chen@asianux.com>
    Cc: Eric Paris <eparis@redhat.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 30dad30922ccc733cfdbfe232090cf674dc374dc
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Wed Jun 12 14:05:04 2013 -0700

    mm: migration: add migrate_entry_wait_huge()
    
    When we have a page fault for the address which is backed by a hugepage
    under migration, the kernel can't wait correctly and do busy looping on
    hugepage fault until the migration finishes.  As a result, users who try
    to kick hugepage migration (via soft offlining, for example) occasionally
    experience long delay or soft lockup.
    
    This is because pte_offset_map_lock() can't get a correct migration entry
    or a correct page table lock for hugepage.  This patch introduces
    migration_entry_wait_huge() to solve this.
    
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Reviewed-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: <stable@vger.kernel.org>	[2.6.35+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 27749f2ff0717e115680922000839ad6a576eddf
Author: Xue jiufei <xuejiufei@huawei.com>
Date:   Wed Jun 12 14:05:03 2013 -0700

    ocfs2: add missing lockres put in dlm_mig_lockres_handler
    
    dlm_mig_lockres_handler() is missing a dlm_lockres_put() on an error path.
    
    Signed-off-by: joyce <xuejiufei@huawei.com>
    Reviewed-by: shencanquan <shencanquan@huawei.com>
    Cc: Mark Fasheh <mfasheh@suse.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 026b08147923142e925a7d0aaa39038055ae0156
Author: Tomasz Stanislawski <t.stanislaws@samsung.com>
Date:   Wed Jun 12 14:05:02 2013 -0700

    mm/page_alloc.c: fix watermark check in __zone_watermark_ok()
    
    The watermark check consists of two sub-checks.  The first one is:
    
    	if (free_pages <= min + lowmem_reserve)
    		return false;
    
    The check assures that there is minimal amount of RAM in the zone.  If
    CMA is used then the free_pages is reduced by the number of free pages
    in CMA prior to the over-mentioned check.
    
    	if (!(alloc_flags & ALLOC_CMA))
    		free_pages -= zone_page_state(z, NR_FREE_CMA_PAGES);
    
    This prevents the zone from being drained from pages available for
    non-movable allocations.
    
    The second check prevents the zone from getting too fragmented.
    
    	for (o = 0; o < order; o++) {
    		free_pages -= z->free_area[o].nr_free << o;
    		min >>= 1;
    		if (free_pages <= min)
    			return false;
    	}
    
    The field z->free_area[o].nr_free is equal to the number of free pages
    including free CMA pages.  Therefore the CMA pages are subtracted twice.
    This may cause a false positive fail of __zone_watermark_ok() if the CMA
    area gets strongly fragmented.  In such a case there are many 0-order
    free pages located in CMA.  Those pages are subtracted twice therefore
    they will quickly drain free_pages during the check against
    fragmentation.  The test fails even though there are many free non-cma
    pages in the zone.
    
    This patch fixes this issue by subtracting CMA pages only for a purpose of
    (free_pages <= min + lowmem_reserve) check.
    
    Laura said:
    
      We were observing allocation failures of higher order pages (order 5 =
      128K typically) under tight memory conditions resulting in driver
      failure.  The output from the page allocation failure showed plenty of
      free pages of the appropriate order/type/zone and mostly CMA pages in
      the lower orders.
    
      For full disclosure, we still observed some page allocation failures
      even after applying the patch but the number was drastically reduced and
      those failures were attributed to fragmentation/other system issues.
    
    Signed-off-by: Tomasz Stanislawski <t.stanislaws@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Tested-by: Laura Abbott <lauraa@codeaurora.org>
    Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Acked-by: Minchan Kim <minchan@kernel.org>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Cc: <stable@vger.kernel.org>	[3.7+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 282c4c0ecce9b9ac1b69acae32a4239441601405
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Jun 12 14:05:00 2013 -0700

    drivers/misc/sgi-gru/grufile.c: fix info leak in gru_get_config_info()
    
    The "info.fill" array isn't initialized so it can leak uninitialized stack
    information to user space.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Robin Holt <holt@sgi.com>
    Acked-by: Dimitri Sivanich <sivanich@sgi.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 4fcc712f5c48b1e32cdbf9b9cfba42a27b2e3160
Author: Kent Overstreet <koverstreet@google.com>
Date:   Wed Jun 12 14:04:59 2013 -0700

    aio: fix io_destroy() regression by using call_rcu()
    
    There was a regression introduced by 36f5588905c1 ("aio: refcounting
    cleanup"), reported by Jens Axboe - the refcounting cleanup switched to
    using RCU in the shutdown path, but the synchronize_rcu() was done in
    the context of the io_destroy() syscall greatly increasing the time it
    could block.
    
    This patch switches it to call_rcu() and makes shutdown asynchronous
    (more asynchronous than it was originally; before the refcount changes
    io_destroy() would still wait on pending kiocbs).
    
    Note that there's a global quota on the max outstanding kiocbs, and that
    quota must be manipulated synchronously; otherwise io_setup() could
    return -EAGAIN when there isn't quota available, and userspace won't
    have any way of waiting until shutdown of the old kioctxs has finished
    (besides busy looping).
    
    So we release our quota before kioctx shutdown has finished, which
    should be fine since the quota never corresponded to anything real
    anyways.
    
    Signed-off-by: Kent Overstreet <koverstreet@google.com>
    Cc: Zach Brown <zab@redhat.com>
    Cc: Felipe Balbi <balbi@ti.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Mark Fasheh <mfasheh@suse.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Reported-by: Jens Axboe <axboe@kernel.dk>
    Tested-by: Jens Axboe <axboe@kernel.dk>
    Cc: Asai Thambi S P <asamymuthupa@micron.com>
    Cc: Selvan Mani <smani@micron.com>
    Cc: Sam Bradshaw <sbradshaw@micron.com>
    Cc: Jeff Moyer <jmoyer@redhat.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
    Tested-by: Benjamin LaHaise <bcrl@kvack.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit bba00e59107275faa615573c44eb0a513a1220a6
Author: Johan Hovold <jhovold@gmail.com>
Date:   Wed Jun 12 14:04:57 2013 -0700

    rtc-at91rm9200: use shadow IMR on at91sam9x5
    
    Add support for the at91sam9x5-family which must use the shadow
    interrupt mask due to a hardware issue (causing RTC_IMR to always be
    zero).
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Cc: Douglas Gilbert <dgilbert@interlog.com>
    Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
    Cc: Ludovic Desroches <ludovic.desroches@atmel.com>
    Cc: Robert Nelson <Robert.Nelson@digikey.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit e9f08bbe3f97829975d2b59091ef557101c83f61
Author: Johan Hovold <jhovold@gmail.com>
Date:   Wed Jun 12 14:04:56 2013 -0700

    rtc-at91rm9200: add shadow interrupt mask
    
    Add shadow interrupt-mask register which can be used on SoCs where the
    actual hardware register is broken.
    
    Note that some care needs to be taken to make sure the shadow mask
    corresponds to the actual hardware state.  The added overhead is not an
    issue for the non-broken SoCs due to the relatively infrequent
    interrupt-mask updates.  We do, however, only use the shadow mask value
    as a fall-back when it actually needed as there is still a theoretical
    possibility that the mask is incorrect (see the code for details).
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Cc: Douglas Gilbert <dgilbert@interlog.com>
    Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
    Cc: Ludovic Desroches <ludovic.desroches@atmel.com>
    Cc: Robert Nelson <Robert.Nelson@digikey.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit e304fcd075a0e97d0e538dd4408b95406b505f85
Author: Johan Hovold <jhovold@gmail.com>
Date:   Wed Jun 12 14:04:55 2013 -0700

    rtc-at91rm9200: refactor interrupt-register handling
    
    Add accessors for the interrupt register.
    
    This will allow us to easily add a shadow interrupt-mask register to use
    on SoCs where the interrupt-mask register cannot be used.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Cc: Douglas Gilbert <dgilbert@interlog.com>
    Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
    Cc: Ludovic Desroches <ludovic.desroches@atmel.com>
    Cc: Robert Nelson <Robert.Nelson@digikey.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit de645475913f677eb024b3d2bd52e264e8106497
Author: Johan Hovold <jhovold@gmail.com>
Date:   Wed Jun 12 14:04:53 2013 -0700

    rtc-at91rm9200: add configuration support
    
    Add configuration support which can be used to implement SoC-specific
    workarounds for broken hardware.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Cc: Douglas Gilbert <dgilbert@interlog.com>
    Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
    Cc: Ludovic Desroches <ludovic.desroches@atmel.com>
    Cc: Robert Nelson <Robert.Nelson@digikey.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 558c61e5579a81551c0d6c2deaed1da3c7bf714a
Author: Johan Hovold <jhovold@gmail.com>
Date:   Wed Jun 12 14:04:52 2013 -0700

    rtc-at91rm9200: add match-table compile guard
    
    The members of Atmel's at91sam9x5 family (9x5) have a broken RTC
    interrupt mask register (AT91_RTC_IMR).  It does not reflect enabled
    interrupts but instead always returns zero.
    
    The kernel's rtc-at91rm9200 driver handles the RTC for the 9x5 family.
    Currently when the date/time is set, an interrupt is generated and this
    driver neglects to handle the interrupt.  The kernel complains about the
    un-handled interrupt and disables it henceforth.  This not only breaks
    the RTC function, but since that interrupt is shared (Atmel's SYS
    interrupt) then other things break as well (e.g.  the debug port no
    longer accepts characters).
    
    Tested on the at91sam9g25.  Bug confirmed by Atmel.
    
    This patch (of 5):
    
    Add missing match-table compile guard.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Cc: Douglas Gilbert <dgilbert@interlog.com>
    Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
    Cc: Ludovic Desroches <ludovic.desroches@atmel.com>
    Cc: Robert Nelson <Robert.Nelson@digikey.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit e099127169429c19544a8f55dd26937fddd5b1f4
Author: Goldwyn Rodrigues <rgoldwyn@gmail.com>
Date:   Wed Jun 12 14:04:51 2013 -0700

    fs/ocfs2/namei.c: remove unecessary ERROR when removing non-empty directory
    
    While removing a non-empty directory, the kernel dumps a message:
    
      (rmdir,21743,1):ocfs2_unlink:953 ERROR: status = -39
    
    Suppress the error message from being printed in the dmesg so users
    don't panic.
    
    Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
    Cc: Mark Fasheh <mfasheh@suse.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Acked-by: Sunil Mushran <sunil.mushran@gmail.com>
    Reviewed-by: Jie Liu <jeff.liu@oracle.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit cbab0e4eec299e9059199ebe6daf48730be46d2b
Author: Rafael Aquini <aquini@redhat.com>
Date:   Wed Jun 12 14:04:49 2013 -0700

    swap: avoid read_swap_cache_async() race to deadlock while waiting on discard I/O completion
    
    read_swap_cache_async() can race against get_swap_page(), and stumble
    across a SWAP_HAS_CACHE entry in the swap map whose page wasn't brought
    into the swapcache yet.
    
    This transient swap_map state is expected to be transitory, but the
    actual placement of discard at scan_swap_map() inserts a wait for I/O
    completion thus making the thread at read_swap_cache_async() to loop
    around its -EEXIST case, while the other end at get_swap_page() is
    scheduled away at scan_swap_map().  This can leave the system deadlocked
    if the I/O completion happens to be waiting on the CPU waitqueue where
    read_swap_cache_async() is busy looping and !CONFIG_PREEMPT.
    
    This patch introduces a cond_resched() call to make the aforementioned
    read_swap_cache_async() busy loop condition to bail out when necessary,
    thus avoiding the subtle race window.
    
    Signed-off-by: Rafael Aquini <aquini@redhat.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Acked-by: Hugh Dickins <hughd@google.com>
    Cc: Shaohua Li <shli@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 24b8256a1fb28d357bc6fa09184ba29b4255ba5c
Author: Tony Lindgren <tony@atomide.com>
Date:   Wed Jun 12 14:04:48 2013 -0700

    drivers/rtc/rtc-twl.c: fix missing device_init_wakeup() when booted with device tree
    
    When booted in legacy mode device_init_wakeup() gets called by
    drivers/mfd/twl-core.c when the children are initialized.  However, when
    booted using device tree, the children are created with
    of_platform_populate() instead add_children().
    
    This means that the RTC driver will not have device_init_wakeup() set,
    and we need to call it from the driver probe like RTC drivers typically
    do.
    
    Without this we cannot test PM wake-up events on omaps for cases where
    there may not be any physical wake-up event.
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Reported-by: Kevin Hilman <khilman@linaro.org>
    Cc: Alessandro Zummo <a.zummo@towertech.it>
    Cc: Jingoo Han <jg1.han@samsung.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 03f47e888daf56c8e9046c674719a0bcc644eed5
Author: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Date:   Wed Jun 12 14:04:47 2013 -0700

    cciss: fix broken mutex usage in ioctl
    
    If a new logical drive is added and the CCISS_REGNEWD ioctl is invoked
    (as is normal with the Array Configuration Utility) the process will
    hang as below.  It attempts to acquire the same mutex twice, once in
    do_ioctl() and once in cciss_unlocked_open().  The BKL was recursive,
    the mutex isn't.
    
      Linux version 3.10.0-rc2 (scameron@localhost.localdomain) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP Fri May 24 14:32:12 CDT 2013
      [...]
      acu             D 0000000000000001     0  3246   3191 0x00000080
      Call Trace:
        schedule+0x29/0x70
        schedule_preempt_disabled+0xe/0x10
        __mutex_lock_slowpath+0x17b/0x220
        mutex_lock+0x2b/0x50
        cciss_unlocked_open+0x2f/0x110 [cciss]
        __blkdev_get+0xd3/0x470
        blkdev_get+0x5c/0x1e0
        register_disk+0x182/0x1a0
        add_disk+0x17c/0x310
        cciss_add_disk+0x13a/0x170 [cciss]
        cciss_update_drive_info+0x39b/0x480 [cciss]
        rebuild_lun_table+0x258/0x370 [cciss]
        cciss_ioctl+0x34f/0x470 [cciss]
        do_ioctl+0x49/0x70 [cciss]
        __blkdev_driver_ioctl+0x28/0x30
        blkdev_ioctl+0x200/0x7b0
        block_ioctl+0x3c/0x40
        do_vfs_ioctl+0x89/0x350
        SyS_ioctl+0xa1/0xb0
        system_call_fastpath+0x16/0x1b
    
    This mutex usage was added into the ioctl path when the big kernel lock
    was removed.  As it turns out, these paths are all thread safe anyway
    (or can easily be made so) and we don't want ioctl() to be single
    threaded in any case.
    
    Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Mike Miller <mike.miller@hp.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit f000cfdde5de4fc15dead5ccf524359c07eadf2b
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Wed Jun 12 14:04:46 2013 -0700

    audit: wait_for_auditd() should use TASK_UNINTERRUPTIBLE
    
    audit_log_start() does wait_for_auditd() in a loop until
    audit_backlog_wait_time passes or audit_skb_queue has a room.
    
    If signal_pending() is true this becomes a busy-wait loop, schedule() in
    TASK_INTERRUPTIBLE won't block.
    
    Thanks to Guy for fully investigating and explaining the problem.
    
    (akpm: that'll cause the system to lock up on a non-preemptible
    uniprocessor kernel)
    
    (Guy: "Our customer was in fact running a uniprocessor machine, and they
    reported a system hang.")
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Reported-by: Guy Streeter <streeter@redhat.com>
    Cc: Eric Paris <eparis@redhat.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit ebf8d6c8630bfd3e24683306599cb953c9a2842c
Author: Derek Basehore <dbasehore@chromium.org>
Date:   Wed Jun 12 14:04:45 2013 -0700

    drivers/rtc/rtc-cmos.c: fix accidentally enabling rtc channel
    
    During resume, we call hpet_rtc_timer_init after masking an irq bit in
    hpet.  This will cause the call to hpet_disable_rtc_channel to be undone
    if RTC_AIE is the only bit not masked.
    
    Allowing the cmos interrupt handler to run before resuming caused some
    issues where the timer for the alarm was not removed.  This would cause
    other, later timers to not be cleared, so utilities such as hwclock
    would time out when waiting for the update interrupt.
    
    [akpm@linux-foundation.org: coding-style tweak]
    Signed-off-by: Derek Basehore <dbasehore@chromium.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 5a280844bb3bcd79076cac6ad002f71d25c798e5
Author: Dmitry Osipenko <digetx@gmail.com>
Date:   Wed Jun 12 14:04:44 2013 -0700

    drivers/rtc/rtc-tps6586x.c: device wakeup flags correction
    
    Use device_init_wakeup() instead of device_set_wakeup_capable() and move
    it before rtc dev registering.  This fixes alarmtimer not registered
    when tps6586x rtc is the only wakeup compatible rtc in the system.
    
    Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
    Cc: Laxman Dewangan <ldewangan@nvidia.com>
    Cc: Jingoo Han <jg1.han@samsung.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit f101a9464bfbda42730b54a66f926d75ed2cd31e
Author: Andrey Vagin <avagin@openvz.org>
Date:   Wed Jun 12 14:04:42 2013 -0700

    memcg: don't initialize kmem-cache destroying work for root caches
    
    struct memcg_cache_params has a union.  Different parts of this union
    are used for root and non-root caches.  A part with destroying work is
    used only for non-root caches.
    
      BUG: unable to handle kernel paging request at 0000000fffffffe0
      IP: kmem_cache_alloc+0x41/0x1f0
      Modules linked in: netlink_diag af_packet_diag udp_diag tcp_diag inet_diag unix_diag ip6table_filter ip6_tables i2c_piix4 virtio_net virtio_balloon microcode i2c_core pcspkr floppy
      CPU: 0 PID: 1929 Comm: lt-vzctl Tainted: G      D      3.10.0-rc1+ #2
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      RIP: kmem_cache_alloc+0x41/0x1f0
      Call Trace:
       getname_flags.part.34+0x30/0x140
       getname+0x38/0x60
       do_sys_open+0xc5/0x1e0
       SyS_open+0x22/0x30
       system_call_fastpath+0x16/0x1b
      Code: f4 53 48 83 ec 18 8b 05 8e 53 b7 00 4c 8b 4d 08 21 f0 a8 10 74 0d 4c 89 4d c0 e8 1b 76 4a 00 4c 8b 4d c0 e9 92 00 00 00 4d 89 f5 <4d> 8b 45 00 65 4c 03 04 25 48 cd 00 00 49 8b 50 08 4d 8b 38 49
      RIP  [<ffffffff8116b641>] kmem_cache_alloc+0x41/0x1f0
    
    Signed-off-by: Andrey Vagin <avagin@openvz.org>
    Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
    Cc: Glauber Costa <glommer@parallels.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Balbir Singh <bsingharora@gmail.com>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Cc: Li Zefan <lizefan@huawei.com>
    Cc: <stable@vger.kernel.org>	[3.9.x]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 7869e590679ed71cd1a1e676e8c1c179762c3efe
Author: Xiaowei.Hu <xiaowei.hu@oracle.com>
Date:   Wed Jun 12 14:04:41 2013 -0700

    ocfs2: ocfs2_prep_new_orphaned_file() should return ret
    
    If an error occurs, for example an EIO in __ocfs2_prepare_orphan_dir,
    ocfs2_prep_new_orphaned_file will release the inode_ac, then when the
    caller of ocfs2_prep_new_orphaned_file gets a 0 return, it will refer to
    a NULL ocfs2_alloc_context struct in the following functions.  A kernel
    panic happens.
    
    Signed-off-by: "Xiaowei.Hu" <xiaowei.hu@oracle.com>
    Reviewed-by: shencanquan <shencanquan@huawei.com>
    Acked-by: Sunil Mushran <sunil.mushran@gmail.com>
    Cc: Joe Jin <joe.jin@oracle.com>
    Cc: Mark Fasheh <mfasheh@suse.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 5402b8047b0d286b6501f9097891cbf1e06daa3a
Author: Chen Gang <gang.chen@asianux.com>
Date:   Wed Jun 12 14:04:40 2013 -0700

    lib/mpi/mpicoder.c: looping issue, need stop when equal to zero, found by 'EXTRA_FLAGS=-W'.
    
    For 'while' looping, need stop when 'nbytes == 0', or will cause issue.
    ('nbytes' is size_t which is always bigger or equal than zero).
    
    The related warning: (with EXTRA_CFLAGS=-W)
    
      lib/mpi/mpicoder.c:40:2: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
    
    Signed-off-by: Chen Gang <gang.chen@asianux.com>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: David Howells <dhowells@redhat.com>
    Cc: James Morris <james.l.morris@oracle.com>
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 637241a900cbd982f744d44646b48a273d609b34
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Jun 12 14:04:39 2013 -0700

    kmsg: honor dmesg_restrict sysctl on /dev/kmsg
    
    The dmesg_restrict sysctl currently covers the syslog method for access
    dmesg, however /dev/kmsg isn't covered by the same protections.  Most
    people haven't noticed because util-linux dmesg(1) defaults to using the
    syslog method for access in older versions.  With util-linux dmesg(1)
    defaults to reading directly from /dev/kmsg.
    
    To fix /dev/kmsg, let's compare the existing interfaces and what they
    allow:
    
     - /proc/kmsg allows:
      - open (SYSLOG_ACTION_OPEN) if CAP_SYSLOG since it uses a destructive
        single-reader interface (SYSLOG_ACTION_READ).
      - everything, after an open.
    
     - syslog syscall allows:
      - anything, if CAP_SYSLOG.
      - SYSLOG_ACTION_READ_ALL and SYSLOG_ACTION_SIZE_BUFFER, if
        dmesg_restrict==0.
      - nothing else (EPERM).
    
    The use-cases were:
     - dmesg(1) needs to do non-destructive SYSLOG_ACTION_READ_ALLs.
     - sysklog(1) needs to open /proc/kmsg, drop privs, and still issue the
       destructive SYSLOG_ACTION_READs.
    
    AIUI, dmesg(1) is moving to /dev/kmsg, and systemd-journald doesn't
    clear the ring buffer.
    
    Based on the comments in devkmsg_llseek, it sounds like actions besides
    reading aren't going to be supported by /dev/kmsg (i.e.
    SYSLOG_ACTION_CLEAR), so we have a strict subset of the non-destructive
    syslog syscall actions.
    
    To this end, move the check as Josh had done, but also rename the
    constants to reflect their new uses (SYSLOG_FROM_CALL becomes
    SYSLOG_FROM_READER, and SYSLOG_FROM_FILE becomes SYSLOG_FROM_PROC).
    SYSLOG_FROM_READER allows non-destructive actions, and SYSLOG_FROM_PROC
    allows destructive actions after a capabilities-constrained
    SYSLOG_ACTION_OPEN check.
    
     - /dev/kmsg allows:
      - open if CAP_SYSLOG or dmesg_restrict==0
      - reading/polling, after open
    
    Addresses https://bugzilla.redhat.com/show_bug.cgi?id=903192
    
    [akpm@linux-foundation.org: use pr_warn_once()]
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reported-by: Christian Kujau <lists@nerdbynature.de>
    Tested-by: Josh Boyer <jwboyer@redhat.com>
    Cc: Kay Sievers <kay@vrfy.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit cf7df378aa4ff7da3a44769b7ff6e9eef1a9f3db
Author: Robin Holt <holt@sgi.com>
Date:   Wed Jun 12 14:04:37 2013 -0700

    reboot: rigrate shutdown/reboot to boot cpu
    
    We recently noticed that reboot of a 1024 cpu machine takes approx 16
    minutes of just stopping the cpus.  The slowdown was tracked to commit
    f96972f2dc63 ("kernel/sys.c: call disable_nonboot_cpus() in
    kernel_restart()").
    
    The current implementation does all the work of hot removing the cpus
    before halting the system.  We are switching to just migrating to the
    boot cpu and then continuing with shutdown/reboot.
    
    This also has the effect of not breaking x86's command line parameter
    for specifying the reboot cpu.  Note, this code was shamelessly copied
    from arch/x86/kernel/reboot.c with bits removed pertaining to the
    reboot_cpu command line parameter.
    
    Signed-off-by: Robin Holt <holt@sgi.com>
    Tested-by: Shawn Guo <shawn.guo@linaro.org>
    Cc: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Russ Anderson <rja@sgi.com>
    Cc: Robin Holt <holt@sgi.com>
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 16e53dbf10a2d7e228709a7286310e629ede5e45
Author: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Date:   Wed Jun 12 14:04:36 2013 -0700

    CPU hotplug: provide a generic helper to disable/enable CPU hotplug
    
    There are instances in the kernel where we would like to disable CPU
    hotplug (from sysfs) during some important operation.  Today the freezer
    code depends on this and the code to do it was kinda tailor-made for
    that.
    
    Restructure the code and make it generic enough to be useful for other
    usecases too.
    
    Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Robin Holt <holt@sgi.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Russ Anderson <rja@sgi.com>
    Cc: Robin Holt <holt@sgi.com>
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
    Cc: Shawn Guo <shawn.guo@linaro.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit c8a22d19dd238ede87aa0ac4f7dbea8da039b9c1
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Jun 5 11:47:18 2013 -0700

    x86: Fix typo in kexec register clearing
    
    Fixes a typo in register clearing code. Thanks to PaX Team for fixing
    this originally, and James Troup for pointing it out.
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: http://lkml.kernel.org/r/20130605184718.GA8396@www.outflux.net
    Cc: <stable@vger.kernel.org> v2.6.30+
    Cc: PaX Team <pageexec@freemail.hu>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

commit b1983b0a7578de09211a696802edab83fd253303
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Jun 11 11:56:52 2013 -0700

    x86, relocs: Move __vvar_page from S_ABS to S_REL
    
    The __vvar_page relocation should actually be listed in S_REL instead
    of S_ABS. Oddly, this didn't always cause things to break, presumably
    because there are no users for relocation information on 64 bits yet.
    
    [ hpa: Not for stable - new code in 3.10 ]
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: http://lkml.kernel.org/r/20130611185652.GA23674@www.outflux.net
    Reported-by: Michael Davidson <md@google.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

commit e0e29b683d6784ef59bbc914eac85a04b650e63c
Author: Kees Cook <keescook@chromium.org>
Date:   Fri May 10 14:48:21 2013 -0700

    b43: stop format string leaking into error msgs
    
    The module parameter "fwpostfix" is userspace controllable, unfiltered,
    and is used to define the firmware filename. b43_do_request_fw() populates
    ctx->errors[] on error, containing the firmware filename. b43err()
    parses its arguments as a format string. For systems with b43 hardware,
    this could lead to a uid-0 to ring-0 escalation.
    
    CVE-2013-2852
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 5efac94999ff218e0101f67a059e44abb4b0b523
Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Date:   Thu Jun 6 10:06:29 2013 +0530

    ath9k: Use minstrel rate control by default
    
    The ath9k rate control algorithm has various architectural
    issues that make it a poor fit in scenarios like congested
    environments etc.
    
    An example: https://bugzilla.redhat.com/show_bug.cgi?id=927191
    
    Change the default to minstrel which is more robust in such cases.
    The ath9k RC code is left in the driver for now, maybe it can
    be removed altogether later on.
    
    Cc: stable@vger.kernel.org
    Cc: Jouni Malinen <jouni@qca.qualcomm.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 96005931785238e1a24febf65ffb5016273e8225
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Mon Jun 3 11:18:57 2013 +0200

    Revert "ath9k_hw: Update rx gain initval to improve rx sensitivity"
    
    This reverts commit 68d9e1fa24d9c7c2e527f49df8d18fb8cf0ec943
    
    This change reduces rx sensitivity with no apparent extra benefit.
    It looks like it was meant for testing in a specific scenario,
    but it was never properly validated.
    
    Cc: rmanohar@qca.qualcomm.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 531671cb17af07281e6f28c1425f754346e65c41
Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Date:   Sat Jun 1 07:08:09 2013 +0530

    ath9k: Disable PowerSave by default
    
    Almost all the DMA issues which have plagued ath9k (in station mode)
    for years are related to PS. Disabling PS usually "fixes" the user's
    connection stablility. Reports of DMA problems are still trickling in
    and are sitting in the kernel bugzilla. Until the PS code in ath9k is
    given a thorough review, disbale it by default. The slight increase
    in chip power consumption is a small price to pay for improved link
    stability.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 71aa5bba83f81722e7f6bfaeda16b983ba8a0cc2
Author: Yijing Wang <wangyijing@huawei.com>
Date:   Fri May 31 14:05:32 2013 +0800

    net: wireless: iwlegacy: fix build error for il_pm_ops
    
    Fix build error for il_pm_ops if CONFIG_PM is set
    but CONFIG_PM_SLEEP is not set.
    
    ERROR: "il_pm_ops" [drivers/net/wireless/iwlegacy/iwl4965.ko] undefined!
    ERROR: "il_pm_ops" [drivers/net/wireless/iwlegacy/iwl3945.ko] undefined!
    make[1]: *** [__modpost] Error 1
    make: *** [modules] Error 2
    
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Cc: Stanislaw Gruszka <sgruszka@redhat.com>
    Cc: "John W. Linville" <linville@tuxdriver.com>
    Cc: netdev@vger.kernel.org
    Cc: linux-wireless@vger.kernel.org
    Cc: Jingoo Han <jg1.han@samsung.com>
    Acked-by: Jingoo Han <jg1.han@samsung.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 87ccee46fabd235c2bac3652dee009e8f791dc10
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Thu May 30 16:21:47 2013 -0500

    rtlwifi: Fix a false leak indication for PCI devices
    
    This false leak indication is avoided with a no-leak annotation to kmemleak.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit a805de4d036152a4ad7d3b18a9993a5c86588d6d
Author: Eliad Peller <eliad@wizery.com>
Date:   Tue May 7 15:41:09 2013 +0300

    wl12xx/wl18xx: scan all 5ghz channels
    
    Due to a typo, the current code copies only sizeof(cmd->channels_2)
    bytes, which is smaller than the correct sizeof(cmd->channels_5)
    size, resulting in a partial scan (some channels are skipped).
    
    Signed-off-by: Eliad Peller <eliad@wizery.com>
    Signed-off-by: Luciano Coelho <coelho@ti.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 0e284c074ef96554f2988298da7d110b0e8d1e23
Author: Luciano Coelho <coelho@ti.com>
Date:   Fri May 10 10:44:25 2013 +0300

    wl12xx: increase minimum singlerole firmware version required
    
    The minimum firmware version required for singlerole after recent
    driver changes is 6/7.3.10.0.133.
    
    Reported-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Luciano Coelho <coelho@ti.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 60c28cf18f970e1c1bd40d615596eeab6efbd9d7
Author: Luciano Coelho <coelho@ti.com>
Date:   Fri May 10 10:19:38 2013 +0300

    wl12xx: fix minimum required firmware version for wl127x multirole
    
    There was a typo in commit 8675f9 (wlcore/wl12xx/wl18xx: verify
    multi-role and single-role fw versions), which was causing the
    multirole firmware for wl127x (WiLink6) to be rejected.  The actual
    minimum version needed for wl127x multirole is 6.5.7.0.42.
    
    Reported-by: Levi Pearson <levipearson@gmail.com>
    Reported-by: Michael Scott <hashcode0f@gmail.com>
    Cc: stable@kernel.org # 3.9+
    Signed-off-by: Luciano Coelho <coelho@ti.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 5b8df24e22e0b00b599cb9ae63dbb96e1959be30
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Thu May 30 18:05:55 2013 -0500

    rtlwifi: rtl8192cu: Fix problem in connecting to WEP or WPA(1) networks
    
    Driver rtl8192cu can connect to WPA2 networks, but fails for any other
    encryption method. The cause is a failure to set the rate control data
    blocks. These changes fix https://bugzilla.redhat.com/show_bug.cgi?id=952793
    and https://bugzilla.redhat.com/show_bug.cgi?id=761525.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit f873ded213d6d8c36354c0fc903af44da4fd6ac5
Author: Mark A. Greer <mgreer@animalcreek.com>
Date:   Wed May 29 12:25:34 2013 -0700

    mwifiex: debugfs: Fix out of bounds array access
    
    When reading the contents of '/sys/kernel/debug/mwifiex/p2p0/info',
    the following panic occurs:
    
    $ cat /sys/kernel/debug/mwifiex/p2p0/info
    Unable to handle kernel paging request at virtual address 74706164
    pgd = de530000
    [74706164] *pgd=00000000
    Internal error: Oops: 5 [#1] SMP ARM
    Modules linked in: phy_twl4030_usb omap2430 musb_hdrc mwifiex_sdio mwifiex
    CPU: 0 PID: 1635 Comm: cat Not tainted 3.10.0-rc1-00010-g1268390 #1
    task: de16b6c0 ti: de048000 task.ti: de048000
    PC is at strnlen+0xc/0x4c
    LR is at string+0x3c/0xf8
    pc : [<c02c123c>]    lr : [<c02c2d1c>]    psr: a0000013
    sp : de049e10  ip : c06efba0  fp : de6d2092
    r10: bf01a260  r9 : ffffffff  r8 : 74706164
    r7 : 0000ffff  r6 : ffffffff  r5 : de6d209c  r4 : 00000000
    r3 : ff0a0004  r2 : 74706164  r1 : ffffffff  r0 : 74706164
    Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
    Control: 10c5387d  Table: 9e530019  DAC: 00000015
    Process cat (pid: 1635, stack limit = 0xde048240)
    Stack: (0xde049e10 to 0xde04a000)
    9e00:                                     de6d2092 00000002 bf01a25e de6d209c
    9e20: de049e80 c02c438c 0000000a ff0a0004 ffffffff 00000000 00000000 de049e48
    9e40: 00000000 2192df6d ff0a0004 ffffffff 00000000 de6d2092 de049ef8 bef3cc00
    9e60: de6b0000 dc358000 de6d2000 00000000 00000003 c02c45a4 bf01790c bf01a254
    9e80: 74706164 bf018698 00000000 de59c3c0 de048000 de049f80 00001000 bef3cc00
    9ea0: 00000008 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    9ec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    9ee0: 00000000 00000000 00000000 00000001 00000000 00000000 6669776d 20786569
    9f00: 20302e31 2e343128 392e3636 3231702e 00202933 00000000 00000003 c0294898
    9f20: 00000000 00000000 00000000 00000000 de59c3c0 c0107c04 de554000 de59c3c0
    9f40: 00001000 bef3cc00 de049f80 bef3cc00 de049f80 00000000 00000003 c0108a00
    9f60: de048000 de59c3c0 00000000 00000000 de59c3c0 00001000 bef3cc00 c0108b60
    9f80: 00000000 00000000 00001000 bef3cc00 00000003 00000003 c0014128 de048000
    9fa0: 00000000 c0013f80 00001000 bef3cc00 00000003 bef3cc00 00001000 00000000
    9fc0: 00001000 bef3cc00 00000003 00000003 00000001 00000001 00000001 00000003
    9fe0: 00000000 bef3cbdc 00011984 b6f1127c 60000010 00000003 18dbdd2c 7f7bfffd
    [<c02c123c>] (strnlen+0xc/0x4c) from [<c02c2d1c>] (string+0x3c/0xf8)
    [<c02c2d1c>] (string+0x3c/0xf8) from [<c02c438c>] (vsnprintf+0x1e8/0x3e8)
    [<c02c438c>] (vsnprintf+0x1e8/0x3e8) from [<c02c45a4>] (sprintf+0x18/0x24)
    [<c02c45a4>] (sprintf+0x18/0x24) from [<bf01790c>] (mwifiex_info_read+0xfc/0x3e8 [mwifiex])
    [<bf01790c>] (mwifiex_info_read+0xfc/0x3e8 [mwifiex]) from [<c0108a00>] (vfs_read+0xb0/0x144)
    [<c0108a00>] (vfs_read+0xb0/0x144) from [<c0108b60>] (SyS_read+0x44/0x70)
    [<c0108b60>] (SyS_read+0x44/0x70) from [<c0013f80>] (ret_fast_syscall+0x0/0x30)
    Code: e12fff1e e3510000 e1a02000 0a00000d (e5d03000)
    ---[ end trace ca98273dc605a04f ]---
    
    The panic is caused by the mwifiex_info_read() routine assuming that
    there can only be four modes (0-3) which is an invalid assumption.
    For example, when testing P2P, the mode is '8' (P2P_CLIENT) so the
    code accesses data beyond the bounds of the bss_modes[] array which
    causes the panic.  Fix this by updating bss_modes[] to support the
    current list of modes and adding a check to prevent the out-of-bounds
    access from occuring in the future when more modes are added.
    
    Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
    Acked-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 96570ffcca0b872dc8626e97569d2697f374d868
Author: Johan Hedberg <johan.hedberg@intel.com>
Date:   Wed May 29 09:51:29 2013 +0300

    Bluetooth: Fix mgmt handling of power on failures
    
    If hci_dev_open fails we need to ensure that the corresponding
    mgmt_set_powered command gets an appropriate response. This patch fixes
    the missing response by adding a new mgmt_set_powered_failed function
    that's used to indicate a power on failure to mgmt. Since a situation
    with the device being rfkilled may require special handling in user
    space the patch uses a new dedicated mgmt status code for this.
    
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Cc: stable@vger.kernel.org
    Acked-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit cb3b3152b2f5939d67005cff841a1ca748b19888
Author: Johan Hedberg <johan.hedberg@intel.com>
Date:   Tue May 28 13:46:30 2013 +0300

    Bluetooth: Fix missing length checks for L2CAP signalling PDUs
    
    There has been code in place to check that the L2CAP length header
    matches the amount of data received, but many PDU handlers have not been
    checking that the data received actually matches that expected by the
    specific PDU. This patch adds passing the length header to the specific
    handler functions and ensures that those functions fail cleanly in the
    case of an incorrect amount of data.
    
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 22f2efed35e02a7c0b1ec73cfe790b1e3d207f4b
Author: Bing Zhao <bzhao@marvell.com>
Date:   Mon May 13 18:15:32 2013 -0700

    Bluetooth: btmrvl: support Marvell Bluetooth device SD8897
    
    The register offsets have been changed in SD8897 and newer chips.
    Define a new btmrvl_sdio_card_reg map for SD88xx.
    
    Signed-off-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: Frank Huang <frankh@marvell.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 757aee0f7177b7c7528aa0c120fc131aca8bf641
Author: Johan Hedberg <johan.hedberg@intel.com>
Date:   Wed Apr 24 13:05:32 2013 +0300

    Bluetooth: Fix checks for LE support on LE-only controllers
    
    LE-only controllers do not support extended features so any kind of host
    feature bit checks do not make sense for them. This patch fixes code
    used for both single-mode (LE-only) and dual-mode (BR/EDR/LE) to use the
    HCI_LE_ENABLED flag instead of the "Host LE supported" feature bit for
    LE support tests.
    
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Acked-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 089920f21db0108fb105ecfd81de4c92d88f06d0
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Thu Jun 6 17:51:21 2013 -0400

    drm/radeon: fix write back suspend regression with uvd v2
    
    UVD ring can't use scratch thus it does need writeback buffer to keep
    a valid address or radeon_ring_backup will trigger a kernel fault.
    
    It's ok to not unpin the write back buffer on suspend as it leave in
    gtt and thus does not need eviction.
    
    v2: Fix the uvd case.
    
    Reported and tracked by Wojtek <wojtask9@wp.pl>
    
    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit 3813f5ca9ab7a00e80a17aab34f155453c66c78a
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Thu Jun 6 12:41:17 2013 -0400

    drm/radeon: do not try to uselessly update virtual memory pagetable
    
    If a buffer is never bound to a virtual memory pagetable than don't try
    to unbind it. Only drawback is that we don't update the pagetable when
    unbinding the ib pool buffer which is fine because it only happens at
    suspend or module unload/shutdown.
    
    Fixes spurious messages about buffers without VM mappings. E.g.:
    radeon 0000:01:00.0: bo ffff88020afac400 don't has a mapping in vm ffff88021ca2b900
    
    Cc: stable@kernel.org
    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit 5939212df87e9377dd3813904264b94a962d19ca
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Wed May 29 10:45:09 2013 +0200

    HID: multitouch: prevent memleak with the allocated name
    
    mt_free_input_name() was never called during .remove():
    hid_hw_stop() removes the hid_input items in hdev->inputs, and so the
    list is therefore empty after the call. In the end, we never free the
    special names that has been allocated during .probe().
    
    Restore the original name before freeing it to avoid acessing already
    freed pointer.
    
    This fixes a regression introduced by 49a5a827a ("HID: multitouch: append " Pen" to
    the name of the stylus input")
    
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit b79462a8b9f9a452edc20c64a70a89ba3b0a6a88
Author: Jiri Pirko <jiri@resnulli.us>
Date:   Sat Jun 8 15:00:55 2013 +0200

    team: fix checks in team_get_first_port_txable_rcu()
    
    should be checked if "cur" is txable, not "port".
    
    Introduced by commit 6e88e1357c "team: use function team_port_txable()
    for determing enabled and up port"
    
    Signed-off-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 72df935d985c1575ed44ad2c8c653b28147993fa
Author: Jiri Pirko <jiri@resnulli.us>
Date:   Sat Jun 8 15:00:54 2013 +0200

    team: move add to port list before port enablement
    
    team_port_enable() adds port to port_hashlist. Reader sees port
    in team_get_port_by_index_rcu() and returns it, but
    team_get_first_port_txable_rcu() tries to go through port_list, where the
    port is not inserted yet -> NULL pointer dereference.
    Fix this by reordering port_list and port_hashlist insertion.
    Panic is easily triggeable when txing packets and adding/removing port
    in a loop.
    
    Introduced by commit 3d249d4c "net: introduce ethernet teaming device"
    
    Signed-off-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 76c455decbbad31de21c727edb184a963f42b40b
Author: Jiri Pirko <jiri@resnulli.us>
Date:   Sat Jun 8 15:00:53 2013 +0200

    team: check return value of team_get_port_by_index_rcu() for NULL
    
    team_get_port_by_index_rcu() might return NULL due to race between port
    removal and skb tx path. Panic is easily triggeable when txing packets
    and adding/removing port in a loop.
    
    introduced by commit 3d249d4ca "net: introduce ethernet teaming device"
    and commit 753f993911b "team: introduce random mode" (for random mode)
    
    Signed-off-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 19a6afb23e5d323e1245baa4e62755492b2f1200
Author: Jason Wang <jasowang@redhat.com>
Date:   Sat Jun 8 14:17:41 2013 +0800

    tuntap: set SOCK_ZEROCOPY flag during open
    
    Commit 54f968d6efdbf7dec36faa44fc11f01b0e4d1990
    (tuntap: move socket to tun_file) forgets to set SOCK_ZEROCOPY flag, which will
    prevent vhost_net from doing zercopy w/ tap. This patch fixes this by setting
    it during file open.
    
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 346f372f7b72a05bfa9b4e6d1b1e5de289a18d8a
Author: Tushar Behera <tushar.behera@linaro.org>
Date:   Thu Jun 6 13:58:18 2013 +0530

    clk: exynos5250: Add CLK_IGNORE_UNUSED flag for pmu clock
    
    Currently 'pmu' clock is not handled by any of the drivers.
    Also before the introduction of CCF, this clock was not defined,
    hence was left enabled always.
    
    When this clock is disabled, software reset register becomes
    inaccessible and system reboot doesn't work.
    
    Upon restoring the default behaviour, system reboot starts working.
    
    Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
    Signed-off-by: Mike Turquette <mturquette@linaro.org>

commit 0c3f3dc68bb6e6950e8cd7851e7778c550e8dfb4
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Tue Jun 11 13:41:48 2013 +0300

    usb: chipidea: fix id change handling
    
    Re-enable chipidea irq even if there's no role changing to do. This is
    a problem since b183c19f ("USB: chipidea: re-order irq handling to avoid
    unhandled irqs"); when it manifests, chipidea irq gets disabled for good.
    
    Cc: stable@vger.kernel.org # v3.7
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d343f4e8d6e4e4237b25b32e4f6a09d1281d4ca3
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Tue Jun 11 13:41:47 2013 +0300

    usb: chipidea: fix no transceiver case
    
    Since usb phy code does return ERR_PTR() values, make sure that we don't
    end up dereferencing them. This is a problem, for example, on platforms
    that don't register a phy for chipidea since b7fa5c2a ("usb: phy: return
    -ENXIO when PHY layer isn't enabled").
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b63cc3ce11822ac96a334a345640f524212cd6b
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Jun 4 00:05:07 2013 +0200

    clk: spear: fix build error for spear3xx
    
    This patch is required to be able to disable spear320 support
    after the spear320_clk_init() prototype changed for the real
    function but not for the dummy.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Mike Turquette <mturquette@linaro.org>

commit d7880812b3594d3c6dcbe3cfd71dabb17347d082
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Jun 10 16:52:03 2013 +0200

    idle: Add the stack canary init to cpu_startup_entry()
    
    Moving x86 to the generic idle implementation (commit 7d1a9417 "x86:
    Use generic idle loop") wreckaged the stack protector.
    
    I stupidly missed that boot_init_stack_canary() must be inlined from a
    function which never returns, but I put that call into
    arch_cpu_idle_prepare() which of course returns.
    
    I pondered to play tricks with arch_cpu_idle_prepare() first, but then
    I noticed, that the other archs which have implemented the
    stackprotector (ARM and SH) do not initialize the canary for the
    non-boot cpus.
    
    So I decided to move the boot_init_stack_canary() call into
    cpu_startup_entry() ifdeffed with an CONFIG_X86 for now. This #ifdef
    is just a temporary measure as I don't want to inflict the
    boot_init_stack_canary() call on ARM and SH that late in the cycle.
    
    I'll queue a patch for 3.11 which removes the #ifdef if the ARM/SH
    maintainers have no objection.
    
    Reported-by: Wouter van Kesteren <woutershep@gmail.com>
    Cc: x86@kernel.org
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: Paul Mundt <lethal@linux-sh.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

commit 58e8eedf18577c7eac722d5d1f190507ea263d1b
Author: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com>
Date:   Tue Apr 23 10:32:39 2013 +0900

    tracing: Fix outputting formats of x86-tsc and counter when use trace_clock
    
    Outputting formats of x86-tsc and counter should be a raw format, but after
    applying the patch(2b6080f28c7cc3efc8625ab71495aae89aeb63a0), the format was
    changed to nanosec. This is because the global variable trace_clock_id was used.
    When we use multiple buffers, clock_id of each sub-buffer should be used. Then,
    this patch uses tr->clock_id instead of the global variable trace_clock_id.
    
    [ Basically, this fixes a regression where the multibuffer code changed the
      trace_clock file to update tr->clock_id but the traces still use the old
      global trace_clock_id variable, negating the file's effect. The global
      trace_clock_id variable is obsolete and removed. - SR ]
    
    Link: http://lkml.kernel.org/r/20130423013239.22334.7394.stgit@yunodevel
    
    Signed-off-by: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

commit 071ff9a36cb08b5a2b099fcdb45b63a61618f928
Author: Doug Anderson <dianders@chromium.org>
Date:   Tue Jun 11 08:24:05 2013 -0700

    clk: samsung: Fix pll36xx_recalc_rate to handle kdiv properly
    
    The KDIV value is often listed as unsigned but it needs to be treated
    as a 16-bit signed value when using it in calculations.  Fix our rate
    recalculation to do this correctly.
    
    Before doing this, I tried setting EPLL on exynos5250 to:
      rate, m, p, s, k = 80000000, 107, 2, 4, 43691
    
    This rate is exactly from the table in the exynos5250 user manual.
    
    I read this back as 80750003 with:
      cat /sys/kernel/debug/clk/fin_pll/fout_epll/clk_rate
    
    After this patch, it reads back as 80000003
    
    Signed-off-by: Doug Anderson <dianders@chromium.org>
    Acked-by: Kukjin Kim <kgene.kim@samsung.com>
    Reviewed-by: Vikas Sajjan <vikas.sajjan@linaro.org>
    Signed-off-by: Mike Turquette <mturquette@linaro.org>

commit 7cdbac71f911494aa7d0343be23c092ca84a5ed4
Author: Patrick McHardy <kaber@trash.net>
Date:   Tue Jun 11 02:52:47 2013 -0700

    netlink: fix error propagation in netlink_mmap()
    
    Return the error if something went wrong instead of unconditionally
    returning 0.
    
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 1abd165ed757db1afdefaac0a4bc8a70f97d258c
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Thu Jun 6 15:53:47 2013 +0200

    net: sctp: fix NULL pointer dereference in socket destruction
    
    While stress testing sctp sockets, I hit the following panic:
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
    IP: [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
    PGD 7cead067 PUD 7ce76067 PMD 0
    Oops: 0000 [#1] SMP
    Modules linked in: sctp(F) libcrc32c(F) [...]
    CPU: 7 PID: 2950 Comm: acc Tainted: GF            3.10.0-rc2+ #1
    Hardware name: Dell Inc. PowerEdge T410/0H19HD, BIOS 1.6.3 02/01/2011
    task: ffff88007ce0e0c0 ti: ffff88007b568000 task.ti: ffff88007b568000
    RIP: 0010:[<ffffffffa0490c4e>]  [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
    RSP: 0018:ffff88007b569e08  EFLAGS: 00010292
    RAX: 0000000000000000 RBX: ffff88007db78a00 RCX: dead000000200200
    RDX: ffffffffa049fdb0 RSI: ffff8800379baf38 RDI: 0000000000000000
    RBP: ffff88007b569e18 R08: ffff88007c230da0 R09: 0000000000000001
    R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
    R13: ffff880077990d00 R14: 0000000000000084 R15: ffff88007db78a00
    FS:  00007fc18ab61700(0000) GS:ffff88007fc60000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 0000000000000020 CR3: 000000007cf9d000 CR4: 00000000000007e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Stack:
     ffff88007b569e38 ffff88007db78a00 ffff88007b569e38 ffffffffa049fded
     ffffffff81abf0c0 ffff88007db78a00 ffff88007b569e58 ffffffff8145b60e
     0000000000000000 0000000000000000 ffff88007b569eb8 ffffffff814df36e
    Call Trace:
     [<ffffffffa049fded>] sctp_destroy_sock+0x3d/0x80 [sctp]
     [<ffffffff8145b60e>] sk_common_release+0x1e/0xf0
     [<ffffffff814df36e>] inet_create+0x2ae/0x350
     [<ffffffff81455a6f>] __sock_create+0x11f/0x240
     [<ffffffff81455bf0>] sock_create+0x30/0x40
     [<ffffffff8145696c>] SyS_socket+0x4c/0xc0
     [<ffffffff815403be>] ? do_page_fault+0xe/0x10
     [<ffffffff8153cb32>] ? page_fault+0x22/0x30
     [<ffffffff81544e02>] system_call_fastpath+0x16/0x1b
    Code: 0c c9 c3 66 2e 0f 1f 84 00 00 00 00 00 e8 fb fe ff ff c9 c3 66 0f
          1f 84 00 00 00 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 <48>
          8b 47 20 48 89 fb c6 47 1c 01 c6 40 12 07 e8 9e 68 01 00 48
    RIP  [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
     RSP <ffff88007b569e08>
    CR2: 0000000000000020
    ---[ end trace e0d71ec1108c1dd9 ]---
    
    I did not hit this with the lksctp-tools functional tests, but with a
    small, multi-threaded test program, that heavily allocates, binds,
    listens and waits in accept on sctp sockets, and then randomly kills
    some of them (no need for an actual client in this case to hit this).
    Then, again, allocating, binding, etc, and then killing child processes.
    
    This panic then only occurs when ``echo 1 > /proc/sys/net/sctp/auth_enable''
    is set. The cause for that is actually very simple: in sctp_endpoint_init()
    we enter the path of sctp_auth_init_hmacs(). There, we try to allocate
    our crypto transforms through crypto_alloc_hash(). In our scenario,
    it then can happen that crypto_alloc_hash() fails with -EINTR from
    crypto_larval_wait(), thus we bail out and release the socket via
    sk_common_release(), sctp_destroy_sock() and hit the NULL pointer
    dereference as soon as we try to access members in the endpoint during
    sctp_endpoint_free(), since endpoint at that time is still NULL. Now,
    if we have that case, we do not need to do any cleanup work and just
    leave the destruction handler.
    
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 288cfe78c8173f35c7a94f06859f60b3693d828a
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Thu Jun 6 15:20:46 2013 +0300

    vhost: fix ubuf_info cleanup
    
    vhost_net_clear_ubuf_info didn't clear ubuf_info
    after kfree, this could trigger double free.
    Fix this and simplify this code to make it more robust: make sure
    ubuf info is always freed through vhost_net_clear_ubuf_info.
    
    Reported-by: Tommi Rantala <tt.rantala@gmail.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 05c05351943cc03bf5c77e86953b24ae6fb21368
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Thu Jun 6 15:20:39 2013 +0300

    vhost: check owner before we overwrite ubuf_info
    
    If device has an owner, we shouldn't touch ubuf_info
    since it might be in use.
    
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit c2020be3c35ab230b4ee046c262ddab3e0d3aab4
Author: Bjørn Mork <bjorn@mork.no>
Date:   Thu Jun 6 12:57:02 2013 +0200

    qmi_wwan/cdc_ether: let qmi_wwan handle the Huawei E1820
    
    Another QMI speaking Qualcomm based device, which should be
    driven by qmi_wwan, while cdc_ether should ignore it.
    
    Like on other Huawei devices, the wwan function can appear
    either as a single vendor specific interface or as a CDC ECM
    class function using separate control and data interfaces.
    The ECM control interface protocol is 0xff, likely in an
    attempt to indicate that vendor specific management is
    required.
    
    In addition to the near standard CDC class, Huawei also add
    vendor specific AT management commands to their firmwares.
    This is probably an attempt to support non-Windows systems
    using standard class drivers.  Unfortunately, this part of
    the firmware is often buggy.  Linux is much better off using
    whatever native vendor specific management protocol the
    device offers, and Windows uses, whenever possible. This
    means QMI in the case of Qualcomm based devices.
    
    The E1820 has been verified to work fine with QMI.
    
    Matching on interface number is necessary to distiguish the
    wwan function from serial functions in the single interface
    mode, as both function types will have class/subclass/function
    set to ff/ff/ff.
    
    The control interface number does not change in CDC ECM mode,
    so the interface number matching rule is sufficient to handle
    both modes.  The cdc_ether blacklist entry is only relevant in
    CDC ECM mode, but using a similar interface number based rule
    helps document this as a transfer from one driver to another.
    
    Other Huawei 02/06/ff devices are left with the cdc_ether driver
    because we do not know whether they are based on Qualcomm chips.
    The Huawei specific AT command management is known to be somewhat
    hardware independent, and their usage of these class codes may
    also be independent of the modem hardware.
    
    Reported-by: Graham Inggs <graham.inggs@uct.ac.za>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 9f8c4265bda4a6e9aa97041d5cfd91386f460b65
Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date:   Wed Jun 5 23:54:01 2013 +0400

    sh_eth: fix result of sh_eth_check_reset() on timeout
    
    When  the first loop in sh_eth_check_reset() runs to its end, 'cnt' is 0, so the
    following check for 'cnt < 0' fails to catch the timeout.  Fix the  condition in
    this check, so that the timeout  is actually reported.
    While at it, fix the grammar in the failure message...
    
    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 2786aae7fc935e44f81d5f359b6a768c81b46a9b
Author: Sebastian Siewior <bigeasy@linutronix.de>
Date:   Wed Jun 5 18:54:00 2013 +0200

    net/ti davinci_mdio: don't hold a spin lock while calling pm_runtime
    
    was playing with suspend and run into this:
    
    |BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:891
    |in_atomic(): 1, irqs_disabled(): 0, pid: 1963, name: bash
    |6 locks held by bash/1963:
    |CPU: 0 PID: 1963 Comm: bash Not tainted 3.10.0-rc4+ #50
    |[<c0014fdc>] (unwind_backtrace+0x0/0xf8) from [<c0011da4>] (show_stack+0x10/0x14)
    |[<c0011da4>] (show_stack+0x10/0x14) from [<c02e8680>] (__pm_runtime_idle+0xa4/0xac)
    |[<c02e8680>] (__pm_runtime_idle+0xa4/0xac) from [<c0341158>] (davinci_mdio_suspend+0x6c/0x9c)
    |[<c0341158>] (davinci_mdio_suspend+0x6c/0x9c) from [<c02e0628>] (platform_pm_suspend+0x2c/0x54)
    |[<c02e0628>] (platform_pm_suspend+0x2c/0x54) from [<c02e52bc>] (dpm_run_callback.isra.3+0x2c/0x64)
    |[<c02e52bc>] (dpm_run_callback.isra.3+0x2c/0x64) from [<c02e57e4>] (__device_suspend+0x100/0x22c)
    |[<c02e57e4>] (__device_suspend+0x100/0x22c) from [<c02e67e8>] (dpm_suspend+0x68/0x230)
    |[<c02e67e8>] (dpm_suspend+0x68/0x230) from [<c0072a20>] (suspend_devices_and_enter+0x68/0x350)
    |[<c0072a20>] (suspend_devices_and_enter+0x68/0x350) from [<c0072f18>] (pm_suspend+0x210/0x24c)
    |[<c0072f18>] (pm_suspend+0x210/0x24c) from [<c0071c74>] (state_store+0x6c/0xbc)
    |[<c0071c74>] (state_store+0x6c/0xbc) from [<c02714dc>] (kobj_attr_store+0x14/0x20)
    |[<c02714dc>] (kobj_attr_store+0x14/0x20) from [<c01341a0>] (sysfs_write_file+0x16c/0x19c)
    |[<c01341a0>] (sysfs_write_file+0x16c/0x19c) from [<c00ddfe4>] (vfs_write+0xb4/0x190)
    |[<c00ddfe4>] (vfs_write+0xb4/0x190) from [<c00de3a4>] (SyS_write+0x3c/0x70)
    |[<c00de3a4>] (SyS_write+0x3c/0x70) from [<c000e2c0>] (ret_fast_syscall+0x0/0x48)
    
    I don't see a reason why the pm_runtime call must be under the lock.
    Further I don't understand why this is a spinlock and not mutex.
    
    Cc: Mugunthan V N <mugunthanvnm@ti.com>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 7c11c0ccc7ba186433b2102cf3775ce6b2445453
Author: Scott Wood <scottwood@freescale.com>
Date:   Thu Jun 6 19:16:32 2013 -0500

    kvm/ppc/booke64: Fix lazy ee handling in kvmppc_handle_exit()
    
    EE is hard-disabled on entry to kvmppc_handle_exit(), so call
    hard_irq_disable() so that PACA_IRQ_HARD_DIS is set, and soft_enabled
    is unset.
    
    Without this, we get warnings such as arch/powerpc/kernel/time.c:300,
    and sometimes host kernel hangs.
    
    Signed-off-by: Scott Wood <scottwood@freescale.com>
    Signed-off-by: Gleb Natapov <gleb@redhat.com>

commit f1e89028f020ca982bf51be6eaba0d462ba0f7fa
Author: Scott Wood <scottwood@freescale.com>
Date:   Thu Jun 6 19:16:31 2013 -0500

    kvm/ppc/booke: Hold srcu lock when calling gfn functions
    
    KVM core expects arch code to acquire the srcu lock when calling
    gfn_to_memslot and similar functions.
    
    Signed-off-by: Scott Wood <scottwood@freescale.com>
    Signed-off-by: Gleb Natapov <gleb@redhat.com>

commit 2b6398fcf2831f52a8ad9f01c123b3ce2ea31277
Author: Scott Wood <scottwood@freescale.com>
Date:   Thu Jun 6 19:16:30 2013 -0500

    kvm/ppc/booke64: Disable e6500 support
    
    The previous patch made 64-bit booke KVM build again, but Altivec
    support is still not complete, and we can't prevent the guest from
    turning on Altivec (which can corrupt host state until state
    save/restore is implemented).  Disable e6500 on KVM until this is
    fixed.
    
    Signed-off-by: Scott Wood <scottwood@freescale.com>
    Signed-off-by: Gleb Natapov <gleb@redhat.com>

commit 4edd1ae91baa63e120b414647c79a7aa5ca50ae7
Author: Mihai Caraman <mihai.caraman@freescale.com>
Date:   Thu Jun 6 19:16:29 2013 -0500

    kvm/ppc/booke64: Fix AltiVec interrupt numbers and build breakage
    
    Interrupt numbers defined for Book3E follows IVORs definition. Align
    BOOKE_INTERRUPT_ALTIVEC_UNAVAIL and BOOKE_INTERRUPT_ALTIVEC_ASSIST to this
    rule which also fixes the build breakage.
    IVORs 32 and 33 are shared so reflect this in the interrupts naming.
    
    This fixes a build break for 64-bit booke KVM.
    
    Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
    Signed-off-by: Scott Wood <scottwood@freescale.com>
    Signed-off-by: Gleb Natapov <gleb@redhat.com>

commit cd3fc1b9a34e535a8acbead7461475fbc43bdd49
Author: Tomasz Figa <t.figa@samsung.com>
Date:   Fri May 17 18:24:29 2013 +0200

    ARM: SAMSUNG: pm: Adjust for pinctrl- and DT-enabled platforms
    
    This patch makes legacy code on suspend/resume path being executed
    conditionally, on non-DT platforms only, to fix suspend/resume of
    DT-enabled systems, for which the code is inappropriate.
    
    Signed-off-by: Tomasz Figa <t.figa@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    [olof: add #include <linux/of.h>]
    Signed-off-by: Olof Johansson <olof@lixom.net>

commit 681865d48e867a4fb55ff0516e2aa1cee3e4f343
Author: David Daney <david.daney@cavium.com>
Date:   Mon Jun 10 12:33:48 2013 -0700

    mips/kvm: Use KVM_REG_MIPS and proper size indicators for *_ONE_REG
    
    The API requires that the GET_ONE_REG and SET_ONE_REG ioctls have this
    extra information encoded in the register identifiers.
    
    Signed-off-by: David Daney <david.daney@cavium.com>
    Signed-off-by: Gleb Natapov <gleb@redhat.com>

commit 2a8fedd0c142d4328ab4667847e05afe17c3295c
Author: David Daney <david.daney@cavium.com>
Date:   Mon Jun 10 12:33:47 2013 -0700

    kvm: Add definition of KVM_REG_MIPS
    
    We use 0x7000000000000000ULL as 0x6000000000000000ULL is reserved for
    ARM64.
    
    Signed-off-by: David Daney <david.daney@cavium.com>
    Signed-off-by: Gleb Natapov <gleb@redhat.com>

commit 7e5955db458b2d349a8180242afebc78a13ed023
Author: Haojian Zhuang <haojian.zhuang@linaro.org>
Date:   Fri Jun 7 11:17:07 2013 +0800

    ARM: prima2: fix incorrect panic usage
    
    In prima2, some functions of checking DT is registered in initcall
    level. If it doesn't match the compatible name of sirf, kernel
    will panic. It blocks the usage of multiplatform on other verndor.
    
    The error message is in below.
    
    Knic - not syncing: unable to find compatible pwrc node in dtb
    CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-rc3-00006-gd7f26ea-dirty #86
    [<c0013adc>] (unwind_backtrace+0x0/0xf8) from [<c0011430>] (show_stack+0x10/0x1)
    [<c0011430>] (show_stack+0x10/0x14) from [<c026f724>] (panic+0x90/0x1e8)
    [<c026f724>] (panic+0x90/0x1e8) from [<c03267fc>] (sirfsoc_of_pwrc_init+0x24/0x)
    [<c03267fc>] (sirfsoc_of_pwrc_init+0x24/0x58) from [<c0320864>] (do_one_initcal)
    [<c0320864>] (do_one_initcall+0x90/0x150) from [<c0320a20>] (kernel_init_freeab)
    [<c0320a20>] (kernel_init_freeable+0xfc/0x1c4) from [<c026b9e8>] (kernel_init+0)
    [<c026b9e8>] (kernel_init+0x8/0xe4) from [<c000e158>] (ret_from_fork+0x14/0x3c)
    
    Signen-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
    Signed-off-by: Olof Johansson <olof@lixom.net>

commit ed13998c319b050fc9abdb73915859dfdbe1fb38
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Wed Jun 5 15:30:55 2013 +0200

    sock_diag: fix filter code sent to userspace
    
    Filters need to be translated to real BPF code for userland, like SO_GETFILTER.
    
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 150e5928d6063b273a80d9d6722417ac3c93ff82
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Mon Jun 10 11:05:40 2013 -0700

    Input: add missing dependencies on CONFIG_HAS_IOMEM
    
    Several drivers don't build on s390 with CONFIG_PCI disabled as
    they require MMIO functions.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: stable@vger.kernel.org # 3.9
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

commit 34376a50fb1fa095b9d0636fa41ed2e73125f214
Author: Ben Greear <greearb@candelatech.com>
Date:   Thu Jun 6 14:29:49 2013 -0700

    Fix lockup related to stop_machine being stuck in __do_softirq.
    
    The stop machine logic can lock up if all but one of the migration
    threads make it through the disable-irq step and the one remaining
    thread gets stuck in __do_softirq.  The reason __do_softirq can hang is
    that it has a bail-out based on jiffies timeout, but in the lockup case,
    jiffies itself is not incremented.
    
    To work around this, re-add the max_restart counter in __do_irq and stop
    processing irqs after 10 restarts.
    
    Thanks to Tejun Heo and Rusty Russell and others for helping me track
    this down.
    
    This was introduced in 3.9 by commit c10d73671ad3 ("softirq: reduce
    latencies").
    
    It may be worth looking into ath9k to see if it has issues with its irq
    handler at a later date.
    
    The hang stack traces look something like this:
    
        ------------[ cut here ]------------
        WARNING: at kernel/watchdog.c:245 watchdog_overflow_callback+0x9c/0xa7()
        Watchdog detected hard LOCKUP on cpu 2
        Modules linked in: ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 nfsv4 auth_rpcgss nfs fscache nf_nat_ipv4 nf_nat veth 8021q garp stp mrp llc pktgen lockd sunrpc]
        Pid: 23, comm: migration/2 Tainted: G         C   3.9.4+ #11
        Call Trace:
         <NMI>   warn_slowpath_common+0x85/0x9f
          warn_slowpath_fmt+0x46/0x48
          watchdog_overflow_callback+0x9c/0xa7
          __perf_event_overflow+0x137/0x1cb
          perf_event_overflow+0x14/0x16
          intel_pmu_handle_irq+0x2dc/0x359
          perf_event_nmi_handler+0x19/0x1b
          nmi_handle+0x7f/0xc2
          do_nmi+0xbc/0x304
          end_repeat_nmi+0x1e/0x2e
         <<EOE>>
          cpu_stopper_thread+0xae/0x162
          smpboot_thread_fn+0x258/0x260
          kthread+0xc7/0xcf
          ret_from_fork+0x7c/0xb0
        ---[ end trace 4947dfa9b0a4cec3 ]---
        BUG: soft lockup - CPU#1 stuck for 22s! [migration/1:17]
        Modules linked in: ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 nfsv4 auth_rpcgss nfs fscache nf_nat_ipv4 nf_nat veth 8021q garp stp mrp llc pktgen lockd sunrpc]
        irq event stamp: 835637905
        hardirqs last  enabled at (835637904): __do_softirq+0x9f/0x257
        hardirqs last disabled at (835637905): apic_timer_interrupt+0x6d/0x80
        softirqs last  enabled at (5654720): __do_softirq+0x1ff/0x257
        softirqs last disabled at (5654725): irq_exit+0x5f/0xbb
        CPU 1
        Pid: 17, comm: migration/1 Tainted: G        WC   3.9.4+ #11 To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M.
        RIP: tasklet_hi_action+0xf0/0xf0
        Process migration/1
        Call Trace:
         <IRQ>
          __do_softirq+0x117/0x257
          irq_exit+0x5f/0xbb
          smp_apic_timer_interrupt+0x8a/0x98
          apic_timer_interrupt+0x72/0x80
         <EOI>
          printk+0x4d/0x4f
          stop_machine_cpu_stop+0x22c/0x274
          cpu_stopper_thread+0xae/0x162
          smpboot_thread_fn+0x258/0x260
          kthread+0xc7/0xcf
          ret_from_fork+0x7c/0xb0
    
    Signed-off-by: Ben Greear <greearb@candelatech.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Acked-by: Pekka Riikonen <priikone@iki.fi>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 589c603b2c591ed470a731ceda589e6d60b77b5f
Author: Tushar Behera <tushar.behera@linaro.org>
Date:   Fri May 17 11:25:53 2013 +0530

    clk: exynos5250: Add sclk_mpll to the parent list of mout_cpu clock
    
    'mout_mpll' is added the list of parent clocks for 'mout_cpu'.
    'mout_mpll' is an alias to the clock 'sclk_mpll'. Hence 'sclk_mpll'
    should be added to the list of parent clocks.
    
    This results in an error when cpufreq driver for EXYNOS5250 tries to
    set 'mout_mpll' as a parent for 'mout_cpu'.
    
    clk_set_parent: clk sclk_mpll can not be parent of clk mout_cpu
    
    Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
    Signed-off-by: Mike Turquette <mturquette@linaro.org>

commit 39b72d89eb2bf74ec94773defece6890febba7a5
Author: Tushar Behera <tushar.behera@linaro.org>
Date:   Fri May 17 11:25:52 2013 +0530

    clk: exynos5250: Update cpufreq related clocks for EXYNOS5250
    
    cpufreq driver for EXYNOS5250 is not a platform driver, hence we cannot
    currently pass the clock names through a device tree node. Instead, we
    need to make them available through a global alias.
    
    cpufreq driver for EXYNOS5250 requires four clocks - 'armclk',
    'mout_cpu', 'mout_mpll' and 'mout_apll'.
    
    'armclk' has already been defined with an alias, 'mout_cpu', 'mout_mpll'
    and 'mout_apll' are now defined with an alias.
    
    Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
    Signed-off-by: Mike Turquette <mturquette@linaro.org>

commit 92bb73ea2c434618a68a58a2f3a5c3fd0b660d18
Author: Jason Wang <jasowang@redhat.com>
Date:   Wed Jun 5 16:44:57 2013 +0800

    tuntap: fix a possible race between queue selection and changing queues
    
    Complier may generate codes that re-read the tun->numqueues during
    tun_select_queue(). This may be a race if vlan->numqueues were changed in the
    same time and can lead unexpected result (e.g. very huge value).
    
    We need prevent the compiler from generating such codes by adding an
    ACCESS_ONCE() to make sure tun->numqueues were only read once.
    
    Bug were introduced by commit c8d68e6be1c3b242f1c598595830890b65cea64a
    (tuntap: multiqueue support).
    
    Reported-by: Michael S. Tsirkin <mst@redhat.com>
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 4364d5f96eed7994a2c625bd9216656e55fba0cb
Author: Jason Wang <jasowang@redhat.com>
Date:   Wed Jun 5 15:40:46 2013 +0800

    vhost_net: clear msg.control for non-zerocopy case during tx
    
    When we decide not use zero-copy, msg.control should be set to NULL otherwise
    macvtap/tap may set zerocopy callbacks which may decrease the kref of ubufs
    wrongly.
    
    Bug were introduced by commit cedb9bdce099206290a2bdd02ce47a7b253b6a84
    (vhost-net: skip head management if no outstanding).
    
    This solves the following warnings:
    
    WARNING: at include/linux/kref.h:47 handle_tx+0x477/0x4b0 [vhost_net]()
    Modules linked in: vhost_net macvtap macvlan tun nfsd exportfs bridge stp llc openvswitch kvm_amd kvm bnx2 megaraid_sas [last unloaded: tun]
    CPU: 5 PID: 8670 Comm: vhost-8668 Not tainted 3.10.0-rc2+ #1566
    Hardware name: Dell Inc. PowerEdge R715/00XHKG, BIOS 1.5.2 04/19/2011
    ffffffffa0198323 ffff88007c9ebd08 ffffffff81796b73 ffff88007c9ebd48
    ffffffff8103d66b 000000007b773e20 ffff8800779f0000 ffff8800779f43f0
    ffff8800779f8418 000000000000015c 0000000000000062 ffff88007c9ebd58
    Call Trace:
    [<ffffffff81796b73>] dump_stack+0x19/0x1e
    [<ffffffff8103d66b>] warn_slowpath_common+0x6b/0xa0
    [<ffffffff8103d6b5>] warn_slowpath_null+0x15/0x20
    [<ffffffffa0197627>] handle_tx+0x477/0x4b0 [vhost_net]
    [<ffffffffa0197690>] handle_tx_kick+0x10/0x20 [vhost_net]
    [<ffffffffa019541e>] vhost_worker+0xfe/0x1a0 [vhost_net]
    [<ffffffffa0195320>] ? vhost_attach_cgroups_work+0x30/0x30 [vhost_net]
    [<ffffffffa0195320>] ? vhost_attach_cgroups_work+0x30/0x30 [vhost_net]
    [<ffffffff81061f46>] kthread+0xc6/0xd0
    [<ffffffff81061e80>] ? kthread_freezable_should_stop+0x70/0x70
    [<ffffffff817a1aec>] ret_from_fork+0x7c/0xb0
    [<ffffffff81061e80>] ? kthread_freezable_should_stop+0x70/0x70
    
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit f8b8404337de4e2466e2e1139ea68b1f8295974f
Author: Matthew Garrett <matthew.garrett@nebula.com>
Date:   Sat Jun 1 16:06:20 2013 -0400

    Modify UEFI anti-bricking code
    
    This patch reworks the UEFI anti-bricking code, including an effective
    reversion of cc5a080c and 31ff2f20. It turns out that calling
    QueryVariableInfo() from boot services results in some firmware
    implementations jumping to physical addresses even after entering virtual
    mode, so until we have 1:1 mappings for UEFI runtime space this isn't
    going to work so well.
    
    Reverting these gets us back to the situation where we'd refuse to create
    variables on some systems because they classify deleted variables as "used"
    until the firmware triggers a garbage collection run, which they won't do
    until they reach a lower threshold. This results in it being impossible to
    install a bootloader, which is unhelpful.
    
    Feedback from Samsung indicates that the firmware doesn't need more than
    5KB of storage space for its own purposes, so that seems like a reasonable
    threshold. However, there's still no guarantee that a platform will attempt
    garbage collection merely because it drops below this threshold. It seems
    that this is often only triggered if an attempt to write generates a
    genuine EFI_OUT_OF_RESOURCES error. We can force that by attempting to
    create a variable larger than the remaining space. This should fail, but if
    it somehow succeeds we can then immediately delete it.
    
    I've tested this on the UEFI machines I have available, but I don't have
    a Samsung and so can't verify that it avoids the bricking problem.
    
    Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
    Signed-off-by: Lee, Chun-Y <jlee@suse.com> [ dummy variable cleanup ]
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>

commit 971394f389992f8462c4e5ae0e3b49a10a9534a3
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Sun Jun 2 07:13:57 2013 -0700

    rcu: Fix deadlock with CPU hotplug, RCU GP init, and timer migration
    
    In Steven Rostedt's words:
    
    > I've been debugging the last couple of days why my tests have been
    > locking up. One of my tracing tests, runs all available tracers. The
    > lockup always happened with the mmiotrace, which is used to trace
    > interactions between priority drivers and the kernel. But to do this
    > easily, when the tracer gets registered, it disables all but the boot
    > CPUs. The lockup always happened after it got done disabling the CPUs.
    >
    > Then I decided to try this:
    >
    > while :; do
    > 	for i in 1 2 3; do
    > 		echo 0 > /sys/devices/system/cpu/cpu$i/online
    > 	done
    > 	for i in 1 2 3; do
    > 		echo 1 > /sys/devices/system/cpu/cpu$i/online
    > 	done
    > done
    >
    > Well, sure enough, that locked up too, with the same users. Doing a
    > sysrq-w (showing all blocked tasks):
    >
    > [ 2991.344562]   task                        PC stack   pid father
    > [ 2991.344562] rcu_preempt     D ffff88007986fdf8     0    10      2 0x00000000
    > [ 2991.344562]  ffff88007986fc98 0000000000000002 ffff88007986fc48 0000000000000908
    > [ 2991.344562]  ffff88007986c280 ffff88007986ffd8 ffff88007986ffd8 00000000001d3c80
    > [ 2991.344562]  ffff880079248a40 ffff88007986c280 0000000000000000 00000000fffd4295
    > [ 2991.344562] Call Trace:
    > [ 2991.344562]  [<ffffffff815437ba>] schedule+0x64/0x66
    > [ 2991.344562]  [<ffffffff81541750>] schedule_timeout+0xbc/0xf9
    > [ 2991.344562]  [<ffffffff8154bec0>] ? ftrace_call+0x5/0x2f
    > [ 2991.344562]  [<ffffffff81049513>] ? cascade+0xa8/0xa8
    > [ 2991.344562]  [<ffffffff815417ab>] schedule_timeout_uninterruptible+0x1e/0x20
    > [ 2991.344562]  [<ffffffff810c980c>] rcu_gp_kthread+0x502/0x94b
    > [ 2991.344562]  [<ffffffff81062791>] ? __init_waitqueue_head+0x50/0x50
    > [ 2991.344562]  [<ffffffff810c930a>] ? rcu_gp_fqs+0x64/0x64
    > [ 2991.344562]  [<ffffffff81061cdb>] kthread+0xb1/0xb9
    > [ 2991.344562]  [<ffffffff81091e31>] ? lock_release_holdtime.part.23+0x4e/0x55
    > [ 2991.344562]  [<ffffffff81061c2a>] ? __init_kthread_worker+0x58/0x58
    > [ 2991.344562]  [<ffffffff8154c1dc>] ret_from_fork+0x7c/0xb0
    > [ 2991.344562]  [<ffffffff81061c2a>] ? __init_kthread_worker+0x58/0x58
    > [ 2991.344562] kworker/0:1     D ffffffff81a30680     0    47      2 0x00000000
    > [ 2991.344562] Workqueue: events cpuset_hotplug_workfn
    > [ 2991.344562]  ffff880078dbbb58 0000000000000002 0000000000000006 00000000000000d8
    > [ 2991.344562]  ffff880078db8100 ffff880078dbbfd8 ffff880078dbbfd8 00000000001d3c80
    > [ 2991.344562]  ffff8800779ca5c0 ffff880078db8100 ffffffff81541fcf 0000000000000000
    > [ 2991.344562] Call Trace:
    > [ 2991.344562]  [<ffffffff81541fcf>] ? __mutex_lock_common+0x3d4/0x609
    > [ 2991.344562]  [<ffffffff815437ba>] schedule+0x64/0x66
    > [ 2991.344562]  [<ffffffff81543a39>] schedule_preempt_disabled+0x18/0x24
    > [ 2991.344562]  [<ffffffff81541fcf>] __mutex_lock_common+0x3d4/0x609
    > [ 2991.344562]  [<ffffffff8103d11b>] ? get_online_cpus+0x3c/0x50
    > [ 2991.344562]  [<ffffffff8103d11b>] ? get_online_cpus+0x3c/0x50
    > [ 2991.344562]  [<ffffffff815422ff>] mutex_lock_nested+0x3b/0x40
    > [ 2991.344562]  [<ffffffff8103d11b>] get_online_cpus+0x3c/0x50
    > [ 2991.344562]  [<ffffffff810af7e6>] rebuild_sched_domains_locked+0x6e/0x3a8
    > [ 2991.344562]  [<ffffffff810b0ec6>] rebuild_sched_domains+0x1c/0x2a
    > [ 2991.344562]  [<ffffffff810b109b>] cpuset_hotplug_workfn+0x1c7/0x1d3
    > [ 2991.344562]  [<ffffffff810b0ed9>] ? cpuset_hotplug_workfn+0x5/0x1d3
    > [ 2991.344562]  [<ffffffff81058e07>] process_one_work+0x2d4/0x4d1
    > [ 2991.344562]  [<ffffffff81058d3a>] ? process_one_work+0x207/0x4d1
    > [ 2991.344562]  [<ffffffff8105964c>] worker_thread+0x2e7/0x3b5
    > [ 2991.344562]  [<ffffffff81059365>] ? rescuer_thread+0x332/0x332
    > [ 2991.344562]  [<ffffffff81061cdb>] kthread+0xb1/0xb9
    > [ 2991.344562]  [<ffffffff81061c2a>] ? __init_kthread_worker+0x58/0x58
    > [ 2991.344562]  [<ffffffff8154c1dc>] ret_from_fork+0x7c/0xb0
    > [ 2991.344562]  [<ffffffff81061c2a>] ? __init_kthread_worker+0x58/0x58
    > [ 2991.344562] bash            D ffffffff81a4aa80     0  2618   2612 0x10000000
    > [ 2991.344562]  ffff8800379abb58 0000000000000002 0000000000000006 0000000000000c2c
    > [ 2991.344562]  ffff880077fea140 ffff8800379abfd8 ffff8800379abfd8 00000000001d3c80
    > [ 2991.344562]  ffff8800779ca5c0 ffff880077fea140 ffffffff81541fcf 0000000000000000
    > [ 2991.344562] Call Trace:
    > [ 2991.344562]  [<ffffffff81541fcf>] ? __mutex_lock_common+0x3d4/0x609
    > [ 2991.344562]  [<ffffffff815437ba>] schedule+0x64/0x66
    > [ 2991.344562]  [<ffffffff81543a39>] schedule_preempt_disabled+0x18/0x24
    > [ 2991.344562]  [<ffffffff81541fcf>] __mutex_lock_common+0x3d4/0x609
    > [ 2991.344562]  [<ffffffff81530078>] ? rcu_cpu_notify+0x2f5/0x86e
    > [ 2991.344562]  [<ffffffff81530078>] ? rcu_cpu_notify+0x2f5/0x86e
    > [ 2991.344562]  [<ffffffff815422ff>] mutex_lock_nested+0x3b/0x40
    > [ 2991.344562]  [<ffffffff81530078>] rcu_cpu_notify+0x2f5/0x86e
    > [ 2991.344562]  [<ffffffff81091c99>] ? __lock_is_held+0x32/0x53
    > [ 2991.344562]  [<ffffffff81548912>] notifier_call_chain+0x6b/0x98
    > [ 2991.344562]  [<ffffffff810671fd>] __raw_notifier_call_chain+0xe/0x10
    > [ 2991.344562]  [<ffffffff8103cf64>] __cpu_notify+0x20/0x32
    > [ 2991.344562]  [<ffffffff8103cf8d>] cpu_notify_nofail+0x17/0x36
    > [ 2991.344562]  [<ffffffff815225de>] _cpu_down+0x154/0x259
    > [ 2991.344562]  [<ffffffff81522710>] cpu_down+0x2d/0x3a
    > [ 2991.344562]  [<ffffffff81526351>] store_online+0x4e/0xe7
    > [ 2991.344562]  [<ffffffff8134d764>] dev_attr_store+0x20/0x22
    > [ 2991.344562]  [<ffffffff811b3c5f>] sysfs_write_file+0x108/0x144
    > [ 2991.344562]  [<ffffffff8114c5ef>] vfs_write+0xfd/0x158
    > [ 2991.344562]  [<ffffffff8114c928>] SyS_write+0x5c/0x83
    > [ 2991.344562]  [<ffffffff8154c494>] tracesys+0xdd/0xe2
    >
    > As well as held locks:
    >
    > [ 3034.728033] Showing all locks held in the system:
    > [ 3034.728033] 1 lock held by rcu_preempt/10:
    > [ 3034.728033]  #0:  (rcu_preempt_state.onoff_mutex){+.+...}, at: [<ffffffff810c9471>] rcu_gp_kthread+0x167/0x94b
    > [ 3034.728033] 4 locks held by kworker/0:1/47:
    > [ 3034.728033]  #0:  (events){.+.+.+}, at: [<ffffffff81058d3a>] process_one_work+0x207/0x4d1
    > [ 3034.728033]  #1:  (cpuset_hotplug_work){+.+.+.}, at: [<ffffffff81058d3a>] process_one_work+0x207/0x4d1
    > [ 3034.728033]  #2:  (cpuset_mutex){+.+.+.}, at: [<ffffffff810b0ec1>] rebuild_sched_domains+0x17/0x2a
    > [ 3034.728033]  #3:  (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff8103d11b>] get_online_cpus+0x3c/0x50
    > [ 3034.728033] 1 lock held by mingetty/2563:
    > [ 3034.728033]  #0:  (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff8131e28a>] n_tty_read+0x252/0x7e8
    > [ 3034.728033] 1 lock held by mingetty/2565:
    > [ 3034.728033]  #0:  (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff8131e28a>] n_tty_read+0x252/0x7e8
    > [ 3034.728033] 1 lock held by mingetty/2569:
    > [ 3034.728033]  #0:  (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff8131e28a>] n_tty_read+0x252/0x7e8
    > [ 3034.728033] 1 lock held by mingetty/2572:
    > [ 3034.728033]  #0:  (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff8131e28a>] n_tty_read+0x252/0x7e8
    > [ 3034.728033] 1 lock held by mingetty/2575:
    > [ 3034.728033]  #0:  (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff8131e28a>] n_tty_read+0x252/0x7e8
    > [ 3034.728033] 7 locks held by bash/2618:
    > [ 3034.728033]  #0:  (sb_writers#5){.+.+.+}, at: [<ffffffff8114bc3f>] file_start_write+0x2a/0x2c
    > [ 3034.728033]  #1:  (&buffer->mutex#2){+.+.+.}, at: [<ffffffff811b3b93>] sysfs_write_file+0x3c/0x144
    > [ 3034.728033]  #2:  (s_active#54){.+.+.+}, at: [<ffffffff811b3c3e>] sysfs_write_file+0xe7/0x144
    > [ 3034.728033]  #3:  (x86_cpu_hotplug_driver_mutex){+.+.+.}, at: [<ffffffff810217c2>] cpu_hotplug_driver_lock+0x17/0x19
    > [ 3034.728033]  #4:  (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff8103d196>] cpu_maps_update_begin+0x17/0x19
    > [ 3034.728033]  #5:  (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff8103cfd8>] cpu_hotplug_begin+0x2c/0x6d
    > [ 3034.728033]  #6:  (rcu_preempt_state.onoff_mutex){+.+...}, at: [<ffffffff81530078>] rcu_cpu_notify+0x2f5/0x86e
    > [ 3034.728033] 1 lock held by bash/2980:
    > [ 3034.728033]  #0:  (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff8131e28a>] n_tty_read+0x252/0x7e8
    >
    > Things looked a little weird. Also, this is a deadlock that lockdep did
    > not catch. But what we have here does not look like a circular lock
    > issue:
    >
    > Bash is blocked in rcu_cpu_notify():
    >
    > 1961		/* Exclude any attempts to start a new grace period. */
    > 1962		mutex_lock(&rsp->onoff_mutex);
    >
    >
    > kworker is blocked in get_online_cpus(), which makes sense as we are
    > currently taking down a CPU.
    >
    > But rcu_preempt is not blocked on anything. It is simply sleeping in
    > rcu_gp_kthread (really rcu_gp_init) here:
    >
    > 1453	#ifdef CONFIG_PROVE_RCU_DELAY
    > 1454			if ((prandom_u32() % (rcu_num_nodes * 8)) == 0 &&
    > 1455			    system_state == SYSTEM_RUNNING)
    > 1456				schedule_timeout_uninterruptible(2);
    > 1457	#endif /* #ifdef CONFIG_PROVE_RCU_DELAY */
    >
    > And it does this while holding the onoff_mutex that bash is waiting for.
    >
    > Doing a function trace, it showed me where it happened:
    >
    > [  125.940066] rcu_pree-10      3.... 28384115273: schedule_timeout_uninterruptible <-rcu_gp_kthread
    > [...]
    > [  125.940066] rcu_pree-10      3d..3 28384202439: sched_switch: prev_comm=rcu_preempt prev_pid=10 prev_prio=120 prev_state=D ==> next_comm=watchdog/3 next_pid=38 next_prio=120
    >
    > The watchdog ran, and then:
    >
    > [  125.940066] watchdog-38      3d..3 28384692863: sched_switch: prev_comm=watchdog/3 prev_pid=38 prev_prio=120 prev_state=P ==> next_comm=modprobe next_pid=2848 next_prio=118
    >
    > Not sure what modprobe was doing, but shortly after that:
    >
    > [  125.940066] modprobe-2848    3d..3 28385041749: sched_switch: prev_comm=modprobe prev_pid=2848 prev_prio=118 prev_state=R+ ==> next_comm=migration/3 next_pid=40 next_prio=0
    >
    > Where the migration thread took down the CPU:
    >
    > [  125.940066] migratio-40      3d..3 28389148276: sched_switch: prev_comm=migration/3 prev_pid=40 prev_prio=0 prev_state=P ==> next_comm=swapper/3 next_pid=0 next_prio=120
    >
    > which finally did:
    >
    > [  125.940066]   <idle>-0       3...1 28389282142: arch_cpu_idle_dead <-cpu_startup_entry
    > [  125.940066]   <idle>-0       3...1 28389282548: native_play_dead <-arch_cpu_idle_dead
    > [  125.940066]   <idle>-0       3...1 28389282924: play_dead_common <-native_play_dead
    > [  125.940066]   <idle>-0       3...1 28389283468: idle_task_exit <-play_dead_common
    > [  125.940066]   <idle>-0       3...1 28389284644: amd_e400_remove_cpu <-play_dead_common
    >
    >
    > CPU 3 is now offline, the rcu_preempt thread that ran on CPU 3 is still
    > doing a schedule_timeout_uninterruptible() and it registered it's
    > timeout to the timer base for CPU 3. You would think that it would get
    > migrated right? The issue here is that the timer migration happens at
    > the CPU notifier for CPU_DEAD. The problem is that the rcu notifier for
    > CPU_DOWN is blocked waiting for the onoff_mutex to be released, which is
    > held by the thread that just put itself into a uninterruptible sleep,
    > that wont wake up until the CPU_DEAD notifier of the timer
    > infrastructure is called, which wont happen until the rcu notifier
    > finishes. Here's our deadlock!
    
    This commit breaks this deadlock cycle by substituting a shorter udelay()
    for the previous schedule_timeout_uninterruptible(), while at the same
    time increasing the probability of the delay.  This maintains the intensity
    of the testing.
    
    Reported-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Tested-by: Steven Rostedt <rostedt@goodmis.org>

commit 016a8d5be6ddcc72ef0432d82d9f6fa34f61b907
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Tue May 28 17:32:53 2013 -0400

    rcu: Don't call wakeup() with rcu_node structure ->lock held
    
    This commit fixes a lockdep-detected deadlock by moving a wake_up()
    call out from a rnp->lock critical section.  Please see below for
    the long version of this story.
    
    On Tue, 2013-05-28 at 16:13 -0400, Dave Jones wrote:
    
    > [12572.705832] ======================================================
    > [12572.750317] [ INFO: possible circular locking dependency detected ]
    > [12572.796978] 3.10.0-rc3+ #39 Not tainted
    > [12572.833381] -------------------------------------------------------
    > [12572.862233] trinity-child17/31341 is trying to acquire lock:
    > [12572.870390]  (rcu_node_0){..-.-.}, at: [<ffffffff811054ff>] rcu_read_unlock_special+0x9f/0x4c0
    > [12572.878859]
    > but task is already holding lock:
    > [12572.894894]  (&ctx->lock){-.-...}, at: [<ffffffff811390ed>] perf_lock_task_context+0x7d/0x2d0
    > [12572.903381]
    > which lock already depends on the new lock.
    >
    > [12572.927541]
    > the existing dependency chain (in reverse order) is:
    > [12572.943736]
    > -> #4 (&ctx->lock){-.-...}:
    > [12572.960032]        [<ffffffff810b9851>] lock_acquire+0x91/0x1f0
    > [12572.968337]        [<ffffffff816ebc90>] _raw_spin_lock+0x40/0x80
    > [12572.976633]        [<ffffffff8113c987>] __perf_event_task_sched_out+0x2e7/0x5e0
    > [12572.984969]        [<ffffffff81088953>] perf_event_task_sched_out+0x93/0xa0
    > [12572.993326]        [<ffffffff816ea0bf>] __schedule+0x2cf/0x9c0
    > [12573.001652]        [<ffffffff816eacfe>] schedule_user+0x2e/0x70
    > [12573.009998]        [<ffffffff816ecd64>] retint_careful+0x12/0x2e
    > [12573.018321]
    > -> #3 (&rq->lock){-.-.-.}:
    > [12573.034628]        [<ffffffff810b9851>] lock_acquire+0x91/0x1f0
    > [12573.042930]        [<ffffffff816ebc90>] _raw_spin_lock+0x40/0x80
    > [12573.051248]        [<ffffffff8108e6a7>] wake_up_new_task+0xb7/0x260
    > [12573.059579]        [<ffffffff810492f5>] do_fork+0x105/0x470
    > [12573.067880]        [<ffffffff81049686>] kernel_thread+0x26/0x30
    > [12573.076202]        [<ffffffff816cee63>] rest_init+0x23/0x140
    > [12573.084508]        [<ffffffff81ed8e1f>] start_kernel+0x3f1/0x3fe
    > [12573.092852]        [<ffffffff81ed856f>] x86_64_start_reservations+0x2a/0x2c
    > [12573.101233]        [<ffffffff81ed863d>] x86_64_start_kernel+0xcc/0xcf
    > [12573.109528]
    > -> #2 (&p->pi_lock){-.-.-.}:
    > [12573.125675]        [<ffffffff810b9851>] lock_acquire+0x91/0x1f0
    > [12573.133829]        [<ffffffff816ebe9b>] _raw_spin_lock_irqsave+0x4b/0x90
    > [12573.141964]        [<ffffffff8108e881>] try_to_wake_up+0x31/0x320
    > [12573.150065]        [<ffffffff8108ebe2>] default_wake_function+0x12/0x20
    > [12573.158151]        [<ffffffff8107bbf8>] autoremove_wake_function+0x18/0x40
    > [12573.166195]        [<ffffffff81085398>] __wake_up_common+0x58/0x90
    > [12573.174215]        [<ffffffff81086909>] __wake_up+0x39/0x50
    > [12573.182146]        [<ffffffff810fc3da>] rcu_start_gp_advanced.isra.11+0x4a/0x50
    > [12573.190119]        [<ffffffff810fdb09>] rcu_start_future_gp+0x1c9/0x1f0
    > [12573.198023]        [<ffffffff810fe2c4>] rcu_nocb_kthread+0x114/0x930
    > [12573.205860]        [<ffffffff8107a91d>] kthread+0xed/0x100
    > [12573.213656]        [<ffffffff816f4b1c>] ret_from_fork+0x7c/0xb0
    > [12573.221379]
    > -> #1 (&rsp->gp_wq){..-.-.}:
    > [12573.236329]        [<ffffffff810b9851>] lock_acquire+0x91/0x1f0
    > [12573.243783]        [<ffffffff816ebe9b>] _raw_spin_lock_irqsave+0x4b/0x90
    > [12573.251178]        [<ffffffff810868f3>] __wake_up+0x23/0x50
    > [12573.258505]        [<ffffffff810fc3da>] rcu_start_gp_advanced.isra.11+0x4a/0x50
    > [12573.265891]        [<ffffffff810fdb09>] rcu_start_future_gp+0x1c9/0x1f0
    > [12573.273248]        [<ffffffff810fe2c4>] rcu_nocb_kthread+0x114/0x930
    > [12573.280564]        [<ffffffff8107a91d>] kthread+0xed/0x100
    > [12573.287807]        [<ffffffff816f4b1c>] ret_from_fork+0x7c/0xb0
    
    Notice the above call chain.
    
    rcu_start_future_gp() is called with the rnp->lock held. Then it calls
    rcu_start_gp_advance, which does a wakeup.
    
    You can't do wakeups while holding the rnp->lock, as that would mean
    that you could not do a rcu_read_unlock() while holding the rq lock, or
    any lock that was taken while holding the rq lock. This is because...
    (See below).
    
    > [12573.295067]
    > -> #0 (rcu_node_0){..-.-.}:
    > [12573.309293]        [<ffffffff810b8d36>] __lock_acquire+0x1786/0x1af0
    > [12573.316568]        [<ffffffff810b9851>] lock_acquire+0x91/0x1f0
    > [12573.323825]        [<ffffffff816ebc90>] _raw_spin_lock+0x40/0x80
    > [12573.331081]        [<ffffffff811054ff>] rcu_read_unlock_special+0x9f/0x4c0
    > [12573.338377]        [<ffffffff810760a6>] __rcu_read_unlock+0x96/0xa0
    > [12573.345648]        [<ffffffff811391b3>] perf_lock_task_context+0x143/0x2d0
    > [12573.352942]        [<ffffffff8113938e>] find_get_context+0x4e/0x1f0
    > [12573.360211]        [<ffffffff811403f4>] SYSC_perf_event_open+0x514/0xbd0
    > [12573.367514]        [<ffffffff81140e49>] SyS_perf_event_open+0x9/0x10
    > [12573.374816]        [<ffffffff816f4dd4>] tracesys+0xdd/0xe2
    
    Notice the above trace.
    
    perf took its own ctx->lock, which can be taken while holding the rq
    lock. While holding this lock, it did a rcu_read_unlock(). The
    perf_lock_task_context() basically looks like:
    
    rcu_read_lock();
    raw_spin_lock(ctx->lock);
    rcu_read_unlock();
    
    Now, what looks to have happened, is that we scheduled after taking that
    first rcu_read_lock() but before taking the spin lock. When we scheduled
    back in and took the ctx->lock, the following rcu_read_unlock()
    triggered the "special" code.
    
    The rcu_read_unlock_special() takes the rnp->lock, which gives us a
    possible deadlock scenario.
    
    	CPU0		CPU1		CPU2
    	----		----		----
    
    				     rcu_nocb_kthread()
        lock(rq->lock);
    		    lock(ctx->lock);
    				     lock(rnp->lock);
    
    				     wake_up();
    
    				     lock(rq->lock);
    
    		    rcu_read_unlock();
    
    		    rcu_read_unlock_special();
    
    		    lock(rnp->lock);
        lock(ctx->lock);
    
    **** DEADLOCK ****
    
    > [12573.382068]
    > other info that might help us debug this:
    >
    > [12573.403229] Chain exists of:
    >   rcu_node_0 --> &rq->lock --> &ctx->lock
    >
    > [12573.424471]  Possible unsafe locking scenario:
    >
    > [12573.438499]        CPU0                    CPU1
    > [12573.445599]        ----                    ----
    > [12573.452691]   lock(&ctx->lock);
    > [12573.459799]                                lock(&rq->lock);
    > [12573.467010]                                lock(&ctx->lock);
    > [12573.474192]   lock(rcu_node_0);
    > [12573.481262]
    >  *** DEADLOCK ***
    >
    > [12573.501931] 1 lock held by trinity-child17/31341:
    > [12573.508990]  #0:  (&ctx->lock){-.-...}, at: [<ffffffff811390ed>] perf_lock_task_context+0x7d/0x2d0
    > [12573.516475]
    > stack backtrace:
    > [12573.530395] CPU: 1 PID: 31341 Comm: trinity-child17 Not tainted 3.10.0-rc3+ #39
    > [12573.545357]  ffffffff825b4f90 ffff880219f1dbc0 ffffffff816e375b ffff880219f1dc00
    > [12573.552868]  ffffffff816dfa5d ffff880219f1dc50 ffff88023ce4d1f8 ffff88023ce4ca40
    > [12573.560353]  0000000000000001 0000000000000001 ffff88023ce4d1f8 ffff880219f1dcc0
    > [12573.567856] Call Trace:
    > [12573.575011]  [<ffffffff816e375b>] dump_stack+0x19/0x1b
    > [12573.582284]  [<ffffffff816dfa5d>] print_circular_bug+0x200/0x20f
    > [12573.589637]  [<ffffffff810b8d36>] __lock_acquire+0x1786/0x1af0
    > [12573.596982]  [<ffffffff810918f5>] ? sched_clock_cpu+0xb5/0x100
    > [12573.604344]  [<ffffffff810b9851>] lock_acquire+0x91/0x1f0
    > [12573.611652]  [<ffffffff811054ff>] ? rcu_read_unlock_special+0x9f/0x4c0
    > [12573.619030]  [<ffffffff816ebc90>] _raw_spin_lock+0x40/0x80
    > [12573.626331]  [<ffffffff811054ff>] ? rcu_read_unlock_special+0x9f/0x4c0
    > [12573.633671]  [<ffffffff811054ff>] rcu_read_unlock_special+0x9f/0x4c0
    > [12573.640992]  [<ffffffff811390ed>] ? perf_lock_task_context+0x7d/0x2d0
    > [12573.648330]  [<ffffffff810b429e>] ? put_lock_stats.isra.29+0xe/0x40
    > [12573.655662]  [<ffffffff813095a0>] ? delay_tsc+0x90/0xe0
    > [12573.662964]  [<ffffffff810760a6>] __rcu_read_unlock+0x96/0xa0
    > [12573.670276]  [<ffffffff811391b3>] perf_lock_task_context+0x143/0x2d0
    > [12573.677622]  [<ffffffff81139070>] ? __perf_event_enable+0x370/0x370
    > [12573.684981]  [<ffffffff8113938e>] find_get_context+0x4e/0x1f0
    > [12573.692358]  [<ffffffff811403f4>] SYSC_perf_event_open+0x514/0xbd0
    > [12573.699753]  [<ffffffff8108cd9d>] ? get_parent_ip+0xd/0x50
    > [12573.707135]  [<ffffffff810b71fd>] ? trace_hardirqs_on_caller+0xfd/0x1c0
    > [12573.714599]  [<ffffffff81140e49>] SyS_perf_event_open+0x9/0x10
    > [12573.721996]  [<ffffffff816f4dd4>] tracesys+0xdd/0xe2
    
    This commit delays the wakeup via irq_work(), which is what
    perf and ftrace use to perform wakeups in critical sections.
    
    Reported-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit d62840995a99c9766803d54e9d7923f247a1c1db
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Wed May 22 02:41:36 2013 -0700

    trace: Allow idle-safe tracepoints to be called from irq
    
    __DECLARE_TRACE_RCU() currently creates an _rcuidle() tracepoint which
    may safely be invoked from what RCU considers to be an idle CPU.
    However, these _rcuidle() tracepoints may -not- be invoked from the
    handler of an irq taken from idle, because rcu_idle_enter() zeroes
    RCU's nesting-level counter, so that the rcu_irq_exit() returning to
    idle will trigger a WARN_ON_ONCE().
    
    This commit therefore substitutes rcu_irq_enter() for rcu_idle_exit()
    and rcu_irq_exit() for rcu_idle_enter() in order to make the _rcuidle()
    tracepoints usable from irq handlers as well as from process context.
    
    Reported-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Steven Rostedt <rostedt@goodmis.org>

commit 2d8f4447b58bba5f8cb895c07690434c02307eaf
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Jun 10 18:29:38 2013 +0200

    USB: pl2303: fix device initialisation at open
    
    Do not use uninitialised termios data to determine when to configure the
    device at open.
    
    This also prevents stack data from leaking to userspace in the OOM error
    path.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e4211f1c47560c36a8b3d4544dfd866dcf7ccd0
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Jun 10 18:29:39 2013 +0200

    USB: spcp8x5: fix device initialisation at open
    
    Do not use uninitialised termios data to determine when to configure the
    device at open.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21886725d58e92188159731c7c1aac803dd6b9dc
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Jun 10 18:29:37 2013 +0200

    USB: f81232: fix device initialisation at open
    
    Do not use uninitialised termios data to determine when to configure the
    device at open.
    
    This also prevents stack data from leaking to userspace.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c6cf64b16438eac6da9a90412a82316ad196e7c
Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
Date:   Mon Jun 10 18:22:26 2013 +0200

    spi: s3c64xx: Fix pm_runtime_get_sync() return value check
    
    If the device is already in a runtime PM enabled state
    pm_runtime_get_sync() will return 1, so a test for negative
    value should be used to check for errors.
    
    Without this patch there are seen errors like:
    
    [    8.540000] s3c64xx-spi 13930000.spi: Failed to enable device: 1
    [    8.545000] spi_master spi1: failed to prepare transfer hardware
    
    Likely because the driver uses synchronous API to runtime enable
    the device and asynchronous one to disable it.
    
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Mark Brown <broonielinaro.org>
    Cc: stable@vger.kernel.org

commit cb2f9938d0a57625644750e66373d3bf4d3a1601
Author: Markos Chandras <markos.chandras@imgtec.com>
Date:   Mon Jun 10 10:35:26 2013 +0000

    MIPS: ftrace: Add missing CONFIG_DYNAMIC_FTRACE
    
    arch_ftrace_update_code and ftrace_modify_all_code are only
    available if CONFIG_DYNAMIC_FTRACE is selected.
    
    Fixes the following build problem on MIPS randconfig:
    
    arch/mips/kernel/ftrace.c: In function 'arch_ftrace_update_code':
    arch/mips/kernel/ftrace.c:31:2: error: implicit declaration of function
    'ftrace_modify_all_code' [-Werror=implicit-function-declaration]
    
    Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
    Acked-by: Steven J. Hill <Steven.Hill@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/5435/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit d414976d1ca721456f7b7c603a8699d117c2ec07
Author: Markos Chandras <markos.chandras@imgtec.com>
Date:   Mon Jun 10 12:16:16 2013 +0000

    MIPS: include: mmu_context.h: Replace VIRTUALIZATION with KVM
    
    The kvm_* symbols are only available if KVM is selected.
    
    Fixes the following linking problem on a randconfig:
    
    arch/mips/built-in.o: In function `local_flush_tlb_mm':
    (.text+0x18a94): undefined reference to `kvm_local_flush_tlb_all'
    arch/mips/built-in.o: In function `local_flush_tlb_range':
    (.text+0x18d0c): undefined reference to `kvm_local_flush_tlb_all'
    kernel/built-in.o: In function `__schedule':
    core.c:(.sched.text+0x2a00): undefined reference to `kvm_local_flush_tlb_all'
    mm/built-in.o: In function `use_mm':
    (.text+0x30214): undefined reference to `kvm_local_flush_tlb_all'
    fs/built-in.o: In function `flush_old_exec':
    (.text+0xf0a0): undefined reference to `kvm_local_flush_tlb_all'
    make: *** [vmlinux] Error 1
    
    Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
    Acked-by: Steven J. Hill <Steven.Hill@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/5437/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit e63a24ddc79cc801766646fb643451ad366a1121
Author: Manuel Lauss <manuel.lauss@gmail.com>
Date:   Sat Jun 8 19:15:41 2013 +0000

    MIPS: Alchemy: fix wait function
    
    Only an interrupt can wake the core from 'wait', enable interrupts
    locally before executing 'wait'.
    
    [ralf@linux-mips.org: This leave the race between an interrupt that's
    setting TIF_NEED_RESCHEd and entering the WAIT status. but at least it's
    going to bring Alchemy back from the dead, so I'm going to apply this
    patch.]
    
    Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
    Cc: Linux-MIPS <linux-mips@linux-mips.org>
    Cc: Maciej W. Rozycki <macro@linux-mips.org>
    Patchwork: https://patchwork.linux-mips.org/patch/5408/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit b2c75c446ae72387916e2caf6e6dca815b6e5e6e
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Fri Jun 7 15:26:03 2013 -0400

    xen/tmem: Don't over-write tmem_frontswap_poolid after tmem_frontswap_init set it.
    
    Commit 10a7a0771399a57a297fca9615450dbb3f88081a ("xen: tmem: enable Xen
    tmem shim to be built/loaded as a module") allows the tmem module
    to be loaded any time. For this work the frontswap API had to
    be able to asynchronously to call tmem_frontswap_init before
    or after the swap image had been set. That was added in git
    commit 905cd0e1bf9ffe82d6906a01fd974ea0f70be97a
    ("mm: frontswap: lazy initialization to allow tmem backends to build/run as modules").
    
    Which means we could do this (The common case):
    
     modprobe tmem		[so calls frontswap_register_ops, no ->init]
    			 modifies tmem_frontswap_poolid = -1
     swapon /dev/xvda1	[__frontswap_init, calls -> init, tmem_frontswap_poolid is
    			 < 0 so tmem hypercall done]
    
    Or the failing one:
    
     swapon /dev/xvda1	[calls __frontswap_init, sets the need_init bitmap]
     modprobe tmem		[calls frontswap_register_ops, -->init calls, finds out
    			tmem_frontswap_poolid is 0, does not make a hypercall.
    			Later in the module_init, sets tmem_frontswap_poolid=-1]
    
    Which meant that in the failing case we would not call the hypercall
    to initialize the pool and never be able to make any frontswap
    backend calls.
    
    Moving the frontswap_register_ops after setting the tmem_frontswap_poolid
    fixes it.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Reviewed-by: Bob Liu <bob.liu@oracle.com>

commit c46b54f7406780ec4cf9c9124d1cfb777674dc70
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Mon Jun 10 15:34:04 2013 +0200

    s390/pci: Implement IRQ functions if !PCI
    
    All architectures must implement IRQ functions.  Since various
    dependencies on !S390 were removed, there are various drivers that can
    be selected but will fail to link.  Provide a dummy implementation of
    these functions for the !PCI case.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: stable@vger.kernel.org # 3.9
    Acked-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit a8241c63517ec0b900695daa9003cddc41c536a1
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Jun 3 12:00:49 2013 +0300

    ipvs: info leak in __ip_vs_get_dest_entries()
    
    The entry struct has a 2 byte hole after ->port and another 4 byte
    hole after ->stats.outpkts.  You must have CAP_NET_ADMIN in your
    namespace to hit this information leak.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

commit 8c9b7a7b2fc2750af418ddc28e707c42e78aa0bf
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Mon Jun 10 13:00:29 2013 +0200

    ACPI / video: Do not bind to device objects with a scan handler
    
    With the introduction of ACPI scan handlers, ACPI device objects
    with an ACPI scan handler attached to them must not be bound to
    by ACPI drivers any more.  Unfortunately, however, the ACPI video
    driver attempts to do just that if there is a _ROM ACPI control
    method defined under a device object with an ACPI scan handler.
    
    Prevent that from happening by making the video driver's "add"
    routine check if the device object already has an ACPI scan handler
    attached to it and return an error code in that case.
    
    That is not sufficient, though, because acpi_bus_driver_init() would
    then clear the device object's driver_data that may be set by its
    scan handler, so for the fix to work acpi_bus_driver_init() has to be
    modified to leave driver_data as is on errors.
    
    References: https://bugzilla.kernel.org/show_bug.cgi?id=58091
    Bisected-and-tested-by: Dmitry S. Demin <dmitryy.demin@gmail.com>
    Reported-and-tested-by: Jason Cassell <bluesloth600@gmail.com>
    Tracked-down-by: Aaron Lu <aaron.lu@intel.com>
    Cc: 3.9+ <stable@kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Aaron Lu <aaron.lu@intel.com>

commit c3456fb3e4712d0448592af3c5d644c9472cd3c1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Jun 10 09:47:58 2013 +0200

    drm/i915: prefer VBT modes for SVDO-LVDS over EDID
    
    In
    
    commit 53d3b4d7778daf15900867336c85d3f8dd70600c
    Author: Egbert Eich <eich@suse.de>
    Date:   Tue Jun 4 17:13:21 2013 +0200
    
        drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC
    
    Egbert Eich fixed a long-standing bug where we simply used a
    non-working i2c controller to read the EDID for SDVO-LVDS panels.
    Unfortunately some machines seem to not be able to cope with the mode
    provided in the EDID. Specifically they seem to not be able to cope
    with a 4x pixel mutliplier instead of a 2x one, which seems to have
    been worked around by slightly changing the panels native mode in the
    VBT so that the dotclock is just barely above 50MHz.
    
    Since it took forever to notice the breakage it's fairly safe to
    assume that at least for SDVO-LVDS panels the VBT contains fairly sane
    data. So just switch around the order and use VBT modes first.
    
    v2: Also add EDID modes just in case, and spell Egbert correctly.
    
    v3: Elaborate a bit more about what's going on on Chris' machine.
    
    Cc: Egbert Eich <eich@suse.de>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65524
    Cc: stable@vger.kernel.org
    Reported-and-tested-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 7ba220cec0bbe9453c1f958cf282f84a157c924f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Jun 9 16:02:04 2013 +0100

    drm/i915: Enable hotplug interrupts after querying hw capabilities.
    
    sdvo->hotplug_active is initialised during intel_sdvo_setup_outputs(),
    and so we never enabled the hotplug interrupts on SDVO as we were
    checking too early.
    
    This regression has been introduced somewhere in the hpd rework for
    the storm detection and handling starting with
    
    commit 1d843f9de4e6dc6a899b6f07f106c00da09925e6
    Author: Egbert Eich <eich@suse.de>
    Date:   Mon Feb 25 12:06:49 2013 -0500
    
        DRM/I915: Add enum hpd_pin to intel_encoder.
    
    and the follow-up patches to use the new encoder->hpd_pin variable for
    the different irq setup functions.
    
    The problem is that encoder->hpd_pin was set up _before_ the output
    setup was done and so before we could assess the hotplug capabilities
    of the outputs on an sdvo encoder.
    
    Reported-by: Alex Fiestas <afiestas@kde.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58405
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    [danvet: Add regression note.]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 7ee2aff373498a887cde0d564f89cf05377c538e
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Jun 9 16:02:03 2013 +0100

    drm/i915: Fix hotplug interrupt enabling for SDVOC
    
    A broken conditional would lead to SDVOC waiting upon hotplug events on
    SDVOB - and so miss all activity on its SDVO port.
    
    This regression has been introduced in
    
    commit 1d843f9de4e6dc6a899b6f07f106c00da09925e6
    Author: Egbert Eich <eich@suse.de>
    Date:   Mon Feb 25 12:06:49 2013 -0500
    
        DRM/I915: Add enum hpd_pin to intel_encoder.
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=58405
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    [danvet: Add regression note.]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit d5b4c93e67b0b1291aa8e2aaf694e40afc3412d0
Author: Simon Wunderlich <simon@open-mesh.com>
Date:   Fri Jun 7 16:52:05 2013 +0200

    batman-adv: Don't handle address updates when bla is disabled
    
    The bridge loop avoidance has a hook to handle address updates of the
    originator. These should not be handled when bridge loop avoidance is
    disabled - it might send some bridge loop avoidance packets which should
    not appear if bla is disabled.
    
    Signed-off-by: Simon Wunderlich <simon@open-mesh.com>
    Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
    Signed-off-by: Antonio Quartulli <ordex@autistici.org>

commit 7c24bbbeab4159f924b65b1e94878e597b762714
Author: Simon Wunderlich <simon@open-mesh.com>
Date:   Thu May 23 13:07:42 2013 +0200

    batman-adv: forward late OGMs from best next hop
    
    When a packet is received from another node first and later from the
    best next hop, this packet is dropped. However the first OGM was sent
    with the BATADV_NOT_BEST_NEXT_HOP flag and thus dropped by neighbors.
    The late OGM from the best neighbor is then dropped because it is a
    duplicate.
    
    If this situation happens constantly, a node might end up not forwarding
    the "valid" OGMs anymore, and nodes behind will starve from not getting
    valid OGMs.
    
    Fix this by refining the duplicate checking behaviour: The actions
    should depend on whether it was a duplicate for a neighbor only or for
    the originator. OGMs which are not duplicates for a specific neighbor
    will now be considered in batadv_iv_ogm_forward(), but only actually
    forwarded for the best next hop. Therefore, late OGMs from the best
    next hop are forwarded now and not dropped as duplicates anymore.
    
    Signed-off-by: Simon Wunderlich <simon@open-mesh.com>
    Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
    Signed-off-by: Antonio Quartulli <ordex@autistici.org>

commit ac16d1484efd5d2d9077c55453b1f8abff49fc18
Author: Matthias Schiffer <mschiffer@universe-factory.net>
Date:   Tue May 28 17:32:32 2013 +0200

    batman-adv: wait for rtnl in batadv_store_mesh_iface instead of failing if it is taken
    
    The rtnl_lock in batadv_store_mesh_iface has been converted to a rtnl_trylock
    some time ago to avoid a possible deadlock between rtnl and s_active on removal
    of the sysfs nodes.
    
    The behaviour introduced by that was quite confusing as it could lead to the
    sysfs store to fail, making batman-adv setup scripts unreliable. As recently the
    sysfs removal was postponed to a worker not running with the rtnl taken, the
    deadlock can't occur any more and it is safe to change the trylock back to a
    lock to make the sysfs store reliable again.
    
    Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
    Reviewed-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
    Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
    Signed-off-by: Antonio Quartulli <ordex@autistici.org>

commit b11ae95100f7061b39a15e5c1ecbf862464ac4b4
Author: Michael Ellerman <michael@ellerman.id.au>
Date:   Wed Jun 5 18:03:36 2013 +0000

    powerpc: Partial revert of "Context switch more PMU related SPRs"
    
    In commit 59affcd I added context switching of more PMU SPRs, because
    they are potentially exposed to userspace on Power8. However despite me
    being a smart arse in the commit message it's actually not correct. In
    particular it interacts badly with a global perf record.
    
    We will have to do something more complicated, but that will have to
    wait for 3.11.
    
    Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit 6772faa1ba22eba18d087c2459030a683b65be57
Author: Michael Ellerman <michael@ellerman.id.au>
Date:   Wed Jun 5 17:58:20 2013 +0000

    powerpc/perf: Fix deadlock caused by calling printk() in PMU exception
    
    In commit bc09c21 "Fix finding overflowed PMC in interrupt" we added
    a printk() to the PMU exception handler. Unfortunately that is not safe.
    
    The problem is that the PMU exception may run even when interrupts are
    soft disabled, aka NMI context. We do this so that we can profile parts
    of the kernel that have interrupts soft-disabled.
    
    But by calling printk() from the exception handler, we can potentially
    deadlock in the printk code on logbuf_lock, eg:
    
      [c00000038ba575c0] c000000000081928 .vprintk_emit+0xa8/0x540
      [c00000038ba576a0] c0000000007bcde8 .printk+0x48/0x58
      [c00000038ba57710] c000000000076504 .perf_event_interrupt+0x2d4/0x490
      [c00000038ba57810] c00000000001f6f8 .performance_monitor_exception+0x48/0x60
      [c00000038ba57880] c0000000000032cc performance_monitor_common+0x14c/0x180
      --- Exception: f01 (Performance Monitor) at c0000000007b25d4 ._raw_spin_lock_irq
      +0x64/0xc0
      [c00000038ba57bf0] c00000000007ed90 .devkmsg_read+0xd0/0x5a0
      [c00000038ba57d00] c0000000001c2934 .vfs_read+0xc4/0x1e0
      [c00000038ba57d90] c0000000001c2cd8 .SyS_read+0x58/0xd0
      [c00000038ba57e30] c000000000009d54 syscall_exit+0x0/0x98
      --- Exception: c01 (System Call) at 00001fffffbf6f7c
      SP (3ffff6d4de10) is in userspace
    
    Fix it by making sure we only call printk() when we are not in NMI
    context.
    
    Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
    Cc: <stable@vger.kernel.org> # 3.9
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit 82a9f16adc12f51c3f8ea59a7c3c120241aff836
Author: Michael Neuling <mikey@neuling.org>
Date:   Thu May 16 20:27:31 2013 +0000

    powerpc/hw_breakpoints: Add DABRX cpu feature to fix 32-bit regression
    
    When introducing support for DABRX in 4474ef0, we broke older 32-bit CPUs
    that don't have that register.
    
    Some CPUs have a DABR but not DABRX.  Configuration are:
    - No 32bit CPUs have DABRX but some have DABR.
    - POWER4+ and below have the DABR but no DABRX.
    - 970 and POWER5 and above have DABR and DABRX.
    - POWER8 has DAWR, hence no DABRX.
    
    This introduces CPU_FTR_DABRX and sets it on appropriate CPUs.  We use
    the top 64 bits for CPU FTR bits since only 64 bit CPUs have this.
    
    Processors that don't have the DABRX will still work as they will fall
    back to software filtering these breakpoints via perf_exclude_event().
    
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Reported-by: "Gorelik, Jacob (335F)" <jacob.gorelik@jpl.nasa.gov>
    cc: stable@vger.kernel.org (v3.9 only)
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit fb0fce3e554e5513aaa1c1c52b2ece11feea3c7d
Author: Michael Neuling <mikey@neuling.org>
Date:   Wed May 29 21:33:19 2013 +0000

    powerpc/power8: Update denormalization handler
    
    POWER8 can take a denormalisation exception on any VSX registers.
    
    This does the extra 32 VSX registers we don't currently handle.
    
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit d7c67fb1cf00b84829ae06fca04ad39408f156ba
Author: Michael Neuling <mikey@neuling.org>
Date:   Wed May 29 21:33:18 2013 +0000

    powerpc/pseries: Simplify denormalization handler
    
    The following simplifies the denorm code by using macros to generate the long
    stream of almost identical instructions.
    
    This patch results in no changes to the output binary, but removes a lot of
    lines of code.
    
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit 6a60f9e7d8bb3e81fa8bd6752f1473e216424ec4
Author: Michael Neuling <mikey@neuling.org>
Date:   Tue Jun 4 19:38:54 2013 +0000

    powerpc/power8: Fix oprofile and perf
    
    In 2ac6f42 powerpc/cputable: Fix oprofile_cpu_type on power8
    we broke all power8 hw events.
    
    This reverts this change and uses oprofile_type instead. Perf now works
    on POWER8 again and oprofile will revert to using timers on POWER8.
    
    Kudos to mpe this fix.
    
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit b8b3de224f194005ad87ede6fd022fcc2bef3b1a
Author: Gavin Shan <shangw@linux.vnet.ibm.com>
Date:   Wed Jun 5 14:25:50 2013 +0000

    powerpc/eeh: Don't check RTAS token to get PE addr
    
    RTAS token "ibm,get-config-addr-info" or ibm,get-config-addr-info2"
    are used to retrieve the PE address according to PCI address, which
    made up of domain/bus/slot/function. If we don't have those 2 tokens,
    the domain/bus/slot/function would be used as the address for EEH
    RTAS operations. Some older f/w might not have those 2 tokens and
    that blocks the EEH functionality to be initialized. It was introduced
    by commit e2af155c ("powerpc/eeh: pseries platform EEH initialization").
    
    The patch skips the check on those 2 tokens so we can bring up EEH
    functionality successfully. And domain/bus/slot/function will be
    used as address for EEH RTAS operations.
    
    Cc: <stable@vger.kernel.org> # v3.4+
    Reported-by: Robert Knight <knight@princeton.edu>
    Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
    Tested-by: Robert Knight <knight@princeton.edu>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit c5df457ffe6db7569de9fb856de490b5317c97b4
Author: Kevin Hao <haokexin@gmail.com>
Date:   Wed Jun 5 02:26:51 2013 +0000

    powerpc/pci: Check the bus address instead of resource address in pcibios_fixup_resources
    
    If a BAR has the value of 0, we would assume that it is unset yet and
    then mark the resource as unset and would reassign it later. But after
    commit 6c5705fe (powerpc/PCI: get rid of device resource fixups)
    the pcibios_fixup_resources is invoked after the bus address was
    translated to linux resource. So the value of res->start is resource
    address. And since the resource and bus address may be different, we
    should translate it to the bus address before doing the check.
    
    Signed-off-by: Kevin Hao <haokexin@gmail.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit 70b1304eeedf211fc9fa185b43350bd9ab4c119c
Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Date:   Sun May 26 18:44:48 2013 +0200

    drm/gma500/cdv: Fix cursor gem obj referencing on cdv
    
    The internal crtc cursor gem object pointer was never set/updated since
    it was required to be set in the first place.
    
    Fixing this will make the pin/unpin count match and prevent cursor
    objects from leaking when userspace drops all references to it. Also
    make sure we drop the gem obj reference on failure.
    
    This patch only affects Cedarview chips.
    
    Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>

commit 3463cf1aad48ef43dd0b4cbd7fed15dcc8d2ca53
Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Date:   Sun May 26 17:56:19 2013 +0200

    drm/gma500/psb: Fix cursor gem obj referencing on psb
    
    The internal crtc cursor gem object pointer was never set/updated since
    it was required to be set in the first place.
    
    Fixing this will make the pin/unpin count match and prevent cursor
    objects from leaking when userspace drops all references to it. Also
    make sure we drop the gem obj reference on failure.
    
    This patch only affects Poulsbo chips.
    
    Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>

commit 22e7c385a80d771aaf3a15ae7ccea3b0686bbe10
Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Date:   Sat Jun 8 20:23:08 2013 +0200

    drm/gma500/cdv: Unpin framebuffer on crtc disable
    
    The framebuffer needs to be unpinned in the crtc->disable callback
    because of previous pinning in psb_intel_pipe_set_base(). This will fix
    a memory leak where the framebuffer was released but not unpinned
    properly. This patch only affects Cedarview.
    
    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=889511
    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=812113
    Cc: stable@vger.kernel.org
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>

commit 820de86a90089ee607d7864538c98a23b503c846
Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Date:   Wed Jun 5 14:24:01 2013 +0200

    drm/gma500/psb: Unpin framebuffer on crtc disable
    
    The framebuffer needs to be unpinned in the crtc->disable callback
    because of previous pinning in psb_intel_pipe_set_base(). This will fix
    a memory leak where the framebuffer was released but not unpinned
    properly. This patch only affects Poulsbo.
    
    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=889511
    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=812113
    Cc: stable@vger.kernel.org
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>

commit af44ad5edd1eb6ca92ed5be48e0004e1f04bf219
Author: Wenbing Wang <wangwb@marvell.com>
Date:   Wed Jun 5 06:37:14 2013 -0300

    [media] soc_camera: error dev remove and v4l2 call
    
    in soc_camera_close(), if ici->ops->remove() removes device firstly,
    and then call __soc_camera_power_off(), it has logic error. Since
    if remove device, it should disable subdev clk. but in __soc_camera_
    power_off(), it will callback v4l2 s_power function which will
    read/write subdev registers to control power by i2c. and then
    i2c read/write will fail because of clk disable.
    So suggest to re-sequence two functions call.
    Change-Id: Iee7a6d4fc7c7c1addb5d342621eb8dcd00fa2745
    
    Signed-off-by: Wenbing Wang <wangwb@marvell.com>
    Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 697a6d2387692c7f9c94f3bfb3dac474aa840f02
Author: Katsuya Matsubara <matsu@igel.co.jp>
Date:   Tue Apr 23 07:51:37 2013 -0300

    [media] sh_veu: fix the buffer size calculation
    
    The 'bytesperline' value only indicates the stride of the Y plane
    if the color format is planar, such as NV12. When calculating
    the total plane size, the size of CbCr plane must also be considered.
    
    Signed-off-by: Katsuya Matsubara <matsu@igel.co.jp>
    Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 6abb3cf2c34554590791b7486e0e32b291feacc4
Author: Katsuya Matsubara <matsu@igel.co.jp>
Date:   Tue Apr 23 07:51:36 2013 -0300

    [media] sh_veu: keep power supply until the m2m context is released
    
    In the sh_veu driver, only the interrupt handler 'sh_veu_bh'
    can invoke the v4l2_m2m_job_finish() function.
    So the hardware must be alive for handling interrupts
    until returning from v4l2_m2m_ctx_release().
    
    Signed-off-by: Katsuya Matsubara <matsu@igel.co.jp>
    Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 9166e1aae3c90720fc389815909cb0bb815d9bca
Author: Katsuya Matsubara <matsu@igel.co.jp>
Date:   Tue Apr 23 07:51:35 2013 -0300

    [media] sh_veu: invoke v4l2_m2m_job_finish() even if a job has been aborted
    
    v4l2_m2m_job_finish() should be invoked even if the current
    ongoing job has been aborted since v4l2_m2m_ctx_release() which
    has issued the job abort may wait until the finish function is invoked.
    
    Signed-off-by: Katsuya Matsubara <matsu@igel.co.jp>
    Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 317ddd256b9c24b0d78fa8018f80f1e495481a10
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Jun 8 17:41:04 2013 -0700

    Linux 3.10-rc5

commit bbd465df73f0d8ba41b8a0732766a243d0f5b356
Author: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Date:   Sun Jun 9 01:25:57 2013 +0200

    hpfs: fix warnings when the filesystem fills up
    
    This patch fixes warnings due to missing lock on write error path.
    
      WARNING: at fs/hpfs/hpfs_fn.h:353 hpfs_truncate+0x75/0x80 [hpfs]()
      Hardware name: empty
      Pid: 26563, comm: dd Tainted: P           O 3.9.4 #12
      Call Trace:
        hpfs_truncate+0x75/0x80 [hpfs]
        hpfs_write_begin+0x84/0x90 [hpfs]
        _hpfs_bmap+0x10/0x10 [hpfs]
        generic_file_buffered_write+0x121/0x2c0
        __generic_file_aio_write+0x1c7/0x3f0
        generic_file_aio_write+0x7c/0x100
        do_sync_write+0x98/0xd0
        hpfs_file_write+0xd/0x50 [hpfs]
        vfs_write+0xa2/0x160
        sys_write+0x51/0xa0
        page_fault+0x22/0x30
        system_call_fastpath+0x1a/0x1f
    
    Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
    Cc: stable@kernel.org  # 2.6.39+
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 560dde24adfdc9dbcd141c75faecc5e0402fe531
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Mon Jun 3 04:35:22 2013 -0300

    [media] v4l2-ioctl: don't print the clips list
    
    The clips pointer is a userspace pointer, not a kernelspace pointer,
    so you can't dereference the clips pointer.
    Also add a few missing commas and newlines.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 3963d4fb869de1144aebe6eef074995f086961c4
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Sun Jun 2 07:55:59 2013 -0300

    [media] v4l2-ctrls: V4L2_CTRL_CLASS_FM_RX controls are also valid radio controls
    
    The radio filter function that filters controls that are valid for a radio
    device should also accept V4L2_CTRL_CLASS_FM_RX controls.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 609c4c12af79b1ba5fd2d31727a95dd3a319c0ae
Author: Hans Verkuil <hverkuil@xs4all.nl>
Date:   Wed May 29 10:44:22 2013 -0300

    [media] cx88: fix NULL pointer dereference
    
    This fixes a NULL pointer deference when loading the cx88_dvb module for a
    Hauppauge HVR4000.
    The bugzilla bug report is here:
    https://bugzilla.kernel.org/show_bug.cgi?id=56271
    The cause is that the wm8775 is optional, so even though the board info says
    there is one, it doesn't have to be there. Checking whether the module was
    actually loaded is much safer.
    Note that this driver is quite buggy when it comes to unloading and reloading
    modules. Unloading cx8800 and reloading it again will still cause a crash,
    most likely because either the i2c bus isn't unloaded at the right time and/or
    the v4l2_device_unregister isn't called at the right time.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Reported-by: Sebastian Frei <sebastian@familie-frei.net>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit dfd50fc9030a62521838eecbe488e1962edcba80
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Wed May 29 05:03:32 2013 -0300

    [media] DocBook/media/v4l: update version number
    
    The version number was still 3.9: update to 3.10.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 6301b13213d55e51b7255b1098618ba99d2945cd
Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
Date:   Fri May 10 12:46:35 2013 -0300

    [media] exynos4-is: Remove "sysreg" clock handling
    
    The "sysreg" clock is required by multiple subsystems and none of the
    other drivers handles this clock explicitly. It is currently assumed
    that this clock is always on, left in its default state after system
    reset.
    Remove handling of this clock from the FIMC-IS driver to avoid breaking
    other subsystems.
    
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit ac2a4a86643aa74236508f0a8c0e34b0622b0b46
Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
Date:   Fri May 31 08:40:37 2013 -0300

    [media] exynos4-is: Fix reported colorspace at FIMC-IS-ISP subdev
    
    The FIMC-IS-ISP handles only Bayer formats thus V4L2_COLORSPACE_SRGB
    should be used. This change applies to the code first added in v3.10.
    
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit b4155d7d5b2c4e82238d629c451f7c27c9f37d9c
Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
Date:   Fri May 31 08:40:36 2013 -0300

    [media] exynos4-is: Ensure fimc-is clocks are not enabled until properly configured
    
    Use clk_prepare_enable/clk_unprepare_disable instead of preparing the
    clocks during the driver initalization and then using just clk_disable/
    clk_enable. The clock framework doesn't guarantee a clock will not get
    enabled during e.g. clk_set_parent if clk_prepare has been called on it.
    So we ensure clk_prepare() is called only when it is safe to enable
    the clocks, i.e. the parent clocks and the clocks' frequencies are set.
    It must be ensured the FIMC-IS clocks have proper frequencies before they
    are enabled, otherwise the whole system will hang.
    
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Kyunmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 3cf138a6393d4ae2aeabce4c4b776d7d15cce69b
Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
Date:   Fri May 31 08:40:35 2013 -0300

    [media] exynos4-is: Prevent NULL pointer dereference when firmware isn't loaded
    
    Ensure the firmware isn't accessed in the driver when the firmware loading
    routine has not completed. This fixes a potential kernel crash:
    [   96.510000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
    [   96.520000] pgd = ee604000
    [   96.520000] [00000000] *pgd=6e947831, *pte=00000000, *ppte=00000000
    [   96.530000] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
    [   96.530000] Modules linked in:
    [   96.530000] CPU: 2 PID: 2787 Comm: camera_test Not tainted 3.10.0-rc1-00269-gcdbde37-dirty #2158
    [   96.545000] task: ee42e400 ti: edfcc000 task.ti: edfcc000
    [   96.545000] PC is at fimc_is_start_firmware+0x14/0x94
    [   96.545000] LR is at fimc_isp_subdev_s_power+0x13c/0x1f8
    	...
    [   96.745000] [<c03e0354>] (fimc_is_start_firmware+0x14/0x94) from [<c03e1cc4>] (fimc_isp_subdev_s_power+0x13c/0x1f8)
    [   96.745000] [<c03e1cc4>] (fimc_isp_subdev_s_power+0x13c/0x1f8) from [<c03ed088>] (__subdev_set_power+0x70/0x84)
    [   96.745000] [<c03ed088>] (__subdev_set_power+0x70/0x84) from [<c03ed164>] (fimc_pipeline_s_power+0xc8/0x164)
    [   96.745000] [<c03ed164>] (fimc_pipeline_s_power+0xc8/0x164) from [<c03ee2b8>] (__fimc_pipeline_open+0x90/0x268)
    [   96.745000] [<c03ee2b8>] (__fimc_pipeline_open+0x90/0x268) from [<c03ec5f0>] (fimc_capture_open+0xe4/0x1ec)
    [   96.745000] [<c03ec5f0>] (fimc_capture_open+0xe4/0x1ec) from [<c03c5560>] (v4l2_open+0xa8/0xe4)
    [   96.745000] [<c03c5560>] (v4l2_open+0xa8/0xe4) from [<c0112900>] (chrdev_open+0x9c/0x158)
    [   96.745000] [<c0112900>] (chrdev_open+0x9c/0x158) from [<c010d3e0>] (do_dentry_open+0x1f4/0x27c)
    [   96.745000] [<c010d3e0>] (do_dentry_open+0x1f4/0x27c) from [<c010d558>] (finish_open+0x34/0x50)
    [   96.745000] [<c010d558>] (finish_open+0x34/0x50) from [<c011bea0>] (do_last+0x59c/0xbcc)
    [   96.745000] [<c011bea0>] (do_last+0x59c/0xbcc) from [<c011c580>] (path_openat+0xb0/0x484)
    [   96.745000] [<c011c580>] (path_openat+0xb0/0x484) from [<c011ca58>] (do_filp_open+0x30/0x84)
    [   96.745000] [<c011ca58>] (do_filp_open+0x30/0x84) from [<c010d060>] (do_sys_open+0xe8/0x170)
    [   96.745000] [<c010d060>] (do_sys_open+0xe8/0x170) from [<c000f040>] (ret_fast_syscall+0x0/0x30)
    
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit d94ea3f6d21e8b4398285516cc307c81d7374ec9
Author: Grant Likely <grant.likely@linaro.org>
Date:   Thu Jun 6 14:11:38 2013 +0100

    irqchip: Return -EPERM for reserved IRQs
    
    The irqdomain core will report a log message for any attempted map call
    that fails unless the error code is -EPERM. This patch changes the
    Versatile irq controller drivers to use -EPERM because it is normal for
    a subset of the IRQ inputs to be marked as reserved on the various
    Versatile platforms.
    
    Signed-off-by: Grant Likely <grant.likely@linaro.org>

commit 94a63da0ac1a67bfb8b30aec1086523c5031ea5a
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Thu Jun 6 12:10:23 2013 +0100

    irqdomain: document the simple domain first_irq
    
    The first_irq needs to be zero to get a linear domain and that
    comes with special semantics. We want to simplify this going
    forward but some documentation never hurts.
    
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Grant Likely <grant.likely@linaro.org>

commit 275e31b10ce20613aedceaa5160129c64b260a98
Author: Chen Gang <gang.chen@asianux.com>
Date:   Tue May 14 19:02:45 2013 +0800

    kernel/irq/irqdomain.c: before use 'irq_data', need check it whether valid.
    
    Since irq_data may be NULL, if so, we WARN_ON(), and continue, 'hwirq'
    which related with 'irq_data' has to initialize later, or it will cause
    issue.
    
    Signed-off-by: Chen Gang <gang.chen@asianux.com>
    Signed-off-by: Grant Likely <grant.likely@linaro.org>

commit 346dbb79ea0118ebb0df372b35cab9d5805216cd
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Apr 25 19:28:54 2013 +0200

    irqdomain: export irq_domain_add_simple
    
    All other irq_domain_add_* functions are exported already, and apparently
    this one got left out by mistake, which causes build errors for ARM
    allmodconfig kernels:
    
    ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-rcar.ko] undefined!
    ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-em.ko] undefined!
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Simon Horman <horms+renesas@verge.net.au>
    Signed-off-by: Grant Likely <grant.likely@linaro.org>

commit 13e6c37b989859e70b0d73d3f2cb0aa022159b17
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Thu May 30 16:55:44 2013 -0400

    Btrfs: stop all workers before cleaning up roots
    
    Dave reported a panic because the extent_root->commit_root was NULL in the
    caching kthread.  That is because we just unset it in free_root_pointers, which
    is not the correct thing to do, we have to either wait for the caching kthread
    to complete or hold the extent_commit_sem lock so we know the thread has exited.
    This patch makes the kthreads all stop first and then we do our cleanup.  This
    should fix the race.  Thanks,
    
    Reported-by: David Sterba <dsterba@suse.cz>
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>

commit 2932505abe7c56477315a3d93ffb3c27c5182e9d
Author: Liu Bo <bo.li.liu@oracle.com>
Date:   Sun May 26 13:50:27 2013 +0000

    Btrfs: fix use-after-free bug during umount
    
    Commit be283b2e674a09457d4563729015adb637ce7cc1
    (    Btrfs: use helper to cleanup tree roots) introduced the following bug,
    
     BUG: unable to handle kernel NULL pointer dereference at 0000000000000034
     IP: [<ffffffffa039368c>] extent_buffer_get+0x4/0xa [btrfs]
    [...]
     Pid: 2463, comm: btrfs-cache-1 Tainted: G           O 3.9.0+ #4 innotek GmbH VirtualBox/VirtualBox
     RIP: 0010:[<ffffffffa039368c>]  [<ffffffffa039368c>] extent_buffer_get+0x4/0xa [btrfs]
     Process btrfs-cache-1 (pid: 2463, threadinfo ffff880112d60000, task ffff880117679730)
    [...]
     Call Trace:
      [<ffffffffa0398a99>] btrfs_search_slot+0x104/0x64d [btrfs]
      [<ffffffffa039aea4>] btrfs_next_old_leaf+0xa7/0x334 [btrfs]
      [<ffffffffa039b141>] btrfs_next_leaf+0x10/0x12 [btrfs]
      [<ffffffffa039ea13>] caching_thread+0x1a3/0x2e0 [btrfs]
      [<ffffffffa03d8811>] worker_loop+0x14b/0x48e [btrfs]
      [<ffffffffa03d86c6>] ? btrfs_queue_worker+0x25c/0x25c [btrfs]
      [<ffffffff81068d3d>] kthread+0x8d/0x95
      [<ffffffff81068cb0>] ? kthread_freezable_should_stop+0x43/0x43
      [<ffffffff8151e5ac>] ret_from_fork+0x7c/0xb0
      [<ffffffff81068cb0>] ? kthread_freezable_should_stop+0x43/0x43
    RIP  [<ffffffffa039368c>] extent_buffer_get+0x4/0xa [btrfs]
    
    We've free'ed commit_root before actually getting to free block groups where
    caching thread needs valid extent_root->commit_root.
    
    Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>

commit a9995eece39a0630ebbfc1ab38570bce6c8a8f5b
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Fri May 31 13:04:36 2013 -0400

    Btrfs: init relocate extent_io_tree with a mapping
    
    Dave reported a NULL pointer deref.  This is caused because he thought he'd be
    smart and add sanity checks to the extent_io bit operations, but he didn't
    expect a tree to have a NULL mapping.  To fix this we just need to init the
    relocation's processed_blocks with the btree_inode->i_mapping.  Thanks,
    
    Reported-by: David Sterba <dsterba@suse.cz>
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>

commit 6379ef9fb2482a92b5fe09f927d6ce1f989c0c6d
Author: Naohiro Aota <naota@elisp.net>
Date:   Thu Jun 6 09:56:34 2013 +0000

    btrfs: Drop inode if inode root is NULL
    
    There is a path where btrfs_drop_inode() is called with its inode's root
    is NULL: In btrfs_new_inode(), when btrfs_set_inode_index() fails,
    iput() is called. We should handle this case before taking look at the
    root->root_item.
    
    Signed-off-by: Naohiro Aota <naota@elisp.net>
    Reviewed-by: Miao Xie <miaox@cn.fujitsu.com>
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>

commit 7b5ff90ed081787ec0765ceb4fe5ccf5677493a6
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Thu Jun 6 10:29:40 2013 -0400

    Btrfs: don't delete fs_roots until after we cleanup the transaction
    
    We get a use after free if we had a transaction to cleanup since there could be
    delayed inodes which refer to their respective fs_root.  Thanks
    
    Reported-by: David Sterba <dsterba@suse.cz>
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>

commit ea7f665612fcc73da6b7698f468cd5fc03a30d47
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Sat Jun 8 02:55:07 2013 +0200

    Revert "ACPI / scan: do not match drivers against objects having scan handlers"
    
    Commit 9f29ab11ddbf ("ACPI / scan: do not match drivers against objects
    having scan handlers") introduced a boot regression on Tony's ia64 HP
    rx2600.  Tony says:
    
      "It panics with the message:
    
       Kernel panic - not syncing: Unable to find SBA IOMMU: Try a generic or DIG kernel
    
       [...] my problem comes from arch/ia64/hp/common/sba_iommu.c
       where the code in sba_init() says:
    
            acpi_bus_register_driver(&acpi_sba_ioc_driver);
            if (!ioc_list) {
    
       but because of this change we never managed to call ioc_init()
       so ioc_list doesn't get set up, and we die."
    
    Revert it to avoid this breakage and we'll fix the problem it attempted
    to address later.
    
    Reported-by: Tony Luck <tony.luck@gmail.com>
    Cc: 3.9+ <stable@vger.kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 9c1fcdccc7ce5611ec1edf45dbbe51b10e333bd3
Author: Doug Anderson <dianders@chromium.org>
Date:   Wed Jun 5 13:56:33 2013 -0700

    ARM: exynos: add debug_ll_io_init() call in exynos_init_io()
    
    If the early MMU mapping of the UART happens to get booted out of the
    TLB between the start of paging_init() and when we finally re-add the
    UART at the very end of s3c_init_cpu(), we'll get a hang at bootup if
    we've got early_printk enabled.  Avoid this hang by calling
    debug_ll_io_init() early.
    
    Without this patch, you can reliably reproduce a hang when early
    printk is enabled by adding flush_tlb_all() at the start of
    exynos_init_io().  After this patch the hang goes away.
    
    Signed-off-by: Doug Anderson <dianders@chromium.org>
    Acked-by: Kukjin Kim <kgene.kim@samsung.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>

commit 437d8ac510b90610da814ae25a7b79aaf3b4910f
Author: Tushar Behera <tushar.behera@linaro.org>
Date:   Tue Jun 4 09:49:10 2013 +0530

    ARM: EXYNOS: uncompress - print debug messages if DEBUG_LL is defined
    
    Printing low-level debug messages make an assumption that the specified
    UART port has been preconfigured by the bootloader. Incorrectly
    specified UART port results in system getting stalled while printing the
    message "Uncompressing Linux... done, booting the kernel"
    This UART port number is specified through S3C_LOWLEVEL_UART_PORT. Since
    the UART port might different for different board, it is not possible to
    specify it correctly for every board that use a common defconfig file.
    
    Calling this print subroutine only when DEBUG_LL fixes the problem. By
    disabling DEBUG_LL in default config file, we would be able to boot
    multiple boards with different default UART ports.
    
    With this current approach, we miss the print "Uncompressing Linux...
    done, booting the kernel." when DEBUG_LL is not defined.
    
    Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
    Signed-off-by: Olof Johansson <olof@lixom.net>

commit 40edeff6e1c6f9a6f16536ae3375e3af9d648449
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Jun 2 11:15:55 2013 +0000

    net_sched: qdisc_get_rtab() must check data[] array
    
    qdisc_get_rtab() should check not only the keys in struct tc_ratespec,
    but also the full data[] array.
    
    "tc ... linklayer atm " only perturbs values in the 256 slots array.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit bcc567e3115055a9cc256183d72864f01286be22
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu May 23 14:29:53 2013 +0300

    dmatest: do not allow to interrupt ongoing tests
    
    When user interrupts ongoing transfers the dmatest may end up with console
    lockup, oops, or data mismatch. This patch prevents user to abort any ongoing
    test.
    
    Documentation is updated accordingly.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reported-by: Will Deacon <will.deacon@arm.com>
    Tested-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>

commit 591bfcfc334a003ba31c0deff03b22e73349939b
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Wed Jun 5 14:09:30 2013 -0700

    hwmon: (adm1021) Strengthen chip detection for ADM1021, LM84 and MAX1617
    
    On a system with both MAX1617 and JC42 sensors, JC42 sensors can be misdetected
    as LM84. Strengthen detection sufficiently enough to avoid this misdetection.
    Also improve detection for ADM1021.
    
    Modeled after chip detection code in sensors-detect command.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Jean Delvare <khali@linux-fr.org>
    Acked-by: Jean Delvare <khali@linux-fr.org>

commit 2894770ec17ff732f911c8495ae0504f06a5dad5
Author: Andreas Irestål <Andreas.Irestal@axis.com>
Date:   Wed Jun 5 08:49:47 2013 +0200

    ASoC: tlv320aic3x: Remove deadlock from snd_soc_dapm_put_volsw_aic3x()
    
    When calling snd_soc_dapm_sync(), it eventually tries to lock the same mutex
    already locked in snd_soc_dapm_put_volsw_aic3x() and a deadlock occurs. By
    moving the mutex unlock to just before snd_soc_dapm_sync(), this deadlock is
    prevented. This problem was introduced in Linux 3.5
    
    Signed-off-by: Andreas Irestål <Andreas.Irestal@axis.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>

commit 7b8dfe289fdde0066be343a3e0271ad6d7b6dbcf
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Jun 7 18:42:00 2013 +0200

    netfilter: nfnetlink_queue: fix missing HW protocol
    
    Locally generated IPv4 and IPv6 traffic gets skb->protocol unset,
    thus passing zero.
    
    ip6tables -I OUTPUT -j NFQUEUE
    libmnl/examples/netfilter# ./nf-queue 0 &
    ping6 ::1
    packet received (id=1 hw=0x0000 hook=3)
                             ^^^^^^
    
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

commit 698b8223631472bf982ed570b0812faa61955683
Author: Dave Chiluk <chiluk@canonical.com>
Date:   Tue May 28 16:06:08 2013 -0500

    ncpfs: fix rmdir returns Device or resource busy
    
    1d2ef5901483004d74947bbf78d5146c24038fe7 caused a regression in ncpfs such that
    directories could no longer be removed.  This was because ncp_rmdir checked
    to see if a dentry could be unhashed before allowing it to be removed. Since
    1d2ef5901483004d74947bbf78d5146c24038fe7 introduced a change that incremented
    dentry->d_count causing it to always be greater than 1 unhash would always
    fail.  Thus causing the error path in ncp_rmdir to always be taken.  Removing
    this error path is safe as unhashing is still accomplished by calls to dput
    from vfs_rmdir.
    
    Signed-off-by: Dave Chiluk <chiluk@canonical.com>
    Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

commit 4616274d3382fa7698536d61b351e63cf0ce27f0
Author: Mark Brown <broonie@linaro.org>
Date:   Wed Jun 5 19:36:11 2013 +0100

    ASoC: dapm: Treat DAI widgets like AIF widgets for power
    
    Even though they are virtual widgets DAI widgets still get counted for the
    DAPM context power management so we can't just use the active state to
    check if they should be powered as they may not be part of a complete path.
    
    Instead split them into input and output widgets and do the same power
    checks as we perform on AIFs.
    
    Reported-by: Stephen Warren <swarren@nvidia.com>
    Tested-by: Stephen Warren <swarren@nvidia.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>

commit 7cd8407d53ef5fb0280fcbe34f42311472f90feb
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Jun 5 14:01:19 2013 +0200

    ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization
    
    Commit b378549 (ACPI / PM: Do not power manage devices in unknown
    initial states) added code to force devices without _PSC, but having
    _PS0 defined in the ACPI namespace, into ACPI power state D0 by
    executing _PS0 for them.  That turned out to break Toshiba P870-303,
    however, so revert that code.
    
    References: https://bugzilla.kernel.org/show_bug.cgi?id=58201
    Reported-and-tested-by: Jerome Cantenot <jerome.cantenot@gmail.com>
    Tracked-down-by: Lan Tianyu <tianyu.lan@intel.com>
    Cc: 3.9+ <stable@vger.kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit 72b5322f11ff0abf6a52b3007486656578d2c982
Author: Lai Jiangshan <laijs@cn.fujitsu.com>
Date:   Mon Jun 3 17:17:15 2013 +0800

    clk: remove notifier from list before freeing it
    
    The @cn is stay in @clk_notifier_list after it is freed, it cause
    memory corruption.
    
    Example, if @clk is registered(first), unregistered(first),
    registered(second), unregistered(second).
    
    The freed @cn will be used when @clk is registered(second),
    and the bug will be happened when @clk is unregistered(second):
    
    [  517.040000] clk_notif_dbg clk_notif_dbg.1: clk_notifier_unregister()
    [  517.040000] Unable to handle kernel paging request at virtual address 00df3008
    [  517.050000] pgd = ed858000
    [  517.050000] [00df3008] *pgd=00000000
    [  517.060000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
    [  517.060000] Modules linked in: clk_notif_dbg(O-) [last unloaded: clk_notif_dbg]
    [  517.060000] CPU: 1 PID: 499 Comm: modprobe Tainted: G           O 3.10.0-rc3-00119-ga93cb29-dirty #85
    [  517.060000] task: ee1e0180 ti: ee3e6000 task.ti: ee3e6000
    [  517.060000] PC is at srcu_readers_seq_idx+0x48/0x84
    [  517.060000] LR is at srcu_readers_seq_idx+0x60/0x84
    [  517.060000] pc : [<c0052720>]    lr : [<c0052738>]    psr: 80070013
    [  517.060000] sp : ee3e7d48  ip : 00000000  fp : ee3e7d6c
    [  517.060000] r10: 00000000  r9 : ee3e6000  r8 : 00000000
    [  517.060000] r7 : ed84fe4c  r6 : c068ec90  r5 : c068e430  r4 : 00000000
    [  517.060000] r3 : 00df3000  r2 : 00000000  r1 : 00000002  r0 : 00000000
    [  517.060000] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
    [  517.060000] Control: 18c5387d  Table: 2d85804a  DAC: 00000015
    [  517.060000] Process modprobe (pid: 499, stack limit = 0xee3e6238)
    [  517.060000] Stack: (0xee3e7d48 to 0xee3e8000)
    ....
    [  517.060000] [<c0052720>] (srcu_readers_seq_idx+0x48/0x84) from [<c0052790>] (try_check_zero+0x34/0xfc)
    [  517.060000] [<c0052790>] (try_check_zero+0x34/0xfc) from [<c00528b0>] (srcu_advance_batches+0x58/0x114)
    [  517.060000] [<c00528b0>] (srcu_advance_batches+0x58/0x114) from [<c0052c30>] (__synchronize_srcu+0x114/0x1ac)
    [  517.060000] [<c0052c30>] (__synchronize_srcu+0x114/0x1ac) from [<c0052d14>] (synchronize_srcu+0x2c/0x34)
    [  517.060000] [<c0052d14>] (synchronize_srcu+0x2c/0x34) from [<c0053a08>] (srcu_notifier_chain_unregister+0x68/0x74)
    [  517.060000] [<c0053a08>] (srcu_notifier_chain_unregister+0x68/0x74) from [<c0375a78>] (clk_notifier_unregister+0x7c/0xc0)
    [  517.060000] [<c0375a78>] (clk_notifier_unregister+0x7c/0xc0) from [<bf008034>] (clk_notif_dbg_remove+0x34/0x9c [clk_notif_dbg])
    [  517.060000] [<bf008034>] (clk_notif_dbg_remove+0x34/0x9c [clk_notif_dbg]) from [<c02bb974>] (platform_drv_remove+0x24/0x28)
    [  517.060000] [<c02bb974>] (platform_drv_remove+0x24/0x28) from [<c02b9bf8>] (__device_release_driver+0x8c/0xd4)
    [  517.060000] [<c02b9bf8>] (__device_release_driver+0x8c/0xd4) from [<c02ba680>] (driver_detach+0x9c/0xc4)
    [  517.060000] [<c02ba680>] (driver_detach+0x9c/0xc4) from [<c02b99c4>] (bus_remove_driver+0xcc/0xfc)
    [  517.060000] [<c02b99c4>] (bus_remove_driver+0xcc/0xfc) from [<c02bace4>] (driver_unregister+0x54/0x78)
    [  517.060000] [<c02bace4>] (driver_unregister+0x54/0x78) from [<c02bbb44>] (platform_driver_unregister+0x1c/0x20)
    [  517.060000] [<c02bbb44>] (platform_driver_unregister+0x1c/0x20) from [<bf0081f8>] (clk_notif_dbg_driver_exit+0x14/0x1c [clk_notif_dbg])
    [  517.060000] [<bf0081f8>] (clk_notif_dbg_driver_exit+0x14/0x1c [clk_notif_dbg]) from [<c00835e4>] (SyS_delete_module+0x200/0x28c)
    [  517.060000] [<c00835e4>] (SyS_delete_module+0x200/0x28c) from [<c000edc0>] (ret_fast_syscall+0x0/0x48)
    [  517.060000] Code: e5973004 e7911102 e0833001 e2881002 (e7933101)
    
    Cc: stable@kernel.org
    Reported-by: Sören Brinkmann <soren.brinkmann@xilinx.com>
    Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
    Tested-by: Sören Brinkmann <soren.brinkmann@xilinx.com>
    Signed-off-by: Mike Turquette <mturquette@linaro.org>
    [mturquette@linaro.org: shortened $SUBJECT]

commit 5f1f3d5088316f827591764aa6a5e7161eb514bd
Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date:   Thu Jun 6 11:21:23 2013 +0200

    arm: mvebu: armada-xp-{gp,openblocks-ax3-4}: specify PCIe range
    
    The ranges DT entry needed by the PCIe controller is defined at the
    SoC .dtsi level. However, some boards have a NOR flash, and to support
    it, they need to override the SoC-level ranges property to add an
    additional range. Since PCIe and NOR support came separately, some
    boards were not properly changed to include the PCIe range in their
    ranges property at the .dts level.
    
    This commit fixes those platforms.
    
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>

commit a7526eb5d06b0084ef12d7b168d008fcf516caab
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Wed Jun 5 19:38:26 2013 +0000

    net: Unbreak compat_sys_{send,recv}msg
    
    I broke them in this commit:
    
        commit 1be374a0518a288147c6a7398792583200a67261
        Author: Andy Lutomirski <luto@amacapital.net>
        Date:   Wed May 22 14:07:44 2013 -0700
    
            net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg
    
    This patch adds __sys_sendmsg and __sys_sendmsg as common helpers that accept
    MSG_CMSG_COMPAT and blocks MSG_CMSG_COMPAT at the syscall entrypoints.  It
    also reverts some unnecessary checks in sys_socketcall.
    
    Apparently I was suffering from underscore blindness the first time around.
    
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Tested-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 4089fe95bfed295c8ad38251d5fe02b6b0ba684c
Author: Nicolas Schichan <nschichan@freebox.fr>
Date:   Thu Jun 6 19:00:46 2013 +0200

    ARM: Kirkwood: handle mv88f6282 cpu in __kirkwood_variant().
    
    MPP_F6281_MASK would be previously be returned when on mv88f6282,
    which would disallow some valid MPP configurations.
    
    Commit 830f8b91 (arm: plat-orion: fix printing of "MPP config
    unavailable on this hardware") made this problem visible as an invalid
    MPP configuration is now correctly detected and not applied.
    
    Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
    Cc: <stable@vger.kernel.org> # v3.9.x
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>

commit f17a5194859a82afe4164e938b92035b86c55794
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Thu May 30 21:10:37 2013 -0400

    tracing: Use current_uid() for critical time tracing
    
    The irqsoff tracer records the max time that interrupts are disabled.
    There are hooks in the assembly code that calls back into the tracer when
    interrupts are disabled or enabled.
    
    When they are enabled, the tracer checks if the amount of time they
    were disabled is larger than the previous recorded max interrupts off
    time. If it is, it creates a snapshot of the currently running trace
    to store where the last largest interrupts off time was held and how
    it happened.
    
    During testing, this RCU lockdep dump appeared:
    
    [ 1257.829021] ===============================
    [ 1257.829021] [ INFO: suspicious RCU usage. ]
    [ 1257.829021] 3.10.0-rc1-test+ #171 Tainted: G        W
    [ 1257.829021] -------------------------------
    [ 1257.829021] /home/rostedt/work/git/linux-trace.git/include/linux/rcupdate.h:780 rcu_read_lock() used illegally while idle!
    [ 1257.829021]
    [ 1257.829021] other info that might help us debug this:
    [ 1257.829021]
    [ 1257.829021]
    [ 1257.829021] RCU used illegally from idle CPU!
    [ 1257.829021] rcu_scheduler_active = 1, debug_locks = 0
    [ 1257.829021] RCU used illegally from extended quiescent state!
    [ 1257.829021] 2 locks held by trace-cmd/4831:
    [ 1257.829021]  #0:  (max_trace_lock){......}, at: [<ffffffff810e2b77>] stop_critical_timing+0x1a3/0x209
    [ 1257.829021]  #1:  (rcu_read_lock){.+.+..}, at: [<ffffffff810dae5a>] __update_max_tr+0x88/0x1ee
    [ 1257.829021]
    [ 1257.829021] stack backtrace:
    [ 1257.829021] CPU: 3 PID: 4831 Comm: trace-cmd Tainted: G        W    3.10.0-rc1-test+ #171
    [ 1257.829021] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
    [ 1257.829021]  0000000000000001 ffff880065f49da8 ffffffff8153dd2b ffff880065f49dd8
    [ 1257.829021]  ffffffff81092a00 ffff88006bd78680 ffff88007add7500 0000000000000003
    [ 1257.829021]  ffff88006bd78680 ffff880065f49e18 ffffffff810daebf ffffffff810dae5a
    [ 1257.829021] Call Trace:
    [ 1257.829021]  [<ffffffff8153dd2b>] dump_stack+0x19/0x1b
    [ 1257.829021]  [<ffffffff81092a00>] lockdep_rcu_suspicious+0x109/0x112
    [ 1257.829021]  [<ffffffff810daebf>] __update_max_tr+0xed/0x1ee
    [ 1257.829021]  [<ffffffff810dae5a>] ? __update_max_tr+0x88/0x1ee
    [ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
    [ 1257.829021]  [<ffffffff810dbf85>] update_max_tr_single+0x11d/0x12d
    [ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
    [ 1257.829021]  [<ffffffff810e2b15>] stop_critical_timing+0x141/0x209
    [ 1257.829021]  [<ffffffff8109569a>] ? trace_hardirqs_on+0xd/0xf
    [ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
    [ 1257.829021]  [<ffffffff810e3057>] time_hardirqs_on+0x2a/0x2f
    [ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
    [ 1257.829021]  [<ffffffff8109550c>] trace_hardirqs_on_caller+0x16/0x197
    [ 1257.829021]  [<ffffffff8109569a>] trace_hardirqs_on+0xd/0xf
    [ 1257.829021]  [<ffffffff811002b9>] user_enter+0xfd/0x107
    [ 1257.829021]  [<ffffffff810029b4>] do_notify_resume+0x92/0x97
    [ 1257.829021]  [<ffffffff8154bdca>] int_signal+0x12/0x17
    
    What happened was entering into the user code, the interrupts were enabled
    and a max interrupts off was recorded. The trace buffer was saved along with
    various information about the task: comm, pid, uid, priority, etc.
    
    The uid is recorded with task_uid(tsk). But this is a macro that uses rcu_read_lock()
    to retrieve the data, and this happened to happen where RCU is blind (user_enter).
    
    As only the preempt and irqs off tracers can have this happen, and they both
    only have the tsk == current, if tsk == current, use current_uid() instead of
    task_uid(), as current_uid() does not use RCU as only current can change its uid.
    
    This fixes the RCU suspicious splat.
    
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

commit 73228a0538a70ebc4547bd09dee8971360dc1d87
Author: Dan Williams <dcbw@redhat.com>
Date:   Wed Jun 5 15:26:27 2013 -0500

    USB: option,zte_ev: move most ZTE CDMA devices to zte_ev
    
    Per some ZTE Linux drivers I found for the AC2716, the following patch
    moves most ZTE CDMA devices from option to zte_ev.  The blacklist stuff
    that option does is not required with zte_ev, because it doesn't
    implement any of the send_setup hooks which the blacklist suppressed.
    
    I did not move the 2718 over because I could not find any ZTE Linux
    drivers for that device, nor even any Windows drivers.
    
    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8a24e6281d37243c06b9497dcbfaa98c1e2ad35
Author: Bjørn Mork <bjorn@mork.no>
Date:   Thu Jun 6 12:57:24 2013 +0200

    USB: option: blacklist network interface on Huawei E1820
    
    The mode used by Windows for the Huawei E1820 will use the
    same ff/ff/ff class codes for both serial and network
    functions.
    
    Reported-by: Graham Inggs <graham.inggs@uct.ac.za>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9eecf22d2b375b9064a20421c6c307b760b03d46
Author: Johan Hovold <jhovold@gmail.com>
Date:   Thu Jun 6 13:32:47 2013 +0200

    USB: whiteheat: fix broken port configuration
    
    When configuring the port (e.g. set_termios) the port minor number
    rather than the port number was used in the request (and they only
    coincide for minor number 0).
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a8aa1939777dd114479677f0044652c1fd72398
Author: Dave Chinner <dchinner@redhat.com>
Date:   Wed Jun 5 12:09:10 2013 +1000

    xfs: increase number of ACL entries for V5 superblocks
    
    The limit of 25 ACL entries is arbitrary, but baked into the on-disk
    format.  For version 5 superblocks, increase it to the maximum nuber
    of ACLs that can fit into a single xattr.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Reviewed-by: Mark Tinguely <tinuguely@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit 5c87d4bc1a86bd6e6754ac3d6e111d776ddcfe57)

commit f763fd440e094be37b38596ee14f1d64caa9bf9c
Author: Dave Chinner <dchinner@redhat.com>
Date:   Wed Jun 5 12:09:09 2013 +1000

    xfs: disable noattr2/attr2 mount options for CRC enabled filesystems
    
    attr2 format is always enabled for v5 superblock filesystems, so the
    mount options to enable or disable it need to be cause mount errors.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit d3eaace84e40bf946129e516dcbd617173c1cf14)

commit ad868afddb908a5d4015c6b7637721b48fb9c8f9
Author: Dave Chinner <dchinner@redhat.com>
Date:   Wed Jun 5 12:09:08 2013 +1000

    xfs: inode unlinked list needs to recalculate the inode CRC
    
    The inode unlinked list manipulations operate directly on the inode
    buffer, and so bypass the inode CRC calculation mechanisms. Hence an
    inode on the unlinked list has an invalid CRC. Fix this by
    recalculating the CRC whenever we modify an unlinked list pointer in
    an inode, ncluding during log recovery. This is trivial to do and
    results in  unlinked list operations always leaving a consistent
    inode in the buffer.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Mark Tinguely <tinguely@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit 0a32c26e720a8b38971d0685976f4a7d63f9e2ef)

commit 75406170751b4de88a01f73dda56efa617ddd5d7
Author: Dave Chinner <dchinner@redhat.com>
Date:   Wed Jun 5 12:09:07 2013 +1000

    xfs: fix log recovery transaction item reordering
    
    There are several constraints that inode allocation and unlink
    logging impose on log recovery. These all stem from the fact that
    inode alloc/unlink are logged in buffers, but all other inode
    changes are logged in inode items. Hence there are ordering
    constraints that recovery must follow to ensure the correct result
    occurs.
    
    As it turns out, this ordering has been working mostly by chance
    than good management. The existing code moves all buffers except
    cancelled buffers to the head of the list, and everything else to
    the tail of the list. The problem with this is that is interleaves
    inode items with the buffer cancellation items, and hence whether
    the inode item in an cancelled buffer gets replayed is essentially
    left to chance.
    
    Further, this ordering causes problems for log recovery when inode
    CRCs are enabled. It typically replays the inode unlink buffer long before
    it replays the inode core changes, and so the CRC recorded in an
    unlink buffer is going to be invalid and hence any attempt to
    validate the inode in the buffer is going to fail. Hence we really
    need to enforce the ordering that the inode alloc/unlink code has
    expected log recovery to have since inode chunk de-allocation was
    introduced back in 2003...
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Mark Tinguely <tinguely@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit a775ad778073d55744ed6709ccede36310638911)

commit ea929536a43226a01d1a73ac8b14d52e81163bd4
Author: Dave Chinner <dchinner@redhat.com>
Date:   Mon Jun 3 15:28:49 2013 +1000

    xfs: fix remote attribute invalidation for a leaf
    
    When invalidating an attribute leaf block block, there might be
    remote attributes that it points to. With the recent rework of the
    remote attribute format, we have to make sure we calculate the
    length of the attribute correctly. We aren't doing that in
    xfs_attr3_leaf_inactive(), so fix it.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Reviewed-by: Mark Tinguely <tinuguely@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit 59913f14dfe8eb772ff93eb442947451b4416329)

commit bb9b8e86ad083ecb2567ae909c1d6cb0bbaa60fe
Author: Dave Chinner <dchinner@redhat.com>
Date:   Mon Jun 3 15:28:46 2013 +1000

    xfs: rework dquot CRCs
    
    Calculating dquot CRCs when the backing buffer is written back just
    doesn't work reliably. There are several places which manipulate
    dquots directly in the buffers, and they don't calculate CRCs
    appropriately, nor do they always set the buffer up to calculate
    CRCs appropriately.
    
    Firstly, if we log a dquot buffer (e.g. during allocation) it gets
    logged without valid CRC, and so on recovery we end up with a dquot
    that is not valid.
    
    Secondly, if we recover/repair a dquot, we don't have a verifier
    attached to the buffer and hence CRCs are not calculated on the way
    down to disk.
    
    Thirdly, calculating the CRC after we've changed the contents means
    that if we re-read the dquot from the buffer, we cannot verify the
    contents of the dquot are valid, as the CRC is invalid.
    
    So, to avoid all the dquot CRC errors that are being detected by the
    read verifier, change to using the same model as for inodes. That
    is, dquot CRCs are calculated and written to the backing buffer at
    the time the dquot is flushed to the backing buffer. If we modify
    the dquot directly in the backing buffer, calculate the CRC
    immediately after the modification is complete. Hence the dquot in
    the on-disk buffer should always have a valid CRC.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit 6fcdc59de28817d1fbf1bd58cc01f4f3fac858fb)

commit a93d8a1cea0899982993e9a93404c6f78b123697
Author: Jean-Philippe Francois <jp.francois@cynove.com>
Date:   Thu Jun 6 08:48:07 2013 -0600

    ARM: omap3: clock: fix wrong container_of in clock36xx.c
    
    omap36xx_pwrdn_clk_enable_with_hsdiv_restore expects the parent hw of
    the clock to be a clk_hw_omap. However, looking at cclock3xxx_data.c,
    all concerned clock have parent defined as clk_divider.  Fix the
    function to use clk_divider.  Tested with 3.9 on dm3730.
    
    Signed-off-by: Jean-Philippe François <jp.francois@cynove.com>
    Cc: NeilBrown <neilb@suse.de>
    Cc: Mike Turquette <mturquette@linaro.org>
    Signed-off-by: Paul Walmsley <paul@pwsan.com>

commit cdfce53986a39daf039b62b69026867734d8430a
Author: John Crispin <blogic@openwrt.org>
Date:   Thu Jun 6 12:55:53 2013 +0000

    MIPS: ralink: add missing SZ_1M multiplier
    
    On RT5350 the memory size is set to Bytes and not MegaBytes due to a missing
    multiplier.
    
    Signed-off-by: John Crispin <blogic@openwrt.org>
    Cc: John Crispin <blogic@openwrt.org>
    Patchwork: https://patchwork.linux-mips.org/patch/5378/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 7b741aa4067b375caa4fce41e292d2f60cf9c98a
Author: Ralf Baechle <ralf@linux-mips.org>
Date:   Wed May 29 00:48:10 2013 +0200

    MIPS: Compat: Fix cputime_to_timeval() arguments in compat binfmt_elf.
    
    cputime_to_timeval() takes a struct timeval *as its second argument but
    a struct compat_timeval * will be passed resulting in:
    
      CC      arch/mips/kernel/binfmt_elfn32.o
    In file included from arch/mips/kernel/binfmt_elfn32.c:122:0:
    arch/mips/kernel/../../../fs/binfmt_elf.c: In function ‘fill_prstatus’:
    arch/mips/kernel/../../../fs/binfmt_elf.c:1330:3: warning: passing argument 2 of ‘cputime_to_timeval’ from incompatible pointer type [enabled by default]
    In file included from include/asm-generic/cputime.h:12:0,
                     from /home/ralf/src/linux/linux-mips/arch/mips/include/asm/cputime.h:4,
                     from include/linux/sched.h:28,
                     from include/linux/ptrace.h:5,
                     from include/uapi/linux/elfcore.h:7,
                     from include/linux/elfcore.h:7,
                     from arch/mips/kernel/binfmt_elfn32.c:55:
    include/asm-generic/cputime_nsecs.h:92:91: note: expected ‘struct timeval *’ but argument is of type ‘struct compat_timeval *’
    In file included from arch/mips/kernel/binfmt_elfn32.c:122:0:
    arch/mips/kernel/../../../fs/binfmt_elf.c:1331:3: warning: passing argument 2 of ‘cputime_to_timeval’ from incompatible pointer type [enabled by default]
    In file included from include/asm-generic/cputime.h:12:0,
                     from /home/ralf/src/linux/linux-mips/arch/mips/include/asm/cputime.h:4,
                     from include/linux/sched.h:28,
                     from include/linux/ptrace.h:5,
                     from include/uapi/linux/elfcore.h:7,
                     from include/linux/elfcore.h:7,
                     from arch/mips/kernel/binfmt_elfn32.c:55:
    include/asm-generic/cputime_nsecs.h:92:91: note: expected ‘struct timeval *’ but argument is of type ‘struct compat_timeval *’
    In file included from arch/mips/kernel/binfmt_elfn32.c:122:0:
    arch/mips/kernel/../../../fs/binfmt_elf.c:1336:3: warning: passing argument 2 of ‘cputime_to_timeval’ from incompatible pointer type [enabled by default]
    In file included from include/asm-generic/cputime.h:12:0,
                     from /home/ralf/src/linux/linux-mips/arch/mips/include/asm/cputime.h:4,
                     from include/linux/sched.h:28,
                     from include/linux/ptrace.h:5,
                     from include/uapi/linux/elfcore.h:7,
                     from include/linux/elfcore.h:7,
                     from arch/mips/kernel/binfmt_elfn32.c:55:
    include/asm-generic/cputime_nsecs.h:92:91: note: expected ‘struct timeval *’ but argument is of type ‘struct compat_timeval *’
    In file included from arch/mips/kernel/binfmt_elfn32.c:122:0:
    arch/mips/kernel/../../../fs/binfmt_elf.c:1337:3: warning: passing argument 2 of ‘cputime_to_timeval’ from incompatible pointer type [enabled by default]
    In file included from include/asm-generic/cputime.h:12:0,
                     from /home/ralf/src/linux/linux-mips/arch/mips/include/asm/cputime.h:4,
                     from include/linux/sched.h:28,
                     from include/linux/ptrace.h:5,
                     from include/uapi/linux/elfcore.h:7,
                     from include/linux/elfcore.h:7,
                     from arch/mips/kernel/binfmt_elfn32.c:55:
    include/asm-generic/cputime_nsecs.h:92:91: note: expected ‘struct timeval *’ but argument is of type ‘struct compat_timeval *’
    In file included from arch/mips/kernel/binfmt_elfn32.c:122:0:
    arch/mips/kernel/../../../fs/binfmt_elf.c:1339:2: warning: passing argument 2 of ‘cputime_to_timeval’ from incompatible pointer type [enabled by default]
    In file included from include/asm-generic/cputime.h:12:0,
                     from /home/ralf/src/linux/linux-mips/arch/mips/include/asm/cputime.h:4,
                     from include/linux/sched.h:28,
                     from include/linux/ptrace.h:5,
                     from include/uapi/linux/elfcore.h:7,
                     from include/linux/elfcore.h:7,
                     from arch/mips/kernel/binfmt_elfn32.c:55:
    include/asm-generic/cputime_nsecs.h:92:91: note: expected ‘struct timeval *’ but argument is of type ‘struct compat_timeval *’
    In file included from arch/mips/kernel/binfmt_elfn32.c:122:0:
    arch/mips/kernel/../../../fs/binfmt_elf.c:1340:2: warning: passing argument 2 of ‘cputime_to_timeval’ from incompatible pointer type [enabled by default]
    In file included from include/asm-generic/cputime.h:12:0,
                     from /home/ralf/src/linux/linux-mips/arch/mips/include/asm/cputime.h:4,
                     from include/linux/sched.h:28,
                     from include/linux/ptrace.h:5,
                     from include/uapi/linux/elfcore.h:7,
                     from include/linux/elfcore.h:7,
                     from arch/mips/kernel/binfmt_elfn32.c:55:
    include/asm-generic/cputime_nsecs.h:92:91: note: expected ‘struct timeval *’ but argument is of type ‘struct compat_timeval *’
      AS      arch/mips/kernel/scall64-n32.o
      CC      arch/mips/kernel/signal_n32.o
      CC      arch/mips/kernel/binfmt_elfo32.o
    In file included from arch/mips/kernel/binfmt_elfo32.c:165:0:
    arch/mips/kernel/../../../fs/binfmt_elf.c: In function ‘fill_prstatus’:
    arch/mips/kernel/../../../fs/binfmt_elf.c:1330:3: warning: passing argument 2 of ‘cputime_to_timeval’ from incompatible pointer type [enabled by default]
    In file included from include/asm-generic/cputime.h:12:0,
                     from /home/ralf/src/linux/linux-mips/arch/mips/include/asm/cputime.h:4,
                     from include/linux/sched.h:28,
                     from include/linux/ptrace.h:5,
                     from include/uapi/linux/elfcore.h:7,
                     from include/linux/elfcore.h:7,
                     from arch/mips/kernel/binfmt_elfo32.c:78:
    include/asm-generic/cputime_nsecs.h:92:91: note: expected ‘struct timeval *’ but argument is of type ‘struct compat_timeval *’
    In file included from arch/mips/kernel/binfmt_elfo32.c:165:0:
    arch/mips/kernel/../../../fs/binfmt_elf.c:1331:3: warning: passing argument 2 of ‘cputime_to_timeval’ from incompatible pointer type [enabled by default]
    In file included from include/asm-generic/cputime.h:12:0,
                     from /home/ralf/src/linux/linux-mips/arch/mips/include/asm/cputime.h:4,
                     from include/linux/sched.h:28,
                     from include/linux/ptrace.h:5,
                     from include/uapi/linux/elfcore.h:7,
                     from include/linux/elfcore.h:7,
                     from arch/mips/kernel/binfmt_elfo32.c:78:
    include/asm-generic/cputime_nsecs.h:92:91: note: expected ‘struct timeval *’ but argument is of type ‘struct compat_timeval *’
    In file included from arch/mips/kernel/binfmt_elfo32.c:165:0:
    arch/mips/kernel/../../../fs/binfmt_elf.c:1336:3: warning: passing argument 2 of ‘cputime_to_timeval’ from incompatible pointer type [enabled by default]
    In file included from include/asm-generic/cputime.h:12:0,
                     from /home/ralf/src/linux/linux-mips/arch/mips/include/asm/cputime.h:4,
                     from include/linux/sched.h:28,
                     from include/linux/ptrace.h:5,
                     from include/uapi/linux/elfcore.h:7,
                     from include/linux/elfcore.h:7,
                     from arch/mips/kernel/binfmt_elfo32.c:78:
    include/asm-generic/cputime_nsecs.h:92:91: note: expected ‘struct timeval *’ but argument is of type ‘struct compat_timeval *’
    In file included from arch/mips/kernel/binfmt_elfo32.c:165:0:
    arch/mips/kernel/../../../fs/binfmt_elf.c:1337:3: warning: passing argument 2 of ‘cputime_to_timeval’ from incompatible pointer type [enabled by default]
    In file included from include/asm-generic/cputime.h:12:0,
                     from /home/ralf/src/linux/linux-mips/arch/mips/include/asm/cputime.h:4,
                     from include/linux/sched.h:28,
                     from include/linux/ptrace.h:5,
                     from include/uapi/linux/elfcore.h:7,
                     from include/linux/elfcore.h:7,
                     from arch/mips/kernel/binfmt_elfo32.c:78:
    include/asm-generic/cputime_nsecs.h:92:91: note: expected ‘struct timeval *’ but argument is of type ‘struct compat_timeval *’
    In file included from arch/mips/kernel/binfmt_elfo32.c:165:0:
    arch/mips/kernel/../../../fs/binfmt_elf.c:1339:2: warning: passing argument 2 of ‘cputime_to_timeval’ from incompatible pointer type [enabled by default]
    In file included from include/asm-generic/cputime.h:12:0,
                     from /home/ralf/src/linux/linux-mips/arch/mips/include/asm/cputime.h:4,
                     from include/linux/sched.h:28,
                     from include/linux/ptrace.h:5,
                     from include/uapi/linux/elfcore.h:7,
                     from include/linux/elfcore.h:7,
                     from arch/mips/kernel/binfmt_elfo32.c:78:
    include/asm-generic/cputime_nsecs.h:92:91: note: expected ‘struct timeval *’ but argument is of type ‘struct compat_timeval *’
    In file included from arch/mips/kernel/binfmt_elfo32.c:165:0:
    arch/mips/kernel/../../../fs/binfmt_elf.c:1340:2: warning: passing argument 2 of ‘cputime_to_timeval’ from incompatible pointer type [enabled by default]
    In file included from include/asm-generic/cputime.h:12:0,
                     from /home/ralf/src/linux/linux-mips/arch/mips/include/asm/cputime.h:4,
                     from include/linux/sched.h:28,
                     from include/linux/ptrace.h:5,
                     from include/uapi/linux/elfcore.h:7,
                     from include/linux/elfcore.h:7,
                     from arch/mips/kernel/binfmt_elfo32.c:78:
    include/asm-generic/cputime_nsecs.h:92:91: note: expected ‘struct timeval *’ but argument is of type ‘struct compat_timeval *’
    
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 38c3c0f6733bec1d1841915a9a82d2c324362686
Author: David Daney <david.daney@cavium.com>
Date:   Fri May 24 16:23:02 2013 +0000

    MIPS: OCTEON: Improve _machine_halt implementation.
    
    As noted by Wladislav Wiebe:
       $ halt
       ..
       Sent SIGKILL to all processes
       Requesting system halt
       [66.729373] System halted.
       [66.733244]
       [66.734761] =====================================
       [66.739473] [ BUG: lock held at task exit time! ]
       [66.744188] 3.8.7-0-sampleversion-fct #49 Tainted: G           O
       [66.750202] -------------------------------------
       [66.754913] init/21479 is exiting with locks still held!
       [66.760234] 1 lock held by init/21479:
       [66.763990]  #0:  (reboot_mutex){+.+...}, at: [<ffffffff801776c8>] SyS_reboot+0xe0/0x218
       [66.772165]
       [66.772165] stack backtrace:
       [66.776532] Call Trace:
       [66.778992] [<ffffffff805780a8>] dump_stack+0x8/0x34
       [66.783972] [<ffffffff801618b0>] do_exit+0x610/0xa70
       [66.788948] [<ffffffff801777a8>] SyS_reboot+0x1c0/0x218
       [66.794186] [<ffffffff8013d6a4>] handle_sys64+0x44/0x64
    
    This is an alternative fix to the one sent by Wladislav.  We kill the
    watchdog for each CPU and then spin in WAIT with interrupts disabled.
    This is the lowest power mode for the OCTEON.  If we were to spin with
    interrupts enabled, we would get a continual stream of warning messages
    and backtraces from the lockup detector, so I chose to disable
    interrupts.
    
    Signed-off-by: David Daney <david.daney@cavium.com>
    Cc: Maxim Uvarov <muvarov@gmail.com>
    Cc: Wladislav Wiebe <wladislav.kw@gmail.com>
    Cc: linux-mips@linux-mips.org
    Cc: David Daney <david.daney@cavium.com>
    Patchwork: https://patchwork.linux-mips.org/patch/5324/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 406b5ee22215554a37760b6fa807da6ad4d52f52
Author: Yoichi Yuasa <yuasa@linux-mips.org>
Date:   Tue May 28 01:23:22 2013 +0000

    MIPS: rtlx: Fix implicit declaration of function set_vi_handler()
    
    arch/mips/kernel/rtlx.c: In function 'rtlx_module_init':
    arch/mips/kernel/rtlx.c:523:3: error: implicit declaration of function 'set_vi_handler' [-Werror=implicit-function-declaration]
    
    Signed-off-by: Yoichi Yuasa <yuasa@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/5340/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit d3bf073aa7d50f06f81b4065a39fd6dc046f8bb2
Author: Matthias Kaehlcke <matthias.list@kaehlcke.net>
Date:   Wed Jun 5 22:42:51 2013 -0700

    Input: cyttsp - fix swapped mfg_stat and mfg_cmd registers
    
    The command and status register in the driver were swapped with
    respect to the order specified in the datasheet (CY8CTMA140).
    Confirmed with Cypress that the order in the datasheet is correct.
    
    Signed-off-by: Matthias Kaehlcke <matthias@kaehlcke.net>
    Acked-by: Javier Martinez Canillas <javier@dowhile0.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

commit fbd5e77e65c36d84dbcd71a19c4d1526f4604bdb
Author: Ferruh Yigit <fery@cypress.com>
Date:   Thu May 23 10:04:36 2013 -0700

    Input: cyttsp - add missing handshake
    
    For the devices that has blocking with timeout communication, these
    extra handshakes will prevent one timeout delay in startup sequence
    
    Tested-by: Ferruh Yigit <fery@cypress.com> on TMA300-DVK
    Signed-off-by: Ferruh Yigit <fery@cypress.com>
    Acked-by: Javier Martinez Canillas <javier@dowhile0.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

commit d2983cdb480157f637df07723f28aaa657b1080d
Author: Ferruh Yigit <fery@cypress.com>
Date:   Thu May 23 09:56:55 2013 -0700

    Input: cyttsp - fix memcpy size param
    
    memcpy param is wrong because of offset in bl_cmd, this may corrupt the
    stack which may cause a crash.
    
    Tested-by: Ferruh Yigit <fery@cypress.com> on TMA300-DVK
    Signed-off-by: Ferruh Yigit <fery@cypress.com>
    Acked-by: Javier Martinez Canillas <javier@dowhile0.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

commit 29eb77825cc7da8d45b642de2de3d423dc8a363f
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Jun 5 12:26:50 2013 +0200

    arch, mm: Remove tlb_fast_mode()
    
    Since the introduction of preemptible mmu_gather TLB fast mode has been
    broken. TLB fast mode relies on there being absolutely no concurrency;
    it frees pages first and invalidates TLBs later.
    
    However now we can get concurrency and stuff goes *bang*.
    
    This patch removes all tlb_fast_mode() code; it was found the better
    option vs trying to patch the hole by entangling tlb invalidation with
    the scheduler.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: Tony Luck <tony.luck@intel.com>
    Reported-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 509eb76ebf9771abc9fe51859382df2571f11447
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Jun 5 11:20:33 2013 +0100

    ARM: 7747/1: pcpu: ensure __my_cpu_offset cannot be re-ordered across barrier()
    
    __my_cpu_offset is non-volatile, since we want its value to be cached
    when we access several per-cpu variables in a row with preemption
    disabled. This means that we rely on preempt_{en,dis}able to hazard
    with the operation via the barrier() macro, so that we can't end up
    migrating CPUs without reloading the per-cpu offset.
    
    Unfortunately, GCC doesn't treat a "memory" clobber on a non-volatile
    asm block as a side-effect, and will happily re-order it before other
    memory clobbers (including those in prempt_disable()) and cache the
    value. This has been observed to break the cmpxchg logic in the slub
    allocator, leading to livelock in kmem_cache_alloc in mainline kernels.
    
    This patch adds a dummy memory input operand to __my_cpu_offset,
    forcing it to be ordered with respect to the barrier() macro.
    
    Cc: <stable@vger.kernel.org>
    Cc: Rob Herring <rob.herring@calxeda.com>
    Reviewed-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit ced2a3b84965f1be8b6a142d6029faf241f109af
Author: Marc C <marc.ceeeee@gmail.com>
Date:   Wed Jun 5 22:02:23 2013 +0100

    ARM: 7750/1: update legacy CPU ID in decompressor cache support jump table
    
    The previous mask values for the legacy ARM CPU IDs were conflicting
    with the CPU ID assignments for late-generation CPUs (like the
    Qualcomm MSM/QSD or Broadcom Brahma-15 processors). This change
    corrects the legacy ARM CPU ID value so that the jump table can
    fall-through to the appropriate cache maintenance / MMU functions.
    
    Signed-off-by: Marc C <marc.ceeeee@gmail.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit da94a829305f1c217cfdf6771cb1faca0917e3b9
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri May 31 22:50:47 2013 +0100

    ARM: 7743/1: compressed/head.S: work around new binutils warning
    
    In August 2012, Matthew Gretton-Dann checked a change into binutils
    labelled "Error on obsolete & warn on deprecated registers", apparently as
    part of ARMv8 support. Apparently, this was supposed to emit the message
    "Warning: This coprocessor register access is deprecated in ARMv8" when
    using certain mcr/mrc instructions and building for ARMv8. Unfortunately,
    the message that is actually emitted appears to be '(null)', which is
    less helpful in comparison.
    
    Even more unfortunately, this is biting us on every single kernel
    build with a new gas, because arch/arm/boot/compressed/head.S and some
    other files in that directory are built with -march=all since kernel
    commit 80cec14a8 "[ARM] Add -march=all to assembly file build in
    arch/arm/boot/compressed" back in v2.6.28.
    
    This patch reverts Russell's nice solution and instead marks the head.S
    file to be built for armv7-a, which fortunately lets us build all
    instructions in that file without warnings even on the broken binutils.
    
    Without this patch, building anything results in:
    
    arch/arm/boot/compressed/head.S: Assembler messages:
    arch/arm/boot/compressed/head.S:565: Warning: (null)
    arch/arm/boot/compressed/head.S:676: Warning: (null)
    arch/arm/boot/compressed/head.S:698: Warning: (null)
    arch/arm/boot/compressed/head.S:722: Warning: (null)
    arch/arm/boot/compressed/head.S:726: Warning: (null)
    arch/arm/boot/compressed/head.S:957: Warning: (null)
    arch/arm/boot/compressed/head.S:996: Warning: (null)
    arch/arm/boot/compressed/head.S:997: Warning: (null)
    arch/arm/boot/compressed/head.S:1027: Warning: (null)
    arch/arm/boot/compressed/head.S:1035: Warning: (null)
    arch/arm/boot/compressed/head.S:1046: Warning: (null)
    arch/arm/boot/compressed/head.S:1060: Warning: (null)
    arch/arm/boot/compressed/head.S:1092: Warning: (null)
    arch/arm/boot/compressed/head.S:1094: Warning: (null)
    arch/arm/boot/compressed/head.S:1095: Warning: (null)
    arch/arm/boot/compressed/head.S:1102: Warning: (null)
    arch/arm/boot/compressed/head.S:1134: Warning: (null)
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: stable@vger.kernel.org
    Cc: Matthew Gretton-Dann <matthew.gretton-dann@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit 92bdd3f5eba299b33c2f4407977d6fa2e2a6a0da
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri May 31 22:49:22 2013 +0100

    ARM: 7742/1: topology: export cpu_topology
    
    The cpu_topology symbol is required by any driver using the topology
    interfaces, which leads to a couple of build errors:
    
    ERROR: "cpu_topology" [drivers/net/ethernet/sfc/sfc.ko] undefined!
    ERROR: "cpu_topology" [drivers/cpufreq/arm_big_little.ko] undefined!
    ERROR: "cpu_topology" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
    
    The obvious solution is to export this symbol.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Cc: stable@vger.kernel.org
    Cc: Nicolas Pitre <nico@linaro.org>
    Cc: Vincent Guittot <vincent.guittot@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit 275236797916924103e133e3d7a7ea777c951273
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
Date:   Wed May 29 16:57:30 2013 +0100

    ARM: 7737/1: fix kernel decompressor compilation error with CONFIG_DEBUG_SEMIHOSTING
    
    Selecting this option produces:
    
      AS      arch/arm/boot/compressed/debug.o
    arch/arm/boot/compressed/debug.S:4:33: fatal error: mach/debug-macro.S: No such file or directory
    compilation terminated.
    make[3]: *** [arch/arm/boot/compressed/debug.o] Error 1
    
    The semihosting support cannot be modelled into a senduart macro as
    it requires memory space for argument passing.  So the
    CONFIG_DEBUG_LL_INCLUDE may not have any sensible value and the include
    directive should be omitted.
    
    While at it, let's add proper semihosting output support to the
    decompressor.
    
    Signed-off-by: Nicolas Pitre <nico@linaro.org>
    Acked-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit 65694c5aaddfedd9da082e4e150cafc6b3fc8a6a
Author: Matt Fleming <matt.fleming@intel.com>
Date:   Wed Jun 5 15:15:41 2013 +0100

    x86/PCI: Map PCI setup data with ioremap() so it can be in highmem
    
    f9a37be0f0 ("x86: Use PCI setup data") added support for using PCI ROM
    images from setup_data.  This used phys_to_virt(), which is not valid for
    highmem addresses, and can cause a crash when booting a 32-bit kernel via
    the EFI boot stub.
    
    pcibios_add_device() assumes that the physical addresses stored in
    setup_data are accessible via the direct kernel mapping, and that calling
    phys_to_virt() is valid.  This isn't guaranteed to be true on x86 where the
    direct mapping range is much smaller than on x86-64.
    
    Calling phys_to_virt() on a highmem address results in the following:
    
     BUG: unable to handle kernel paging request at 39a3c198
     IP: [<c262be0f>] pcibios_add_device+0x2f/0x90
     ...
     Call Trace:
      [<c2370c73>] pci_device_add+0xe3/0x130
      [<c274640b>] pci_scan_single_device+0x8b/0xb0
      [<c2370d08>] pci_scan_slot+0x48/0x100
      [<c2371904>] pci_scan_child_bus+0x24/0xc0
      [<c262a7b0>] pci_acpi_scan_root+0x2c0/0x490
      [<c23b7203>] acpi_pci_root_add+0x312/0x42f
      ...
    
    The solution is to use ioremap() instead of phys_to_virt() to map the
    setup data into the kernel address space.
    
    [bhelgaas: changelog]
    Tested-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Cc: Seth Forshee <seth.forshee@canonical.com>
    Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
    Cc: stable@vger.kernel.org	# v3.8+

commit 98f6d1a6681b9398968f9fe5e016d19c259b04c2
Author: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
Date:   Wed Jun 5 15:51:57 2013 +0200

    s390/sclp: fix new line detection
    
    When printing multi-line text using sclp_print, line endings are not
    correctly handled. The routine is expecting an EBCDIC new line character
    as line terminator while the input text is encoded in ASCII format.
    
    Fix this problem by modifying sclp_print to scan for ASCII new line
    characters.
    
    Signed-off-by: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit a8f6e7f7953d1baa05a346bf7cee44f1d022c63d
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Wed Jun 5 09:25:34 2013 +0200

    s390/pgtable: make pgste lock an explicit barrier
    
    Getting and Releasing the pgste lock has lock semantics. Make the
    code an explicit barrier.
    
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit 3a82603be4f5523ce21dd468a323aa36ff845f6d
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Wed Jun 5 09:22:33 2013 +0200

    s390/pgtable: Save pgste during modify_prot_start/commit
    
    In modify_prot_start we update the pgste value but never store it back
    into the original location. Lets save the calculated result, since
    modify_prot_commit will use the value of the pgste.
    
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit 9cc5c206d9b44b7763aab3082a5be72c78a3ef7a
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Tue Jun 4 11:00:08 2013 +0200

    s390/dumpstack: fix address ranges for asynchronous and panic stack
    
    git commit dc7ee00d4771b321 "s390: lowcore stack pointer offsets"
    introduced a regression in regard to show_stack(). The stack pointer
    for the asynchronous and the panic stack in the lowcore now have an
    additional offset applied to them. This offset needs to be taken into
    account in the calculation for the low and high address for the stacks.
    
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit 338679f7ba4a81906b3fdfa6507824fdf704be80
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Tue Jun 4 09:53:59 2013 +0200

    s390/pgtable: Fix guest overindication for change bit
    
    When doing the transition invalid->valid in the host page table for
    a guest, then the guest view of C/R is in the pgste. After validation
    the view is pgste OR real key. We must zero out the real key C/R to
    avoid guest over-indication for change (and reference).
    
    Touching the real key is ok also for the host: The change bit is
    tracked via write protection and the reference bit is also ok
    because set_pte_at was called and  the page will be touched anyway
    soon. Furthermore architecture defines reference as "substantially
    accurate", over- and underindication are ok.
    
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit f4488035abdac56682153aa0cff3d1dce84e1c54
Author: Johan Hovold <jhovold@gmail.com>
Date:   Wed Jun 5 12:21:11 2013 +0200

    USB: serial: fix TIOCMIWAIT return value
    
    Fix regression introduced by commit 143d9d9616 ("USB: serial: add
    tiocmiwait subdriver operation") which made the ioctl operation return
    ENODEV rather than ENOIOCTLCMD when a subdriver TIOCMIWAIT
    implementation is missing.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a6aa279d3d17af73a029fa40654e92f4e75e8bb
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
Date:   Wed Jun 5 08:54:16 2013 -0600

    vfio: fix crash on rmmod
    
    devtmpfs_delete_node() calls devnode() callback with mode==NULL but
    vfio still tries to write there.
    
    The patch fixes this.
    
    Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>

commit ee4b7c7fe0c50b97d074f9185dba9558d9440c21
Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date:   Wed Jun 5 14:51:30 2013 +0100

    ASoC: arizona: Correct AEC loopback enable
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>

commit 409b545ac10d9548929557a75ad86540f59a2c83
Author: Phil Oester <kernel@linuxace.com>
Date:   Tue Jun 4 05:09:27 2013 +0000

    netfilter: xt_TCPMSS: Fix violation of RFC879 in absence of MSS option
    
    The clamp-mss-to-pmtu option of the xt_TCPMSS target can cause issues
    connecting to websites if there was no MSS option present in the
    original SYN packet from the client. In these cases, it may add a
    MSS higher than the default specified in RFC879. Fix this by never
    setting a value > 536 if no MSS option was specified by the client.
    
    This closes netfilter's bugzilla #662.
    
    Signed-off-by: Phil Oester <kernel@linuxace.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

commit 0ca684365547cd5f214b5739568dae3df5d6cec9
Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Date:   Mon Feb 25 18:22:37 2013 +0100

    cpufreq: cpufreq-cpu0: use the exact frequency for clk_set_rate()
    
    clk_set_rate() isn't supposed to accept approximate frequencies, instead
    a supported frequency should be obtained from clk_round_rate() and then
    used to set the clock.
    
    Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
    Acked-by: Shawn Guo <shawn.guo@linaro.org>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit 2f7021a815f20f3481c10884fe9735ce2a56db35
Author: Michael Wang <wangyun@linux.vnet.ibm.com>
Date:   Wed Jun 5 08:49:37 2013 +0000

    cpufreq: protect 'policy->cpus' from offlining during __gov_queue_work()
    
    Jiri Kosina <jkosina@suse.cz> and Borislav Petkov <bp@alien8.de>
    reported the warning:
    
    [   51.616759] ------------[ cut here ]------------
    [   51.621460] WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule+0x58/0x60()
    [   51.629638] Modules linked in: ext2 vfat fat loop snd_hda_codec_hdmi usbhid snd_hda_codec_realtek coretemp kvm_intel kvm snd_hda_intel snd_hda_codec crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hwdep snd_pcm aesni_intel sb_edac aes_x86_64 ehci_pci snd_page_alloc glue_helper snd_timer xhci_hcd snd iTCO_wdt iTCO_vendor_support ehci_hcd edac_core lpc_ich acpi_cpufreq lrw gf128mul ablk_helper cryptd mperf usbcore usb_common soundcore mfd_core dcdbas evdev pcspkr processor i2c_i801 button microcode
    [   51.675581] CPU: 0 PID: 244 Comm: kworker/1:1 Tainted: G        W    3.10.0-rc1+ #10
    [   51.683407] Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A08 01/24/2013
    [   51.690901] Workqueue: events od_dbs_timer
    [   51.695069]  0000000000000009 ffff88043a2f5b68 ffffffff8161441c ffff88043a2f5ba8
    [   51.702602]  ffffffff8103e540 0000000000000033 0000000000000001 ffff88043d5f8000
    [   51.710136]  00000000ffff0ce1 0000000000000001 ffff88044fc4fc08 ffff88043a2f5bb8
    [   51.717691] Call Trace:
    [   51.720191]  [<ffffffff8161441c>] dump_stack+0x19/0x1b
    [   51.725396]  [<ffffffff8103e540>] warn_slowpath_common+0x70/0xa0
    [   51.731473]  [<ffffffff8103e58a>] warn_slowpath_null+0x1a/0x20
    [   51.737378]  [<ffffffff81025628>] native_smp_send_reschedule+0x58/0x60
    [   51.744013]  [<ffffffff81072cfd>] wake_up_nohz_cpu+0x2d/0xa0
    [   51.749745]  [<ffffffff8104f6bf>] add_timer_on+0x8f/0x110
    [   51.755214]  [<ffffffff8105f6fe>] __queue_delayed_work+0x16e/0x1a0
    [   51.761470]  [<ffffffff8105f251>] ? try_to_grab_pending+0xd1/0x1a0
    [   51.767724]  [<ffffffff8105f78a>] mod_delayed_work_on+0x5a/0xa0
    [   51.773719]  [<ffffffff814f6b5d>] gov_queue_work+0x4d/0xc0
    [   51.779271]  [<ffffffff814f60cb>] od_dbs_timer+0xcb/0x170
    [   51.784734]  [<ffffffff8105e75d>] process_one_work+0x1fd/0x540
    [   51.790634]  [<ffffffff8105e6f2>] ? process_one_work+0x192/0x540
    [   51.796711]  [<ffffffff8105ef22>] worker_thread+0x122/0x380
    [   51.802350]  [<ffffffff8105ee00>] ? rescuer_thread+0x320/0x320
    [   51.808264]  [<ffffffff8106634a>] kthread+0xea/0xf0
    [   51.813200]  [<ffffffff81066260>] ? flush_kthread_worker+0x150/0x150
    [   51.819644]  [<ffffffff81623d5c>] ret_from_fork+0x7c/0xb0
    [   51.918165] nouveau E[     DRM] GPU lockup - switching to software fbcon
    [   51.930505]  [<ffffffff81066260>] ? flush_kthread_worker+0x150/0x150
    [   51.936994] ---[ end trace f419538ada83b5c5 ]---
    
    It was caused by the policy->cpus changed during the process of
    __gov_queue_work(), in other word, cpu offline happened.
    
    Use get/put_online_cpus() to prevent the offline from happening while
    __gov_queue_work() is running.
    
    [rjw: The problem has been present since recent commit 031299b
    (cpufreq: governors: Avoid unnecessary per cpu timer interrupts)]
    
    References: https://lkml.org/lkml/2013/6/5/88
    Reported-by: Borislav Petkov <bp@alien8.de>
    Reported-and-tested-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit 9f29ab11ddbfc12db54df5a66dab22b39ad94e8e
Author: Aaron Lu <aaron.lu@intel.com>
Date:   Tue Jun 4 23:02:58 2013 +0200

    ACPI / scan: do not match drivers against objects having scan handlers
    
    With the introduction of ACPI scan handlers, an ACPI device object
    with an ACPI scan handler attached to it must not be bound to an ACPI
    driver any more.  Therefore it doesn't make sense to match those
    ACPI device objects against a newly registered ACPI driver in
    acpi_bus_match(), so make that function return 0 if the device
    object passed to it has an ACPI scan handler attached.
    
    This also addresses a regression related to a broken ACPI table in
    the BIOS, where it has defined a _ROM method under the PCI root
    bridge object.  This causes the video module to treat that object
    as a display controller device (since only display devices are
    supposed to have a _ROM method defined according to the ACPI spec).
    As a result, the ACPI video driver binds to the PCI root bridge
    object and overwrites the previously assigned driver_data field of
    it, causing subsequent calls to acpi_get_pci_dev() to fail.
    
    [rjw: Subject and changelog]
    References: https://bugzilla.kernel.org/show_bug.cgi?id=58091
    Reported-by: Jason Cassell <bluesloth600@gmail.com>
    Reported-and-bisected-by: Dmitry S. Demin <dmitryy.demin@gmail.com>
    Cc: 3.9+ <stable@kernel.org>
    Signed-off-by: Aaron Lu <aaron.lu@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit a98d4f64a20b2b88697e7e08c871144a7e3f0ec4
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Mon Jun 3 02:08:39 2013 +0000

    ACPI / APEI: fix error return code in ghes_probe()
    
    Fix to return a negative error code in the acpi_gsi_to_irq() and
    request_irq() error handling case instead of 0, as done elsewhere
    in this function.
    
    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Reviewed-by: Huang Ying <ying.huang@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit 8673b83bf2f013379453b4779047bf3c6ae387e4
Author: Ross Lagerwall <rosslagerwall@gmail.com>
Date:   Fri May 31 20:45:17 2013 +0100

    acpi-cpufreq: set current frequency based on target P-State
    
    Commit 4b31e774 (Always set P-state on initialization) fixed bug
    #4634 and caused the driver to always set the target P-State at
    least once since the initial P-State may not be the desired one.
    Commit 5a1c0228 (cpufreq: Avoid calling cpufreq driver's target()
    routine if target_freq == policy->cur) caused a regression in
    this behavior.
    
    This fixes the regression by setting policy->cur based on the CPU's
    target frequency rather than the CPU's current reported frequency
    (which may be different).  This means that the P-State will be set
    initially if the CPU's target frequency is different from the
    governor's target frequency.
    
    This fixes an issue where setting the default governor to
    performance wouldn't correctly enable turbo mode on all cores.
    
    Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com>
    Reviewed-by: Len Brown <len.brown@intel.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Cc: 3.8+ <stable@vger.kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit 37bc4f8dfa72fb43b84381abca39cfdbbc8ff2df
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Sat Jun 1 15:36:02 2013 +0200

    netfilter: nfnetlink_cttimeout: fix incomplete dumping of objects
    
    Fix broken incomplete object dumping if the list of objects does not
    fit into one single netlink message.
    
    Reported-by: Gabriel Lazar <Gabriel.Lazar@com.utcluj.ro>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

commit 991a6b735ff47710769545b11e481bb140b2e6f7
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Sat Jun 1 15:31:40 2013 +0200

    netfilter: nfnetlink_acct: fix incomplete dumping of objects
    
    Fix broken incomplete object dumping if the list of objects does not
    fit into one single netlink message.
    
    Reported-by: Gabriel Lazar <Gabriel.Lazar@com.utcluj.ro>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

commit 066a1a5fca0e188c41636d0874ab7495f24f595b
Author: James Hogan <james.hogan@imgtec.com>
Date:   Wed May 22 12:29:22 2013 +0100

    KVM: add kvm_para_available to asm-generic/kvm_para.h
    
    According to include/uapi/linux/kvm_para.h architectures should define
    kvm_para_available, so add an implementation to asm-generic/kvm_para.h
    which just returns false.
    
    This fixes intel8x0.c build failure on mips with KVM enabled.
    
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: Gleb Natapov <gleb@redhat.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Gleb Natapov <gleb@redhat.com>

commit 68be0b1ae355c6deb11326df6758f80154f44cf0
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Jun 3 23:57:37 2013 +0200

    crypto: sahara - fix building as module
    
    The sahara crypto driver has an incorrect MODULE_DEVICE_TABLE, which
    prevents us from actually building this driver as a loadable module.
    
    sahara_dt_ids is a of_device_id array, so we have to use
    MODULE_DEVICE_TABLE(of, ...).
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Javier Martin <javier.martin@vista-silicon.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

commit edb7c7cdba90c3fb2339e51c15d21982bdf72fdc
Author: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Date:   Sun Jun 2 19:51:52 2013 +0300

    crypto: blowfish - disable AVX2 implementation
    
    It appears that the performance of 'vpgatherdd' is suboptimal for this kind of
    workload (tested on Core i5-4570) and causes blowfish-avx2 to be significantly
    slower than blowfish-amd64. So disable the AVX2 implementation to avoid
    performance regressions.
    
    Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

commit 3ef91f21a66826cf1003bb7b3c51ac2de4c28182
Author: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Date:   Sun Jun 2 19:51:47 2013 +0300

    crypto: twofish - disable AVX2 implementation
    
    It appears that the performance of 'vpgatherdd' is suboptimal for this kind of
    workload (tested on Core i5-4570) and causes twofish_avx2 to be significantly
    slower than twofish_avx. So disable the AVX2 implementation to avoid
    performance regressions.
    
    Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

commit bc5abcf7e411b889f73ea2a90439071a0f451011
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Tue Jun 4 10:24:56 2013 -0700

    eCryptfs: Check return of filemap_write_and_wait during fsync
    
    Error out of ecryptfs_fsync() if filemap_write_and_wait() fails.
    
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Cc: Paul Taysom <taysom@chromium.org>
    Cc: Olof Johansson <olofj@chromium.org>
    Cc: stable@vger.kernel.org # v3.6+

commit 11e7064f35bb87da8f427d1aa4bbd8b7473a3993
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jun 5 08:35:26 2013 +0200

    ALSA: usb-audio - Fix invalid volume resolution on Logitech HD webcam c270
    
    USB audio driver spews an error message when probing Logitech HD
    webcam c270:
      ALSA mixer.c:1300 usb_audio: Warning! Unlikely big volume range (=6144), cval->res is probably wrong.
      ALSA mixer.c:1304 usb_audio: [5] FU [Mic Capture Volume] ch = 1, val = 1536/7680/1
    
    Obviously the device needs a fixed volume resolution (cval->res = 384)
    like other Logitech devices.
    
    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=821735
    
    Reported-and-tested-by: Cristian Rodríguez <crrodriguez@opensuse.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit d40ee48acde16894fb3b241d7e896d5fa84e0f10
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Mon Jun 3 16:40:14 2013 +1000

    drm/nv50/kms: use dac loadval from vbios, where it's available
    
    Regression from merging the old nv50/nvd9 code together, and may be
    needed to fully fix fdo#64904.
    
    The value is ignored completely by the hardware starting from nva3.
    
    Reported-by: Emil Velikov <emil.l.velikov@gmail.com>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

commit ea9197cc323839ef3d5280c0453b2c622caa6bc7
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Mon Jun 3 16:07:06 2013 +1000

    drm/nv50/disp: force dac power state during load detect
    
    fdo#64904
    
    Reported-by: Gerhard Bräunlich <wippbox@gmx.net>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

commit 89e033a4bc688bc6631c6de8b66d7f26f8e0652b
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Mon Jun 3 15:43:30 2013 +1000

    drm/nv50-nv84/fifo: fix resume regression introduced by playlist race fix
    
    Reported-by: Maarten Maathuis <madman2003@gmail.com>
    Reported-by: Sven Joachim <svenjoac@gmx.de>
    Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

commit beba44b17d572ebb4909c1327360918ee4d89e43
Author: Alexander Stein <alexander.stein@informatik.tu-chemnitz.de>
Date:   Mon May 20 19:14:00 2013 +0200

    drm/nv84/disp: Fix HDMI audio regression
    
    Code refactoring in commit 8e9e3d2deacc460fbb8a4691140318f6e85e6891
    (drm/nv84/disp: move hdmi control into core) disabled HDMI audio on my
    nv84 by removing too much old code without adding it in the new one.
    This patch adds the missing code within the new code layout resulting in
    HDMI audio working again.
    It should work on any HDMI head, but due to lacking ahrdware I could
    only test the (1st) one.
    It also might be possible that similar code is needed for nva3, which I
    can't test.
    
    Signed-off-by: Alexander Stein <alexander.stein@informatik.tu-chemnitz.de>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

commit 5343a7f8be11951cb3095b91e8e4eb506cfacc0f
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jun 4 07:11:48 2013 +0000

    net_sched: htb: do not mix 1ns and 64ns time units
    
    commit 56b765b79 ("htb: improved accuracy at high rates") added another
    regression for low rates, because it mixes 1ns and 64ns time units.
    
    So the maximum delay (mbuffer) was not 60 second, but 937 ms.
    
    Lets convert all time fields to 1ns as 64bit arches are becoming the
    norm.
    
    Reported-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Tested-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 5e71d9d77c07fa7d4c42287a177f7b738d0cd4b9
Author: Pablo Neira <pablo@netfilter.org>
Date:   Mon Jun 3 09:28:43 2013 +0000

    net: fix sk_buff head without data area
    
    Eric Dumazet spotted that we have to check skb->head instead
    of skb->data as skb->head points to the beginning of the
    data area of the skbuff. Similarly, we have to initialize the
    skb->head pointer, not skb->data in __alloc_skb_head.
    
    After this fix, netlink crashes in the release path of the
    sk_buff, so let's fix that as well.
    
    This bug was introduced in (0ebd0ac net: add function to
    allocate sk_buff head without data area).
    
    Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 9bc297ea0622bb2a6b3abfa2fa84f0a3b86ef8c8
Author: Nithin Sujir <nsujir@broadcom.com>
Date:   Mon Jun 3 09:19:34 2013 +0000

    tg3: Add read dma workaround for 5720
    
    Commit 091f0ea30074bc43f9250961b3247af713024bc6 "tg3: Add New 5719 Read
    DMA workaround" added a workaround for TX DMA stall on the 5719. This
    workaround needs to be applied to the 5720 as well.
    
    Cc: stable@vger.kernel.org
    Reported-by: Roland Dreier <roland@purestorage.com>
    Tested-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
    Signed-off-by: Michael Chan <mchan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 3a5395b3d57b9e3836c755434c88f4590d5ea6f6
Author: Jens Renner \(EFE\) <renner@efe-gmbh.de>
Date:   Mon Jun 3 04:32:52 2013 +0000

    net: ethernet: xilinx_emaclite: set protocol selector bits when writing ANAR
    
    This patch sets the protocol selector bits (4:0) of the PHY's MII_ADVERTISE
    register (ANAR) when writing ADVERTISE_ALL. The protocol selector bits are
    indicating IEEE 803.3u support and are fixed / read-only on some PHYs. Not
    setting them correctly on others (like TI DP83630) makes the PHY fall back
    to 10M HDX mode which should be avoided.
    
    Tested for TI DP83630 PHY on Microblaze platform.
    
    Signed-off-by: Jens Renner <renner@efe-gmbh.de>
    Tested-by: Michal Simek <monstr@monstr.eu>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 44dbc78ee43d5df0bbcd7f3ae6a0ba00ed261e95
Author: Yuval Mintz <yuvalmin@broadcom.com>
Date:   Mon Jun 3 02:59:57 2013 +0000

    bnx2x: Fix bridged GSO for 57710/57711 chips
    
    It was recently found out that GSO on 57710/57711 was broken, due to packets
    being sent without a valid IP checksum.
    
    Commit 057cf65 "bnx2x: Fix GSO for 57710/57711 chips" partially fixed this
    issue, but failed to set the correct IP checksum when receiving GSO packets
    via bridges, as such packets enter bnx2x_tx_split() and the FW flags needed
    to calculate IP checksum were erroneously set in the incorrect
    buffer descriptor.
    
    This patch re-enables GSO in said scenario for 57710/57711 chips.
    
    Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
    Signed-off-by: Ariel Elior <ariele@broadcom.com>
    Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit f3bdf34465307fc3f6967a9202a921e11505b2e6
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Fri May 17 12:40:32 2013 +0000

    IB/qib: Fix lockdep splat in qib_alloc_lkey()
    
    The following backtrace is reported with CONFIG_PROVE_RCU:
    
        drivers/infiniband/hw/qib/qib_keys.c:64 suspicious rcu_dereference_check() usage!
        other info that might help us debug this:
        rcu_scheduler_active = 1, debug_locks = 1
        4 locks held by kworker/0:1/56:
        #0:  (events){.+.+.+}, at: [<ffffffff8107a4f5>] process_one_work+0x165/0x4a0
        #1:  ((&wfc.work)){+.+.+.}, at: [<ffffffff8107a4f5>] process_one_work+0x165/0x4a0
        #2:  (device_mutex){+.+.+.}, at: [<ffffffffa0148dd8>] ib_register_device+0x38/0x220 [ib_core]
        #3:  (&(&dev->lk_table.lock)->rlock){......}, at: [<ffffffffa017e81c>] qib_alloc_lkey+0x3c/0x1b0 [ib_qib]
    
        stack backtrace:
        Pid: 56, comm: kworker/0:1 Not tainted 3.10.0-rc1+ #6
        Call Trace:
        [<ffffffff810c0b85>] lockdep_rcu_suspicious+0xe5/0x130
        [<ffffffffa017e8e1>] qib_alloc_lkey+0x101/0x1b0 [ib_qib]
        [<ffffffffa0184886>] qib_get_dma_mr+0xa6/0xd0 [ib_qib]
        [<ffffffffa01461aa>] ib_get_dma_mr+0x1a/0x50 [ib_core]
        [<ffffffffa01678dc>] ib_mad_port_open+0x12c/0x390 [ib_mad]
        [<ffffffff810c2c55>] ?  trace_hardirqs_on_caller+0x105/0x190
        [<ffffffffa0167b92>] ib_mad_init_device+0x52/0x110 [ib_mad]
        [<ffffffffa01917c0>] ?  sl2vl_attr_show+0x30/0x30 [ib_qib]
        [<ffffffffa0148f49>] ib_register_device+0x1a9/0x220 [ib_core]
        [<ffffffffa01b1685>] qib_register_ib_device+0x735/0xa40 [ib_qib]
        [<ffffffff8106ba98>] ? mod_timer+0x118/0x220
        [<ffffffffa017d425>] qib_init_one+0x1e5/0x400 [ib_qib]
        [<ffffffff812ce86e>] local_pci_probe+0x4e/0x90
        [<ffffffff81078118>] work_for_cpu_fn+0x18/0x30
        [<ffffffff8107a566>] process_one_work+0x1d6/0x4a0
        [<ffffffff8107a4f5>] ?  process_one_work+0x165/0x4a0
        [<ffffffff8107c9c9>] worker_thread+0x119/0x370
        [<ffffffff8107c8b0>] ?  manage_workers+0x180/0x180
        [<ffffffff8108294e>] kthread+0xee/0x100
        [<ffffffff81082860>] ?  __init_kthread_worker+0x70/0x70
        [<ffffffff815c04ac>] ret_from_fork+0x7c/0xb0
        [<ffffffff81082860>] ?  __init_kthread_worker+0x70/0x70
    
    Per Documentation/RCU/lockdep-splat.txt, the code now uses rcu_access_pointer()
    vs. rcu_dereference().
    
    Reported-by: Jay Fenlason <fenlason@redhat.com>
    Reviewed-by: Dean Luick <dean.luick@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>

commit 1e65eb425b660ccd7c8d3ffb353512352690c67f
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date:   Wed May 8 12:21:19 2013 +0000

    MAINTAINERS: Add entry for iSCSI Extensions for RDMA (iSER) initiator
    
    Add entry for the iSER initiator driver and which is maintained by Or
    Gerlitz and Roi Dayan below the kernel InfiniBand subsystem.
    
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>

commit 28f292e879a6acf745005e75196fe8f7cc504103
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date:   Wed May 8 12:21:18 2013 +0000

    IB/iser: Add Mellanox copyright
    
    Add Mellanox copyright to the iser initiator source code which I maintain.
    
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>

commit 5b61ff43a774b9843402fb280fec6d700e1fe583
Author: Roi Dayan <roid@mellanox.com>
Date:   Wed May 8 12:21:17 2013 +0000

    IB/iser: Fix device removal flow
    
    Change the code to destroy the "last opened" rdma_cm id after making
    sure we released all other objects (QP, CQs, PD, etc) associated with
    the IB device.
    
    Since iser accesses the IB device using the rdma_cm id, we need to
    free any objects that are related to the device that is associated
    with the rdma_cm id prior to destroying that id.  When this isn't
    done, the low level driver that created this device can be unloaded
    before iser has a chance to free all the objects and a such a call may
    invoke code segment which isn't valid any more and crash.
    
    Cc: Sean Hefty <sean.hefty@intel.com
    Signed-off-by: Roi Dayan <roid@mellanox.com>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>

commit ff5b2fabf53426c15a5f041505687f94d1b2109f
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Mon Jun 3 00:38:39 2013 +0000

    net: fec: add fallback to random MAC address
    
    If no valid MAC address could be obtained from the hardware,
    fall back to a randomly generated one.
    
    Signed-off-by: Pavel Machek <pavel@denx.de>
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit e768fb292d362ff2742d843e346a10853bde68be
Author: Dmitry Kravkov <dmitry@broadcom.com>
Date:   Sun Jun 2 23:28:41 2013 +0000

    bnx2x: fix TCP offload for tunneling ipv4 over ipv6
    
    FW was initialized with data from wrong header, this caused TSO packets
    have wrong IP csum.
    
    Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
    Signed-off-by: Ariel Elior <ariele@broadcom.com>
    Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 534c877928a16ae5f9776436a497109639bf67dc
Author: Gao feng <gaofeng@cn.fujitsu.com>
Date:   Sun Jun 2 22:16:21 2013 +0000

    ipv6: assign rt6_info to inet6_ifaddr in init_loopback
    
    Commit 25fb6ca4ed9cad72f14f61629b68dc03c0d9713f
    "net IPv6 : Fix broken IPv6 routing table after loopback down-up"
    forgot to assign rt6_info to the inet6_ifaddr.
    When disable the net device, the rt6_info which allocated
    in init_loopback will not be destroied in __ipv6_ifa_notify.
    
    This will trigger the waring message below
    [23527.916091] unregister_netdevice: waiting for tap0 to become free. Usage count = 1
    
    Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
    Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit c418253f12c0a95c7cd894953644c7488899c9fd
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date:   Tue Jun 4 05:13:29 2013 +0000

    net/mlx4_core: Keep VF assigned MAC in the PF admin table
    
    MAC addresses assigned by the PF to VFs were not kept in the PF driver
    admin table. As a result, displaying the VF MACs from the PF interface
    to user space showed zero address where in fact the VF got non-zero
    address from the PF, fix that.
    
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit ef96f7d46ad86625237da8a35e812bdf7896e640
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date:   Tue Jun 4 05:13:28 2013 +0000

    net/mlx4_en: Handle unassigned VF MAC address correctly
    
    When a VF sense they didn't get MAC address, use random one. This will
    address the case of administrator not assigning MAC to the VF through
    the PF OS APIs and keep udev happy.
    
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 5efe5355f22fb9b7bb64d19809c0a75805e0ccb8
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Tue Jun 4 05:13:27 2013 +0000

    net/mlx4_core: Return -EPROBE_DEFER when a VF is probed before PF is sufficiently initialized
    
    In the PF initialization, SRIOV is enabled before the PF is fully initialized.
    This allows the kernel to probe the newly-exposed VFs before the PF is ready
    to handle them (nested probes).
    
    Have the probe method return the -EPROBE_DEFER value in this situation (instead
    of the VF probe method retrying its initialization in a loop, and returning -EIO
    on failure). When -EPROBE_DEFER is returned by the VF probe method, the kernel
    itself will retry the probe after a suitable delay.
    
    Based upon a suggestion by Ben Hutchings <bhutchings@solarflare.com>
    
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit a1c6693a50391683e7f5787bb027b1aae1afbedb
Author: Sagi Grimberg <sagig@mellanox.co.il>
Date:   Tue Jun 4 05:13:26 2013 +0000

    net/mlx4_en: Fix adaptive moderation cq update
    
    When turning on adaptive_rx under adaptive moderation, the CQ's moderation
    count wasn't updated according to rx_frames which resulted in too many
    interrupts and bandwidth drop.
    
    Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Amir Vadai <amirv@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit bc2bfffc3866e8c87dde19d5619262a810a51ed8
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Sun May 26 17:59:20 2013 -0700

    spi: hspi: fixup long delay time
    
    Current HSPI driver is using msleep(20) on hspi_status_check_timeout(),
    but it was too long delay for SPI device.
    Bock-W board SPI access was too slow without this patch.
    This patch uses udelay(10) for it.
    
    Tested-by: Yusuke Goda <yusuke.goda.sx@renesas.com>
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit 6c5d4c96f979611f0165dc825af9e1cea8dd35b9
Author: Michael Hennerich <michael.hennerich@analog.com>
Date:   Mon Jun 3 09:04:00 2013 +0100

    iio:inkern: Fix typo/bug in convert raw to processed.
    
    Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>

commit 2eb3a81eef0510511a3211bb3da560f446a8c8de
Author: Michael Hennerich <michael.hennerich@analog.com>
Date:   Mon Jun 3 14:30:00 2013 +0100

    iio: frequency: ad4350: Fix bug / typo in mask
    
    Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
    Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>

commit 68c315bb951d94210c43c52166d326f9c26f7ce8
Author: Peter Crosthwaite <peter.crosthwaite@petalogix.com>
Date:   Tue Jun 4 16:02:34 2013 +0200

    spi: spi-xilinx: Remove ISR race condition
    
    The ISR currently consumes the rx buffer data and re-enables transmission
    from within interrupt context. This is bad because if the interrupt
    occurs again before the ISR exits, the new interrupt will be erroneously
    cleared by the still completing ISR.
    
    Simplified the ISR by just setting the completion variable and exiting with
    no action. Then just looped the transmit functionality in
    xilinx_spi_txrx_bufs().
    
    Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>

commit e916b80d2b1988e985abc0a1c85eca5b96c61f48
Author: Joe Perches <joe@perches.com>
Date:   Tue Jun 4 15:44:00 2013 +0100

    inkern: iio_device_put after incorrect return/goto
    
    The code uses
    
        return foo;
        goto err_type;
    
    when instead the form should have been
    
        ret = foo;
        goto err_type;
    
    Here this causes a useful iio_device_put to be skipped.
    
    Signed-off-by: Joe Perches <joe@perches.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>

commit 60bba385c5e86ee6a654e3345093eb48e258eb1d
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Jun 4 16:13:25 2013 +0300

    staging: alarm-dev: information leak in alarm_compat_ioctl()
    
    If we pass an invalid clock type then "ts" is never set.  We need to
    check for errors earlier, otherwise we end up passing uninitialized
    stack data to userspace.
    
    Reported-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 702df9f1819c7fc7e257251fabc5eec674342c32
Author: Jonathan Cameron <jic23@kernel.org>
Date:   Wed May 22 22:41:00 2013 +0100

    iio:callback buffer: free the scan_mask
    
    Reported-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>

commit a26f009a070e840fadacb91013b2391ba7ab6cc2
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Jun 4 18:50:31 2013 +0200

    USB: mos7720: fix hardware flow control
    
    The register access to enable hardware flow control depends on the
    device port number and not the port minor number.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1ec1bcf0c97cdd4e25f16524c962fae9a4a39f9
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Jun 4 18:50:30 2013 +0200

    USB: keyspan: remove unused endpoint-array access
    
    Remove the no longer used endpoint-array access completely.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a07088098a650267b2eda689538133a324b9523f
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Jun 4 18:50:29 2013 +0200

    USB: keyspan: fix bogus array index
    
    The outcont_endpoints array was indexed using the port minor number
    (which can be greater than the array size) rather than the device port
    number.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8a1d0d54d5fdac0347b75e9afd554b3dfaa465f
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Jun 4 18:50:28 2013 +0200

    USB: zte_ev: fix broken open
    
    Remove bogus port-number check in open and close, which prevented this
    driver from being used with a minor number different from zero.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3bd1f7e2db4124a2726f9afdeaaf82f09b0bd8eb
Author: Ping Cheng <pinglinux@gmail.com>
Date:   Thu May 23 10:22:33 2013 -0700

    Input: wacom - fix a typo for Cintiq 22HDT
    
    And make the lines easier to read.
    
    Signed-off-by: Ping Cheng <pingc@wacom.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

commit eeb065582a9618c1cf5b7154df7bae06aeb44636
Author: Eric Miao <eric.miao@canonical.com>
Date:   Tue Jun 4 09:30:55 2013 -0700

    Input: synaptics - fix sync lost after resume on some laptops
    
    In summary, the symptom is intermittent key events lost after resume
    on some machines with synaptics touchpad (seems this is synaptics _only_),
    and key events loss is due to serio port reconnect after psmouse sync lost.
    Removing psmouse and inserting it back during the suspend/resume process
    is able to work around the issue, so the difference between psmouse_connect()
    and psmouse_reconnect() is the key to the root cause of this problem.
    
    After comparing the two different paths, synaptics driver has its own
    implementation of synaptics_reconnect(), and the missing psmouse_probe()
    seems significant, the patch below added psmouse_probe() to the reconnect
    process, and has been verified many times that the issue could not be reliably
    reproduced.
    
    There are two PS/2 commands in psmouse_probe():
    
      1. PSMOUSE_CMD_GETID
      2. PSMOUSE_CMD_RESET_DIS
    
    Only the PSMOUSE_CMD_GETID seems to be significant. The
    PSMOUSE_CMD_RESET_DIS is irrelevant to this issue after trying
    several times.  So we have only implemented this patch to issue
    the PSMOUSE_CMD_GETID so far.
    
    Tested-by: Daniel Manrique <daniel.manrique@canonical.com>
    Signed-off-by: James M Leddy <james.leddy@canonical.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

commit 53d3b4d7778daf15900867336c85d3f8dd70600c
Author: Egbert Eich <eich@suse.de>
Date:   Tue Jun 4 17:13:21 2013 +0200

    drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC.
    
    In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used
    for DDC. Thus the code will always have to rely on a LVDS panel
    mode supplied by VBT.
    In most cases this succeeds, so this didn't get detected for quite
    a while.
    
    This regression seems to have been introduced in
    
    commit f899fc64cda8569d0529452aafc0da31c042df2e
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Tue Jul 20 15:44:45 2010 -0700
    
        drm/i915: use GMBUS to manage i2c links
    
    Signed-off-by: Egbert Eich <eich@suse.de>
    Cc: stable@vger.kernel.org
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    [danvet: Add note about which commit likely introduced this issue.]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 8eafc0a161123d90617c9ca2eddfe87b382b1b89
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Jun 4 16:02:54 2013 +0200

    ALSA: usb-audio - Apply Logitech QuickCam Pro 9000 quirk only to audio iface
    
    ... instead of applying to all interfaces.
    
    Reference: http://forums.gentoo.org/viewtopic-p-6886404.html
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 466318a87f28cb3ba0d08a3b7ef1a37ae73d5aa7
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Mon Jun 3 10:33:55 2013 -0400

    xen/smp: Fixup NOHZ per cpu data when onlining an offline CPU.
    
    The xen_play_dead is an undead function. When the vCPU is told to
    offline it ends up calling xen_play_dead wherin it calls the
    VCPUOP_down hypercall which offlines the vCPU. However, when the
    vCPU is onlined back, it resumes execution right after
    VCPUOP_down hypercall.
    
    That was OK (albeit the API for play_dead assumes that the CPU
    stays dead and never returns) but with commit 4b0c0f294
    (tick: Cleanup NOHZ per cpu data on cpu down) that is no longer safe
    as said commit resets the ts->inidle which at the start of the
    cpu_idle loop was set.
    
    The net effect is that we get this warn:
    
    Broke affinity for irq 16
    installing Xen timer for CPU 1
    cpu 1 spinlock event irq 48
    ------------[ cut here ]------------
    WARNING: at /home/konrad/linux-linus/kernel/time/tick-sched.c:935 tick_nohz_idle_exit+0x195/0x1b0()
    Modules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs
    CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.10.0-rc3upstream-00068-gdcdbe33 #1
    Hardware name: BIOSTAR Group N61PB-M2S/N61PB-M2S, BIOS 6.00 PG 09/03/2009
     ffffffff8193b448 ffff880039da5e60 ffffffff816707c8 ffff880039da5ea0
     ffffffff8108ce8b ffff880039da4010 ffff88003fa8e500 ffff880039da4010
     0000000000000001 ffff880039da4000 ffff880039da4010 ffff880039da5eb0
    Call Trace:
     [<ffffffff816707c8>] dump_stack+0x19/0x1b
     [<ffffffff8108ce8b>] warn_slowpath_common+0x6b/0xa0
     [<ffffffff8108ced5>] warn_slowpath_null+0x15/0x20
     [<ffffffff810e4745>] tick_nohz_idle_exit+0x195/0x1b0
     [<ffffffff810da755>] cpu_startup_entry+0x205/0x250
     [<ffffffff81661070>] cpu_bringup_and_idle+0x13/0x15
    ---[ end trace 915c8c486004dda1 ]---
    
    b/c ts_inidle is set to zero. Thomas suggested that we just add a workaround
    to call tick_nohz_idle_enter before returning from xen_play_dead() - and
    that is what this patch does and fixes the issue.
    
    We also add the stable part b/c git commit 4b0c0f294 is on the stable
    tree.
    
    CC: stable@vger.kernel.org
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 5600a8485603b240790005b9b58de4c4f6ada69d
Author: Simon Horman <horms+renesas@verge.net.au>
Date:   Wed May 22 19:47:05 2013 +0900

    ARM: shmobile: sh73a0: Update CMT clockevent rating to 80
    
    Update the CMT clockevent rating from 125 to 80.
    
    This resolves a boot-failure regression for kzm9g-reference in v3.10-rc1
    introduced by f7db706b132f11c79ae1d74b2382e0926cf31644 ("ARM: 7674/1: smp:
    Avoid dummy clockevent being preferred over real").
    
    The patch noted above reduces the rating of dummy clockevent from 400 to 100.
    This patch reduces the rating of CMT so that it is once again less than that
    of the dummy clockevent.
    
    Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

commit 350753bf2bd1267f471e89829d68c35b9abf4930
Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date:   Tue May 21 12:39:31 2013 +0200

    sh-pfc: r8a7779: Don't group USB OVC and PENC pins
    
    The USB_OVCn pins are alternate options for USB over-current detection
    when using a 3.3V USB interface. As they're not mandatory they can be
    used independently of the USB PENC pins. Don't group the USB_OVCn and
    PENC pins to avoid conflicts when the USB_OVCn pins are used by another
    function.
    
    Reported-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

commit e919b86c3b018c0e0c5e522354e743dcc0824ee1
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Jun 3 02:02:31 2013 -0700

    staging: alarm-dev: information leak in alarm_ioctl()
    
    Smatch complains that if we pass an invalid clock type then "ts" is
    never set.  We need to check for errors earlier, otherwise we end up
    passing uninitialized stack data to userspace.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1c1cc664342cf197afeea4b0dd8145d1edee35c
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date:   Wed May 29 00:10:00 2013 -0300

    [media] s5p-mfc: Add NULL check for allocated buffer
    
    In certain cases, dma_alloc_coherent returns NULL. Add check for
    NULL pointer.
    
    Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
    Signed-off-by: Kamil Debski <k.debski@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 4130eabc55f4d4d1510d2e1c556fe3e0237c5ba5
Author: Andrzej Hajda <a.hajda@samsung.com>
Date:   Tue May 28 03:26:16 2013 -0300

    [media] s5p-mfc: added missing end-of-lines in debug messages
    
    Many debug messages missed end-of-line.
    
    Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Kamil Debski <k.debski@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 69c9fe6f4afae54cad12635bdb8e90e7d832e240
Author: Andrzej Hajda <a.hajda@samsung.com>
Date:   Tue May 28 03:26:15 2013 -0300

    [media] s5p-mfc: v4l2 controls setup routine moved to initialization code
    
    Callback .start_streaming is called once for every queue,
    so v4l2_ctrl_handler_setup was called twice during stream start.
    Moving v4l2_ctrl_handler_setup to context initialization
    reduces numbers of calls and seems to be more consistent with API.
    
    Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Kamil Debski <k.debski@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit ac5f867fbfbd1ff5a43e796ed470deff42b630d2
Author: Andrzej Hajda <a.hajda@samsung.com>
Date:   Tue May 28 03:26:14 2013 -0300

    [media] s5p-mfc: separate encoder parameters for h264 and mpeg4
    
    This patch fixes a bug which caused overwriting h264 codec
    parameters by mpeg4 parameters during V4L2 control setting.
    
    Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Kamil Debski <k.debski@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit fc906b6d189f26e869b11b94eaa9a733b3950740
Author: Arun Kumar K <arun.kk@samsung.com>
Date:   Mon May 27 03:39:29 2013 -0300

    [media] s5p-mfc: Remove special clock usage in driver
    
    MFC uses two clocks - MFC gate clock and special clock
    which is named as "sclk_mfc" in exynos4 and "aclk_333" in
    exynos5 SoC. The driver was doing just a clk_prepare on
    this special clock without a clk_enable call. As this
    sclk is the parent of gate clock, it gets prepared and
    enabled along with the gate clock. So there is no need
    for the driver to use this sclk. This patch removes the
    sclk usage from driver.
    
    Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
    Signed-off-by: Kamil Debski <k.debski@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 644469aefbac3c007284b43ac932ba6f1794a110
Author: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
Date:   Sat May 25 07:25:55 2013 -0300

    [media] s5p-mfc: Remove unused s5p_mfc_get_decoded_status_v6() function
    
    This patch fixes following compilation warning:
      CC [M]  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.o
    drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c:1733:12: warning: ‘s5p_mfc_get_decoded_status_v6’ defined but not used
    It assigns existing but not used s5p_mfc_get_dec_status_v6() function to the
    get_dec_status callback. It seems the get_dec_status callback is not used
    anyway, as there is no corresponding s5p_mfc_hw_call().
    
    Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
    Signed-off-by: Kamil Debski <k.debski@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit b730627ad65f023dd9ce83047a3076330ebaefe5
Author: John Sheu <sheu@google.com>
Date:   Thu May 23 20:41:48 2013 -0300

    [media] v4l2: mem2mem: save irq flags correctly
    
    Save flags correctly when taking spinlocks in v4l2_m2m_try_schedule.
    
    Signed-off-by: John Sheu <sheu@google.com>
    Signed-off-by: Kamil Debski <k.debski@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 8fdf94a254ab2f90ae79b82e56b1f8e9d7582026
Author: Philipp Zabel <p.zabel@pengutronix.de>
Date:   Tue May 21 04:16:29 2013 -0300

    [media] coda: v4l2-compliance fix: add VIDIOC_CREATE_BUFS support
    
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Kamil Debski <k.debski@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 8b94ca61d7065fa7fa7bdb08ce31a9385be5205b
Author: Philipp Zabel <p.zabel@pengutronix.de>
Date:   Tue May 21 04:16:28 2013 -0300

    [media] v4l2-mem2mem: add v4l2_m2m_create_bufs helper
    
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Kamil Debski <k.debski@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 57183467c09555d985ae62b79c754e64279381df
Author: Seung-Woo Kim <sw0312.kim@samsung.com>
Date:   Mon May 20 23:47:30 2013 -0300

    [media] media: v4l2-mem2mem: return for polling if a buffer is available
    
    The v4l2_m2m_poll() does not need to wait if there is already a buffer in
    done_list of source and destination queues, but current v4l2_m2m_poll() always
    waits. So done_list of each queue is checked before calling poll_wait().
    
    Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
    Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Kamil Debski <k.debski@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 412cb87d28a1f299ee82fe1c8bfe6cbeec9a4655
Author: Seung-Woo Kim <sw0312.kim@samsung.com>
Date:   Mon May 20 23:47:29 2013 -0300

    [media] media: vb2: return for polling if a buffer is available
    
    The vb2_poll() does not need to wait next vb_buffer_done() if there is already
    a buffer in done_list of queue, but current vb2_poll() always waits.
    So done_list is checked before calling poll_wait().
    
    Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
    Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Kamil Debski <k.debski@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit e9d98ddc0a4e4e11603c818bf234644031bff384
Author: Arun Kumar K <arun.kk@samsung.com>
Date:   Wed Apr 24 09:41:53 2013 -0300

    [media] s5p-mfc: Update v6 encoder buffer alloc
    
    MFC v6 needs minimum number of output buffers to be queued
    for encoder depending on the stream type and profile.
    The patch modifies the driver so that encoding cannot be
    started with lesser number of OUTPUT buffers than required.
    This also fixes the crash happeninig during multi instance
    encoder-decoder simultaneous run due to memory allocation
    happening from interrupt context.
    
    Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
    Signed-off-by: Kamil Debski <k.debski@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 8a2f132a01c2dd4c3905fa560f92019761ed72b1
Author: Richard Weinberger <richard@nod.at>
Date:   Fri May 24 12:01:51 2013 +0200

    USB: serial: Add Option GTM681W to qcserial device table.
    
    The Option GTM681W uses a qualcomm chip and can be
    served by the qcserial device driver.
    
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6529591e3eef65f0f528a81ac169f6e294b947a7
Author: Robert Butora <robert.butora.fi@gmail.com>
Date:   Fri May 31 18:09:51 2013 +0300

    USB: Serial: cypress_M8: Enable FRWD Dongle hidcom device
    
    The patch adds a new HIDCOM device and does not affect other devices
    driven by the cypress_M8 module. Changes are:
    - add VendorID ProductID to device tables
    - skip unstable speed check because FRWD uses 115200bps
    - skip reset at probe which is an issue workaround for this
    particular device.
    
    Signed-off-by: Robert Butora <robert.butora.fi@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 317a68427d4b0a302ecff252fd83a00557947db8
Author: Kyle McMartin <kyle@infradead.org>
Date:   Mon Jun 3 09:38:26 2013 -0400

    Revert "serial: 8250: Make SERIAL_8250_RUNTIME_UARTS work correctly"
    
    This reverts commit cfcec52e9781f08948c6eb98198d65c45be75a70.
    
    This regresses a longstanding behaviour on X86 systems, which end up with
    PCI serial ports moving between ttyS4 and ttyS0 when you bisect to opposite
    sides of this commit, resulting in the need to constantly modify the console
    setting in order to bisect across it.
    
    Please revert, we can work on solving this for ARM platforms in a less
    disruptive way.
    
    Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
    Cc: Karthik Manamcheri <karthik.manamcheri@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60e93575476f90a72146b51283f514da655410a7
Author: Chander Kashyap <chander.kashyap@linaro.org>
Date:   Tue May 28 18:32:07 2013 +0530

    serial: samsung: enable clock before clearing pending interrupts during init
    
    Ensure that the uart controller clock is enabled prior to writing to the
    interrupt mask and pending registers in the s3c24xx_serial_init_port
    function.
    
    Signed-off-by: Chander Kashyap <chander.kashyap@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bff09b099b31a31573b3c5943f805f6a08c714f0
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Thu May 30 15:47:04 2013 +0200

    serial/imx: disable hardware flow control at startup
    
    We only want to enable hardware flow control if RTS/CTS pins
    are connected.
    
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6a4d98b0124b5d3befe8b3a99f51f1b4fcc6dcf
Author: Bob Peterson <rpeterso@redhat.com>
Date:   Wed May 29 11:51:52 2013 -0400

    GFS2: Don't cache iopen glocks
    
    This patch makes GFS2 immediately reclaim/delete all iopen glocks
    as soon as they're dequeued. This allows deleters to get an
    EXclusive lock on iopen so files are deleted properly instead of
    being set as unlinked.
    
    Signed-off-by: Bob Peterson <rpeterso@redhat.com>
    Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>

commit e8830d8856e3ad61067dd46c05438b0d75a0441a
Author: Bob Peterson <rpeterso@redhat.com>
Date:   Thu May 30 09:48:56 2013 -0400

    GFS2: Fall back to vmalloc if kmalloc fails for dir hash tables
    
    This version has one more correction: the vmalloc calls are replaced
    by __vmalloc calls to preserve the GFP_NOFS flag.
    
    When GFS2's directory management code allocates buffers for a
    directory hash table, if it can't get the memory it needs, it
    currently gives a bad return code. Rather than giving an error,
    this patch allows it to use virtual memory rather than kernel
    memory for the hash table. This should make it possible for
    directories to function properly, even when kernel memory becomes
    very fragmented.
    
    Signed-off-by: Bob Peterson <rpeterso@redhat.com>
    Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>

commit 2b3dcf35810ff02ad0e785527a25c1b13bf82b19
Author: Bob Peterson <rpeterso@redhat.com>
Date:   Tue May 28 10:04:44 2013 -0400

    GFS2: Increase i_writecount during gfs2_setattr_size
    
    This patch calls get_write_access in a few functions. This
    merely increases inode->i_writecount for the duration of the function.
    That will ensure that any file closes won't delete the inode's
    multi-block reservation while the function is running.
    
    Signed-off-by: Bob Peterson <rpeterso@redhat.com>
    Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>

commit 4a586812055dbd2588b0836ab758f6b9670c3949
Author: Bob Peterson <rpeterso@redhat.com>
Date:   Fri May 24 15:02:49 2013 -0400

    GFS2: Set log descriptor type for jdata blocks
    
    This patch sets the log descriptor type according to whether the
    journal commit is for (journaled) data or metadata. This was
    recently broken when the functions to process data and metadata
    log ops were combined.
    
    Signed-off-by: Bob Peterson <rpeterso@redhat.com>
    Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>

commit b5f83e9b069f4bf19214ca6130947806a2b853fa
Author: Markus Pargmann <mpa@pengutronix.de>
Date:   Tue May 28 17:00:57 2013 +0200

    ARM: mxs: icoll: Fix interrupts gpio bank 0
    
    The mxs interrupt controller does not support polling for interrupts,
    but the driver still does it, which is a relict from
    pre-MULTI_IRQ_HANDLER times.
    
    The existing code assumes that 0x7f means no interrupt, but this value
    is an actually valid irq number, namely gpio bank 0's irq. This results
    in the driver not detecting when irq 0x7f is active which makes the
    machine effectively dead lock.
    
    This patch removes the interrupt poll loop and allows usage of gpio0
    interrupt without an infinite loop.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>

commit 1cbcca302a318499f20a512847c5d6a510c08c35
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Jun 3 10:32:40 2013 -0400

    drm/radeon: don't allow audio on DCE6
    
    It's not supported yet.  Fixes display issues when
    users force it on.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org

commit 65337e60a7616a610ef53b7a9f807eb80a827070
Author: Samuel Li <samuel.li@amd.com>
Date:   Fri Apr 5 17:50:53 2013 -0400

    drm/radeon: Use direct mapping for fast fb access on RS780/RS880 (v2)
    
    v2: fix trailing whitespace
    
    Signed-off-by: Samuel Li <samuel.li@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit e49f3959a96dc279860af7e86e6dbcfda50580a5
Author: Adis Hamzić <adis@hamzadis.com>
Date:   Sun Jun 2 16:47:54 2013 +0200

    radeon: Fix system hang issue when using KMS with older cards
    
    The current radeon driver initialization routines, when using KMS, are written
    so that the IRQ installation routine is called before initializing the WB buffer
    and the CP rings. With some ASICs, though, the IRQ routine tries to access the
    GFX_INDEX ring causing a call to RREG32 with the value of -1 in
    radeon_fence_read. This, in turn causes the system to completely hang with some
    cards, requiring a hard reset.
    
    A call stack that can cause such a hang looks like this (using rv515 ASIC for the
    example here):
     * rv515_init (rv515.c)
     * radeon_irq_kms_init (radeon_irq_kms.c)
     * drm_irq_install (drm_irq.c)
     * radeon_driver_irq_preinstall_kms (radeon_irq_kms.c)
     * rs600_irq_process (rs600.c)
     * radeon_fence_process - due to SW interrupt (radeon_fence.c)
     * radeon_fence_read (radeon_fence.c)
     * hang due to RREG32(-1)
    
    The patch moves the IRQ installation to the card startup routine, after the ring
    has been initialized, but before the IRQ has been set. This fixes the issue, but
    requires a check to see if the IRQ is already installed, as is the case in the
    system resume codepath.
    I have tested the patch on three machines using the rv515, the rv770 and the
    evergreen ASIC. They worked without issues.
    
    This seems to be a known issue and has been reported on several bug tracking
    sites by various distributions (see links below). Most of reports recommend
    booting the system with KMS disabled and then enabling KMS by reloading the
    radeon module. For some reason, this was indeed a usable workaround, however,
    UMS is now deprecated and disabled by default.
    
    Bug reports:
    https://bugzilla.redhat.com/show_bug.cgi?id=845745
    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/561789
    https://bbs.archlinux.org/viewtopic.php?id=156964
    
    Signed-off-by: Adis Hamzić <adis@hamzadis.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org

commit e5c5f05dca0cf90f0f3bb1aea85dcf658baff185
Author: Maxim Patlasov <mpatlasov@parallels.com>
Date:   Thu May 30 16:41:34 2013 +0400

    fuse: fix alignment in short read optimization for async_dio
    
    The bug was introduced with async_dio feature: trying to optimize short reads,
    we cut number-of-bytes-to-read to i_size boundary. Hence the following example:
    
    	truncate --size=300 /mnt/file
    	dd if=/mnt/file of=/dev/null iflag=direct
    
    led to FUSE_READ request of 300 bytes size. This turned out to be problem
    for userspace fuse implementations who rely on assumption that kernel fuse
    does not change alignment of request from client FS.
    
    The patch turns off the optimization if async_dio is disabled. And, if it's
    enabled, the patch fixes adjustment of number-of-bytes-to-read to preserve
    alignment.
    
    Note, that we cannot throw out short read optimization entirely because
    otherwise a direct read of a huge size issued on a tiny file would generate
    a huge amount of fuse requests and most of them would be ACKed by userspace
    with zero bytes read.
    
    Signed-off-by: Maxim Patlasov <MPatlasov@parallels.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>

commit c9ecf989cc7626e9edf8abef79f64b909542129b
Author: Brian Foster <bfoster@redhat.com>
Date:   Thu May 30 15:35:50 2013 -0400

    fuse: return -EIOCBQUEUED from fuse_direct_IO() for all async requests
    
    If request submission fails for an async request (i.e.,
    get_user_pages() returns -ERESTARTSYS), we currently skip the
    -EIOCBQUEUED return and drop into wait_for_sync_kiocb() forever.
    
    Avoid this by always returning -EIOCBQUEUED for async requests. If
    an error occurs, the error is passed into fuse_aio_complete(),
    returned via aio_complete() and thus propagated to userspace via
    io_getevents().
    
    Signed-off-by: Brian Foster <bfoster@redhat.com>
    Reviewed-by: Maxim Patlasov <MPatlasov@parallels.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>

commit 8341613afbc8d65bca8c81158edfb49f36b7ad92
Author: Suman Anna <s-anna@ti.com>
Date:   Wed Apr 17 18:23:15 2013 -0500

    ARM: dts: OMAP5: Fix missing PWM capability to timer nodes
    
    OMAP5 has 6 timers (GPTimers 5, 6, 8 to 11) that are capable of PWM.
    The PWM capability property is missing from the node definitions of
    couple of timers.
    
    Add ti,timer-pwm attribute for timer 5, 6, 8 and 11.
    
    Signed-off-by: Suman Anna <s-anna@ti.com>
    [benoit.cousson@linaro.org: Update changelog and subject to highlight
    the fix]
    Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>

commit 1e68f43b7dcf0e5eee10baeb3cbe4e1ca59db9fd
Author: Kevin Hilman <khilman@linaro.org>
Date:   Fri May 24 17:24:21 2013 -0700

    ARM: dts: omap4-panda|sdp: Fix mux for twl6030 IRQ pin and msecure line
    
    Earlier commits ensured proper muxing of pins related to proper
    TWL6030 behavior: see commit 265a2bc8 (ARM: OMAP3: TWL4030: ensure
    sys_nirq1 is mux'd and wakeup enabled) and commit 1ef43369 (ARM:
    OMAP4: TWL: mux sys_drm_msecure as output for PMIC).
    
    However these only fixed legacy boot and not DT boot.  For DT boot,
    the default mux values need to be set properly in DT.
    
    Special thanks to Nishanth Menon for the review and catching some
    major flaws in earlier versions.
    
    Tested on OMAP4430/Panda and OMAP4460/Panda-ES.
    
    Cc: Nishanth Menon <nm@ti.com>
    Cc: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Kevin Hilman <khilman@linaro.org>
    Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
    [benoit.cousson@linaro.org: Slightly change the subject to align
    board name with file name]
    Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>

commit 00dddcaa51f997cdc6dbae3303a31024e29a0fc0
Author: Lars Poeschel <poeschel@lemonage.de>
Date:   Tue May 28 10:24:57 2013 +0200

    ARM: dts: AM33xx: Fix properties on gpmc node
    
    The gpmc driver is actually looking for "gpmc,num-cs" and
    "gpmc,num-waitpins" properties in DT. The binding doc also states
    this.
    Correct the properties in the dts to provide the right values for the
    gpmc driver.
    
    Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
    Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
    Acked-by: Pekon Gupta <pekon@ti.com>
    Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>

commit 28420dad233520811c0e0860e7fb4975ed863fc4
Author: Miklos Szeredi <mszeredi@suse.cz>
Date:   Mon Jun 3 14:40:22 2013 +0200

    fuse: fix readdirplus Oops in fuse_dentry_revalidate
    
    Fix bug introduced by commit 4582a4ab2a "FUSE: Adapt readdirplus to application
    usage patterns".
    
    We need to check for a positive dentry; negative dentries are not added by
    readdirplus.  Secondly we need to advise the use of readdirplus on the *parent*,
    otherwise the whole thing is useless.  Thirdly all this is only relevant if
    "readdirplus_auto" mode is selected by the filesystem.
    
    We advise the use of readdirplus only if the dentry was still valid.  If we had
    to redo the lookup then there was no use in doing the -plus version.
    
    Reported-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    CC: Feng Shuo <steve.shuo.feng@gmail.com>
    CC: stable@vger.kernel.org

commit 45a211d75137b1ac869a8a758a6667f15827a115
Author: Ben Mesman <ben@bnc.nl>
Date:   Tue Apr 16 20:00:28 2013 +0200

    drm/i915: no lvds quirk for hp t5740
    
    Last year, a patch was made for the "HP t5740e Thin Client" (see
    http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html).
    This device reports an lvds panel, but does not really have one.
    
    The predecessor of this device is the "hp t5740", which also does not have
    an lvds panel. This patch will add the same quirk for this device.
    
    Signed-off-by: Ben Mesman <ben@bnc.nl>
    Cc: stable@vger.kernel.org
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit d62cf62ad07d5584da1f2132641928ded8216327
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed May 29 10:41:29 2013 +0200

    drm/i915: Quirk the pipe A quirk in the modeset state checker
    
    If we always force the pipe A to on we can't use the hw state to
    decide whether it should be on. Hence quirk the quirk.
    
    The problem is that crtc->active tracks the state of the entire
    display pipe, i.e. including planes, encoders and all. But our hw
    state readout simply looks at the pipe. But with the pipe A quirk we
    force-enable that (together with it's pll). To fix that mismatch we
    have two options:
    - Quirk the checked state to match what our sw tracking states if the
      pipe A quirk is in effect.
    - Improve the hw state readout to not get fooled by the pipe A quirk.
    
    Since we already have similar state clamping in e.g. assert_pipe I've
    opted for the first variant. Also note that we don't really loose any
    state checking: Individual pieces of the abstract crtc pipe are
    checked in the enable/disable functions with the various asssert_*
    checks we have, and the hw state check code doesn't check anything if
    the pipe is off anyway.
    
    v2: Pimp commit message after discussion with Chris and only apply the
    quirk for the quirk if we're checking pipe A. Otherwise we'll miss
    state checking for pipe B on i830M ...
    
    v3: Make the code comment consistent with the improved commit message,
    too (Chris).
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64764
    Cc: stable@vger.kernel.org
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Reported-and-Tested-by: mlsemon35@gmail.com (v1)
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 7abb690a0e095717420ba78dcab4309abbbec78a
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri May 24 21:29:32 2013 +0200

    drm/i915: Fix spurious -EIO/SIGBUS on wedged gpus
    
    Chris Wilson noticed that since
    
    commit 1f83fee08d625f8d0130f9fe5ef7b17c2e022f3c [v3.9]
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Thu Nov 15 17:17:22 2012 +0100
    
        drm/i915: clear up wedged transitions
    
    X can again get -EIO when it does not expect it. And even worse score
    a SIGBUS when accessing gtt mmaps. The established ABI is that we
    _only_ return an -EIO from execbuf - all other ioctls should just
    work. And since the reset code moves all bos out of gpu domains and
    clears out all the last_seqno/ring tracking there really shouldn't be
    any reason for non-execbuf code to ever touch the hw and see an -EIO.
    
    After some extensive discussions we've noticed that these spurios -EIO
    are caused by i915_gem_wait_for_error:
    
    http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg20540.html
    
    That is easy to fix by returning 0 instead of -EIO, since grabbing the
    dev->struct_mutex does not yet mean that we actually want to touch the
    hw. And so there is no reason at all to fail with -EIO.
    
    But that's not the entire since, since often (at least it's easily
    googleable) dmesg indicates that the reset fails and we declare the
    gpu wedged. Then, quite a bit later X wakes up with the "Timed out
    waiting for the gpu reset to complete" DRM_ERROR message in
    wait_for_errror and brings down the desktop with an -EIO/SIGBUS.
    
    So clearly we're missing a wakeup somewhere, since the gpu reset just
    doesn't take 10 seconds to complete. And indeed we're do handle the
    terminally wedged state wrong.
    
    Fix this all up.
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=63921
    References: https://bugs.freedesktop.org/show_bug.cgi?id=64073
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Damien Lespiau <damien.lespiau@intel.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit f14e22435a27ef183bbfa78f77ad86644c0b354c
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Thu May 16 11:36:40 2013 +0200

    net: can: peak_usb: Do not do dma on the stack
    
    smatch reports the following warnings:
    drivers/net/can/usb/peak_usb/pcan_usb_pro.c:514 pcan_usb_pro_drv_loaded() error: doing dma on the stack (buffer)
    drivers/net/can/usb/peak_usb/pcan_usb_pro.c:878 pcan_usb_pro_init() error: doing dma on the stack (&fi)
    drivers/net/can/usb/peak_usb/pcan_usb_pro.c:889 pcan_usb_pro_init() error: doing dma on the stack (&bi)
    
    See "Documentation/DMA-API-HOWTO.txt" section "What memory is DMA'able?"
    
    Cc: Stephane Grosjean <s.grosjean@peak-system.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

commit fae37f81fdf3680c5d70abdc57e7b83f4b6c266a
Author: Olivier Sobrie <olivier@sobrie.be>
Date:   Fri Jan 18 09:14:04 2013 +0100

    net: can: esd_usb2: Do not do dma on the stack
    
    smatch reports the following warnings:
    drivers/net/can/usb/esd_usb2.c:640 esd_usb2_start() error: doing dma on the stack (&msg)
    drivers/net/can/usb/esd_usb2.c:846 esd_usb2_close() error: doing dma on the stack (&msg)
    drivers/net/can/usb/esd_usb2.c:855 esd_usb2_close() error: doing dma on the stack (&msg)
    drivers/net/can/usb/esd_usb2.c:923 esd_usb2_set_bittiming() error: doing dma on the stack (&msg)
    drivers/net/can/usb/esd_usb2.c:1047 esd_usb2_probe() error: doing dma on the stack (&msg)
    drivers/net/can/usb/esd_usb2.c:1053 esd_usb2_probe() error: doing dma on the stack (&msg)
    
    See "Documentation/DMA-API-HOWTO.txt" section "What memory is DMA'able?"
    
    Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
    Cc: Matthias Fuchs <matthias.fuchs@esd.eu>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

commit a90f13b24fb40d02d11496cce6a10ae8d4b319b2
Author: Jonas Peterson <jonas.peterson@gmail.com>
Date:   Tue May 7 22:05:23 2013 +0200

    net: can: kvaser_usb: fix reception on "USBcan Pro" and "USBcan R" type hardware.
    
    Unlike Kvaser Leaf light devices, some other Kvaser devices (like USBcan
    Pro, USBcan R) receive CAN messages in CMD_LOG_MESSAGE frames. This
    patch adds support for it.
    
    Cc: linux-stable <stable@vger.kernel.org> # >= v3.8
    Signed-off-by: Jonas Peterson <jonas.peterson@gmail.com>
    Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

commit 963afde9509c4bef1b06be7117d018a8da26480a
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri May 31 15:20:31 2013 +0200

    ALSA: hda/via - Clean up duplicated codes
    
    The previous commit was written in the way to make the backport to
    3.9.y easier, and left the duplicated open codes intentionally.
    Now let's clean up the duplicated codes.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 62bc82a82bb1e2b5ee5048c088af7260ddb2b7b5
Author: Michal Simek <michal.simek@xilinx.com>
Date:   Mon Jun 3 11:30:04 2013 +0200

    microblaze: Use static inline functions in cacheflush.h
    
    Using static inline functions ensure proper type checking
    which also remove compilation warning for no MMU
    
    Compilation warning:
    arch/microblaze/include/asm/cacheflush.h: warning: 'addr'
     may be used uninitialized in this function [-Wmaybe-uninitialized]
    
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>

commit 5a6f294e87974e6ec68d7113553ffd975d83bf15
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jun 3 11:17:38 2013 +0200

    ALSA: hda/via - Fix wrongly cleared pins after suspend on VT1802
    
    VIA driver has a special suspend handling only for VT1802 to reduce
    the pop noise.  During the transition to the generic parser, the
    behavior of snd_hda_set_pin_ctl() was also changed to modify the
    cached values, too.  And this caused a regression where the pin is
    still cleared even after the resume (including the resume from power
    save), resulting in the silent output.
    
    The fix is simply to replace snd_hda_set_pin_ctl() with the explicit
    call of snd_hda_codec_write() again.
    
    Reported-by: Alex Riesen <raa.lkml@gmail.com>
    Cc: <stable@vger.kernel.org> [v3.9]
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 05909d5c679cf7c9a8a5bc663677c066a546894f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri May 31 19:55:54 2013 +0200

    ALSA: hda - Add keep_eapd_on flag to generic parser
    
    VT1802 codec seems to reset EAPD of other pins in the hardware level,
    and this was another reason of the silent headphone output on some
    machines.  As a workaround, introduce a new flag indicating to keep
    the EPAD on to the generic parser, and set it in patch_via.c.
    
    Reported-by: Alex Riesen <raa.lkml@gmail.com>
    Cc: <stable@vger.kernel.org> [v3.9]
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 77afe0e94884ae40de29cd813a1fb7ddee583591
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri May 31 14:10:03 2013 +0200

    ALSA: hda - Allow setting automute/automic hooks after parsing
    
    Some codec drivers (VIA codecs and some Realtek fixups) set the
    automute and automic hooks after calling
    snd_hda_gen_parse_auto_config().  In the current code, the hook
    pointers are referred only in snd_hda_gen_parse_auto_config() and
    passed to snd_hda_jack_detect_enable_callback(), thus changing the
    hook values won't change the actually called callbacks properly.
    
    This patch fixes this bug by setting the static functions as the
    primary callback functions for the jack detection, and let them
    calling the appropriate hooks dynamically.
    
    Cc: <stable@vger.kernel.org> [v3.9]
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 087c2e3b4e062573dbbc8a50b9208992e3768dcf
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri May 31 13:54:10 2013 +0200

    ALSA: hda/via - Disable broken dynamic power control
    
    Since the transition to the generic parser, the actual routes used
    there don't match always with the assumed static paths in some
    set_widgets_power_state callbacks.  This results in the wrong power
    setup in the end.  As a temporary workaround, we need to disable the
    calls together with the non-functional dynamic power control enum.
    
    Reported-by: Alex Riesen <raa.lkml@gmail.com>
    Cc: <stable@vger.kernel.org> [v3.9]
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 768dc16397fb18c9de209cbcb84d890b8279faa7
Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date:   Tue May 28 17:17:45 2013 +0200

    arm: omap2: fix AM33xx hwmod infos for UART2
    
    The UART2 hwmod structure is pointing to the EDMA channels of UART1,
    which doesn't look right. This patch fixes this by making the UART2
    hwmod structure to a new structure that lists the EDMA channels to be
    used by the UART2.
    
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>
    [paul@pwsan.com: updated to apply]
    Signed-off-by: Paul Walmsley <paul@pwsan.com>

commit 91f8f105f2b82b4a38dee2d74760bc39d40ec42c
Author: Christopher Harvey <charvey@matrox.com>
Date:   Fri May 31 20:33:07 2013 +0000

    drm/mgag200: Add missing write to index before accessing data register
    
    This is a bug fix for some versions of g200se cards while doing
    mode-setting.
    
    Signed-off-by: Christopher Harvey <charvey@matrox.com>
    Tested-by: Julia Lemire <jlemire@matrox.com>
    Acked-by: Julia Lemire <jlemire@matrox.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dave Airlie <airlied@gmail.com>

commit b06f6a9d06f4b0fa38bd3e32714106d824470813
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri May 31 22:22:40 2013 +0000

    drm/nouveau: use mdelay instead of large udelay constants
    
    ARM cannot handle udelay for more than 2 miliseconds, so we
    should use mdelay instead for those.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: David Airlie <airlied@linux.ie>
    Cc: Ben Skeggs <bskeggs@redhat.com>
    Cc: dri-devel@lists.freedesktop.org
    Signed-off-by: Dave Airlie <airlied@gmail.com>

commit 1ed7fad6dbb211142cb61169d8d0bbbb049d4de1
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri May 31 22:22:47 2013 +0000

    drm/tilcd: select BACKLIGHT_LCD_SUPPORT
    
    The dependecies for BACKLIGHT_CLASS_DEVICE are defined a bit
    strange, but it seems one has to always select both BACKLIGHT_CLASS_DEVICE
    and BACKLIGHT_LCD_SUPPORT to avoid this error:
    
    drivers/gpu/drm/tilcdc/tilcdc_panel.c:396:
     undefined reference to `of_find_backlight_by_node'
    
    Cc: Rob Clark <robdclark@gmail.com>
    Cc: dri-devel@lists.freedesktop.org
    Cc: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Dave Airlie <airlied@gmail.com>

commit b7ea85a4fed37835eec78a7be3039c8dc22b8178
Author: Huacai Chen <chenhc@lemote.com>
Date:   Tue May 21 06:23:43 2013 +0000

    drm: fix a use-after-free when GPU acceleration disabled
    
    When GPU acceleration is disabled, drm_vblank_cleanup() will free the
    vblank-related data, such as vblank_refcount, vblank_inmodeset, etc.
    But we found that drm_vblank_post_modeset() may be called after the
    cleanup, which use vblank_refcount and vblank_inmodeset. And this will
    cause a kernel panic.
    
    Fix this by return immediately if dev->num_crtcs is zero. This is the
    same thing that drm_vblank_pre_modeset() does.
    
    Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup():
    [   62.628906] [<ffffffff804868d0>] drm_vblank_post_modeset+0x34/0xb4
    [   62.628906] [<ffffffff804c7008>] atombios_crtc_dpms+0xb4/0x174
    [   62.628906] [<ffffffff804c70e0>] atombios_crtc_commit+0x18/0x38
    [   62.628906] [<ffffffff8047f038>] drm_crtc_helper_set_mode+0x304/0x3cc
    [   62.628906] [<ffffffff8047f92c>] drm_crtc_helper_set_config+0x6d8/0x988
    [   62.628906] [<ffffffff8047dd40>] drm_fb_helper_set_par+0x94/0x104
    [   62.628906] [<ffffffff80439d14>] fbcon_init+0x424/0x57c
    [   62.628906] [<ffffffff8046a638>] visual_init+0xb8/0x118
    [   62.628906] [<ffffffff8046b9f8>] take_over_console+0x238/0x384
    [   62.628906] [<ffffffff80436df8>] fbcon_takeover+0x7c/0xdc
    [   62.628906] [<ffffffff8024fa20>] notifier_call_chain+0x44/0x94
    [   62.628906] [<ffffffff8024fcbc>] __blocking_notifier_call_chain+0x48/0x68
    [   62.628906] [<ffffffff8042d990>] register_framebuffer+0x228/0x260
    [   62.628906] [<ffffffff8047e010>] drm_fb_helper_single_fb_probe+0x260/0x314
    [   62.628906] [<ffffffff8047e2c4>] drm_fb_helper_initial_config+0x200/0x234
    [   62.628906] [<ffffffff804e5560>] radeon_fbdev_init+0xd4/0xf4
    [   62.628906] [<ffffffff804e0e08>] radeon_modeset_init+0x9bc/0xa18
    [   62.628906] [<ffffffff804bfc14>] radeon_driver_load_kms+0xdc/0x12c
    [   62.628906] [<ffffffff8048b548>] drm_get_pci_dev+0x148/0x238
    [   62.628906] [<ffffffff80423564>] local_pci_probe+0x5c/0xd0
    [   62.628906] [<ffffffff80241ac4>] work_for_cpu_fn+0x1c/0x30
    [   62.628906] [<ffffffff802427c8>] process_one_work+0x274/0x3bc
    [   62.628906] [<ffffffff80242934>] process_scheduled_works+0x24/0x44
    [   62.628906] [<ffffffff8024515c>] worker_thread+0x31c/0x3f4
    [   62.628906] [<ffffffff802497a8>] kthread+0x88/0x90
    [   62.628906] [<ffffffff80206794>] kernel_thread_helper+0x10/0x18
    
    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Signed-off-by: Binbin Zhou <zhoubb@lemote.com>
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
    Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
    Signed-off-by: Dave Airlie <airlied@gmail.com>

commit 056790923e1c4eed5d8cc502e1092944a2b23025
Author: Mark Brown <broonie@kernel.org>
Date:   Sat Jun 1 23:13:53 2013 +0100

    ASoC: pcm: Require both CODEC and CPU support when declaring stream caps
    
    When declaring playback and capture capabilities check for both CODEC
    side and CPU side support rather than only checking for CODEC side
    support.  While it is unusual some CPUs do have unidirectional DAIs.
    
    Reported-by: Fabio Estevam <fabio.estevam@freescale.com>
    Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
    Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>

commit 8706a6b6303dd75c7ee2baf2161de0f5a2fbdd8b
Author: Michal Simek <michal.simek@xilinx.com>
Date:   Thu May 30 15:10:52 2013 +0200

    microblaze: Fix sparse warnings
    
    arch/microblaze/include/asm/uaccess.h:101:3:
     warning: cast removes address space of expression
    arch/microblaze/include/asm/uaccess.h:107:2:
     warning: cast removes address space of expression
    
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>

commit 299018f44ac553dce3caf84df1d14c4764faa279
Author: Gleb Natapov <gleb@redhat.com>
Date:   Mon Jun 3 11:30:02 2013 +0300

    KVM: Fix race in apic->pending_events processing
    
    apic->pending_events processing has a race that may cause INIT and
    SIPI
    processing to be reordered:
    
    vpu0:                            vcpu1:
    set INIT
                                   test_and_clear_bit(KVM_APIC_INIT)
                                      process INIT
    set INIT
    set SIPI
                                   test_and_clear_bit(KVM_APIC_SIPI)
                                      process SIPI
    
    At the end INIT is left pending in pending_events. The following patch
    fixes this by latching pending event before processing them.
    
    Signed-off-by: Gleb Natapov <gleb@redhat.com>

commit 8acb42070ec4c87a9baab5c7bac626030d5bef28
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu May 30 16:35:55 2013 +0200

    KVM: fix sil/dil/bpl/spl in the mod/rm fields
    
    The x86-64 extended low-byte registers were fetched correctly from reg,
    but not from mod/rm.
    
    This fixes another bug in the boot of RHEL5.9 64-bit, but it is still
    not enough.
    
    Cc: <stable@vger.kernel.org> # 3.9
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Gleb Natapov <gleb@redhat.com>

commit 103f98ea64a1b0a67d8a1b23070b4db3533db2b8
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu May 30 13:22:39 2013 +0200

    KVM: Emulate multibyte NOP
    
    This is encountered when booting RHEL5.9 64-bit.  There is another bug
    after this one that is not a simple emulation failure, but this one lets
    the boot proceed a bit.
    
    Cc: <stable@vger.kernel.org> # 3.9
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Gleb Natapov <gleb@redhat.com>

commit d4cb9df5d1f79950b34e78ec5d1b1b59d6e9c7b7
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue May 14 12:11:34 2013 +0100

    ARM: KVM: be more thorough when invalidating TLBs
    
    The KVM/ARM MMU code doesn't take care of invalidating TLBs before
    freeing a {pte,pmd} table. This could cause problems if the page
    is reallocated and then speculated into by another CPU.
    
    Reported-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>

commit e8180dcaa8470ceca21109f143876fdcd9fe050a
Author: Andre Przywara <andre.przywara@linaro.org>
Date:   Thu May 9 00:28:06 2013 +0200

    ARM: KVM: prevent NULL pointer dereferences with KVM VCPU ioctl
    
    Some ARM KVM VCPU ioctls require the vCPU to be properly initialized
    with the KVM_ARM_VCPU_INIT ioctl before being used with further
    requests. KVM_RUN checks whether this initialization has been
    done, but other ioctls do not.
    Namely KVM_GET_REG_LIST will dereference an array with index -1
    without initialization and thus leads to a kernel oops.
    Fix this by adding checks before executing the ioctl handlers.
    
     [ Removed superflous comment from static function - Christoffer ]
    
    Changes from v1:
     * moved check into a static function with a meaningful name
    
    Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
    Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>

commit ed829857b36bc0155d85b661ab227df57ac898f3
Author: David Daney <david.daney@cavium.com>
Date:   Thu May 23 09:49:10 2013 -0700

    mips/kvm: Use ENOIOCTLCMD to indicate unimplemented ioctls.
    
    The Linux Way is to return -ENOIOCTLCMD to the vfs when an
    unimplemented ioctl is requested.  Do this in kvm_mips instead of a
    random mixture of -ENOTSUPP and -EINVAL.
    
    Signed-off-by: David Daney <david.daney@cavium.com>
    Acked-by: Sanjay Lal <sanjayl@kymasys.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit 4c73fb2b05192f2c817940b38015c36007379380
Author: David Daney <david.daney@cavium.com>
Date:   Thu May 23 09:49:09 2013 -0700

    mips/kvm: Fix ABI by moving manipulation of CP0 registers to KVM_{G,S}ET_ONE_REG
    
    Because not all 256 CP0 registers are ever implemented, we need a
    different method of manipulating them.  Use the
    KVM_SET_ONE_REG/KVM_GET_ONE_REG mechanism.
    
    Now unused code and definitions are removed.
    
    Signed-off-by: David Daney <david.daney@cavium.com>
    Acked-by: Sanjay Lal <sanjayl@kymasys.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit 8d17dd041a548b016ff401d36be6b2563c940ed5
Author: David Daney <david.daney@cavium.com>
Date:   Thu May 23 09:49:08 2013 -0700

    mips/kvm: Use ARRAY_SIZE() instead of hardcoded constants in kvm_arch_vcpu_ioctl_{s,g}et_regs
    
    Also we cannot set special zero register, so force it to zero.
    
    Signed-off-by: David Daney <david.daney@cavium.com>
    Acked-by: Sanjay Lal <sanjayl@kymasys.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit bf32ebf66d74e8a196256d7ac2a4f3c6938c614a
Author: David Daney <david.daney@cavium.com>
Date:   Thu May 23 09:49:07 2013 -0700

    mips/kvm: Fix name of gpr field in struct kvm_regs.
    
    Signed-off-by: David Daney <david.daney@cavium.com>
    Acked-by: Sanjay Lal <sanjayl@kymasys.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit 688cded320a4760de679160b42f9a81face02674
Author: David Daney <david.daney@cavium.com>
Date:   Thu May 23 09:49:06 2013 -0700

    mips/kvm: Fix ABI for use of 64-bit registers.
    
    All registers are 64-bits wide, 32-bit guests use the least
    significant portion of the register storage fields.
    
    Signed-off-by: David Daney <david.daney@cavium.com>
    Acked-by: Sanjay Lal <sanjayl@kymasys.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit 1f3dc6d76424538efb2095055035254b14499c77
Author: David Daney <david.daney@cavium.com>
Date:   Thu May 23 09:49:05 2013 -0700

    mips/kvm: Fix ABI for use of FPU.
    
    Define a non-empty struct kvm_fpu.
    
    Signed-off-by: David Daney <david.daney@cavium.com>
    Acked-by: Sanjay Lal <sanjayl@kymasys.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit a0c6d309c6df14655f9962f666d1da96318b0b7c
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Sun Jun 2 19:49:07 2013 +0200

    ALSA: usb-audio: fix Roland/Cakewalk UM-3G support
    
    Commit 927c9423dd5f2d1c0b93d5e694ab84b4a5559713 (ALSA: usb-audio: add
    Edirol UM-3G support) used a wrong quirk type, which would make the
    driver refuse to attach with the error message "MIDIStreaming interface
    descriptor not found".
    
    Cc: <stable@vger.kernel.org> # 3.3 and later
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit a08b9bc586a7810cdebbc316d5cbaed56a2a04a9
Author: Anson Huang <b20788@freescale.com>
Date:   Fri May 31 17:01:54 2013 -0400

    ARM: imx: clk-imx6q: AXI clock select index is incorrect
    
    The AXI clock mux should be as below:
    
    00: periph;
    01: pll2_pfd2_396m;
    10: periph;
    11: pll3_pfd1_540m;
    
    Signed-off-by: Anson Huang <b20788@freescale.com>
    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>

commit 01cb71d2d47b78354358e4bb938bb06323e17498
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Jun 2 13:55:05 2013 +0000

    net_sched: restore "overhead xxx" handling
    
    commit 56b765b79 ("htb: improved accuracy at high rates")
    broke the "overhead xxx" handling, as well as the "linklayer atm"
    attribute.
    
    tc class add ... htb rate X ceil Y linklayer atm overhead 10
    
    This patch restores the "overhead xxx" handling, for htb, tbf
    and act_police
    
    The "linklayer atm" thing needs a separate fix.
    
    Reported-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Vimalkumar <j.vimal@gmail.com>
    Cc: Jiri Pirko <jpirko@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit c87a124a5d5e8cf8e21c4363c3372bcaf53ea190
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Wed May 29 09:06:27 2013 +0000

    net: force a reload of first item in hlist_nulls_for_each_entry_rcu
    
    Roman Gushchin discovered that udp4_lib_lookup2() was not reloading
    first item in the rcu protected list, in case the loop was restarted.
    
    This produced soft lockups as in https://lkml.org/lkml/2013/4/16/37
    
    rcu_dereference(X)/ACCESS_ONCE(X) seem to not work as intended if X is
    ptr->field :
    
    In some cases, gcc caches the value or ptr->field in a register.
    
    Use a barrier() to disallow such caching, as documented in
    Documentation/atomic_ops.txt line 114
    
    Thanks a lot to Roman for providing analysis and numerous patches.
    
    Diagnosed-by: Roman Gushchin <klamm@yandex-team.ru>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Boris Zhmurov <zhmurov@yandex-team.ru>
    Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
    Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 13731d862cf5219216533a3b0de052cee4cc5038
Author: Jongsung Kim <neidhard.kim@lge.com>
Date:   Wed May 29 22:07:39 2013 -0600

    ARM: bcm2835: override the HW UART periphid
    
    Stephen Warren reported the recent commit 78506f2 (add support for
    extended FIFO-size of PL011-r1p5) breaks the serial port on the
    BCM2835 ARM SoC.
    
    A UART compatible with the ARM PL011-r1p5 should have 32-deep FIFOs.
    The BCM2835 UART just looks like an ARM PL011-r1p5, but has 16-deep
    FIFOs just like PL011-r1p4 or earlier revisions. As a workaround for
    this compatibility issue, this patch overrides the HW UART periphid
    register values with the actually compatible UART periphid 0x00241011
    (r1p3 or r1p4).
    
    Reported-by: Stephen Warren <swarren@wwwdotorg.org>
    Signed-off-by: Jongsung Kim <neidhard.kim@lge.com>
    Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
    Signed-off-by: Olof Johansson <olof@lixom.net>

commit d683b96b072dc4680fc74964eca77e6a23d1fa6e
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Jun 2 17:11:17 2013 +0900

    Linux 3.10-rc4

commit 52a2a1087b5924de00484f35ef5e2a73f61dbd22
Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date:   Sat Jun 1 02:38:35 2013 +0400

    sata_rcar: fix interrupt handling
    
    The driver's interrupt handling code is too picky in deciding whether it should
    handle an interrupt or not which causes completely unneeded spurious interrupts.
    Thus make sata_rcar_{ata|serr}_interrupt() *void*; add ATA status register read
    to sata_rcar_ata_interrupt() to clear an unexpected ATA interrupt -- it doesn't
    get cleared by writing to the SATAINTSTAT register in the interrupt mode we use.
    
    Also, in sata_rcar_ata_interrupt() we should check SATAINTSTAT register only for
    enabled interrupts and we should clear  only those interrupts  that we have read
    as active first time around, because else we have  a  race and risk clearing  an
    interrupt that  can  occur between read  and write of the  SATAINTSTAT  register
    and never registering it...
    
    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: stable@vger.kernel.org

commit 780a6ec640a3fed671fc2c40e4dd30c03eca3ac3
Author: Ash Willis <ashwillis.kernel@gmail.com>
Date:   Wed May 29 01:27:59 2013 +0000

    ACPI / video: ignore BIOS initial backlight value for HP Pavilion g6
    
    This patch addresses kernel bug 56661. BIOS reports an incorrect
    backlight value, causing the driver to switch off the backlight
    completely during startup. This patch ignores the incorrect value from
    BIOS.
    
    References: https://bugzilla.kernel.org/show_bug.cgi?id=56661
    Signed-off-by: Ash Willis <ashwillis@programmer.net>
    Cc: All <stable@vger.kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit fedbe9bc6fd3e14b1ffbb3dac407777ac4a3650c
Author: Alex Hung <alex.hung@canonical.com>
Date:   Tue May 28 02:05:09 2013 +0000

    ACPI / video: ignore BIOS initial backlight value for HP m4
    
    On HP m4 lapops, BIOS reports minimum backlight on boot and
    causes backlight to dim completely. This ignores the initial backlight
    values and set to max brightness.
    
    References: https://bugs.launchpad.net/bugs/1184501
    Cc: All <stable@vger.kernel.org>
    Signed-off-by: Alex Hung <alex.hung@canonical.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit af1d486c18bad7820b0ca52b413458914231102c
Author: lan,Tianyu <tianyu.lan@intel.com>
Date:   Tue May 28 02:25:33 2013 +0000

    x86 / platform / hp_wmi: Fix bluetooth_rfkill misuse in hp_wmi_rfkill_setup()
    
    HP wmi platform driver fails to initialize GPS and causes poweroff
    failure in HP Elitebook 6930p.
    
    Call Trace:
     [<ffffffffa088d25a>] hp_wmi_bios_setup+0x25a/0x3a0 [hp_wmi]
     [<ffffffff8135978c>] platform_drv_probe+0x3c/0x70
     [<ffffffff81356d6a>] ? driver_sysfs_add+0x7a/0xb0
     [<ffffffff81357407>] driver_probe_device+0x87/0x3a0
     [<ffffffff813577f3>] __driver_attach+0x93/0xa0
     [<ffffffff81357760>] ? __device_attach+0x40/0x40
     [<ffffffff81355403>] bus_for_each_dev+0x63/0xa0
     [<ffffffff81356e8e>] driver_attach+0x1e/0x20
     [<ffffffff81356a28>] bus_add_driver+0x1f8/0x2b0
     [<ffffffff81357e81>] driver_register+0x71/0x150
     [<ffffffff813594e6>] platform_driver_register+0x46/0x50
     [<ffffffff813595ab>] platform_driver_probe+0x1b/0xa0
     [<ffffffffa088d55e>] hp_wmi_init+0x1be/0x1fb [hp_wmi]
     [<ffffffffa088d3a0>] ? hp_wmi_bios_setup+0x3a0/0x3a0 [hp_wmi]
     [<ffffffff8100210a>] do_one_initcall+0x10a/0x160
     [<ffffffff810bdac6>] load_module+0x1b46/0x2640
     [<ffffffff8128da20>] ? ddebug_proc_write+0xf0/0xf0
     [<ffffffff810be662>] sys_init_module+0xa2/0xf0
     [<ffffffff814d975d>] system_call_fastpath+0x1a/0x1f
    Code: 48 ff ff ff 80 7b 24 00 74 d2 41 83 e5 01 45 38 ec 74 c9 48 8d bb a0 03 00 00 e8 ed fb aa e0 5b 41 5c 41 5d 44 89 f0 41 5e 5d c3 <0f> 0b 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66
    RIP  [<ffffffffa05c57af>] rfkill_set_hw_state+0x9f/0xb0 [rfkill]
     RSP <ffff880071523b60>
    
    Check code and find this error is caused by misusing variable bluetooth_rfkill
    where gps_rfkill should be.
    
    Reported-and-tested-by: Iru Cai <mytbk920423@gmail.com>
    References: https://bugzilla.kernel.org/show_bug.cgi?id=58401
    Cc: All <stable@vger.kernel.org>
    Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit d9f1f489c034829c1082c0e7efa09450e716d23e
Author: Mark Brown <broonie@linaro.org>
Date:   Sat Jun 1 19:31:15 2013 +0100

    MAINTAINERS: Remove myself from Wolfson maintainers
    
    I no longer work for Wolfson.
    
    Signed-off-by: Mark Brown <broonie@linaro.org>

commit f3284f91535cc2e1406b7efe27a1de96c96c19b4
Author: Maarten ter Huurne <maarten@treewalker.org>
Date:   Fri May 31 16:45:13 2013 +0200

    regmap: rbtree: Fixed node range check on sync
    
    A node starting before the minimum register is no reason to reject it,
    since its end could be in range. The check for the end already exists
    two lines lower, so we can just remove the incorrect check.
    
    Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
    Signed-off-by: Mark Brown <broonie@linaro.org>

commit 4edb38695d9a3cd62739f8595e21f36f0aabf4c2
Author: Helge Deller <deller@gmx.de>
Date:   Thu May 30 21:06:39 2013 +0000

    parisc: parport0: fix this legacy no-device port driver!
    
    Fix the above kernel error from parport_announce_port() on 32bit GSC
    machines (e.g. B160L). The parport driver requires now a pointer to the
    device struct.
    
    Signed-off-by: Helge Deller <deller@gmx.de>

commit c218c713c56b01d4a1cd69390f675cc44857f5fd
Author: Helge Deller <deller@gmx.de>
Date:   Thu May 30 16:24:46 2013 +0000

    parport_pc: disable PARPORT_PC_SUPERIO on parisc architecture
    
    If enabled, CONFIG_PARPORT_PC_SUPERIO scans on PC-like hardware for
    various super-io chips by accessing i/o ports in a range which will
    crash any parisc hardware at once.
    
    In addition, parisc has it's own incompatible superio chip
    (CONFIG_SUPERIO), so if we disable PARPORT_PC_SUPERIO completely for
    parisc we can avoid that people by accident enable the parport_pc
    superio option too.
    
    Signed-off-by: Helge Deller <deller@gmx.de>

commit b204a4d2d4f2061659bb5c33f5a4013fb0f6ffbe
Author: Helge Deller <deller@gmx.de>
Date:   Fri May 31 22:24:58 2013 +0000

    parisc/PCI: lba: fix: convert to pci_create_root_bus() for correct root bus resources (v2)
    
    commit dc7dce280a
    Author: Bjorn Helgaas <bhelgaas@google.com>
    Date:   Fri Oct 28 16:27:27 2011 -0600
       parisc/PCI: lba: convert to pci_create_root_bus() for correct root bus
                        resources
    
      Supply root bus resources to pci_create_root_bus() so they're correct
      immediately.  This fixes the problem of "early" and "header" quirks seeing
      incorrect root bus resources.
    
    added tests for elmmio_space.start while it should use
    elmmio_space.flags.  This for example led to incorrect resource
    assignments and a non-working stifb framebuffer on most parisc machines.
    
    LBA 10:1: PCI host bridge to bus 0000:01
    pci_bus 0000:01: root bus resource [io  0x12000-0x13fff] (bus address [0x2000-0x3fff])
    pci_bus 0000:01: root bus resource [mem 0xfffffffffa000000-0xfffffffffbffffff] (bus address [0xfa000000-0xfbffffff])
    pci_bus 0000:01: root bus resource [mem 0xfffffffff4800000-0xfffffffff4ffffff] (bus address [0xf4800000-0xf4ffffff])
    pci_bus 0000:01: root bus resource [??? 0x00000001 flags 0x0]
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>

commit b47d4934e71d918814aee4a1d0211f81329b767e
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Thu May 30 11:45:39 2013 -0600

    parisc/PCI: Set type for LBA bus_num resource
    
    The non-PAT resource probing code failed to set the type of the LBA bus_num
    resource (30aa80da43 "parisc/PCI: register busn_res for root buses" did
    the corresponding thing for the PAT case).
    
    This causes incorrect resource assignments and a non-working stifb
    framebuffer on most parisc machines.
    
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Helge Deller <deller@gmx.de>

commit 2b6bac9ee99fa7d60dfa0debd82ccf4217931b1e
Author: Helge Deller <deller@gmx.de>
Date:   Thu May 30 13:48:07 2013 +0000

    MAINTAINERS: update parisc architecture file list
    
    Signed-off-by: Helge Deller <deller@gmx.de>

commit ea99b1adf22abd62bdcf14b1c9a0a4d3664eefd8
Author: Chen Gang <gang.chen@asianux.com>
Date:   Thu May 30 01:18:43 2013 +0000

    parisc: kernel: using strlcpy() instead of strcpy()
    
    'boot_args' is an input args, and 'boot_command_line' has a fix length.
    So use strlcpy() instead of strcpy() to avoid memory overflow.
    
    Signed-off-by: Chen Gang <gang.chen@asianux.com>
    Acked-by: Kyle McMartin <kyle@mcmartin.ca>
    Signed-off-by: Helge Deller <deller@gmx.de>

commit 766039022a480ede847659daaa78772bdcc598ae
Author: Paul Bolle <pebolle@tiscali.nl>
Date:   Wed May 29 09:56:58 2013 +0000

    parisc: rename "CONFIG_PA7100" to "CONFIG_PA7000"
    
    There's a Makefile line setting cflags for CONFIG_PA7100. But that
    Kconfig macro doesn't exist. There is a Kconfig symbol PA7000, which
    covers both PA7000 and PA7100 processors. So let's use the corresponding
    Kconfig macro.
    
    Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
    Signed-off-by: Helge Deller <deller@gmx.de>

commit ae249b5fa27f9fba25aa59664d4338efc2dd2394
Author: Helge Deller <deller@gmx.de>
Date:   Tue May 28 20:35:54 2013 +0000

    parisc: fix kernel BUG at arch/parisc/include/asm/mmzone.h:50
    
    With CONFIG_DISCONTIGMEM=y and multiple physical memory areas,
    cat /proc/kpageflags triggers this kernel bug:
    
    kernel BUG at arch/parisc/include/asm/mmzone.h:50!
    CPU: 2 PID: 7848 Comm: cat Tainted: G      D W 3.10.0-rc3-64bit #44
     IAOQ[0]: kpageflags_read0x128/0x238
     IAOQ[1]: kpageflags_read0x12c/0x238
     RP(r2): proc_reg_read0xbc/0x130
    Backtrace:
     [<00000000402ca2d4>] proc_reg_read0xbc/0x130
     [<0000000040235bcc>] vfs_read0xc4/0x1d0
     [<0000000040235f0c>] SyS_read0x94/0xf0
     [<0000000040105fc0>] syscall_exit0x0/0x14
    
    kpageflags_read() walks through the whole memory, even if some memory
    areas are physically not available. So, we should better not BUG on an
    unavailable pfn in pfn_to_nid() but just return the expected value -1 or
    0.
    
    Signed-off-by: Helge Deller <deller@gmx.de>

commit 3f108de96ba449a8df3d7e3c053bf890fee2cb95
Author: Chen Gang <gang.chen@asianux.com>
Date:   Mon May 27 04:57:09 2013 +0000

    parisc: memory overflow, 'name' length is too short for using
    
    'path.bc[i]' can be asigned by PCI_SLOT() which can '> 10', so sizeof(6
    * "%u:" + "%u" + '\0') may be 21.
    
    Since 'name' length is 20, it may be memory overflow.
    
    And 'path.bc[i]' is 'unsigned char' for printing, we can be sure the
    max length of 'name' must be less than 28.
    
    So simplify thinking, we can use 28 instead of 20 directly, and do not
    think of whether 'patchc.bc[i]' can '> 100'.
    
    Signed-off-by: Chen Gang <gang.chen@asianux.com>
    Signed-off-by: Helge Deller <deller@gmx.de>

commit c802db1164f28e62c6a43132b8d290cb8113f2ac
Author: Haiyang Zhang <haiyangz@microsoft.com>
Date:   Tue May 28 06:15:56 2013 +0000

    hyperv: Fix vlan_proto setting in netvsc_recv_callback()
    
    Since the recent addition of 8021AD, we need to set the new field vlan_proto in
    sk_buff. Otherwise, it will trigger BUG() call in vlan_proto_idx().
    
    This patch fixes the problem.
    
    Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
    Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 3f3e7ce4ff87c8ea69acaa7700699fb26baa2914
Author: Jiri Pirko <jiri@resnulli.us>
Date:   Wed May 29 05:02:57 2013 +0000

    team: fix port list dump for big number of ports
    
    In case the port list dump does not fit into one skb currently the
    dump would start over again. Fix this by continue from the last dumped
    port.
    
    Introduced by commit d90f889e9c (team: handle sending port list in the
    same way option list is sent)
    
    Signed-off-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 6d7581e62f8be462440d7b22c6361f7c9fa4902b
Author: Jiri Pirko <jiri@resnulli.us>
Date:   Wed May 29 05:02:56 2013 +0000

    list: introduce list_first_entry_or_null
    
    non-rcu variant of list_first_or_null_rcu
    
    Signed-off-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit e4e8536f65b51ce91c30588b0925872bdfc60d03
Author: Paul Moore <pmoore@redhat.com>
Date:   Wed May 29 07:36:32 2013 +0000

    selinux: fix the labeled xfrm/IPsec reference count handling
    
    The SELinux labeled IPsec code was improperly handling its reference
    counting, dropping a reference on a delete operation instead of on a
    free/release operation.
    
    Reported-by: Ondrej Moris <omoris@redhat.com>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit e4c1721642bbd42d8142f4811cde0588c28db51d
Author: Paul Moore <pmoore@redhat.com>
Date:   Wed May 29 07:36:25 2013 +0000

    xfrm: force a garbage collection after deleting a policy
    
    In some cases after deleting a policy from the SPD the policy would
    remain in the dst/flow/route cache for an extended period of time
    which caused problems for SELinux as its dynamic network access
    controls key off of the number of XFRM policy and state entries.
    This patch corrects this problem by forcing a XFRM garbage collection
    whenever a policy is sucessfully removed.
    
    Reported-by: Ondrej Moris <omoris@redhat.com>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 1e2bd517c108816220f262d7954b697af03b5f9c
Author: Pravin B Shelar <pshelar@nicira.com>
Date:   Thu May 30 06:45:27 2013 +0000

    udp6: Fix udp fragmentation for tunnel traffic.
    
    udp6 over GRE tunnel does not work after to GRE tso changes. GRE
    tso handler passes inner packet but keeps track of outer header
    start in SKB_GSO_CB(skb)->mac_offset.  udp6 fragment need to
    take care of outer header, which start at the mac_offset, while
    adding fragment header.
    This bug is introduced by commit 68c3316311 (GRE: Add TCP
    segmentation offload for GRE).
    
    Reported-by: Dmitry Kravkov <dkravkov@gmail.com>
    Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
    Tested-by: Dmitry Kravkov <dmitry@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit b190a50875b95e58ebe2b00ed3bf7f1d44961471
Author: Jay Vosburgh <fubar@us.ibm.com>
Date:   Fri May 31 11:57:29 2013 +0000

    net/core: dev_mc_sync_multiple calls wrong helper
    
    The dev_mc_sync_multiple function is currently calling
    __hw_addr_sync, and not __hw_addr_sync_multiple.  This will result in
    addresses only being synced to the first device from the set.
    
    	Corrected by calling the _multiple variant.
    
    Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
    Reviewed-by: Vlad Yasevich <vyasevic@redhat.com>
    Tested-by: Shawn Bohrer <sbohrer@rgmadvisors.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 29ca2f8fcc721517b83d0a560c47cee2dde827a6
Author: Jay Vosburgh <fubar@us.ibm.com>
Date:   Fri May 31 11:57:28 2013 +0000

    net/core: __hw_addr_sync_one / _multiple broken
    
    Currently, __hw_addr_sync_one is called in a loop by
    __hw_addr_sync_multiple to sync each of a "from" device's hw addresses
    to a "to" device.  __hw_addr_sync_one calls __hw_addr_add_ex to attempt
    to add each address.  __hw_addr_add_ex is called with global=false, and
    sync=true.
    
    	__hw_addr_add_ex checks to see if the new address matches an
    address already on the list.  If so, it tests global and sync.  In this
    case, sync=true, and it then checks if the address is already synced,
    and if so, returns 0.
    
    	This 0 return causes __hw_addr_sync_one to increment the sync_cnt
    and refcount for the "from" list's address entry, even though the address
    is already synced and has a reference and sync_cnt.  This will cause
    the sync_cnt and refcount to increment without bound every time an
    addresses is added to the "from" device and synced to the "to" device.
    
    	The fix here has two parts:
    
    	First, when __hw_addr_add_ex finds the address already exists
    and is synced, return -EEXIST instead of 0.
    
    	Second, __hw_addr_sync_one checks the error return for -EEXIST,
    and if so, it (a) does not add a refcount/sync_cnt, and (b) returns 0
    itself so that __hw_addr_sync_multiple will not return an error.
    
    Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
    Reviewed-by: Vlad Yasevich <vyasevic@redhat.com>
    Tested-by: Shawn Bohrer <sbohrer@rgmadvisors.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 60ba834c2fb65f2fafee47e03c258fac579d0591
Author: Jay Vosburgh <fubar@us.ibm.com>
Date:   Fri May 31 11:57:27 2013 +0000

    net/core: __hw_addr_unsync_one "from" address not marked synced
    
    When an address is added to a subordinate interface (the "to"
    list), the address entry in the "from" list is not marked "synced" as
    the entry added to the "to" list is.
    
    	When performing the unsync operation (e.g., dev_mc_unsync),
    __hw_addr_unsync_one calls __hw_addr_del_entry with the "synced"
    parameter set to true for the case when the address reference is being
    released from the "from" list.  This causes a test inside to fail,
    with the result being that the reference count on the "from" address
    is not properly decremeted and the address on the "from" list will
    never be freed.
    
    	Correct this by having __hw_addr_unsync_one call the
    __hw_addr_del_entry function with the "sync" flag set to false for the
    "remove from the from list" case.
    
    Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
    Reviewed-by: Vlad Yasevich <vyasevic@redhat.com>
    Tested-by: Shawn Bohrer <sbohrer@rgmadvisors.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 9747ba6636be8a7e8ba83a1fb231d061ca318e4f
Author: Jay Vosburgh <fubar@us.ibm.com>
Date:   Fri May 31 11:57:26 2013 +0000

    net/core: __hw_addr_create_ex does not initialize sync_cnt
    
    The sync_cnt field is not being initialized, which can result
    in arbitrary values in the field.  Fixed by initializing it to zero.
    
    Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
    Reviewed-by: Vlad Yasevich <vyasevic@redhat.com>
    Tested-by: Shawn Bohrer <sbohrer@rgmadvisors.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit badec11b645e21acbc2411d7759e3efa559af443
Author: Will Schmidt <will_schmidt@vnet.ibm.com>
Date:   Mon May 20 05:04:18 2013 +0000

    powerpc/cputable: Fix typo on P7+ cputable entry
    
    Fix a typo in setting COMMON_USER2_POWER7 bits to .cpu_user_features2
    cpu specs table.
    
    Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
    Acked-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit fda3f402f446e82204266f4a3bf26912f2d55e75
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Fri May 31 05:37:57 2013 +0000

    snmp6: remove IPSTATS_MIB_CSUMERRORS
    
    This stat is not relevant in IPv6, there is no checksum in IPv6 header.
    Just leave a comment to explain the hole.
    
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 58a032c3b106adcd2b83b7e631de3b79f238cdd2
Author: Michael Ellerman <michael@ellerman.id.au>
Date:   Wed May 15 20:19:31 2013 +0000

    powerpc/perf: Add missing SIER support
    
    Commit 8f61aa3 "Add support for SIER" missed updates to siar_valid()
    and perf_get_data_addr().
    
    In both cases we need to check the SIER instead of mmcra.
    
    Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit cbda6aa10bd2d97e38f4d26a03a0b2183ad580ba
Author: Michael Ellerman <michael@ellerman.id.au>
Date:   Wed May 15 20:19:30 2013 +0000

    powerpc/perf: Revert to original NO_SIPR logic
    
    This is a revert and then some of commit 860aad7 "Add regs_no_sipr()".
    This workaround was only needed on early chip versions.
    
    As before NO_SIPR becomes a static flag of the PMU struct.
    
    Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit 858957ab1e3a7ee29ed40309bdf0f1b7bcf5bf30
Author: Kevin Hao <haokexin@gmail.com>
Date:   Thu May 16 20:58:42 2013 +0000

    powerpc/pci: Remove the unused variables in pci_process_bridge_OF_ranges
    
    The codes which ever used these two variables have gone. Throw away
    them too.
    
    Signed-off-by: Kevin Hao <haokexin@gmail.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit 279838960484fa22d903086eea743a6b6700647d
Author: Kevin Hao <haokexin@gmail.com>
Date:   Thu May 16 20:58:41 2013 +0000

    powerpc/pci: Remove the stale comments of pci_process_bridge_OF_ranges
    
    These comments already don't apply to the current code. So just remove
    them.
    
    Signed-off-by: Kevin Hao <haokexin@gmail.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit f274ef8747d3be649bba8708696fb31cb00fa75a
Author: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Date:   Tue May 21 09:32:48 2013 +0000

    powerpc/pseries: Always enable CONFIG_HOTPLUG_CPU on PSERIES SMP
    
    Adam Lackorzynski reported the following build failure on
    !CONFIG_HOTPLUG_CPU configuration:
    
      CC      arch/powerpc/kernel/rtas.o
    arch/powerpc/kernel/rtas.c: In function ‘rtas_cpu_state_change_mask’:
    arch/powerpc/kernel/rtas.c:843:4: error: implicit declaration of function ‘cpu_down’ [-Werror=implicit-function-declaration]
    cc1: all warnings being treated as errors
    make[1]: *** [arch/powerpc/kernel/rtas.o] Error 1
    make: *** [arch/powerpc/kernel] Error 2
    
    The build fails because cpu_down() is defined only under CONFIG_HOTPLUG_CPU.
    
    Looking further, the mobility code in pseries is one of the call-sites which
    uses rtas_ibm_suspend_me(), which in turn calls rtas_cpu_state_change_mask().
    And the mobility code is unconditionally compiled-in (it does not fall under
    any Kconfig option). And commit 120496ac (powerpc: Bring all threads online
    prior to migration/hibernation) which introduced this build regression is
    critical for the proper functioning of the migration code. So it appears
    that the only solution to this problem is to enable CONFIG_HOTPLUG_CPU if
    SMP is enabled on PPC_PSERIES platforms. So make that change in the Kconfig.
    
    Reported-by: Adam Lackorzynski <adam@os.inf.tu-dresden.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit 8e44ddc3f34d22c55f2977ac8b160609935d37ca
Author: Paul Mackerras <paulus@samba.org>
Date:   Thu May 23 15:42:21 2013 +0000

    powerpc/kvm/book3s: Add support for H_IPOLL and H_XIRR_X in XICS emulation
    
    This adds the remaining two hypercalls defined by PAPR for manipulating
    the XICS interrupt controller, H_IPOLL and H_XIRR_X.  H_IPOLL returns
    information about the priority and pending interrupts for a virtual
    cpu, without changing any state.  H_XIRR_X is like H_XIRR in that it
    reads and acknowledges the highest-priority pending interrupt, but it
    also returns the timestamp (timebase register value) from when the
    interrupt was first received by the hypervisor.  Currently we just
    return the current time, since we don't do any software queueing of
    virtual interrupts inside the XICS emulation code.
    
    These hcalls are not currently used by Linux guests, but may be in
    future.
    
    Signed-off-by: Paul Mackerras <paulus@samba.org>
    Acked-by: Scott Wood <scottwood@freescale.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit f7b3367774f92a688d39ed767f0ae9b93af7873a
Author: Priyanka Jain <Priyanka.Jain@freescale.com>
Date:   Fri May 31 01:20:02 2013 +0000

    powerpc/32bit:Store temporary result in r0 instead of r8
    
    Commit a9c4e541ea9b22944da356f2a9258b4eddcc953b
    "powerpc/kprobe: Complete kprobe and migrate exception frame"
    introduced a regression:
    
    While returning from exception handling in case of PREEMPT enabled,
    _TIF_NEED_RESCHED bit is checked in TI_FLAGS (thread_info flag) of current
    task. Only if this bit is set, it should continue with the process of
    calling preempt_schedule_irq() to schedule highest priority task if
    available.
    
    Current code assumes that r8 contains TI_FLAGS and check this for
    _TIF_NEED_RESCHED, but as r8 is modified in the code which executes before
    this check, r8 no longer contains the expected TI_FLAGS information.
    
    As a result check for comparison with _TIF_NEED_RESCHED was failing even if
    NEED_RESCHED bit is set in the current thread_info flag. Due to this,
    preempt_schedule_irq() and in turn scheduler was not getting called even if
    highest priority task is ready for execution.
    
    So, store temporary results in r0 instead of r8 to prevent r8 from getting
    modified as subsequent code is dependent on its value.
    
    Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
    CC: <stable@vger.kernel.org> [v3.7+]
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit 0608d692463598c1d6e826d9dd7283381b4f246c
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Date:   Fri May 31 01:03:24 2013 +0000

    powerpc/mm: Always invalidate tlb on hpte invalidate and update
    
    If a hash bucket gets full, we "evict" a more/less random entry from it.
    When we do that we don't invalidate the TLB (hpte_remove) because we assume
    the old translation is still technically "valid". This implies that when
    we are invalidating or updating pte, even if HPTE entry is not valid
    we should do a tlb invalidate.
    
    This was a regression introduced by b1022fbd293564de91596b8775340cf41ad5214c
    
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit 280a5ba22ca35575721d42e536176a3561f4ec43
Author: Michael Neuling <mikey@neuling.org>
Date:   Wed May 29 19:34:29 2013 +0000

    powerpc/pseries: Improve stream generation comments in copypage/user
    
    No code changes, just documenting what's happening a little better.
    
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit a515348fc69fd1d9e8ebd34a16f1026d7fe32048
Author: Michael Neuling <mikey@neuling.org>
Date:   Wed May 29 19:34:27 2013 +0000

    powerpc/pseries: Kill all prefetch streams on context switch
    
    On context switch, we should have no prefetch streams leak from one
    userspace process to another.  This frees up prefetch resources for the
    next process.
    
    Based on patch from Milton Miller.
    
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit 2ac6f427ad837a69561160b282eff80d9f0c2466
Author: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Date:   Tue May 28 10:39:50 2013 +0000

    powerpc/cputable: Fix oprofile_cpu_type on power8
    
    Maynard informed me that neither the oprofile kernel module nor oprofile
    userspace has been updated to support that "legacy" oprofile module
    interface for power8, which is indicated by "ppc64/power8." This results
    in no samples. The solution is to default to the "timer" type, instead.
    The raw entry also should be updated, as "ppc64/ibm-compat-v1" indicates
    to oprofile userspace to use "compatibility events" which are obsolete
    in ISA 2.07.
    
    Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit e242114afff0a41550e174cd787cdbafd34625de
Author: chenhui zhao <chenhui.zhao@freescale.com>
Date:   Mon May 27 21:59:43 2013 +0000

    powerpc/mpic: Fix irq distribution problem when MPIC_SINGLE_DEST_CPU
    
    For the mpic with a flag MPIC_SINGLE_DEST_CPU, only one bit should be
    set in interrupt destination registers.
    
    The code is applicable to 64-bit platforms as well as 32-bit.
    
    Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit 2b3f8e87cf99a33fb6faf5026d7147748bbd77b6
Author: Michael Neuling <mikey@neuling.org>
Date:   Sun May 26 18:09:41 2013 +0000

    powerpc/tm: Fix userspace stack corruption on signal delivery for active transactions
    
    When in an active transaction that takes a signal, we need to be careful with
    the stack.  It's possible that the stack has moved back up after the tbegin.
    The obvious case here is when the tbegin is called inside a function that
    returns before a tend.  In this case, the stack is part of the checkpointed
    transactional memory state.  If we write over this non transactionally or in
    suspend, we are in trouble because if we get a tm abort, the program counter
    and stack pointer will be back at the tbegin but our in memory stack won't be
    valid anymore.
    
    To avoid this, when taking a signal in an active transaction, we need to use
    the stack pointer from the checkpointed state, rather than the speculated
    state.  This ensures that the signal context (written tm suspended) will be
    written below the stack required for the rollback.  The transaction is aborted
    becuase of the treclaim, so any memory written between the tbegin and the
    signal will be rolled back anyway.
    
    For signals taken in non-TM or suspended mode, we use the
    normal/non-checkpointed stack pointer.
    
    Tested with 64 and 32 bit signals
    
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Cc: <stable@vger.kernel.org> # v3.9
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit b75c100ef24894bd2c8b52e123bcc5f191c5d9fd
Author: Michael Neuling <mikey@neuling.org>
Date:   Sun May 26 18:30:56 2013 +0000

    powerpc/tm: Move TM abort cause codes to uapi
    
    These cause codes are usable by userspace, so let's export to uapi.
    
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Cc: <stable@vger.kernel.org> # v3.9
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit 6ce6c629fd8254b3177650de99699682ff7f6707
Author: Michael Neuling <mikey@neuling.org>
Date:   Sun May 26 18:09:39 2013 +0000

    powerpc/tm: Abort on emulation and alignment faults
    
    If we are emulating an instruction inside an active user transaction that
    touches memory, the kernel can't emulate it as it operates in transactional
    suspend context.  We need to abort these transactions and send them back to
    userspace for the hardware to rollback.
    
    We can service these if the user transaction is in suspend mode, since the
    kernel will operate in the same suspend context.
    
    This adds a check to all alignment faults and to specific instruction
    emulations (only string instructions for now).  If the user process is in an
    active (non-suspended) transaction, we abort the transaction go back to
    userspace allowing the HW to roll back the transaction and tell the user of the
    failure.  This also adds new tm abort cause codes to report the reason of the
    persistent error to the user.
    
    Crappy test case here http://neuling.org/devel/junkcode/aligntm.c
    
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Cc: <stable@vger.kernel.org> # v3.9
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit 24b92375dc4ec8a15262e8aaaab60b7404d4b1e7
Author: Michael Neuling <mikey@neuling.org>
Date:   Sun May 26 18:09:38 2013 +0000

    powerpc/tm: Update cause codes documentation
    
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Cc: <stable@vger.kernel.org> # 3.9 only
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit 35f7097fcedec63fcba1852dbee96f74a2d90878
Author: Michael Neuling <mikey@neuling.org>
Date:   Sun May 26 18:09:37 2013 +0000

    powerpc/tm: Make room for hypervisor in abort cause codes
    
    PAPR carves out 0xff-0xe0 for hypervisor use of transactional memory software
    abort cause codes.  Unfortunately we don't respect this currently.
    
    Below fixes this to move our cause codes to below this region.
    
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Cc: <stable@vger.kernel.org> # 3.9 only
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit 1fc29bacedeabb278080e31bb9c1ecb49f143c3b
Author: Jeff Layton <jlayton@redhat.com>
Date:   Fri May 31 10:00:18 2013 -0400

    cifs: fix off-by-one bug in build_unc_path_to_root
    
    commit 839db3d10a (cifs: fix up handling of prefixpath= option) changed
    the code such that the vol->prepath no longer contained a leading
    delimiter and then fixed up the places that accessed that field to
    account for that change.
    
    One spot in build_unc_path_to_root was missed however. When doing the
    pointer addition on pos, that patch failed to account for the fact that
    we had already incremented "pos" by one when adding the length of the
    prepath. This caused a buffer overrun by one byte.
    
    This patch fixes the problem by correcting the handling of "pos".
    
    Cc: <stable@vger.kernel.org> # v3.8+
    Reported-by: Marcus Moeller <marcus.moeller@gmx.ch>
    Reported-by: Ken Fallon <ken.fallon@gmail.com>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>

commit a1457c0ce976bad1356b9b0437f2a5c3ab8a9cfc
Author: Jeff Mahoney <jeffm@suse.com>
Date:   Fri May 31 15:51:17 2013 -0400

    reiserfs: fix deadlock with nfs racing on create/lookup
    
    Reiserfs is currently able to be deadlocked by having two NFS clients
    where one has removed and recreated a file and another is accessing the
    file with an open file handle.
    
    If one client deletes and recreates a file with timing such that the
    recreated file obtains the same [dirid, objectid] pair as the original
    file while another client accesses the file via file handle, the create
    and lookup can race and deadlock if the lookup manages to create the
    in-memory inode first.
    
    The create thread, in insert_inode_locked4, will hold the write lock
    while waiting on the other inode to be unlocked. The lookup thread,
    anywhere in the iget path, will release and reacquire the write lock while
    it schedules. If it needs to reacquire the lock while the create thread
    has it, it will never be able to make forward progress because it needs
    to reacquire the lock before ultimately unlocking the inode.
    
    This patch drops the write lock across the insert_inode_locked4 call so
    that the ordering of inode_wait -> write lock is retained. Since this
    would have been the case before the BKL push-down, this is safe.
    
    Signed-off-by: Jeff Mahoney <jeffm@suse.com>
    Signed-off-by: Jan Kara <jack@suse.cz>

commit 4a8570112b76a63ad21cfcbe2783f98f7fd5ba1b
Author: Jeff Mahoney <jeffm@suse.com>
Date:   Fri May 31 15:54:17 2013 -0400

    reiserfs: fix problems with chowning setuid file w/ xattrs
    
    reiserfs_chown_xattrs() takes the iattr struct passed into ->setattr
    and uses it to iterate over all the attrs associated with a file to change
    ownership of xattrs (and transfer quota associated with the xattr files).
    
    When the setuid bit is cleared during chown, ATTR_MODE and iattr->ia_mode
    are passed to all the xattrs as well. This means that the xattr directory
    will have S_IFREG added to its mode bits.
    
    This has been prevented in practice by a missing IS_PRIVATE check
    in reiserfs_acl_chmod, which caused a double-lock to occur while holding
    the write lock. Since the file system was completely locked up, the
    writeout of the corrupted mode never happened.
    
    This patch temporarily clears everything but ATTR_UID|ATTR_GID for the
    calls to reiserfs_setattr and adds the missing IS_PRIVATE check.
    
    Signed-off-by: Jeff Mahoney <jeffm@suse.com>
    Signed-off-by: Jan Kara <jack@suse.cz>

commit 0bdc7acba56a7ca4232f15f37b16f7ec079385ab
Author: Jeff Mahoney <jeffm@jeffreymahoney.com>
Date:   Fri May 31 15:07:52 2013 -0400

    reiserfs: fix spurious multiple-fill in reiserfs_readdir_dentry
    
    After sleeping for filldir(), we check to see if the file system has
    changed and research. The next_pos pointer is updated but its value
    isn't pushed into the key used for the search itself. As a result,
    the search returns the same item that the last cycle of the loop did
    and filldir() is called multiple times with the same data.
    
    The end result is that the buffer can contain the same name multiple
    times. This can be returned to userspace or used internally in the
    xattr code where it can manifest with the following warning:
    
    jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-2)
    
    reiserfs_for_each_xattr uses reiserfs_readdir_dentry to iterate over
    the xattr names and ends up trying to unlink the same name twice. The
    second attempt fails with -ENOENT and the error is returned. At some
    point I'll need to add support into reiserfsck to remove the orphaned
    directories left behind when this occurs.
    
    The fix is to push the value into the key before researching.
    
    Signed-off-by: Jeff Mahoney <jeffm@suse.com>
    Signed-off-by: Jan Kara <jack@suse.cz>

commit 7de3d66b1387ddf5a37d9689e5eb8510fb75c765
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Fri May 31 08:53:07 2013 -0700

    x86: Fix adjust_range_size_mask calling position
    
    Commit
    
        8d57470d x86, mm: setup page table in top-down
    
    causes a kernel panic while setting mem=2G.
    
         [mem 0x00000000-0x000fffff] page 4k
         [mem 0x7fe00000-0x7fffffff] page 1G
         [mem 0x7c000000-0x7fdfffff] page 1G
         [mem 0x00100000-0x001fffff] page 4k
         [mem 0x00200000-0x7bffffff] page 2M
    
    for last entry is not what we want, we should have
         [mem 0x00200000-0x3fffffff] page 2M
         [mem 0x40000000-0x7bffffff] page 1G
    
    Actually we merge the continuous ranges with same page size too early.
    in this case, before merging we have
         [mem 0x00200000-0x3fffffff] page 2M
         [mem 0x40000000-0x7bffffff] page 2M
    after merging them, will get
         [mem 0x00200000-0x7bffffff] page 2M
    even we can use 1G page to map
         [mem 0x40000000-0x7bffffff]
    
    that will cause problem, because we already map
         [mem 0x7fe00000-0x7fffffff] page 1G
         [mem 0x7c000000-0x7fdfffff] page 1G
    with 1G page, aka [0x40000000-0x7fffffff] is mapped with 1G page already.
    During phys_pud_init() for [0x40000000-0x7bffffff], it will not
    reuse existing that pud page, and allocate new one then try to use
    2M page to map it instead, as page_size_mask does not include
    PG_LEVEL_1G. At end will have [7c000000-0x7fffffff] not mapped, loop
    in phys_pmd_init stop mapping at 0x7bffffff.
    
    That is right behavoir, it maps exact range with exact page size that
    we ask, and we should explicitly call it to map [7c000000-0x7fffffff]
    before or after mapping 0x40000000-0x7bffffff.
    Anyway we need to make sure ranges' page_size_mask correct and consistent
    after split_mem_range for each range.
    
    Fix that by calling adjust_range_size_mask before merging range
    with same page size.
    
    -v2: update change log.
    -v3: add more explanation why [7c000000-0x7fffffff] is not mapped, and
        it causes panic.
    
    Bisected-by: "Xie, ChanglongX" <changlongx.xie@intel.com>
    Bisected-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
    Reported-and-tested-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Link: http://lkml.kernel.org/r/1370015587-20835-1-git-send-email-yinghai@kernel.org
    Cc: <stable@vger.kernel.org> v3.9
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

commit 4ad1f70ebcdb69393ce083f514bf4a4a3a3e65cb
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu May 23 04:38:22 2013 -0400

    zoran: racy refcount handling in vm_ops ->open()/->close()
    
    worse, we lock ->resource_lock too late when we are destroying the
    final clonal VMA; the check for lack of other mappings of the same
    opened file can race with mmap().
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

commit 56c21b53ab071feb3ce93375a563ead745fa7105
Author: Richard Genoud <richard.genoud@gmail.com>
Date:   Fri May 31 15:49:35 2013 +0000

    atmel_lcdfb: blank the backlight on remove
    
    When removing atmel_lcdfb module, the backlight is unregistered but not
    blanked. (only for CONFIG_BACKLIGHT_ATMEL_LCDC case).
    This can result in the screen going full white depending on how the PWM
    is wired.
    
    Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
    Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

commit 65ac057bce426b4abdf42384c4e09e40a634df32
Author: Richard Genoud <richard.genoud@gmail.com>
Date:   Fri May 31 14:28:38 2013 +0000

    trivial: atmel_lcdfb: add missing error message
    
    When a too small framebuffer is given, the atmel_lcdfb_check_var
    silently fails.
    Adding an error message will save some head scratching.
    
    Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
    Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

commit 448293aadb54ab38b9c053bf9f1eecafdc0ed214
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Wed May 22 13:41:26 2013 -0400

    befs_readdir(): do not increment ->f_pos if filldir tells us to stop
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

commit 31abdab9c11bb1694ecd1476a7edbe8e964d94ac
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat May 18 02:38:52 2013 -0400

    hpfs: deadlock and race in directory lseek()
    
    For one thing, there's an ABBA deadlock on hpfs fs-wide lock and i_mutex
    in hpfs_dir_lseek() - there's a lot of methods that grab the former with
    the caller already holding the latter, so it must take i_mutex first.
    
    For another, locking the damn thing, carefully validating the offset,
    then dropping locks and assigning the offset is obviously racy.
    
    Moreover, we _must_ do hpfs_add_pos(), or the machinery in dnode.c
    won't modify the sucker on B-tree surgeries.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

commit 1d7095c72d35eee4ebc28e66563e636b9adafeb2
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri May 17 15:21:56 2013 -0400

    qnx6: qnx6_readdir() has a braino in pos calculation
    
    We want to mask lower 5 bits out, not leave only those and clear the
    rest...  As it is, we end up always starting to read from the beginning
    of directory, no matter what the current position had been.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

commit 801d9d26bfd6e88e9cf0efbb30b649d1bdc15dcf
Author: Jan Beulich <JBeulich@suse.com>
Date:   Wed May 29 13:26:53 2013 +0100

    fix buffer leak after "scsi: saner replacements for ->proc_info()"
    
    That patch failed to set proc_scsi_fops' .release method.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

commit 5d477b6079619910dab882fa229cce1f14f86cf8
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri May 10 14:04:11 2013 +0200

    vfs: Fix invalid ida_remove() call
    
    When the group id of a shared mount is not allocated, the umount still
    tries to call mnt_release_group_id(), which eventually hits a kernel
    warning at ida_remove() spewing a message like:
      ida_remove called for id=0 which is not allocated.
    
    This patch fixes the bug simply checking the group id in the caller.
    
    Reported-by: Cristian Rodríguez <crrodriguez@opensuse.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

commit 24a923e4e9a296a8f8ff852109d423ba07616cc4
Author: Dustin Kirkland <dustin.kirkland@gazzang.com>
Date:   Fri May 31 10:41:43 2013 -0500

    Update eCryptFS maintainers
    
    Remove myself from the eCryptFS kernel maintainers.
    
    Add the ecryptfs.org website.
    
    I will continue to actively maintain and monitor the ecryptfs-utils
    user space project and packages.
    
    Signed-off-by: Dustin Kirkland <dustin.kirkland@gazzang.com>
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>

commit fa08a396647767abd24a9e7015cb177121d0cf15
Author: Ramachandra Rao Gajula <rama@fastorsystems.com>
Date:   Sat May 11 15:19:31 2013 -0700

    NVMe: Add MSI support
    
    Some devices only have support for MSI, not MSI-X.  While MSI is more
    limited, it still provides better performance than line-based interrupts.
    
    Signed-off-by: Ramachandra Gajula <rama@fastorsystems.com>
    Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>

commit e86cbd8765bd2e1f9eeb209822449c9b1e5958cf
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Wed May 29 13:08:39 2013 +0200

    s390/pgtable: Fix gmap notifier address
    
    The address of the gmap notifier was broken, resulting in
    unhandled validity intercepts in KVM. Fix the rmap->vmaddr
    to be on a segment boundary.
    
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit 8b811bae69cf30e0a9676d7dcafb0cf16f13b3bc
Author: Stefan Weinhuber <wein@de.ibm.com>
Date:   Tue May 28 15:26:06 2013 +0200

    s390/dasd: fix handling of gone paths
    
    When a path is gone and dasd_generic_path_event is called with a
    PE_PATH_GONE event, we must assume that any I/O request on that
    subchannel is still running. This is unlike the dasd_generic_notify
    handler and the CIO_NO_PATH event, which implies that the subchannel
    has been cleared.
    If dasd_generic_path_event finds that the path has been the last
    usable path, it must not call dasd_generic_last_path_gone (which would
    reset the state of running requests), but just set the
    DASD_STOPPED_DC_WAIT bit.
    
    Signed-off-by: Stefan Weinhuber <wein@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit 9955ac47f4ba1c95ecb6092aeaefb40a22e99268
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Tue May 28 15:54:15 2013 +0100

    arm64: don't kill the kernel on a bad esr from el0
    
    Rather than completely killing the kernel if we receive an esr value we
    can't deal with in the el0 handlers, send the process a SIGILL and log
    the esr value in the hope that we can debug it. If we receive a bad esr
    from el1, we'll die() as before.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Cc: stable@vger.kernel.org

commit 381cc2b9705512ee7c7f1839cbdde374625a2a9f
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Fri May 24 12:02:35 2013 +0100

    arm64: treat unhandled compat el0 traps as undef
    
    Currently, if a compat process reads or writes from/to a disabled
    cp15/cp14 register, the trap is not handled by the el0_sync_compat
    handler, and the kernel will head to bad_mode, where it will die(), and
    oops(). For 64 bit processes, disabled system register accesses are
    currently treated as unhandled instructions.
    
    This patch modifies entry.S to treat these unhandled traps as undefined
    instructions, sending a SIGILL to userspace. This gives processes a
    chance to handle this and stop using inaccessible registers, and
    prevents further issues in the kernel as a result of the die().
    
    Reported-by: Johannes Jensen <Johannes.Jensen@arm.com>
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

commit f5d00c1f9adb350c24c5301600f7bf2da99b66de
Author: Jiri Bohac <jbohac@suse.cz>
Date:   Tue May 28 15:29:03 2013 +0200

    tick: Remove useless timekeeping duty attribution to broadcast source
    
    Since 7300711e ("clockevents: broadcast fixup possible waiters"),
    the timekeeping duty is assigned to the CPU that handles the tick
    broadcast clock device by the time it is set in one shot mode.
    
    This is an issue in full dynticks mode where the timekeeping duty
    must stay handled by the boot CPU for now. Otherwise it prevents
    secondary CPUs from offlining and this breaks
    suspend/shutdown/reboot/...
    
    As it appears there is no reason for this timekeeping duty to be
    moved to the broadcast CPU, besides nothing prevent it from being
    later re-assigned to another target, let's simply remove it.
    
    Signed-off-by: Jiri Bohac <jbohac@suse.cz>
    Reported-by: Steven Rostedt <rostedt@goodmis.org>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit b0bc225d0e5de887340d4d92a8c594ef0f60d412
Author: Andrew Jones <drjones@redhat.com>
Date:   Wed May 29 14:48:15 2013 +0200

    sched/x86: Construct all sibling maps if smt
    
    Commit 316ad248307fb ("sched/x86: Rewrite
    set_cpu_sibling_map()") broke the construction of sibling maps,
    which also broke the booted_cores accounting.
    
    Before the rewrite, if smt was present, then each map was
    updated for each smt sibling. After the rewrite only
    cpu_sibling_mask gets updated, as the llc and core maps depend
    on 'has_mc = x86_max_cores > 1' instead. This leads to problems
    with topologies like the following
    
    (qemu -smp sockets=2,cores=1,threads=2)
    
      processor       : 0
      physical id     : 0
      siblings        : 1    <= should be 2
      core id         : 0
      cpu cores       : 1
    
      processor       : 1
      physical id     : 0
      siblings        : 1    <= should be 2
      core id         : 0
      cpu cores       : 0    <= should be 1
    
      processor       : 2
      physical id     : 1
      siblings        : 1    <= should be 2
      core id         : 0
      cpu cores       : 1
    
      processor       : 3
      physical id     : 1
      siblings        : 1    <= should be 2
      core id         : 0
      cpu cores       : 0    <= should be 1
    
    This patch restores the former construction by defining has_mc
    as (has_smt || x86_max_cores > 1). This should be fine as there
    were no (has_smt && !has_mc) conditions in the context.
    
    Aso rename has_mc to has_mp now that it's not just for cores.
    
    Signed-off-by: Andrew Jones <drjones@redhat.com>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Cc: a.p.zijlstra@chello.nl
    Cc: fenghua.yu@intel.com
    Link: http://lkml.kernel.org/r/1369831695-11970-1-git-send-email-drjones@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit 1a7f829f094dd7951e7d46c571a18080e455a436
Author: Li Zhong <zhong@linux.vnet.ibm.com>
Date:   Fri May 17 16:44:04 2013 +0800

    nohz: Fix notifier return val that enforce timekeeping
    
    In tick_nohz_cpu_down_callback() if the cpu is the one handling
    timekeeping, we must return something that stops the CPU_DOWN_PREPARE
    notifiers and then start notify CPU_DOWN_FAILED on the already called
    notifier call backs.
    
    However traditional errno values are not handled by the notifier unless
    these are encapsulated using errno_to_notifier().
    
    Hence the current -EINVAL is misinterpreted and converted to junk after
    notifier_to_errno(), leaving the notifier subsystem to random behaviour
    such as eventually allowing the cpu to go down.
    
    Fix this by using the standard NOTIFY_BAD instead.
    
    Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
    Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Acked-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit 521921bad1192fb1b8f9b6a5aa673635848b8b5f
Author: Frederic Weisbecker <fweisbec@gmail.com>
Date:   Thu May 16 01:21:38 2013 +0200

    kvm: Move guest entry/exit APIs to context_tracking
    
    The kvm_host.h header file doesn't handle well
    inclusion when archs don't support KVM.
    
    This results in build crashes for such archs when they
    want to implement context tracking because this subsystem
    includes kvm_host.h in order to implement the
    guest_enter/exit APIs but it doesn't handle KVM off case.
    
    To fix this, move the guest_enter()/guest_exit()
    declarations and generic implementation to the context
    tracking headers. These generic APIs actually belong to
    this subsystem, besides other domains boundary tracking
    like user_enter() et al.
    
    KVM now properly becomes a user of this library, not the
    other buggy way around.
    
    Reported-by: Kevin Hilman <khilman@linaro.org>
    Reviewed-by: Kevin Hilman <khilman@linaro.org>
    Tested-by: Kevin Hilman <khilman@linaro.org>
    Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Kevin Hilman <khilman@linaro.org>
    Cc: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: Gleb Natapov <gleb@redhat.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit 45eacc692771bd2b1ea3d384e6345cab3da10861
Author: Frederic Weisbecker <fweisbec@gmail.com>
Date:   Wed May 15 22:16:32 2013 +0200

    vtime: Use consistent clocks among nohz accounting
    
    While computing the cputime delta of dynticks CPUs,
    we are mixing up clocks of differents natures:
    
    * local_clock() which takes care of unstable clock
    sources and fix these if needed.
    
    * sched_clock() which is the weaker version of
    local_clock(). It doesn't compute any fixup in case
    of unstable source.
    
    If the clock source is stable, those two clocks are the
    same and we can safely compute the difference against
    two random points.
    
    Otherwise it results in random deltas as sched_clock()
    can randomly drift away, back or forward, from local_clock().
    
    As a consequence, some strange behaviour with unstable tsc
    has been observed such as non progressing constant zero cputime.
    (The 'top' command showing no load).
    
    Fix this by only using local_clock(), or its irq safe/remote
    equivalent, in vtime code.
    
    Reported-by: Mike Galbraith <efault@gmx.de>
    Suggested-by: Mike Galbraith <efault@gmx.de>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Li Zhong <zhong@linux.vnet.ibm.com>
    Cc: Mike Galbraith <efault@gmx.de>
    Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit 3ee2102fbe92150af2b6d1d87f6bbefbaff0c7ca
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Fri May 31 10:41:04 2013 +0200

    ALSA: hda - Add headset quirk for two Dell machines
    
    This quirk is required for the headset mic to work on these
    two machines.
    
    BugLink: https://bugs.launchpad.net/bugs/1186170
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit df66834a43c461de2565c45d815288ba1c0def37
Author: Finn Thain <fthain@telegraphics.com.au>
Date:   Wed May 29 12:37:17 2013 +1000

    m68k/mac: Fix unexpected interrupt with CONFIG_EARLY_PRINTK
    
    The present code does not wait for the SCC to finish resetting itself
    before trying to initialise the device. The result is that the SCC
    interrupt sources become enabled (if they weren't already). This leads to
    an early boot crash (unexpected interrupt) given CONFIG_EARLY_PRINTK. Fix
    this by adding a delay. A successful reset disables the interrupt sources.
    
    Also, after the reset for channel A setup, the SCC then gets a second
    reset for channel B setup which leaves channel A uninitialised again. Fix
    this by performing the reset only once.
    
    Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
    Cc: stable@vger.kernel.org
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

commit aafc9d158b0039e600fc429246c7bb04a111fb26
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Fri May 31 00:49:41 2013 -0700

    iscsi-target: Fix iscsit_free_cmd() se_cmd->cmd_kref shutdown handling
    
    With the introduction of target_get_sess_cmd() referencing counting for
    ISCSI_OP_SCSI_CMD processing with iser-target, iscsit_free_cmd() usage
    in traditional iscsi-target driver code now needs to be aware of the
    active I/O shutdown case when a remaining se_cmd->cmd_kref reference may
    exist after transport_generic_free_cmd() completes, requiring a final
    target_put_sess_cmd() to release iscsi_cmd descriptor memory.
    
    This patch changes iscsit_free_cmd() to invoke __iscsit_free_cmd() before
    transport_generic_free_cmd() -> target_put_sess_cmd(), and also avoids
    aquiring the per-connection queue locks for typical fast-path calls
    during normal ISTATE_REMOVE operation.
    
    Also update iscsit_free_cmd() usage throughout iscsi-target to
    use the new 'bool shutdown' parameter.
    
    This patch fixes a regression bug introduced during v3.10-rc1 in
    commit 3e1c81a95, that was causing the following WARNING to appear:
    
    [  257.235153] ------------[ cut here]------------
    [  257.240314] WARNING: at kernel/softirq.c:160 local_bh_enable_ip+0x3c/0x86()
    [  257.248089] Modules linked in: vhost_scsi ib_srpt ib_cm ib_sa ib_mad ib_core tcm_qla2xxx tcm_loop
    	tcm_fc libfc iscsi_target_mod target_core_pscsi target_core_file
    	target_core_iblock target_core_mod configfs ipv6 iscsi_tcp libiscsi_tcp
    	libiscsi scsi_transport_iscsi loop acpi_cpufreq freq_table mperf
    	kvm_intel kvm crc32c_intel button ehci_pci pcspkr joydev i2c_i801
    	microcode ext3 jbd raid10 raid456 async_pq async_xor xor async_memcpy
    	async_raid6_recov raid6_pq async_tx raid1 raid0 linear igb hwmon
    	i2c_algo_bit i2c_core ptp ata_piix libata qla2xxx uhci_hcd ehci_hcd
    	mlx4_core scsi_transport_fc scsi_tgt pps_core
    [  257.308748] CPU: 1 PID: 3295 Comm: iscsi_ttx Not tainted 3.10.0-rc2+ #103
    [  257.316329] Hardware name: Intel Corporation S5520HC/S5520HC, BIOS S5500.86B.01.00.0057.031020111721 03/10/2011
    [  257.327597]  ffffffff814c24b7 ffff880458331b58 ffffffff8138eef2 ffff880458331b98
    [  257.335892]  ffffffff8102c052 ffff880400000008 0000000000000000 ffff88085bdf0000
    [  257.344191]  ffff88085bdf00d8 ffff88085bdf00e0 ffff88085bdf00f8 ffff880458331ba8
    [  257.352488] Call Trace:
    [  257.355223]  [<ffffffff8138eef2>] dump_stack+0x19/0x1f
    [  257.360963]  [<ffffffff8102c052>] warn_slowpath_common+0x62/0x7b
    [  257.367669]  [<ffffffff8102c080>] warn_slowpath_null+0x15/0x17
    [  257.374181]  [<ffffffff81032345>] local_bh_enable_ip+0x3c/0x86
    [  257.380697]  [<ffffffff813917fd>] _raw_spin_unlock_bh+0x10/0x12
    [  257.387311]  [<ffffffffa029069c>] iscsit_free_r2ts_from_list+0x5e/0x67 [iscsi_target_mod]
    [  257.396438]  [<ffffffffa02906c5>] iscsit_release_cmd+0x20/0x223 [iscsi_target_mod]
    [  257.404893]  [<ffffffffa02977a4>] lio_release_cmd+0x3a/0x3e [iscsi_target_mod]
    [  257.412964]  [<ffffffffa01d59a1>] target_release_cmd_kref+0x7a/0x7c [target_core_mod]
    [  257.421712]  [<ffffffffa01d69bc>] target_put_sess_cmd+0x5f/0x7f [target_core_mod]
    [  257.430071]  [<ffffffffa01d6d6d>] transport_release_cmd+0x59/0x6f [target_core_mod]
    [  257.438625]  [<ffffffffa01d6eb4>] transport_put_cmd+0x131/0x140 [target_core_mod]
    [  257.446985]  [<ffffffffa01d6192>] ? transport_wait_for_tasks+0xfa/0x1d5 [target_core_mod]
    [  257.456121]  [<ffffffffa01d6f11>] transport_generic_free_cmd+0x4e/0x52 [target_core_mod]
    [  257.465159]  [<ffffffff81050537>] ? __migrate_task+0x110/0x110
    [  257.471674]  [<ffffffffa02904ba>] iscsit_free_cmd+0x46/0x55 [iscsi_target_mod]
    [  257.479741]  [<ffffffffa0291edb>] iscsit_immediate_queue+0x301/0x353 [iscsi_target_mod]
    [  257.488683]  [<ffffffffa0292f7e>] iscsi_target_tx_thread+0x1c6/0x2a8 [iscsi_target_mod]
    [  257.497623]  [<ffffffff81047486>] ? wake_up_bit+0x25/0x25
    [  257.503652]  [<ffffffffa0292db8>] ? iscsit_ack_from_expstatsn+0xd5/0xd5 [iscsi_target_mod]
    [  257.512882]  [<ffffffff81046f89>] kthread+0xb0/0xb8
    [  257.518329]  [<ffffffff81046ed9>] ? kthread_freezable_should_stop+0x60/0x60
    [  257.526105]  [<ffffffff81396fec>] ret_from_fork+0x7c/0xb0
    [  257.532133]  [<ffffffff81046ed9>] ? kthread_freezable_should_stop+0x60/0x60
    [  257.539906] ---[ end trace 5520397d0f2e0800 ]---
    
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit d5ddad4168348337d98d6b8f156a3892de444411
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Fri May 31 00:46:11 2013 -0700

    target: Propigate up ->cmd_kref put return via transport_generic_free_cmd
    
    Go ahead and propigate up the ->cmd_kref put return value from
    target_put_sess_cmd() -> transport_release_cmd() -> transport_put_cmd()
    -> transport_generic_free_cmd().
    
    This is useful for certain fabrics when determining the active I/O
    shutdown case with SCF_ACK_KREF where a final target_put_sess_cmd()
    is still required by the caller.
    
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 6b4dc2bd7e706570167e086a41b87ea250a55b34
Author: Ebben Aries <earies@dscp.org>
Date:   Wed May 29 22:27:18 2013 -0600

    ALSA: hda - add dock support for Thinkpad T431s
    
    Add a model/fixup string "lenovo-dock", for Thinkpad T431s, to allow sound in docking station.
    
    Tested on Lenovo T431s with ThinkPad Mini Dock Plus Series 3
    
    Signed-off-by: Ebben Aries <earies@dscp.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 8b1dacb6ae15c94d50642a474e5af8981555253b
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Thu May 30 19:55:34 2013 +0800

    ALSA: sis7019: fix error return code in sis_chip_create()
    
    Fix to return a negative error code in the pci_set_dma_mask() error
    handling case instead of 0, as done elsewhere in this function.
    
    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 970fa986fadb1165cf38b45b70e98302a3bee497
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri May 31 12:45:09 2013 +1000

    drm/qxl: fix build warnings on 32-bit
    
    Just the usual printk related warnings.
    
    Signed-off-by: Dave Airlie <airlied@redhat.com>

commit d68c380590c390a488fe214e5ebf9439216ac3ba
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date:   Mon May 27 12:28:25 2013 -0300

    clk: mxs: Include clk mxs header file
    
    Fix the following sparse warnings:
    
    drivers/clk/mxs/clk-imx28.c:72:5: warning: symbol 'mxs_saif_clkmux_select' was not declared. Should it be static?
    drivers/clk/mxs/clk-imx28.c:156:12: warning: symbol 'mx28_clocks_init' was not declared. Should it be static?
    
    Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
    Acked-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Mike Turquette <mturquette@linaro.org>
    [mturquette@linaro.org: fixed $SUBJECT line]

commit cea4dcfdad926a27a18e188720efe0f2c9403456
Author: Kees Cook <keescook@chromium.org>
Date:   Thu May 23 10:32:17 2013 -0700

    iscsi-target: fix heap buffer overflow on error
    
    If a key was larger than 64 bytes, as checked by iscsi_check_key(), the
    error response packet, generated by iscsi_add_notunderstood_response(),
    would still attempt to copy the entire key into the packet, overflowing
    the structure on the heap.
    
    Remote preauthentication kernel memory corruption was possible if a
    target was configured and listening on the network.
    
    CVE-2013-2850
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 21363ca873334391992f2f424856aa864345bb61
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed May 29 21:35:23 2013 -0700

    target/file: Fix off-by-one READ_CAPACITY bug for !S_ISBLK export
    
    This patch fixes a bug where FILEIO was incorrectly reporting the number
    of logical blocks (+ 1) when using non struct block_device export mode.
    
    It changes fd_get_blocks() to follow all other backend ->get_blocks() cases,
    and reduces the calculated dev_size by one dev->dev_attrib.block_size
    number of bytes, and also fixes initial fd_block_size assignment at
    fd_configure_device() time introduced in commit 0fd97ccf4.
    
    Reported-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
    Reported-by: Badari Pulavarty <pbadari@us.ibm.com>
    Tested-by: Badari Pulavarty <pbadari@us.ibm.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 01e5b2c4559d084f4eaf0d160d84cc185db141ba
Author: Somnath Kotur <somnath.kotur@emulex.com>
Date:   Wed May 29 22:56:17 2013 +0000

    be2net: Fix crash on 2nd invocation of PCI AER/EEH error_detected hook
    
    During a PCI EEH/AER error recovery flow, if the device did not successfully
    restart, the error_detected() hook may be called a second time with a
    "perm_failure" state. This patch skips over driver cleanup for the second
    invocation of the callback.
    
    Also, Lancer error recovery code is fixed-up to handle these changes.
    
    Signed-off-by: Kalesh AP <kalesh.purayil@emulex.com>
    Signed-off-by: Somnath kotur <somnath.kotur@emulex.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit e38b170695d4108eeb6cd84db36f567fc6de4120
Author: Somnath Kotur <somnath.kotur@emulex.com>
Date:   Wed May 29 22:55:56 2013 +0000

    be2net: Mark checksum fail for IP fragmented packets
    
    HW does not compute L4 checksum for IP Fragmented packets.
    
    Signed-off-by: Kalesh AP <kalesh.purayil@emulex.com>
    Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 5187b28ff08249ab8a162e802209ed04e271ca02
Author: Pekka Riikonen <priikone@iki.fi>
Date:   Mon May 13 14:32:07 2013 +0200

    x86: Allow FPU to be used at interrupt time even with eagerfpu
    
    With the addition of eagerfpu the irq_fpu_usable() now returns false
    negatives especially in the case of ksoftirqd and interrupted idle task,
    two common cases for FPU use for example in networking/crypto.  With
    eagerfpu=off FPU use is possible in those contexts.  This is because of
    the eagerfpu check in interrupted_kernel_fpu_idle():
    
    ...
      * For now, with eagerfpu we will return interrupted kernel FPU
      * state as not-idle. TBD: Ideally we can change the return value
      * to something like __thread_has_fpu(current). But we need to
      * be careful of doing __thread_clear_has_fpu() before saving
      * the FPU etc for supporting nested uses etc. For now, take
      * the simple route!
    ...
     	if (use_eager_fpu())
     		return 0;
    
    As eagerfpu is automatically "on" on those CPUs that also have the
    features like AES-NI this patch changes the eagerfpu check to return 1 in
    case the kernel_fpu_begin() has not been said yet.  Once it has been the
    __thread_has_fpu() will start returning 0.
    
    Notice that with eagerfpu the __thread_has_fpu is always true initially.
    FPU use is thus always possible no matter what task is under us, unless
    the state has already been saved with kernel_fpu_begin().
    
    [ hpa: this is a performance regression, not a correctness regression,
      but since it can be quite serious on CPUs which need encryption at
      interrupt time I am marking this for urgent/stable. ]
    
    Signed-off-by: Pekka Riikonen <priikone@iki.fi>
    Link: http://lkml.kernel.org/r/alpine.GSO.2.00.1305131356320.18@git.silcnet.org
    Cc: <stable@vger.kernel.org> v3.7+
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

commit 2baad6121e2b2fa3428ee6cb2298107be11ab23a
Author: Jan Beulich <JBeulich@suse.com>
Date:   Wed May 29 13:43:54 2013 +0100

    x86, crc32-pclmul: Fix build with older binutils
    
    binutils prior to 2.18 (e.g. the ones found on SLE10) don't support
    assembling PEXTRD, so a macro based approach like the one for PCLMULQDQ
    in the same file should be used.
    
    This requires making the helper macros capable of recognizing 32-bit
    general purpose register operands.
    
    [ hpa: tagging for stable as it is a low risk build fix ]
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Link: http://lkml.kernel.org/r/51A6142A02000078000D99D8@nat28.tlf.novell.com
    Cc: Alexander Boyko <alexander_boyko@xyratex.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Huang Ying <ying.huang@intel.com>
    Cc: <stable@vger.kernel.org> v3.9
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

commit 7bc0dc271e494e12be3afd3c6431e5216347c624
Author: Dave Chinner <dchinner@redhat.com>
Date:   Tue May 21 18:02:08 2013 +1000

    xfs: rework remote attr CRCs
    
    Note: this changes the on-disk remote attribute format. I assert
    that this is OK to do as CRCs are marked experimental and the first
    kernel it is included in has not yet reached release yet. Further,
    the userspace utilities are still evolving and so anyone using this
    stuff right now is a developer or tester using volatile filesystems
    for testing this feature. Hence changing the format right now to
    save longer term pain is the right thing to do.
    
    The fundamental change is to move from a header per extent in the
    attribute to a header per filesytem block in the attribute. This
    means there are more header blocks and the parsing of the attribute
    data is slightly more complex, but it has the advantage that we
    always know the size of the attribute on disk based on the length of
    the data it contains.
    
    This is where the header-per-extent method has problems. We don't
    know the size of the attribute on disk without first knowing how
    many extents are used to hold it. And we can't tell from a
    mapping lookup, either, because remote attributes can be allocated
    contiguously with other attribute blocks and so there is no obvious
    way of determining the actual size of the atribute on disk short of
    walking and mapping buffers.
    
    The problem with this approach is that if we map a buffer
    incorrectly (e.g. we make the last buffer for the attribute data too
    long), we then get buffer cache lookup failure when we map it
    correctly. i.e. we get a size mismatch on lookup. This is not
    necessarily fatal, but it's a cache coherency problem that can lead
    to returning the wrong data to userspace or writing the wrong data
    to disk. And debug kernels will assert fail if this occurs.
    
    I found lots of niggly little problems trying to fix this issue on a
    4k block size filesystem, finally getting it to pass with lots of
    fixes. The thing is, 1024 byte filesystems still failed, and it was
    getting really complex handling all the corner cases that were
    showing up. And there were clearly more that I hadn't found yet.
    
    It is complex, fragile code, and if we don't fix it now, it will be
    complex, fragile code forever more.
    
    Hence the simple fix is to add a header to each filesystem block.
    This gives us the same relationship between the attribute data
    length and the number of blocks on disk as we have without CRCs -
    it's a linear mapping and doesn't require us to guess anything. It
    is simple to implement, too - the remote block count calculated at
    lookup time can be used by the remote attribute set/get/remove code
    without modification for both CRC and non-CRC filesystems. The world
    becomes sane again.
    
    Because the copy-in and copy-out now need to iterate over each
    filesystem block, I moved them into helper functions so we separate
    the block mapping and buffer manupulations from the attribute data
    and CRC header manipulations. The code becomes much clearer as a
    result, and it is a lot easier to understand and debug. It also
    appears to be much more robust - once it worked on 4k block size
    filesystems, it has worked without failure on 1k block size
    filesystems, too.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit ad1858d77771172e08016890f0eb2faedec3ecee)

commit 634fd5322a3e6ae632dcf5f20eebc0583ba50838
Author: Dave Chinner <dchinner@redhat.com>
Date:   Tue May 21 18:02:06 2013 +1000

    xfs: fully initialise temp leaf in xfs_attr3_leaf_compact
    
    xfs_attr3_leaf_compact() uses a temporary buffer for compacting the
    the entries in a leaf. It copies the the original buffer into the
    temporary buffer, then zeros the original buffer completely. It then
    copies the entries back into the original buffer.  However, the
    original buffer has not been correctly initialised, and so the
    movement of the entries goes horribly wrong.
    
    Make sure the zeroed destination buffer is fully initialised, and
    once we've set up the destination incore header appropriately, write
    is back to the buffer before starting to move entries around.
    
    While debugging this, the _d/_s prefixes weren't sufficient to
    remind me what buffer was what, so rename then all _src/_dst.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit d4c712bcf26a25c2b67c90e44e0b74c7993b5334)

commit 9e80c76205b46b338cb56c336148f54b2326342f
Author: Dave Chinner <dchinner@redhat.com>
Date:   Tue May 21 18:02:05 2013 +1000

    xfs: fully initialise temp leaf in xfs_attr3_leaf_unbalance
    
    xfs_attr3_leaf_unbalance() uses a temporary buffer for recombining
    the entries in two leaves when the destination leaf requires
    compaction. The temporary buffer ends up being copied back over the
    original destination buffer, so the header in the temporary buffer
    needs to contain all the information that is in the destination
    buffer.
    
    To make sure the temporary buffer is fully initialised, once we've
    set up the temporary incore header appropriately, write is back to
    the temporary buffer before starting to move entries around.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit 8517de2a81da830f5d90da66b4799f4040c76dc9)

commit 58a72281555bf301f6dff24db2db205c87ef8db1
Author: Dave Chinner <dchinner@redhat.com>
Date:   Tue May 21 18:02:04 2013 +1000

    xfs: correctly map remote attr buffers during removal
    
    If we don't map the buffers correctly (same as for get/set
    operations) then the incore buffer lookup will fail. If a block
    number matches but a length is wrong, then debug kernels will ASSERT
    fail in _xfs_buf_find() due to the length mismatch. Ensure that we
    map the buffers correctly by basing the length of the buffer on the
    attribute data length rather than the remote block count.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit 6863ef8449f1908c19f43db572e4474f24a1e9da)

commit 26f714450c3907ce07c41a0bd1bea40368e0b4da
Author: Dave Chinner <dchinner@redhat.com>
Date:   Tue May 21 18:02:03 2013 +1000

    xfs: remote attribute tail zeroing does too much
    
    When an attribute data does not fill then entire remote block, we
    zero the remaining part of the buffer. This, however, needs to take
    into account that the buffer has a header, and so the offset where
    zeroing starts and the length of zeroing need to take this into
    account. Otherwise we end up with zeros over the end of the
    attribute value when CRCs are enabled.
    
    While there, make sure we only ask to map an extent that covers the
    remaining range of the attribute, rather than asking every time for
    the full length of remote data. If the remote attribute blocks are
    contiguous with other parts of the attribute tree, it will map those
    blocks as well and we can potentially zero them incorrectly. We can
    also get buffer size mistmatches when trying to read or remove the
    remote attribute, and this can lead to not finding the correct
    buffer when looking it up in cache.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit 4af3644c9a53eb2f1ecf69cc53576561b64be4c6)

commit 551b382f5368900d6d82983505cb52553c946a2b
Author: Dave Chinner <dchinner@redhat.com>
Date:   Tue May 21 18:02:02 2013 +1000

    xfs: remote attribute read too short
    
    Reading a maximally size remote attribute fails when CRCs are
    enabled with this verification error:
    
    XFS (vdb): remote attribute header does not match required off/len/owner)
    
    There are two reasons for this, the first being that the
    length of the buffer being read is determined from the
    args->rmtblkcnt which doesn't take into account CRC headers. Hence
    the mapped length ends up being too short and so we need to
    calculate it directly from the value length.
    
    The second is that the byte count of valid data within a buffer is
    capped by the length of the data and so doesn't take into account
    that the buffer might be longer due to headers. Hence we need to
    calculate the data space in the buffer first before calculating the
    actual byte count of data.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit 913e96bc292e1bb248854686c79d6545ef3ee720)

commit 9531e2de6b7f04bd734b4bbc1e16a6955121615a
Author: Dave Chinner <dchinner@redhat.com>
Date:   Tue May 21 18:02:01 2013 +1000

    xfs: remote attribute allocation may be contiguous
    
    When CRCs are enabled, there may be multiple allocations made if the
    headers cause a length overflow. This, however, does not mean that
    the number of headers required increases, as the second and
    subsequent extents may be contiguous with the previous extent. Hence
    when we map the extents to write the attribute data, we may end up
    with less extents than allocations made. Hence the assertion that we
    consume the number of headers we calculated in the allocation loop
    is incorrect and needs to be removed.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit 90253cf142469a40f89f989904abf0a1e500e1a6)

commit e400d27d1690d609f203f2d7d8efebc98cbc3089
Author: Dave Chinner <dchinner@redhat.com>
Date:   Tue May 28 18:37:17 2013 +1000

    xfs: fix dir3 freespace block corruption
    
    When the directory freespace index grows to a second block (2017
    4k data blocks in the directory), the initialisation of the second
    new block header goes wrong. The write verifier fires a corruption
    error indicating that the block number in the header is zero. This
    was being tripped by xfs/110.
    
    The problem is that the initialisation of the new block is done just
    fine in xfs_dir3_free_get_buf(), but the caller then users a dirv2
    structure to zero on-disk header fields that xfs_dir3_free_get_buf()
    has already zeroed. These lined up with the block number in the dir
    v3 header format.
    
    While looking at this, I noticed that the struct xfs_dir3_free_hdr()
    had 4 bytes of padding in it that wasn't defined as padding or being
    zeroed by the initialisation. Add a pad field declaration and fully
    zero the on disk and in-core headers in xfs_dir3_free_get_buf() so
    that this is never an issue in the future. Note that this doesn't
    change the on-disk layout, just makes the 32 bits of padding in the
    layout explicit.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit 5ae6e6a401957698f2bd8c9f4a86d86d02199fea)

commit 7c9950fd2ac97431230544142d5e652e1b948372
Author: Dave Chinner <dchinner@redhat.com>
Date:   Mon May 27 16:38:24 2013 +1000

    xfs: disable swap extents ioctl on CRC enabled filesystems
    
    Currently, swapping extents from one inode to another is a simple
    act of switching data and attribute forks from one inode to another.
    This, unfortunately in no longer so simple with CRC enabled
    filesystems as there is owner information embedded into the BMBT
    blocks that are swapped between inodes. Hence swapping the forks
    between inodes results in the inodes having mapping blocks that
    point to the wrong owner and hence are considered corrupt.
    
    To fix this we need an extent tree block or record based swap
    algorithm so that the BMBT block owner information can be updated
    atomically in the swap transaction. This is a significant piece of
    new work, so for the moment simply don't allow swap extent
    operations to succeed on CRC enabled filesystems.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit 02f75405a75eadfb072609f6bf839e027de6a29a)

commit e7927e879d12d27aa06b9bbed57cc32dcd7d17fd
Author: Dave Chinner <dchinner@redhat.com>
Date:   Mon May 27 16:38:26 2013 +1000

    xfs: add fsgeom flag for v5 superblock support.
    
    Currently userspace has no way of determining that a filesystem is
    CRC enabled. Add a flag to the XFS_IOC_FSGEOMETRY ioctl output to
    indicate that the filesystem has v5 superblock support enabled.
    This will allow xfs_info to correctly report the state of the
    filesystem.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Eric Sandeen <sandeen@redhat.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit 74137fff067961c9aca1e14d073805c3de8549bd)

commit 1de09d1ae48152e56399aba0bfd984fb0ddae6b0
Author: Dave Chinner <dchinner@redhat.com>
Date:   Mon May 27 16:38:20 2013 +1000

    xfs: fix incorrect remote symlink block count
    
    When CRCs are enabled, the number of blocks needed to hold a remote
    symlink on a 1k block size filesystem may be 2 instead of 1. The
    transaction reservation for the allocated blocks was not taking this
    into account and only allocating one block. Hence when trying to
    read or invalidate such symlinks, we are mapping a hole where there
    should be a block and things go bad at that point.
    
    Fix the reservation to use the correct block count, clean up the
    block count calculation similar to the remote attribute calculation,
    and add a debug guard to detect when we don't write the entire
    symlink to disk.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit 321a95839e65db3759a07a3655184b0283af90fe)

commit 7d2ffe80aa000a149246b3745968634192eb5358
Author: Dave Chinner <dchinner@redhat.com>
Date:   Mon May 27 16:38:23 2013 +1000

    xfs: fix split buffer vector log recovery support
    
    A long time ago in a galaxy far away....
    
    .. the was a commit made to fix some ilinux specific "fragmented
    buffer" log recovery problem:
    
    http://oss.sgi.com/cgi-bin/gitweb.cgi?p=archive/xfs-import.git;a=commitdiff;h=b29c0bece51da72fb3ff3b61391a391ea54e1603
    
    That problem occurred when a contiguous dirty region of a buffer was
    split across across two pages of an unmapped buffer. It's been a
    long time since that has been done in XFS, and the changes to log
    the entire inode buffers for CRC enabled filesystems has
    re-introduced that corner case.
    
    And, of course, it turns out that the above commit didn't actually
    fix anything - it just ensured that log recovery is guaranteed to
    fail when this situation occurs. And now for the gory details.
    
    xfstest xfs/085 is failing with this assert:
    
    XFS (vdb): bad number of regions (0) in inode log format
    XFS: Assertion failed: 0, file: fs/xfs/xfs_log_recover.c, line: 1583
    
    Largely undocumented factoid #1: Log recovery depends on all log
    buffer format items starting with this format:
    
    struct foo_log_format {
    	__uint16_t	type;
    	__uint16_t	size;
    	....
    
    As recoery uses the size field and assumptions about 32 bit
    alignment in decoding format items.  So don't pay much attention to
    the fact log recovery thinks that it decoding an inode log format
    item - it just uses them to determine what the size of the item is.
    
    But why would it see a log format item with a zero size? Well,
    luckily enough xfs_logprint uses the same code and gives the same
    error, so with a bit of gdb magic, it turns out that it isn't a log
    format that is being decoded. What logprint tells us is this:
    
    Oper (130): tid: a0375e1a  len: 28  clientid: TRANS  flags: none
    BUF:  #regs: 2   start blkno: 144 (0x90)  len: 16  bmap size: 2  flags: 0x4000
    Oper (131): tid: a0375e1a  len: 4096  clientid: TRANS  flags: none
    BUF DATA
    ----------------------------------------------------------------------------
    Oper (132): tid: a0375e1a  len: 4096  clientid: TRANS  flags: none
    xfs_logprint: unknown log operation type (4e49)
    **********************************************************************
    * ERROR: data block=2                                                 *
    **********************************************************************
    
    That we've got a buffer format item (oper 130) that has two regions;
    the format item itself and one dirty region. The subsequent region
    after the buffer format item and it's data is them what we are
    tripping over, and the first bytes of it at an inode magic number.
    Not a log opheader like there is supposed to be.
    
    That means there's a problem with the buffer format item. It's dirty
    data region is 4096 bytes, and it contains - you guessed it -
    initialised inodes. But inode buffers are 8k, not 4k, and we log
    them in their entirety. So something is wrong here. The buffer
    format item contains:
    
    (gdb) p /x *(struct xfs_buf_log_format *)in_f
    $22 = {blf_type = 0x123c, blf_size = 0x2, blf_flags = 0x4000,
           blf_len = 0x10, blf_blkno = 0x90, blf_map_size = 0x2,
           blf_data_map = {0xffffffff, 0xffffffff, .... }}
    
    Two regions, and a signle dirty contiguous region of 64 bits.  64 *
    128 = 8k, so this should be followed by a single 8k region of data.
    And the blf_flags tell us that the type of buffer is a
    XFS_BLFT_DINO_BUF. It contains inodes. And because it doesn't have
    the XFS_BLF_INODE_BUF flag set, that means it's an inode allocation
    buffer. So, it should be followed by 8k of inode data.
    
    But we know that the next region has a header of:
    
    (gdb) p /x *ohead
    $25 = {oh_tid = 0x1a5e37a0, oh_len = 0x100000, oh_clientid = 0x69,
           oh_flags = 0x0, oh_res2 = 0x0}
    
    and so be32_to_cpu(oh_len) = 0x1000 = 4096 bytes. It's simply not
    long enough to hold all the logged data. There must be another
    region. There is - there's a following opheader for another 4k of
    data that contains the other half of the inode cluster data - the
    one we assert fail on because it's not a log format header.
    
    So why is the second part of the data not being accounted to the
    correct buffer log format structure? It took a little more work with
    gdb to work out that the buffer log format structure was both
    expecting it to be there but hadn't accounted for it. It was at that
    point I went to the kernel code, as clearly this wasn't a bug in
    xfs_logprint and the kernel was writing bad stuff to the log.
    
    First port of call was the buffer item formatting code, and the
    discontiguous memory/contiguous dirty region handling code
    immediately stood out. I've wondered for a long time why the code
    had this comment in it:
    
                            vecp->i_addr = xfs_buf_offset(bp, buffer_offset);
                            vecp->i_len = nbits * XFS_BLF_CHUNK;
                            vecp->i_type = XLOG_REG_TYPE_BCHUNK;
    /*
     * You would think we need to bump the nvecs here too, but we do not
     * this number is used by recovery, and it gets confused by the boundary
     * split here
     *                      nvecs++;
     */
                            vecp++;
    
    And it didn't account for the extra vector pointer. The case being
    handled here is that a contiguous dirty region lies across a
    boundary that cannot be memcpy()d across, and so has to be split
    into two separate operations for xlog_write() to perform.
    
    What this code assumes is that what is written to the log is two
    consecutive blocks of data that are accounted in the buf log format
    item as the same contiguous dirty region and so will get decoded as
    such by the log recovery code.
    
    The thing is, xlog_write() knows nothing about this, and so just
    does it's normal thing of adding an opheader for each vector. That
    means the 8k region gets written to the log as two separate regions
    of 4k each, but because nvecs has not been incremented, the buf log
    format item accounts for only one of them.
    
    Hence when we come to log recovery, we process the first 4k region
    and then expect to come across a new item that starts with a log
    format structure of some kind that tells us whenteh next data is
    going to be. Instead, we hit raw buffer data and things go bad real
    quick.
    
    So, the commit from 2002 that commented out nvecs++ is just plain
    wrong. It breaks log recovery completely, and it would seem the only
    reason this hasn't been since then is that we don't log large
    contigous regions of multi-page unmapped buffers very often. Never
    would be a closer estimate, at least until the CRC code came along....
    
    So, lets fix that by restoring the nvecs accounting for the extra
    region when we hit this case.....
    
    .... and there's the problemin log recovery it is apparently working
    around:
    
    XFS: Assertion failed: i == item->ri_total, file: fs/xfs/xfs_log_recover.c, line: 2135
    
    Yup, xlog_recover_do_reg_buffer() doesn't handle contigous dirty
    regions being broken up into multiple regions by the log formatting
    code. That's an easy fix, though - if the number of contiguous dirty
    bits exceeds the length of the region being copied out of the log,
    only account for the number of dirty bits that region covers, and
    then loop again and copy more from the next region. It's a 2 line
    fix.
    
    Now xfstests xfs/085 passes, we have one less piece of mystery
    code, and one more important piece of knowledge about how to
    structure new log format items..
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Mark Tinguely <tinguely@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit 709da6a61aaf12181a8eea8443919ae5fc1b731d)

commit 2962f5a5dcc56f69cbf62121a7be67cc15d6940b
Author: Dave Chinner <dchinner@redhat.com>
Date:   Mon May 27 16:38:25 2013 +1000

    xfs: kill suid/sgid through the truncate path.
    
    XFS has failed to kill suid/sgid bits correctly when truncating
    files of non-zero size since commit c4ed4243 ("xfs: split
    xfs_setattr") introduced in the 3.1 kernel. Fix it.
    
    Fix it.
    
    cc: stable kernel <stable@vger.kernel.org>
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    
    (cherry picked from commit 56c19e89b38618390addfc743d822f99519055c6)

commit 08fb39051f5581df45ae2a20c6cf2d0c4cddf7c2
Author: Dave Chinner <dchinner@redhat.com>
Date:   Tue May 21 18:02:00 2013 +1000

    xfs: avoid nesting transactions in xfs_qm_scall_setqlim()
    
    Lockdep reports:
    
    =============================================
    [ INFO: possible recursive locking detected ]
    3.9.0+ #3 Not tainted
    ---------------------------------------------
    setquota/28368 is trying to acquire lock:
     (sb_internal){++++.?}, at: [<c11e8846>] xfs_trans_alloc+0x26/0x50
    
    but task is already holding lock:
     (sb_internal){++++.?}, at: [<c11e8846>] xfs_trans_alloc+0x26/0x50
    
    from xfs_qm_scall_setqlim()->xfs_dqread() when a dquot needs to be
    allocated.
    
    xfs_qm_scall_setqlim() is starting a transaction and then not
    passing it into xfs_qm_dqet() and so it starts it's own transaction
    when allocating the dquot.  Splat!
    
    Fix this by not allocating the dquot in xfs_qm_scall_setqlim()
    inside the setqlim transaction. This requires getting the dquot
    first (and allocating it if necessary) then dropping and relocking
    the dquot before joining it to the setqlim transaction.
    
    Reported-by: Michael L. Semon <mlsemon35@gmail.com>
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    (cherry picked from commit f648167f3ac79018c210112508c732ea9bf67c7b)

commit 5489e948dc0f41a249c109d74612bf5aceab8f38
Author: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Date:   Thu May 30 22:23:44 2013 +0200

    MAINTAINERS: Framebuffer Layer maintainers update
    
    Tomi and I will now take care of the Framebuffer Layer
    
    The git tree is now on kernel.org
    
    Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
    Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Cc: Olof Johansson <olof@lixom.net>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
    Cc: linux-fbdev@vger.kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit eb54d43707c69340581940e1fcaecb4d7d17b814
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue May 14 14:37:56 2013 -0400

    NFS: Fix security flavor negotiation with legacy binary mounts
    
    Darrick J. Wong <darrick.wong@oracle.com> reports:
    > I have a kvm-based testing setup that netboots VMs over NFS, the
    > client end of which seems to have broken somehow in 3.10-rc1.  The
    > server's exports file looks like this:
    >
    > /storage/mtr/x64	192.168.122.0/24(ro,sync,no_root_squash,no_subtree_check)
    >
    > On the client end (inside the VM), the initrd runs the following
    > command to try to mount the rootfs over NFS:
    >
    > # mount -o nolock -o ro -o retrans=10 192.168.122.1:/storage/mtr/x64/ /root
    >
    > (Note: This is the busybox mount command.)
    >
    > The mount fails with -EINVAL.
    
    Commit 4580a92d44 "NFS: Use server-recommended security flavor by
    default (NFSv3)" introduced a behavior regression for NFS mounts
    done via a legacy binary mount(2) call.
    
    Ensure that a default security flavor is specified for legacy binary
    mount requests, since they do not invoke nfs_select_flavor() in the
    kernel.
    
    Busybox uses klibc's nfsmount command, which performs NFS mounts
    using the legacy binary mount data format.  /sbin/mount.nfs is not
    affected by this regression.
    
    Reported-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Tested-by: Darrick J. Wong <darrick.wong@oracle.com>
    Acked-by: Weston Andros Adamson <dros@netapp.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 2d403f7b198163d14a37ab79de33e27e390bb3b1
Author: Tony Lindgren <tony@atomide.com>
Date:   Thu May 30 12:44:47 2013 -0700

    ARM: OMAP3: Fix iva2_pwrdm settings for 3703
    
    Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists)
    changed PM to not access IVA registers on omaps that don't have
    them. Turns out we still need to idle iva2 as otherwise
    iva2_pwrdm will stay on and block deeper idle states.
    
    It seems that the only part of the reset that may not be needed
    is the setting of the iva2 boot mode to idle. But as that register
    seems to be there and is harmless if no iva2 is on the SoC, it's
    probably safest to do the complete reset.
    
    Acked-by: Mark A. Greer <mgreer@animalcreek.com>
    Acked-by: Kevin Hilman <khilman@linaro.org>
    Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>

commit 37448adfc7ce0d6d5892b87aa8d57edde4126f49
Author: Lance Ortiz <lance.ortiz@hp.com>
Date:   Thu May 30 08:25:12 2013 -0600

    aerdrv: Move cper_print_aer() call out of interrupt context
    
    The following warning was seen on 3.9 when a corrected PCIe error was being
    handled by the AER subsystem.
    
    WARNING: at .../drivers/pci/search.c:214 pci_get_dev_by_id+0x8a/0x90()
    
    This occurred because a call to pci_get_domain_bus_and_slot() was added to
    cper_print_pcie() to setup for the call to cper_print_aer().  The warning
    showed up because cper_print_pcie() is called in an interrupt context and
    pci_get* functions are not supposed to be called in that context.
    
    The solution is to move the cper_print_aer() call out of the interrupt
    context and into aer_recover_work_func() to avoid any warnings when calling
    pci_get* functions.
    
    Signed-off-by: Lance Ortiz <lance.ortiz@hp.com>
    Acked-by: Borislav Petkov <bp@suse.de>
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>

commit 7afce3f5e56e9cb97cf1f35832bf8e8dde08cc45
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Thu May 30 13:42:27 2013 +0100

    ASoC: wm8994: Ensure microphone detection state is reset on removal
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit 077f5f1c23b3cf1134c031677497dfb6077e6bdd
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed May 29 11:33:52 2013 -0400

    USB: EHCI: fix regression related to qh_refresh()
    
    This patch adds some code that inadvertently got left out of commit
    c1fdb68e3d73741630ca16695cf9176c233be7ed (USB: EHCI: changes related
    to qh_refresh()).  The calls to qh_refresh() and qh_link_periodic()
    were taken out of qh_schedule(); therefore it is necessary to call
    these routines manually after calling qh_schedule().
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: Oleksij Rempel <linux@rempel-privat.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76554b87c85c0ac5ba56797dda670bad6677f9f1
Author: Bob Liu <lliubbo@gmail.com>
Date:   Mon May 27 11:15:40 2013 +0800

    drivers: staging: zcache: fix compile error
    
    Fix below compile error:
    drivers/built-in.o: In function `zcache_pampd_free':
    >> zcache-main.c:(.text+0xb1c8a): undefined reference to `ramster_pampd_free'
    >> zcache-main.c:(.text+0xb1cbc): undefined reference to `ramster_count_foreign_pages'
    drivers/built-in.o: In function `zcache_pampd_get_data_and_free':
    >> zcache-main.c:(.text+0xb1f05): undefined reference to `ramster_count_foreign_pages'
    drivers/built-in.o: In function `zcache_cpu_notifier':
    >> zcache-main.c:(.text+0xb228d): undefined reference to `ramster_cpu_up'
    >> zcache-main.c:(.text+0xb2339): undefined reference to `ramster_cpu_down'
    drivers/built-in.o: In function `zcache_pampd_create':
    >> (.text+0xb26ce): undefined reference to `ramster_count_foreign_pages'
    drivers/built-in.o: In function `zcache_pampd_create':
    >> (.text+0xb27ef): undefined reference to `ramster_count_foreign_pages'
    drivers/built-in.o: In function `zcache_put_page':
    >> (.text+0xb299f): undefined reference to `ramster_do_preload_flnode'
    drivers/built-in.o: In function `zcache_flush_page':
    >> (.text+0xb2ea3): undefined reference to `ramster_do_preload_flnode'
    drivers/built-in.o: In function `zcache_flush_object':
    >> (.text+0xb307c): undefined reference to `ramster_do_preload_flnode'
    drivers/built-in.o: In function `zcache_init':
    >> zcache-main.c:(.text+0xb3629): undefined reference to `ramster_register_pamops'
    >> zcache-main.c:(.text+0xb3868): undefined reference to `ramster_init'
    >> drivers/built-in.o:(.rodata+0x15058): undefined reference to `ramster_foreign_eph_pages'
    >> drivers/built-in.o:(.rodata+0x15078): undefined reference to `ramster_foreign_pers_pages'
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Bob Liu <bob.liu@oracle.com>
    Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 308853139fcd440e4ca28d844678c7e69fb40826
Author: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
Date:   Fri May 24 16:27:56 2013 -0700

    staging: dwc2: fix value of dma_mask
    
    Passing the value DMA_BIT_MASK(31) to dma_set_mask() causes the
    dwc2-pci driver to sometimes fail (cannot enumerate the connected
    device). Change it to DMA_BIT_MASK(32) instead, which is a more
    sensible value anyway.
    
    Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e43088bb015397930d6c9ea5edba92abc0dc655
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Wed May 29 18:38:46 2013 +0100

    ASoC: wm8994: Avoid leaking pm_runtime reference on removed jack race
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit f232168df0c7e7414b70ac5d8fed83086d441c0b
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Thu May 30 15:55:09 2013 +0530

    regulator: palmas: Fix "enable_reg" to point to the correct reg for SMPS10
    
    regulator_enable_regmap() uses enable_reg to enable the regulator.
    But enable_reg for smps10 points to SMPS10_STATUS which is a
    read-only register. Fixed the same by having enable_reg
    set to SMPS10_CTRL.
    
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Cc: stable@vger.kernel.org

commit 3f4d6364084ca0525591836eba4a59f04bb85c68
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date:   Wed May 8 16:09:06 2013 +0530

    regulator: palmas: Fix incorrect condition
    
    Since 'id' cannot take two values at the same time, the condition
    should probably be an OR (||) instead of AND (&&).
    
    Introduced by commit 28d1e8cd67 ("regulator: palma: add ramp delay
    support through regulator constraints").
    
    Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit ac4e97abce9b80c020e7113325f49e58b7b15e3f
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Thu May 30 09:19:35 2013 +0200

    scatterlist: sg_set_buf() argument must be in linear mapping
    
    Add a check behind CONFIG_DEBUG_SG to verify this.
    
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>

commit 4997b72ee62930cb841d185398ea547d979789f4
Author: Kent Overstreet <koverstreet@google.com>
Date:   Thu May 30 08:44:39 2013 +0200

    raid5: Initialize bi_vcnt
    
    The patch that converted raid5 to use bio_reset() forgot to initialize
    bi_vcnt.
    
    Signed-off-by: Kent Overstreet <koverstreet@google.com>
    Cc: NeilBrown <neilb@suse.de>
    Cc: linux-raid@vger.kernel.org
    Tested-by: Ilia Mirkin <imirkin@alum.mit.edu>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>

commit 1aeeac7ad484e1bea6fe602880893b3074adb40a
Author: David Howells <dhowells@redhat.com>
Date:   Tue May 28 20:21:25 2013 +0100

    MN10300: Need pci_iomap() and __pci_ioport_map() defining
    
    Include the generic definitions of pci_iomap() and __pci_ioport_map()
    otherwise we can get errors like:
    
      lib/pci_iomap.c: In function 'pci_iomap':
      lib/pci_iomap.c:37: error: implicit declaration of function '__pci_ioport_map'
      lib/pci_iomap.c:37: warning: return makes pointer from integer without a cast
    
    and:
    
      drivers/pci/quirks.c: In function 'disable_igfx_irq':
      drivers/pci/quirks.c:2893: error: implicit declaration of function 'pci_iomap'
      drivers/pci/quirks.c:2893: warning: initialization makes pointer from integer without a cast
      drivers/pci/quirks.c: In function 'reset_ivb_igd':
      drivers/pci/quirks.c:3133: warning: assignment makes pointer from integer without a cast
    
    Signed-off-by: David Howells <dhowells@redhat.com>
    Acked-by: Ken Cox <jkc@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit b8bc9b0237873e814266566f84003d73799f170f
Author: David Howells <dhowells@redhat.com>
Date:   Tue May 28 20:21:17 2013 +0100

    MN10300: ASB2305's PCI code needs the definition of XIRQ1
    
    The code for PCI in the ASB2305 needs the definition of XIRQ1 from proc/irq.h
    otherwise the following error appears:
    
      arch/mn10300/unit-asb2305/pci.c: In function 'unit_pci_init':
      arch/mn10300/unit-asb2305/pci.c:481: error: 'XIRQ1' undeclared (first use in this function)
      arch/mn10300/unit-asb2305/pci.c:481: error: (Each undeclared identifier is reported only once
      arch/mn10300/unit-asb2305/pci.c:481: error: for each function it appears in.)
    
    Signed-off-by: David Howells <dhowells@redhat.com>
    Acked-by: Ken Cox <jkc@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit d17fc238ac1486906ff724b4a5fe4ec169f554c5
Author: David Howells <dhowells@redhat.com>
Date:   Tue May 28 20:21:10 2013 +0100

    MN10300: Enable IRQs more in system call exit work path
    
    Enable IRQs when calling schedule() for TIF_NEED_RESCHED and
    do_notify_resume().  If interrupts are enabled during do_notify_resume(), a
    warning can be seen (see lower down).
    
    Whilst we're at it, resume_userspace can be made local to entry.S as it is not
    called outside of there and it can be merged with the part of work_resched that
    occurs after schedule() is called.
    
      WARNING: at kernel/softirq.c:160 local_bh_enable+0x42/0xa0()
      Call Trace:
        local_bh_enable+0x42/0xa0
        unix_release_sock+0x86/0x23c
        unix_release+0x20/0x28
        sock_release+0x17/0x88
        sock_close+0x20/0x28
        __fput+0xc9/0x1fc
        ____fput+0xb/0x10
        task_work_run+0x64/0x78
        do_notify_resume+0x53d/0x544
        work_notifysig+0xa/0xc
    
    Signed-off-by: David Howells <dhowells@redhat.com>
    Acked-by: Ken Cox <jkc@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 1e00227d4e8017ac9c3f73bf949a06c6e27f5122
Author: David Howells <dhowells@redhat.com>
Date:   Tue May 28 20:21:02 2013 +0100

    MN10300: Fix ret_from_kernel_thread
    
    ret_from_kernel_thread needs to set A2 to the thread_info pointer before
    jumping to syscall_exit.
    
    Without this, we never correctly start userspace.
    
    This was caused by the rejuggling of the fork/exec paths in commit
    ddf23e87a804 ("mn10300: switch to saner kernel_execve() semantics")
    
    Reported-by: Ken Cox <jkc@redhat.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Acked-by: Ken Cox <jkc@redhat.com>
    Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 1d19f7800d643b270b28d0a969c5eca455d54397
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed May 15 01:30:01 2013 -0700

    ib_srpt: Call target_sess_cmd_list_set_waiting during shutdown_session
    
    Given that srpt_release_channel_work() calls target_wait_for_sess_cmds()
    to allow outstanding se_cmd_t->cmd_kref a change to complete, the call
    to perform target_sess_cmd_list_set_waiting() needs to happen in
    srpt_shutdown_session()
    
    Also, this patch adds an explicit call to srpt_shutdown_session() within
    srpt_drain_channel() so that target_sess_cmd_list_set_waiting() will be
    called in the cases where TFO->shutdown_session() is not triggered
    directly by TCM.
    
    Cc: Joern Engel <joern@logfs.org>
    Cc: Roland Dreier <roland@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 9b31a328e344e62e7cc98ae574edcb7b674719bb
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed May 15 00:52:44 2013 -0700

    target: Re-instate sess_wait_list for target_wait_for_sess_cmds
    
    Switch back to pre commit 1c7b13fe652 list splicing logic for active I/O
    shutdown with tcm_qla2xxx + ib_srpt fabrics.
    
    The original commit was done under the incorrect assumption that it's safe to
    walk se_sess->sess_cmd_list unprotected in target_wait_for_sess_cmds() after
    sess->sess_tearing_down = 1 has been set by target_sess_cmd_list_set_waiting()
    during session shutdown.
    
    So instead of adding sess->sess_cmd_lock protection around sess->sess_cmd_list
    during target_wait_for_sess_cmds(), switch back to sess->sess_wait_list to
    allow wait_for_completion() + TFO->release_cmd() to occur without having to
    walk ->sess_cmd_list after the list_splice.
    
    Also add a check to exit if target_sess_cmd_list_set_waiting() has already
    been called, and add a WARN_ON to check for any fabric bug where new se_cmds
    are added to sess->sess_cmd_list after sess->sess_tearing_down = 1 has already
    been set.
    
    Cc: Joern Engel <joern@logfs.org>
    Cc: Roland Dreier <roland@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 419e321df8d7d605f21f980903befc65ee66e848
Author: Tony Prisk <linux@prisktech.co.nz>
Date:   Sat May 18 09:18:49 2013 +1200

    clk: vt8500: Fix unbalanced spinlock in vt8500_dclk_set_rate()
    
    With the addition of a DVO clock, a bug is now evident in the vt8500
    clock code:
    [    0.290000] WARNING: at init/main.c:698 do_one_initcall+0x158/0x18c()
    [    0.300000] initcall wm8505fb_driver_init+0x0/0xc returned with disabled int
    
    This is caused by an unbalanced spinlock in vt8500_dclk_set_rate().
    Replace the second call to spin_lock_irqsave() with spin_unlock_irqrestore().
    
    Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
    Signed-off-by: Mike Turquette <mturquette@linaro.org>

commit e983b7b17ad1a978e954e6aaa62cf12bfc747883
Author: Dirk Gouders <dirk@gouders.net>
Date:   Tue May 21 10:54:11 2013 +0200

    kconfig/menu.c: fix multiple references to expressions in menu_add_prop()
    
    menu_add_prop() applies upper menus' visibilities to actual prompts
    by AND-ing the prompts visibilities with the upper menus ones.
    
    This creates a further reference to the menu's visibilities and when
    the expression reduction functions do their work, they may remove or
    modify expressions that have multiple references, thus causing
    unpredictable side-effects.
    
    The following example Kconfig constructs a case where this causes
    problems: a menu and a prompt which's visibilities depend on the same
    symbol.  When invoking mconf with this Kconfig and pressing "Z" we
    see a problem caused by a free'd expression still referenced by the
    menu's visibility:
    
    ------------------------------------------------------------------------
    mainmenu "Kconfig Testing Configuration"
    
    config VISIBLE
    	def_bool n
    
    config Placeholder
    	bool "Place holder"
    
    menu "Invisible"
    	visible if VISIBLE
    
    config TEST_VAR
    	bool "Test option" if VISIBLE
    
    endmenu
    ------------------------------------------------------------------------
    
    This patch fixes this problem by creating copies of the menu's
    visibility expressions before AND-ing them with the prompt's one.
    
    Signed-off-by: Dirk Gouders <dirk@gouders.net>
    [yann.morin.1998@free.fr: move variable into its block-scope,
                              keep lines <80 chars, typo]
    Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
    Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
    Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

commit 063f4661fde8c03c4c03f8a205071a52691c152e
Author: Dirk Gouders <dirk@gouders.net>
Date:   Sun May 19 21:48:44 2013 +0200

    mconf: handle keys in empty dialogs
    
    When entering an empty dialog, using the movement keys resulted in
    unexpected characters beeing displayed, other keys like "z" and "h"
    did not work as expected.
    
    This patch handles the movement keys as well as other keys, especially
    "z", "h" and "/".
    
    Signed-off-by: Dirk Gouders <dirk@gouders.net>
    [yann.morin.1998@free.fr: keep lines <80 chars, so reorder test]
    Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
    Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
    Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

commit 6532cb71fb31436b8d31818a056f45b8f95dfb31
Author: Marek Belisko <marek.belisko@gmail.com>
Date:   Fri May 3 07:53:23 2013 +0200

    clk: si5351: Set initial clkout rate when defined in platform data.
    
    clock-frequency property from platform data was read but never used.
    Apply defined rate when clock is registered.
    
    Signed-off-by: Marek Belisko <marek.belisko@streamunlimited.com>
    Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
    Signed-off-by: Mike Turquette <mturquette@linaro.org>
    [mturquette@linaro.org: add missing changelog]
    Cc: stable@kernel.org
    
    Signed-off-by: Mike Turquette <mturquette@linaro.org>

commit 67e1e2268e598861dc771e3c976daf07db380638
Author: Marek Belisko <marek.belisko@gmail.com>
Date:   Fri May 3 07:53:22 2013 +0200

    clk: si5351: Fix clkout rate computation.
    
    Rate was incorrectly computed because we read from wrong divider register.
    
    Signed-off-by: Marek Belisko <marek.belisko@streamunlimited.com>
    Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
    Signed-off-by: Mike Turquette <mturquette@linaro.org>
    Cc: stable@kernel.org

commit f448badd34700ae728a32ba024249626d49c10e1
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed May 29 15:36:40 2013 -0400

    NFSv4: Fix a thinko in nfs4_try_open_cached
    
    We need to pass the full open mode flags to nfs_may_open() when doing
    a delegated open.
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Cc: stable@vger.kernel.org

commit 0184d50f9fd17658c232d6ee6d465a87f989d706
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Wed May 29 15:56:49 2013 -0400

    tracing: Fix bad parameter passed in branch selftest
    
    The branch selftest calls trace_test_buffer(), but with the new code
    it expects the first parameter to be a pointer to a struct trace_buffer.
    All self tests were changed but the branch selftest was missed.
    
    This caused either a crash or failed test when the branch selftest was
    enabled.
    
    Link: http://lkml.kernel.org/r/20130529141333.GA24064@localhost
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

commit 8d0b8801c9e4c2c6b20cdac74dbab16facce7653
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Wed May 29 17:02:58 2013 +0100

    xenbus_client.c: correct exit path for xenbus_map_ring_valloc_hvm
    
    Apparently we should not free page that has not been allocated.
    This is b/c alloc_xenballooned_pages will take care of freeing
    the page on its own.
    
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 056f3d58db6f7d19be7dbc2aab8d049f28e20d6e
Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
Date:   Fri May 10 18:38:09 2013 +0200

    clk: samsung: Add CLK_IGNORE_UNUSED flag for the sysreg clocks
    
    Currently no driver *) handles the sysreg clock, with an assumption
    that this clock is always left in its default state (enabled).
    
    Before commit 6e6aac7590f902d14d90bace3fd499
    ARM: EXYNOS: Migrate clock support to common clock framework
    
    the sysreg clock was not even defined and hence wasn't handled
    explicitly in the kernel.
    
    To restore the previous behaviour disable masking the sysreg clock
    off in the clock core by default.
    
    *) Except the Exynos4x12 FIMC-IS driver, which will be modified
       to not touch the sysreg clock.
    
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Mike Turquette <mturquette@linaro.org>

commit f586938ba2cf83ed4cbebe96436220d182a7808e
Author: Fabio Baltieri <fabio.baltieri@linaro.org>
Date:   Tue Apr 30 14:45:06 2013 +0200

    clk: ux500: clk-sysctrl: handle clocks with no parents
    
    Fix clk_reg_sysctrl() to set main clock registers of new struct
    clk_sysctrl even if the registered clock has no parents.
    
    This fixes an issue where "ulpclk" was registered with all clk->reg_*
    fields uninitialized, causing a -EINVAL error from clk_prepare().
    
    Signed-off-by: Fabio Baltieri <fabio.baltieri@linaro.org>
    Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Mike Turquette <mturquette@linaro.org>

commit dd4704480372fdbf3e8f7826274a883c4c7c335a
Author: Lee Jones <lee.jones@linaro.org>
Date:   Wed May 8 14:29:03 2013 +0100

    clk: ux500: Provide device enumeration number suffix for SMSC911x
    
    First Ethernet device has a ".0" appended onto the device name. It
    appears that we need this in order to obtain the correct clock.
    
    Without this fix Ethernet does not function on Ux500 devices, which is a
    regression.
    
    Cc: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Mike Turquette <mturquette@linaro.org>
    [mturquette@linaro.org: improved changelog]

commit 7d8acf2cba81d7c64842b5dac0d7b3dae16f0378
Author: Nicolas Schichan <nschichan@freebox.fr>
Date:   Wed May 29 20:01:20 2013 +0200

    ASoC: cs42l52: fix hp_gain_enum shift value.
    
    Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
    Acked-by: Brian Austin <brian.austin@cirrus.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit 8ac60a6866e58b861f2a15689c6513faf1602a3d
Author: Nicolas Schichan <nschichan@freebox.fr>
Date:   Wed May 29 20:01:19 2013 +0200

    ASoC: cs42l52: use correct PCM mixer TLV dB scale to match datasheet.
    
    Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
    Acked-by: Brian Austin <brian.austin@cirrus.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit 7e0e41963740525af702bb23edede8ae9afc4ac0
Author: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
Date:   Fri May 3 19:43:13 2013 -0300

    radeon: use max_bus_speed to activate gen2 speeds
    
    radeon currently uses a drm function to get the speed capabilities for
    the bus, drm_pcie_get_speed_cap_mask. However, this is a non-standard
    method of performing this detection and this patch changes it to use
    the max_bus_speed attribute.
    
    From: Lucas Kannebley Tavares <lucaskt@linux.vnet.ibm.com>
    Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit 50a583f64bfe53aae4996965c1d1b25d90ce4f64
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed May 22 13:29:33 2013 -0400

    drm/radeon: narrow scope of Apple re-POST hack
    
    This narrows the scope of the apple re-POST hack added in:
    drm/radeon: re-POST the asic on Apple hardware when booted via EFI
    
    That patch prevents UVD from working on macs when booted in EFI
    mode.  The original patch fixed macbook2,1 systems which were
    r5xx and hence have no UVD.  Limit the hack to those systems to
    prevent UVD breakage on newer systems.
    
    Fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=63935
    
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Acked-by: Matthew Garrett <matthew.garrett@nebula.com>

commit a70b9641e6a90d6821e4354a2c2fede74015db29
Author: Jan Beulich <JBeulich@suse.com>
Date:   Wed May 29 13:33:51 2013 +0100

    ipvs: ip_vs_sh: fix build
    
    kfree_rcu() requires offsetof(..., rcu_head) < 4096, which can
    get violated with a sufficiently high CONFIG_IP_VS_SH_TAB_BITS.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

commit 2cf3a4fcc64e5b54a8a3cd793c6c0024b5d8da6c
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed May 22 11:30:34 2013 -0400

    drm/radeon: don't check crtcs in card_posted() on cards without DCE
    
    Skip checking crtcs in hardware without them.  Avoids checking
    non-existent hardware.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit 09fb8bd1a63b0f9f15e655c4fe8d047e5d2bf67a
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed May 22 11:22:51 2013 -0400

    drm/radeon: fix card_posted check for newer asics
    
    Newer asics have variable numbers of crtcs.  Use that
    rather than the asic family to determine which crtcs
    to check.  This avoids checking non-existent crtcs or
    missing crtcs on certain asics.
    
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org

commit 468ef1a58c9268ac9709350bf95eaf1c22a69f29
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue May 21 13:35:19 2013 -0400

    drm/radeon: fix typo in cu_per_sh on verde
    
    Should be 5 rather than 2.
    
    Noticed by sroland and glisse on IRC.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org

commit 27b0705c68dab67a6c8ffa19869aeca3eaf75d78
Author: Christian König <christian.koenig@amd.com>
Date:   Tue May 21 17:14:18 2013 +0200

    drm/radeon: UVD block on SUMO2 is the same as on SUMO
    
    The chip id for SUMO2 isn't used.
    
    fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=63935
    
    Tested-By: Dave Witbrodt <dawitbro@sbcglobal.net>
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit afe3c3fd5392b2f0066930abc5dbd3f4b14a0f13
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Fri May 24 17:24:34 2013 -0400

    svcrpc: fix failures to handle -1 uid's and gid's
    
    As of f025adf191924e3a75ce80e130afcd2485b53bb8 "sunrpc: Properly decode
    kuids and kgids in RPC_AUTH_UNIX credentials" any rpc containing a -1
    (0xffff) uid or gid would fail with a badcred error.
    
    Reported symptoms were xmbc clients failing on upgrade of the NFS
    server; examination of the network trace showed them sending -1 as the
    gid.
    
    Reported-by: Julian Sikorski <belegdol@gmail.com>
    Tested-by: Julian Sikorski <belegdol@gmail.com>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

commit 104529661b645295903c5007ae632d2dd4029254
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu May 16 11:11:08 2013 +0300

    pktcdvd: silence static checker warning
    
    Static checkers complain about widening the binary "not" operations here
    because sectors are u64 and "(pd)->settings.size" is unsigned int.
    It unintentionally clears the high 32 bits of the sector.  This means
    that the driver won't work for devices with over 2TB of space.  Since
    this is a DVD drive, we're unlikely to reach that limit, but we may as
    well silence the warning.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit d69c0e3975e4955dd596c162d1628ba1dbb1eb45
Author: Jan Beulich <JBeulich@suse.com>
Date:   Wed May 29 13:31:15 2013 +0100

    xen-pciback: more uses of cached MSI-X capability offset
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 1db01b4903639fcfaec213701a494fe3fb2c490b
Author: Stefan Bader <stefan.bader@canonical.com>
Date:   Wed May 8 16:37:35 2013 +0200

    xen: Clean up apic ipi interface
    
    Commit f447d56d36af18c5104ff29dcb1327c0c0ac3634 introduced the
    implementation of the PV apic ipi interface. But there were some
    odd things (it seems none of which cause really any issue but
    maybe they should be cleaned up anyway):
     - xen_send_IPI_mask_allbutself (and by that xen_send_IPI_allbutself)
       ignore the passed in vector and only use the CALL_FUNCTION_SINGLE
       vector. While xen_send_IPI_all and xen_send_IPI_mask use the vector.
     - physflat_send_IPI_allbutself is declared unnecessarily. It is never
       used.
    
    This patch tries to clean up those things.
    
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 33c1174bae3ea8f420abce53cf8aded778987583
Author: Aurelien Chartier <aurelien.chartier@citrix.com>
Date:   Tue May 28 18:09:55 2013 +0100

    xenbus: save xenstore local status for later use
    
    Save the xenstore local status computed in xenbus_init. It can then be used
    later to check if xenstored is running in this domain.
    
    Signed-off-by: Aurelien Chartier <aurelien.chartier@citrix.com>
    [Changes in v4:
    - Change variable name to xen_store_domain_type]
    Reviewed-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit 2abb274629614bef4044a0b98ada42e977feadfd
Author: Aurelien Chartier <aurelien.chartier@citrix.com>
Date:   Tue May 28 18:09:56 2013 +0100

    xenbus: delay xenbus frontend resume if xenstored is not running
    
    If the xenbus frontend is located in a domain running xenstored, the device
    resume is hanging because it is happening before the process resume. This
    patch adds extra logic to the resume code to check if we are the domain
    running xenstored and delay the resume if needed.
    
    Signed-off-by: Aurelien Chartier <aurelien.chartier@citrix.com>
    [Changes in v2:
    - Instead of bypassing the resume, process it in a workqueue]
    [Changes in v3:
    - Add a struct work in xenbus_device to avoid dynamic allocation
    - Several small code fixes]
    [Changes in v4:
    - Use a dedicated workqueue]
    [Changes in v5:
    - Move create_workqueue error handling to xenbus_frontend_dev_resume]
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit d660164d79b67f879db35a7d61e47d3b99bc714e
Author: Michal Kubeček <mkubecek@suse.cz>
Date:   Tue May 28 22:37:03 2013 +0000

    netfilter: xt_LOG: fix mark logging for IPv6 packets
    
    In dump_ipv6_packet(), the "recurse" parameter is zero only if
    dumping contents of a packet embedded into an ICMPv6 error
    message. Therefore we want to log packet mark if recurse is
    non-zero, not when it is zero.
    
    Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

commit e2e2f0ea1c935edcf53feb4c4c8fdb4f86d57dd9
Author: Federico Manzan <f.manzan@gmail.com>
Date:   Fri May 24 18:18:48 2013 +0200

    usbfs: Increase arbitrary limit for USB 3 isopkt length
    
    Increase the current arbitrary limit for isocronous packet size to a
    value large enough to account for USB 3.0 super bandwidth streams,
    bMaxBurst (0~15 allowed, 1~16 packets)
    bmAttributes (bit 1:0, mult 0~2, 1~3 packets)
    so the size max for one USB 3 isocronous transfer is
    1024 byte * 16 * 3 = 49152 byte
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Federico Manzan <f.manzan@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e6d91ae0917bf934ed86411148f79d904728d51
Author: Jason Wang <jasowang@redhat.com>
Date:   Tue May 28 18:32:11 2013 +0000

    tuntap: forbid changing mq flag for persistent device
    
    We currently allow changing the mq flag (IFF_MULTI_QUEUE) for a persistent
    device. This will result a mismatch between the number the queues in netdev and
    tuntap. This is because we only allocate a 1q netdevice when IFF_MULTI_QUEUE was
    not specified, so when we set the IFF_MULTI_QUEUE and try to attach more queues
    later, netif_set_real_num_tx_queues() may fail which result a single queue
    netdevice with multiple sockets attached.
    
    Solve this by disallowing changing the mq flag for persistent device.
    
    Bug was introduced by commit edfb6a148ce62e5e19354a1dcd9a34e00815c2a1
    (tuntap: reduce memory using of queues).
    
    Reported-by: Sriram Narasimhan <sriram.narasimhan@hp.com>
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 456db6a4d495f40777da6f1f32f62f13026f52db
Author: Federico Vaga <federico.vaga@gmail.com>
Date:   Tue May 28 05:02:44 2013 +0000

    net/core/sock.c: add missing VSOCK string in af_family_*_key_strings
    
    The three arrays of strings: af_family_key_strings,
    af_family_slock_key_strings and af_family_clock_key_strings have not
    VSOCK's string
    
    Signed-off-by: Federico Vaga <federico.vaga@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit cf6c31fc5c3de225348742c95cc6185fca20a2f2
Author: Greg Ungerer <gerg@uclinux.org>
Date:   Mon Apr 29 10:04:46 2013 +1000

    m68k: only use local gpio_request_one if not using GPIOLIB
    
    Compiling for targets that use the local gpio code (not GPIOLIB) fail to
    compile with:
    
      CC      arch/m68k/platform/coldfire/device.o
    In file included from include/linux/gpio.h:45:0,
                     from arch/m68k/platform/coldfire/device.c:15:
    /home/gerg/new-wave.git/linux-3.x/arch/m68k/include/asm/gpio.h:89:19: error: static declaration of ‘gpio_request_one’ follows non-static declaration
    include/asm-generic/gpio.h:195:12: note: previous declaration of ‘gpio_request_one’ was here
    
    Fix by conditionally using the local gpio_request_one() function based on
    !CONFIG_GPIOLIB.
    
    Signed-off-by: Greg Ungerer <gerg@uclinux.org>

commit 1be374a0518a288147c6a7398792583200a67261
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Wed May 22 14:07:44 2013 -0700

    net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg
    
    To: linux-kernel@vger.kernel.org
    Cc: x86@kernel.org, trinity@vger.kernel.org, Andy Lutomirski <luto@amacapital.net>, netdev@vger.kernel.org, "David S.
    	Miller" <davem@davemloft.net>
    Subject: [PATCH 5/5] net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg
    
    MSG_CMSG_COMPAT is (AFAIK) not intended to be part of the API --
    it's a hack that steals a bit to indicate to other networking code
    that a compat entry was used.  So don't allow it from a non-compat
    syscall.
    
    This prevents an oops when running this code:
    
    int main()
    {
    	int s;
    	struct sockaddr_in addr;
    	struct msghdr *hdr;
    
    	char *highpage = mmap((void*)(TASK_SIZE_MAX - 4096), 4096,
    	                      PROT_READ | PROT_WRITE,
    	                      MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
    	if (highpage == MAP_FAILED)
    		err(1, "mmap");
    
    	s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
    	if (s == -1)
    		err(1, "socket");
    
            addr.sin_family = AF_INET;
            addr.sin_port = htons(1);
            addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
    	if (connect(s, (struct sockaddr*)&addr, sizeof(addr)) != 0)
    		err(1, "connect");
    
    	void *evil = highpage + 4096 - COMPAT_MSGHDR_SIZE;
    	printf("Evil address is %p\n", evil);
    
    	if (syscall(__NR_sendmmsg, s, evil, 1, MSG_CMSG_COMPAT) < 0)
    		err(1, "sendmmsg");
    
    	return 0;
    }
    
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 1bb539ca36e21c2f4fce0865e11df384bc7b7656
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Tue May 28 14:38:43 2013 -0400

    ftrace: Use the rcu _notrace variants for rcu_dereference_raw() and friends
    
    As rcu_dereference_raw() under RCU debug config options can add quite a
    bit of checks, and that tracing uses rcu_dereference_raw(), these checks
    happen with the function tracer. The function tracer also happens to trace
    these debug checks too. This added overhead can livelock the system.
    
    Have the function tracer use the new RCU _notrace equivalents that do
    not do the debug checks for RCU.
    
    Link: http://lkml.kernel.org/r/20130528184209.467603904@goodmis.org
    
    Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

commit 12bcbe66d7b3cc9f9f86cd02f925666eaa3c2107
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Tue May 28 14:38:42 2013 -0400

    rcu: Add _notrace variation of rcu_dereference_raw() and hlist_for_each_entry_rcu()
    
    As rcu_dereference_raw() under RCU debug config options can add quite a
    bit of checks, and that tracing uses rcu_dereference_raw(), these checks
    happen with the function tracer. The function tracer also happens to trace
    these debug checks too. This added overhead can livelock the system.
    
    Add a new interface to RCU for both rcu_dereference_raw_notrace() as well
    as hlist_for_each_entry_rcu_notrace() as the hlist iterator uses the
    rcu_dereference_raw() as well, and is used a bit with the function tracer.
    
    Link: http://lkml.kernel.org/r/20130528184209.304356745@goodmis.org
    
    Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

commit 5cbfa3acdcbf19e1d29cf3479ad8200d2e644e44
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon May 27 14:44:44 2013 +0200

    USB: zte_ev: fix control-message timeouts
    
    The control-message timeout is specified in milliseconds and should not
    depend on HZ.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 849513a7809175420d353625b6f651d961e99d49
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon May 27 14:44:43 2013 +0200

    USB: mos7720: fix message timeouts
    
    The control and bulk-message timeouts are specified in milliseconds and
    should not depend on HZ.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c13ff68a7ce01da7a51b44241a7aad8eaaedde7
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon May 27 14:44:42 2013 +0200

    USB: iuu_phoenix: fix bulk-message timeout
    
    The bulk-message timeout is specified in milliseconds and should not
    depend on HZ.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 634371911730a462626071065b64cd6e1fe213e0
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon May 27 14:44:41 2013 +0200

    USB: ark3116: fix control-message timeout
    
    The control-message timeout is specified in milliseconds and should not
    depend on HZ.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15ee89c3347fbf58a4361011eda5ac2731e45126
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon May 27 14:44:40 2013 +0200

    USB: mos7840: fix DMA to stack
    
    Fix regression introduced by commit 0eafe4de1a ("USB: serial: mos7840:
    add support for MCS7810 devices") which used stack-allocated buffers for
    control messages.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72ea18a558ed7a63a50bb121ba60d73b5b38ae30
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon May 27 14:44:39 2013 +0200

    USB: mos7720: fix DMA to stack
    
    The read_mos_reg function is called with stack-allocated buffers, which
    must not be used for control messages.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 420021a395ce38b7ab2cceb52dee4038be7d8fa3
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon May 27 14:44:38 2013 +0200

    USB: visor: fix initialisation of Treo/Kyocera devices
    
    Fix regression introduced by commit 214916f2e ("USB: visor: reimplement
    using generic framework") which broke initialisation of Treo/Kyocera
    devices that re-mapped bulk-in endpoints.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f8e2c07d75967ee49a5da1d21ddf5f50d48cda0
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon May 27 14:44:37 2013 +0200

    USB: serial: fix Treo/Kyocera interrrupt-in urb context
    
    The first and second interrupt-in urbs are swapped for some Treo/Kyocera
    devices, but the urb context was never updated with the new port.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fdc03438f53a00294ed9939eb3a1f6db6f3d8963
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue May 28 14:03:10 2013 -0400

    USB: revert periodic scheduling bugfix
    
    This patch reverts commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d
    (USB: EHCI: fix bug in scheduling periodic split transfers).  The
    commit was valid -- it fixed a real bug -- but the periodic scheduler
    in ehci-hcd is in such bad shape (especially the part that handles
    split transactions) that fixing one bug is very likely to cause
    another to surface.  That's what happened in this case; the result was
    choppy and noisy playback on certain 24-bit audio devices.
    
    The only real fix will be to rewrite this entire section of code.  My
    next project...
    
    This fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110.
    
    Thanks to Tim Richardson for extra testing and feedback, and to Joseph
    Salisbury and Tyson Tan for tracking down the original source of the
    problem.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: Joseph Salisbury <joseph.salisbury@canonical.com>
    CC: Tim Richardson <tim@tim-richardson.net>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fcce9a35f8faaa1f52236c554ef1b15d99a7537e
Author: George Spelvin <linux@horizon.com>
Date:   Wed May 29 10:20:35 2013 +0900

    ahci: add an observed PCI ID for Marvell 88se9172 SATA controller
    
    A third possible PCI ID, as personally observed, and found in the
    pci.ids list.
    
    Signed-off-by: George Spelvin <linux@horizon.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>

commit da9d0fbf5e9aa47492a19588bd0efd18d6d172e0
Author: Olof Johansson <olof@lixom.net>
Date:   Thu May 9 13:58:19 2013 -0700

    ARM: exynos: defconfig update
    
    This turns on a number of configs that are useful on the Chromebook, but also
    good to have on in general:
    
    * USB host and MMC drivers(!)
    * I2C GPIO arbitration driver
    * CYAPA trackpad driver
    * simplefb
    * CROS EC and keyboard drivers
    * S5M8767 driver
    * MAX77686 drivers
    * MAX8997 driver
    * DEVTMPFS + mount
    * DM_CRYPT (as module)
    * CRYPTOLOOP
    * HIGHMEM
    * PRINTK timestamps
    
    This also turns off DEBUG_LL, and switches the hardcoded Samsung lowlevel
    uart to uart 3 (which is only used to show the "uncompressing kernel"
    message at boot, it seems).
    
    Signed-off-by: Olof Johansson <olof@lixom.net>
    Reviewed-by: Doug Anderson <dianders@chromium.org>
    Tested-by: Tushar Behera <tushar.behera@linaro.org>
    Acked-by: Kukjin Kim <kgene.kim@samsung.com>

commit 2a0ff3fbe39bc93f719ff857e5a359d9780579ff
Author: Jeff Liu <jeff.liu@oracle.com>
Date:   Sun May 26 21:33:09 2013 +0800

    cgroup: warn about mismatching options of a new mount of an existing hierarchy
    
    With the new __DEVEL__sane_behavior mount option was introduced,
    if the root cgroup is alive with no xattr function, to mount a
    new cgroup with xattr will be rejected in terms of design which
    just fine.  However, if the root cgroup does not mounted with
    __DEVEL__sane_hehavior, to create a new cgroup with xattr option
    will succeed although after that the EA function does not works
    as expected but will get ENOTSUPP for setting up attributes under
    either cgroup. e.g.
    
    setfattr: /cgroup2/test: Operation not supported
    
    Instead of keeping silence in this case, it's better to drop a log
    entry in warning level.  That would be helpful to understand the
    reason behind the scene from the user's perspective, and this is
    essentially an improvement does not break the backward compatibilities.
    
    With this fix, above mount attemption will keep up works as usual but
    the following line cound be found at the system log:
    
    [ ...] cgroup: new mount options do not match the existing superblock
    
    tj: minor formatting / message updates.
    
    Signed-off-by: Jie Liu <jeff.liu@oracle.com>
    Reported-by: Alexey Kodanev <alexey.kodanev@oracle.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: stable@vger.kernel.org

commit e9d0626ed43a41a3fc526d1df06122b0d4eac174
Author: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Date:   Tue May 14 14:48:58 2013 +0800

    x86-64, init: Fix a possible wraparound bug in switchover in head_64.S
    
    In head_64.S, a switchover has been used to handle kernel crossing
    1G, 512G boundaries.
    
    And commit 8170e6bed465b4b0c7687f93e9948aca4358a33b
        x86, 64bit: Use a #PF handler to materialize early mappings on demand
    said:
        During the switchover in head_64.S, before #PF handler is available,
        we use three pages to handle kernel crossing 1G, 512G boundaries with
        sharing page by playing games with page aliasing: the same page is
        mapped twice in the higher-level tables with appropriate wraparound.
    
    But from the switchover code, when we set up the PUD table:
    114         addq    $4096, %rdx
    115         movq    %rdi, %rax
    116         shrq    $PUD_SHIFT, %rax
    117         andl    $(PTRS_PER_PUD-1), %eax
    118         movq    %rdx, (4096+0)(%rbx,%rax,8)
    119         movq    %rdx, (4096+8)(%rbx,%rax,8)
    
    It seems line 119 has a potential bug there. For example,
    if the kernel is loaded at physical address 511G+1008M, that is
        000000000 111111111 111111000 000000000000000000000
    and the kernel _end is 512G+2M, that is
        000000001 000000000 000000001 000000000000000000000
    So in this example, when using the 2nd page to setup PUD (line 114~119),
    rax is 511.
    In line 118, we put rdx which is the address of the PMD page (the 3rd page)
    into entry 511 of the PUD table. But in line 119, the entry we calculate from
    (4096+8)(%rbx,%rax,8) has exceeded the PUD page. IMO, the entry in line
    119 should be wraparound into entry 0 of the PUD table.
    
    The patch fixes the bug.
    
    Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
    Link: http://lkml.kernel.org/r/5191DE5A.3020302@cn.fujitsu.com
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Cc: <stable@vger.kernel.org> v3.9
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

commit b161c144404c18f6a9e20e46b63828ae3c2eb093
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Fri May 24 09:47:49 2013 -0400

    svcrpc: implement O_NONBLOCK behavior for use-gss-proxy
    
    Somebody noticed LTP was complaining about O_NONBLOCK opens of
    /proc/net/rpc/use-gss-proxy succeeding and then a following read
    hanging.
    
    I'm not convinced LTP really has any business opening random proc files
    and expecting them to behave a certain way.  Maybe this isn't really a
    bug.
    
    But in any case the O_NONBLOCK behavior could be useful for someone that
    wants to test whether gss-proxy is up without waiting.
    
    Reported-by: Jan Stancek <jstancek@redhat.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

commit cf9f123b38345b2c2777e642eb9bb561f4b7de91
Author: Matthew Wilcox <matthew.r.wilcox@intel.com>
Date:   Tue May 28 16:46:46 2013 -0400

    NVMe: Use dma_set_mask() correctly
    
    In some circumstances setting a 64-bit DMA mask can fail, as explained
    in Documentation/DMA-API-HOWTO.txt.  Use the recommended code sequence
    to set a 32-bit DMA mask if setting a 64-bit DMA mask fails.
    
    Reported-by: Chayan Biswas <Chayan.Biswas@sandisk.com>
    Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>

commit 0d6bd9953f739dad96d9a0de65383e479ab4e10d
Author: Zoran Markovic <zoran.markovic@linaro.org>
Date:   Fri May 17 11:24:05 2013 -0700

    timekeeping: Correct run-time detection of persistent_clock.
    
    Since commit 31ade30692dc9680bfc95700d794818fa3f754ac, timekeeping_init()
    checks for presence of persistent clock by attempting to read a non-zero
    time value. This is an issue on platforms where persistent_clock (instead
    is implemented as a free-running counter (instead of an RTC) starting
    from zero on each boot and running during suspend. Examples are some ARM
    platforms (e.g. PandaBoard).
    
    An attempt to read such a clock during timekeeping_init() may return zero
    value and falsely declare persistent clock as missing. Additionally, in
    the above case suspend times may be accounted twice (once from
    timekeeping_resume() and once from rtc_resume()), resulting in a gradual
    drift of system time.
    
    This patch does a run-time correction of the issue by doing the same check
    during timekeeping_suspend().
    
    A better long-term solution would have to return error when trying to read
    non-existing clock and zero when trying to read an uninitialized clock, but
    that would require changing all persistent_clock implementations.
    
    This patch addresses the immediate breakage, for now.
    
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Feng Tang <feng.tang@intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org>
    [jstultz: Tweaked commit message and subject]
    Signed-off-by: John Stultz <john.stultz@linaro.org>

commit aa848233f740abbabfa7669daca0ab94aaa37bcd
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Fri May 3 23:27:07 2013 +0200

    ntp: Remove unused variable flags in __hardpps
    
    kernel/time/ntp.c: In function ‘__hardpps’:
    kernel/time/ntp.c:877: warning: unused variable ‘flags’
    
    commit a076b2146fabb0894cae5e0189a8ba3f1502d737 ("ntp: Remove ntp_lock,
    using the timekeeping locks to protect ntp state") removed its users,
    but not the actual variable.
    
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: John Stultz <john.stultz@linaro.org>

commit ed74df12dc3e07a37d99aab60211496e871488a0
Author: Virupax Sadashivpetimath <virupax.sadashivpetimath@stericsson.com>
Date:   Wed Apr 24 08:38:48 2013 +0200

    usb: musb: make use_sg flag URB specific
    
    Since highmem PIO URB handling was introduced in:
    
    8e8a551 usb: musb: host: Handle highmem in PIO mode
    
    when a URB is being handled it may happen that the static use_sg flag
    was set by a previous URB with buffer in highmem.  This leads to error
    in handling the present URB.
    
    Fix this by making the use_sg flag URB specific.
    
    Cc: stable <stable@vger.kernel.org> # 3.7+
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Virupax Sadashivpetimath <virupax.sadashivpetimath@stericsson.com>
    Signed-off-by: Fabio Baltieri <fabio.baltieri@linaro.org>
    Signed-off-by: Felipe Balbi <balbi@ti.com>

commit 5bf8fae33d14cc5c3c53a926f9079f92c8b082b0
Author: George Cherian <george.cherian@ti.com>
Date:   Mon May 27 14:35:49 2013 +0530

    usb: dwc3: gadget: free trb pool only from epnum 2
    
    we never allocate a TRB pool for physical endpoints
    0 and 1 so trying to free it (a invalid TRB pool pointer)
    will lead us in a warning while removing dwc3.ko module.
    
    In order to fix the situation, all we have to do is skip
    dwc3_free_trb_pool() for physical endpoints 0 and 1 just
    as we while deleting endpoints from the endpoints list.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: George Cherian <george.cherian@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>

commit 022d0547aa8b00ff5035ba6207ebc2c08ea0a51f
Author: Peter Chen <peter.chen@freescale.com>
Date:   Fri May 24 14:30:16 2013 +0800

    usb: dwc3: exynos: PHY should be deleted later than dwc3 core
    
    If the glue layer is removed first (core layer later),
    it deletes the phy device first, then the core device.
    But at core's removal, it still uses PHY's resources, it may
    cause kernel's oops. It is much like the problem
    Paul Zimmerman reported at:
    http://marc.info/?l=linux-usb&m=136547502011472&w=2.
    
    Besides, it is reasonable the PHY is deleted at last as
    the controller is the PHY's user.
    
    Signed-off-by: Peter Chen <peter.chen@freescale.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Felipe Balbi <balbi@ti.com>

commit f28c42c576b293b3a1daaed8ca2775ebc2fe5398
Author: Peter Chen <peter.chen@freescale.com>
Date:   Fri May 24 14:29:20 2013 +0800

    usb: dwc3: pci: PHY should be deleted later than dwc3 core
    
    If the glue layer is removed first (core layer later),
    it deletes the phy device first, then the core device.
    But at core's removal, it still uses PHY's resources, it may
    cause kernel's oops. It is much like the problem
    Paul Zimmerman reported at:
    http://marc.info/?l=linux-usb&m=136547502011472&w=2.
    
    Besides, it is reasonable the PHY is deleted at last as
    the controller is the PHY's user.
    
    Signed-off-by: Peter Chen <peter.chen@freescale.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Felipe Balbi <balbi@ti.com>

commit add295a4afbdf5852d004c754c552d692b0fcac8
Author: Gabor Juhos <juhosg@openwrt.org>
Date:   Tue May 28 14:52:19 2013 +0200

    ath9k: use correct OTP register offsets for AR9550
    
    Accessing the OTP memory on AR9950 causes a data bus
    like this:
    
      Data bus error, epc == 801f7774, ra == 801f7774
      Oops[#1]:
      CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0-rc3 #592
      task: 87c28000 ti: 87c22000 task.ti: 87c22000
      $ 0   : 00000000 00000061 deadc0de 00000000
      $ 4   : b8115f18 00015f18 00000007 00000004
      $ 8   : 00000001 7c7c3c7c 7c7c7c7c 7c7c7c7c
      $12   : 7c7c3c7c 80320a68 00000000 7c7c7c3c
      $16   : 87cd8010 00015f18 00000007 00000000
      $20   : 00000064 00000004 87c23c7c 8035210c
      $24   : 00000000 801f3674
      $28   : 87c22000 87c23b48 00000001 801f7774
      Hi    : 00000000
      Lo    : 00000064
      epc   : 801f7774 ath9k_hw_wait+0x58/0xb0
          Not tainted
      ra    : 801f7774 ath9k_hw_wait+0x58/0xb0
      Status: 1000cc03 KERNEL EXL IE
      Cause : 4080801c
      PrId  : 00019750 (MIPS 74Kc)
      Modules linked in:
      Process swapper (pid: 1, threadinfo=87c22000, task=87c28000, ts=00000000)
      Stack : 0000000f 00000061 00002710 8006240c 00000001 87cd8010 87c23bb0 87cd8010
              00000000 00000004 00000003 80210c7c 000000b3 67fa8000 0000032a 000006fe
              000003e8 00000002 00000028 87c23bf0 000003ff 80210d24 803e5630 80210e28
              00000000 00000007 87cd8010 00007044 00000004 00000061 000003ff 000001ff
              87c26000 87cd8010 00000220 87cd8bb8 80210000 8020fcf4 87c22000 87c23c08
              ...
      Call Trace:
      [<801f7774>] ath9k_hw_wait+0x58/0xb0
      [<80210c7c>] ar9300_otp_read_word+0x80/0xd4
      [<80210d24>] ar9300_read_otp+0x54/0xb0
      [<8020fcf4>] ar9300_check_eeprom_header+0x1c/0x40
      [<80210fe4>] ath9k_hw_ar9300_fill_eeprom+0x118/0x39c
      [<80206650>] ath9k_hw_eeprom_init+0x74/0xb4
      [<801f96d0>] ath9k_hw_init+0x7ec/0x96c
      [<801e65ec>] ath9k_init_device+0x340/0x758
      [<801f35d0>] ath_ahb_probe+0x21c/0x2c0
      [<801c041c>] driver_probe_device+0xc0/0x1e4
      [<801c05ac>] __driver_attach+0x6c/0xa4
      [<801bea08>] bus_for_each_dev+0x64/0xa8
      [<801bfa40>] bus_add_driver+0xcc/0x24c
      [<801c0954>] driver_register+0xbc/0x17c
      [<803f8fc0>] ath9k_init+0x5c/0x88
      [<800608fc>] do_one_initcall+0xec/0x1a0
      [<803e6a68>] kernel_init_freeable+0x13c/0x200
      [<80309cdc>] kernel_init+0x1c/0xe4
      [<80062450>] ret_from_kernel_thread+0x10/0x18
    
    On the AR9550, the OTP registers are located at
    the same address as on the AR9340. Use the correct
    values to avoid the error.
    
    Cc: stable@vger.kernel.org  # 3.6+
    Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 102fd0d69eed4c778555fe957f8660dfee1568ea
Author: Hante Meuleman <meuleman@broadcom.com>
Date:   Mon May 27 21:09:59 2013 +0200

    brcmfmac: Disable powersave mode for P2P link.
    
    For p2p client mode powersave mode should be kept disabled. It is
    working but inefficient. In general p2p links do no benefit from this
    mode, because these links are setup temporarily to transfer data.
    
    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>

commit 1c9d30cfac9901c4f7447deacdfb6b77eee1a096
Author: Hante Meuleman <meuleman@broadcom.com>
Date:   Mon May 27 21:09:58 2013 +0200

    brcmfmac: Add multi channel support for P2P.
    
    Multi channel support was disabled. This patch will enable it and
    configure the P2P GO on the correct frequency when multi channel
    is used.
    
    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>

commit cbb371da233eb2b4c200010a5372579b880b4ae6
Author: Arend van Spriel <arend@broadcom.com>
Date:   Mon May 27 21:09:57 2013 +0200

    brcmfmac: use struct net_device::destructor to remove interfaces
    
    Upon deleting a P2P_CLIENT/GO interface the vif and consequently
    the wdev is freed before the net_device is actually being unregistered
    but cfg80211 still needs to access the wdev. Using destructor field
    to free the net_device and vif.
    
    Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
    Signed-off-by: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 9390ace916b2fd866c1762b1cd16c276d8c8c890
Author: Arend van Spriel <arend@broadcom.com>
Date:   Mon May 27 21:09:56 2013 +0200

    brcmfmac: free net device when registration fails
    
    When registration fails the net device is no longer needed. Free
    the net device and remove reference to private data from the
    driver.
    
    Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
    Signed-off-by: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 24e28beef939df8666a5d2784d6617cd9bb910a0
Author: Arend van Spriel <arend@broadcom.com>
Date:   Mon May 27 21:09:55 2013 +0200

    brcmfmac: add additional parameter to brcmf_free_vif()
    
    Pass the struct brcmf_cfg80211_info instance instead of obtaining
    through vif itself using vif->wdev. This is needed as the netdev
    associated with this vif is already unregistered.
    
    Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
    Signed-off-by: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 15a953d0919e3e7c94691ecabd0d9f74373f19aa
Author: Hante Meuleman <meuleman@broadcom.com>
Date:   Mon May 27 21:09:54 2013 +0200

    brcmfmac: Fix p2p setup when connected to ap on 5G.
    
    The firmware requires that on p2p setup when net interfaces
    are created or updated that they start initially with the same
    channel as the channel in use for the current connection
    (if any). If none exists take default channel 11.
    
    Reviewed-by: Arend Van Spriel <arend@broadcom.com>
    Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
    Reviewed-by: Pieter-Paul Giesberts <pieterpg@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>

commit b3657453f16a7b84eab9b93bb9a9a2901ffc70af
Author: Hante Meuleman <meuleman@broadcom.com>
Date:   Mon May 27 21:09:53 2013 +0200

    brcmfmac: Turn off ARP offloading when configured for AP.
    
    ARP offloading should only be used in STA or P2P client mode. It
    is currently configured once at init. When being configured for AP
    ARP offloading should be turned off and when AP mode is left it can
    be turned back on.
    
    Cc: stable@vger.kernel.org
    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>

commit 6390460af8a672754dd6743f326515e98f52b2a7
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Date:   Mon May 20 23:05:15 2013 +0530

    net/9p: Handle error in zero copy request correctly for 9p2000.u
    
    For zero copy request, error will be encoded in the user space buffer.
    So copy the error code correctly using copy_from_user. Here we use the
    extra bytes we allocate for zero copy request. If total error details
    are more than P9_ZC_HDR_SZ - 7 bytes, we return -EFAULT. The patch also
    avoid a memory allocation in the error path.
    
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>

commit 6721cb60022629ae76365551f05d9658b8d14c55
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Thu May 23 14:21:36 2013 -0400

    ring-buffer: Do not poll non allocated cpu buffers
    
    The tracing infrastructure sets up for possible CPUs, but it uses
    the ring buffer polling, it is possible to call the ring buffer
    polling code with a CPU that hasn't been allocated. This will cause
    a kernel oops when it access a ring buffer cpu buffer that is part
    of the possible cpus but hasn't been allocated yet as the CPU has never
    been online.
    
    Reported-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Tested-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

commit b60b61d41220c8d34e2c62a748bc78bc5d40585e
Author: Nadav Haklai <nadavh@marvell.com>
Date:   Thu May 23 10:54:02 2013 +0200

    ARM: mvebu: Fix bug in coherency fabric low level init function
    
    When adding CPU to the SMP group and enabling the coherency on this
    CPU we must protect the register access.
    The previous implementation claims to be atomic but doesn't provide
    any protection against parallel access to the coherency fabric control
    and configuration registers.
    
    This patch fixes this by using the ldrex and strex mechanism.
    This method should be used in all accesses to those registers.
    
    [gregory.clement@free-electrons.com: fixed the commit's topic]
    Signed-off-by: Nadav Haklai <nadavh@marvell.com>
    Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>

commit e89b4058096569c999fa599370162022a5a2b3d2
Author: Andrew Lunn <andrew@lunn.ch>
Date:   Tue May 21 19:41:48 2013 +0200

    ARM: Kirkwood: TS219: Fix crash by double PCIe instantiation
    
    When creating the DT based boards-ts219.c the none DT ts219-setup.c
    was used as a template. This includes a lateinit() call to initialize
    the PCIe bus. The code makes use of machine_is_ts219() which is never
    true on DT, so a FIXME was added and the code left as is. This was
    unproblematic until b73690c8f8b5d: "ARM: Kirkwood: Support basic
    hotplug for PCI-E" which changes the way the PCIe bus is
    initialized. The non-DT ts219-setup.c now crashes during boot.  The
    lateinit() call in the DT boards-ts219.c is being called,
    machine_is_ts219() is true and so the PCIe is initialized a second
    time.
    
    This patch removes the useless, and now clearly dangerous, code from
    boards-ts219.c, making ts219-setup.c work again.
    
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Cc: <stable@vger.kernel.org> # v3.9.x
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>

commit 04d245b7899c020559402841d2f70ddd740a7704
Author: Nicolas Schichan <nschichan@freebox.fr>
Date:   Thu May 23 16:53:02 2013 +0200

    ASoC: cs42l52: fix default value for MASTERA_VOL.
    
    The default register value for MASTERA_VOL is 0x00, the same as
    MASTERB_VOL.
    
    Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
    Acked-by: Brian Austin <brian.austin@cirrus.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Cc: stable@vger.kernel.org

commit 7d6898be8db92450ce7a0afcc4238680b9703e2b
Author: Vinod Koul <vinod.koul@intel.com>
Date:   Tue May 28 15:06:42 2013 +0530

    ASoC: wm8994: check for array index returned
    
    The array 'drc_cfg' of size 3 may use index value -22 (EINVAL)
    The array 'retune_mobile_cfg' of size 3 may use index value -22 (EINVAL)
    
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit 9767a58b8b2a0b153c246fb6306c7d48d51bb379
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Tue May 28 12:52:08 2013 +0100

    ASoC: wm8994: Fix reporting of accessory removal on WM8958
    
    During recent refactoring the code to report removal when MICDET reports
    an absent microphone was removed, causing problems for systems which rely
    solely on the MICDET for this functionality. Restore it.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit d3134e211e8db7fa833c40b5879fc022693e16c2
Author: Vinod Koul <vinod.koul@intel.com>
Date:   Tue May 28 15:41:57 2013 +0530

    ASoC: wm8994: use the correct pointer to get the control value
    
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit 1d7004f0593f631b78745e4c835d8e09b31f4996
Author: Frederico Cadete <frederico@cadete.eu>
Date:   Sat May 25 22:48:57 2013 +0200

    xmem/tmem: fix 'undefined variable' build error.
    
    In the (not so useful) kernel configuration where CONFIG_SWAP
    is undefined and CONFIG_XEN_SELFBALLOONING is defined,
    xen_tmem_init would use undefined variable 'static bool frontswap'.
    
    Added #else to have #define frontswap (0) in the case where
    CONFIG_FRONTSWAP is not defined.
    
    Signed-off-by: Frederico Cadete <frederico@cadete.eu>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

commit b56433cb782d1cc7e44fc46d2ce3917fa75d2236
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Mon May 27 16:19:55 2013 +0200

    s390/pgtable: Fix check for pgste/storage key handling
    
    pte_present might return true on PAGE_TYPE_NONE, even if
    the invalid bit is on. Modify the existing check of the
    pgste functions to avoid crashes.
    
    [ Martin Schwidefsky: added ptep_modify_prot_[start|commit] bits ]
    
    Reported-by: Martin Schwidefky <schwidefsky@de.ibm.com>
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    CC: stable@vger.kernel.org
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit 15ef0298deb3929eb6ad6d2334fd2059fd53807c
Author: Pavel Tikhomirov <snorcht@gmail.com>
Date:   Fri May 17 02:12:03 2013 +0400

    posix-timers: Show clock ID in proc file
    
    Expand information about posix-timers in /proc/<pid>/timers by adding
    info about clock, with which the timer was created. I.e. in the forth
    line of timer info after "notify:" line go "ClockID: <clock_id>".
    
    Signed-off-by: Pavel Tikhomirov <snorcht@gmail.com>
    Cc: Michael Kerrisk <mtk.manpages@gmail.com>
    Cc: Matthew Helsley <matt.helsley@gmail.com>
    Cc: Pavel Emelyanov <xemul@parallels.com>
    Link: http://lkml.kernel.org/r/1368742323-46949-2-git-send-email-snorcht@gmail.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

commit 26cb63ad11e04047a64309362674bcbbd6a6f246
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue May 28 10:55:48 2013 +0200

    perf: Fix perf mmap bugs
    
    Vince reported a problem found by his perf specific trinity
    fuzzer.
    
    Al noticed 2 problems with perf's mmap():
    
     - it has issues against fork() since we use vma->vm_mm for accounting.
     - it has an rb refcount leak on double mmap().
    
    We fix the issues against fork() by using VM_DONTCOPY; I don't
    think there's code out there that uses this; we didn't hear
    about weird accounting problems/crashes. If we do need this to
    work, the previously proposed VM_PINNED could make this work.
    
    Aside from the rb reference leak spotted by Al, Vince's example
    prog was indeed doing a double mmap() through the use of
    perf_event_set_output().
    
    This exposes another problem, since we now have 2 events with
    one buffer, the accounting gets screwy because we account per
    event. Fix this by making the buffer responsible for its own
    accounting.
    
    Reported-by: Vince Weaver <vincent.weaver@maine.edu>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
    Link: http://lkml.kernel.org/r/20130528085548.GA12193@twins.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit 7b959fc582741227a1c4cba710d6aff8fb183128
Author: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Date:   Wed May 22 18:34:09 2013 +0900

    kprobes: Fix to free gone and unused optprobes
    
    Fix to free gone and unused optprobes. This bug will
    cause a kernel panic if the user reuses the killed and
    unused probe.
    
    Reported at:
    
      http://sourceware.org/ml/systemtap/2013-q2/msg00142.html
    
    In the normal path, an optprobe on an init function is
    unregistered when a module goes live.
    
    unregister_kprobe(kp)
     -> __unregister_kprobe_top
       ->__disable_kprobe
         ->disarm_kprobe(ap == op)
           ->__disarm_kprobe
            ->unoptimize_kprobe : the op is queued
                                  on unoptimizing_list
    and do nothing in __unregister_kprobe_bottom
    
    After a while (usually wait 5 jiffies), kprobe_optimizer
    runs to unoptimize and free optprobe.
    
    kprobe_optimizer
     ->do_unoptimize_kprobes
       ->arch_unoptimize_kprobes : moved to free_list
     ->do_free_cleaned_kprobes
       ->hlist_del: the op is removed
       ->free_aggr_kprobe
         ->arch_remove_optimized_kprobe
         ->arch_remove_kprobe
         ->kfree: the op is freed
    
    Here, if kprobes_module_callback is called and the delayed
    unoptimizing probe is picked BEFORE kprobe_optimizer runs,
    
    kprobes_module_callback
     ->kill_kprobe
       ->kill_optimized_kprobe : dequeued from unoptimizing_list <=!!!
         ->arch_remove_optimized_kprobe
       ->arch_remove_kprobe
       (but op is not freed, and on the kprobe hash table)
    
    This doesn't happen if the probe unregistration is done AFTER
    kprobes_module_callback is called (because at that time the op
    is gone), and kprobe-tracer does it.
    
    To fix this bug, this patch changes kprobes_module_callback to
    enqueue the op to freeing_list at kill_optimized_kprobe only
    if the op is unused. The unused probes on freeing_list will
    be freed in do_free_cleaned_kprobes.
    
    Note that this calls arch_remove_*kprobe twice on the
    same probe. Thus those functions have to check the double free.
    Fortunately, most of arch codes already checked that except
    for mips. This will be fixed in the next patch.
    
    Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Cc: Timo Juhani Lindfors <timo.lindfors@iki.fi>
    Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
    Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
    Cc: Frank Ch. Eigler <fche@redhat.com>
    Cc: systemtap@sourceware.org
    Cc: yrl.pp-manager.tt@hitachi.com
    Cc: David S. Miller <davem@davemloft.net>
    Cc: "David S. Miller" <davem@davemloft.net>
    Link: http://lkml.kernel.org/r/20130522093409.9084.63554.stgit@mhiramat-M0-7522
    [ Minor edits. ]
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

commit d5b4c2f4938aaebc392669111385c3cf50dd309f
Author: Chen Gang <gang.chen@asianux.com>
Date:   Mon May 27 17:55:13 2013 +0800

    arch: s390: appldata: using strncpy() and strnlen() instead of sprintf()
    
    'buf[2]' is 2 bytes length, and sprintf() will append '\0' at the end
    of string "?\n", so original implementation is memory overflow.
    
    Need use strncpy() and strnlen() instead of sprintf().
    
    Signed-off-by: Chen Gang <gang.chen@asianux.com>
    Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit 37c14e83ee173cc3f6310d80f00f2e588c402b61
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Tue May 28 10:22:06 2013 +0200

    m68k: Update defconfigs for v3.9
    
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

commit 2938d2757fc99c26aa678ce4eba910c4a77c3a55
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue May 28 09:33:01 2013 +0200

    tick: Cure broadcast false positive pending bit warning
    
    commit 26517f3e (tick: Avoid programming the local cpu timer if
    broadcast pending) added a warning if the cpu enters broadcast mode
    again while the pending bit is still set. Meelis reported that the
    warning triggers. There are two corner cases which have been not
    considered:
    
    1) cpuidle calls clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER)
       twice. That can result in the following scenario
    
       CPU0                    CPU1
                               cpuidle_idle_call()
                                 clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER)
                                   set cpu in tick_broadcast_oneshot_mask
    
       broadcast interrupt
         event expired for cpu1
         set pending bit
    
                                 acpi_idle_enter_simple()
                                   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER)
                                     WARN_ON(pending bit)
    
      Move the WARN_ON into the section where we enter broadcast mode so
      it wont provide false positives on the second call.
    
    2) safe_halt() enables interrupts, so a broadcast interrupt can be
       delivered befor the broadcast mode is disabled. That sets the
       pending bit for the CPU which receives the broadcast
       interrupt. Though the interrupt is delivered right away from the
       broadcast handler and leaves the pending bit stale.
    
       Clear the pending bit for the current cpu in the broadcast handler.
    
    Reported-and-tested-by: Meelis Roos <mroos@linux.ee>
    Cc: Len Brown <lenb@kernel.org>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Rafael J. Wysocki <rjw@sisk.pl>
    Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1305271841130.4220@ionos
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

commit c89b65e7fffef745bdd36c372aa0dea778fecbab
Author: Andrew Jones <drjones@redhat.com>
Date:   Mon May 27 15:58:04 2013 +0200

    qxl: fix Kconfig deps - select FB_DEFERRED_IO
    
    Signed-off-by: Andrew Jones <drjones@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

commit f96ef988cc603487c03a6de07807b06cbe641829
Author: Michal Kubecek <mkubecek@suse.cz>
Date:   Tue May 28 08:26:49 2013 +0200

    ipv4: fix redirect handling for TCP packets
    
    Unlike ipv4_redirect() and ipv4_sk_redirect(), ip_do_redirect()
    doesn't call __build_flow_key() directly but via
    ip_rt_build_flow_key() wrapper. This leads to __build_flow_key()
    getting pointer to IPv4 header of the ICMP redirect packet
    rather than pointer to the embedded IPv4 header of the packet
    initiating the redirect.
    
    As a result, handling of ICMP redirects initiated by TCP packets
    is broken. Issue was introduced by
    
    	4895c771c ("ipv4: Add FIB nexthop exceptions.")
    
    Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 9a9c56cb34e65000d1f0a4b7553399bfcf7c5a52
Author: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date:   Sun May 26 21:31:28 2013 +0000

    net: phy: fix a bug when verify the EEE support
    
    The phy_init_eee has to exit with an error when the
    local device and its link partner both do not support EEE.
    So this patch fixes a problem when verify this.
    
    Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit de614e561b9c633073caae8f86399aa8923ef85d
Author: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Date:   Tue May 21 17:09:41 2013 +0300

    crypto: sha256_ssse3 - fix stack corruption with SSSE3 and AVX implementations
    
    The _XFER stack element size was set too small, 8 bytes, when it needs to be
    16 bytes. As _XFER is the last stack element used by these implementations,
    the 16 byte stores with 'movdqa' corrupt the stack where the value of register
    %r12 is temporarily stored. As these implementations align the stack pointer
    to 16 bytes, this corruption did not happen every time.
    
    Patch corrects this issue.
    
    Reported-by: Julian Wollrath <jwollrath@web.de>
    Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
    Tested-by: Julian Wollrath <jwollrath@web.de>
    Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

commit 9ecb41bd8cf002fd8f3e063db4df81647ddd623c
Author: Rabin Vincent <rabin.vincent@stericsson.com>
Date:   Mon May 27 16:03:40 2013 +0200

    dmaengine: ste_dma40: fix pm runtime ref counting
    
    The pm runtime reference counting of the driver is broken for the case
    when there is more than one transfer queued, leading to the device being
    runtime suspend while active.  Fix it.
    
    Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>

commit a386267a2ceea33d76fa2b7f1c2e72a858fcb68e
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Mon May 27 15:53:32 2013 +0200

    pinctrl: pinconf: take the right mutex
    
    The pinconf_dgb_config_print() takes the per-pincontroller
    mutex, when what it wants to take is actually the pin maps
    mutex.
    
    Reported-by: James Hogan <james.hogan@imgtec.com>
    Cc: Patrice Chotard <patrice.chotard@st.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

commit d72f88a42bf9761e3a92e58879d25a65712ca87a
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Thu May 23 17:32:14 2013 +0800

    pinctrl: sunxi: fix error return code in sunxi_pinctrl_probe()
    
    Fix to return a negative error code from the devm_clk_get() error
    handling case instead of 0, as done elsewhere in this function.
    
    Introduced by commit 950707c0eb5c7aeaa2c446a04c824f4be686d2f6
    (pinctrl: sunxi: add clock support)
    
    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

commit 7ccbc60cd9c293304829662b043f4356f554fc3a
Author: Tomasz Figa <t.figa@samsung.com>
Date:   Wed May 22 16:03:17 2013 +0200

    pinctrl: exynos: Handle suspend/resume of GPIO EINT registers
    
    Some GPIO EINT control registers needs to be preserved across
    suspend/resume cycle. This patch extends the driver to take care of
    this.
    
    Signed-off-by: Tomasz Figa <t.figa@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

commit 3385474c3a2f5e81df67cba426c29beefd8a5c18
Author: Tomasz Figa <t.figa@samsung.com>
Date:   Fri May 17 18:24:31 2013 +0200

    pinctrl: samsung: Allow per-bank SoC-specific private data
    
    This patch extends pin bank descriptor structure with SoC-specific
    private data field that allows SoC-specific drivers to store their own
    private data.
    
    Signed-off-by: Tomasz Figa <t.figa@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Tested-by: Doug Anderson <dianders@chromium.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

commit 21c219933fd123d4cdfc8853f51c41330b9d6c28
Author: Tomasz Figa <t.figa@samsung.com>
Date:   Fri May 17 18:24:30 2013 +0200

    pinctrl: samsung: Add support for SoC-specific suspend/resume callbacks
    
    SoC-specific driver might require additional save and restore of
    registers. This patch adds pair of SoC-specific callbacks per pinctrl
    device to account for this.
    
    Signed-off-by: Tomasz Figa <t.figa@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Tested-by: Doug Anderson <dianders@chromium.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

commit 97fc463769f1564e8eda2e2f70d3b6e92a25ff16
Author: Axel Lin <axel.lin@ingics.com>
Date:   Sun May 19 13:58:37 2013 +0800

    pinctrl: Don't override the error code in probe error handling
    
    Otherwise, we return 0 in probe error paths when gpiochip_remove() returns 0.
    Also show error message if gpiochip_remove() fails.
    
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Acked-by: Tony Prisk <linux@prisktech.co.nz>
    Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

commit b134dc3feaa5136b376c7d2658bbe156bea19e63
Author: Tomasz Figa <t.figa@samsung.com>
Date:   Fri May 17 18:24:28 2013 +0200

    ARM: EXYNOS: Fix EINT wake-up mask configuration when pinctrl is used
    
    On DT-enabled systems pinctrl-exynos driver is responsible for handling
    of wake-up EINT interrupts. This patch adjusts wake-up mask
    configuration code to take wake-up mask value from pinctrl-exynos driver
    on DT-enabled systems.
    
    Signed-off-by: Tomasz Figa <t.figa@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Tested-by: Doug Anderson <dianders@chromium.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

commit ad350cd9d5411353397843c8f410a6e7e84a71f9
Author: Tomasz Figa <t.figa@samsung.com>
Date:   Fri May 17 18:24:27 2013 +0200

    pinctrl: exynos: Add support for set_irq_wake of wake-up EINTs
    
    This patch adds support of IRQ wake-up ability configuration for
    wake-up EINTs on Exynos SoCs.
    
    Signed-off-by: Tomasz Figa <t.figa@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Tested-by: Doug Anderson <dianders@chromium.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

commit d9f998639f539613bb25cbbca380c81c892d586c
Author: Doug Anderson <dianders@chromium.org>
Date:   Thu May 16 21:33:18 2013 -0700

    pinctrl: samsung: fix suspend/resume functionality
    
    The GPIO states need to be restored after s2r and this is not currently
    supported in the pinctrl driver. This patch saves the gpio states before
    suspend and restores them after resume.
    
    Saving and restoring is done very early using syscore_ops and must
    happen before pins are released from their powerdown state.
    
    Patch originally from Prathyush K <prathyush.k@samsung.com> but
    rewritten by Doug Anderson <dianders@chromium.org>.
    
    Signed-off-by: Prathyush K <prathyush.k@samsung.com>
    Signed-off-by: Doug Anderson <dianders@chromium.org>
    Tested-by: Tomasz Figa <t.figa@samsung.com>
    Acked-by: Kukjin Kim <kgene.kim@samsung.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

commit 6719a4974600fdaa4a3ac2ea2aed819a35d06605
Author: Xiong Zhou <jencce.kernel@gmail.com>
Date:   Fri May 17 07:24:05 2013 -0300

    [media] staging/solo6x10: select the desired font
    
    Make sure FONT_8x16 can be found by find_font().
    
    Signed-off-by: Xiong Zhou <jencce.kernel@gmail.com>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 449875756055e2fff6074b4e69b35b9583f9f84d
Author: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Date:   Mon May 13 06:39:07 2013 -0300

    [media] drivers/staging: davinci: vpfe: fix dependency for building the driver
    
    from commit 3778d05036cc7ddd983ae2451da579af00acdac2
    [media: davinci: kconfig: fix incorrect selects]
    VIDEO_VPFE_CAPTURE was removed but there was a negative
    dependancy for building the DM365 VPFE MC based capture driver
    (VIDEO_DM365_VPFE), This patch fixes this dependency by replacing
    the VIDEO_VPFE_CAPTURE with VIDEO_DM365_ISIF, so as when older DM365
    ISIF v4l driver is selected the newer media controller driver for
    DM365 isnt visible.
    
    Reported-by: Paul Bolle <pebolle@tiscali.nl>
    Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 67b7c75e1a42f8288450203cd80a26b11dab8582
Author: Lee Jones <lee.jones@linaro.org>
Date:   Fri May 24 12:22:19 2013 +0100

    ARM: ux500: Provide supplies for AUX1, AUX2 and AUX3
    
    This patch fixes a bug introduced in the v3.10 merge window.
    
    The AB8500 External Regulator driver has recently landed upstream,
    which registers each of the 3 external regulators located on the
    AB8500. If these regulators are marked as 'always on', there is a
    potential for power-loss. If they're not and are seemingly unused
    the Regulator subsystem will attempt to disable them to save power.
    This causes an issue for AUX1, AUX2 and AUX3 as they obtain their
    power from EXT3. So we're specifying that here to prevent EXT3 from
    being powered down.
    
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

commit 2c06897e4597b1cd68ef29e4145917a751c2b4cd
Author: Lee Jones <lee.jones@linaro.org>
Date:   Thu May 16 12:15:35 2013 +0100

    ARM: ux500: Only configure wake-up reasons on ux500 based platforms
    
    Multiplatform calls all enabled platforms' initcalls. In the
    ux500_idle_init() initcall we call into the DBx500-PRCMU which in turn
    executes some ux500 specific register reads/writes. When running on
    some !ux500 platforms this ends up causing a kernel Oops. This patch
    ensures the PRCMU call is only invoked when running on ux500 based
    platforms.
    
    Reported-by: Rob Herring <rob.herring@calxeda.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

commit dc7b3eb900aab02e5cafbca3948d005be13fb4a5
Author: Grzegorz Lyczba <grzegorz.lyczba@gmail.com>
Date:   Mon May 13 23:56:24 2013 +0200

    ipvs: Fix reuse connection if real server is dead
    
    Expire cached connection for new TCP/SCTP connection if real
    server is down. Otherwise, IPVS uses the dead server for the
    reused connection, instead of a new working one.
    
    Signed-off-by: Grzegorz Lyczba <grzegorz.lyczba@gmail.com>
    Acked-by: Hans Schillstrom <hans@schillstrom.com>
    Acked-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

commit f6a12a7d0b1a70e969ae4f6d7c5201cdaf6edde0
Author: Meyer, Kirk <Kirk.Meyer@sencore.com>
Date:   Thu May 23 17:06:57 2013 +0000

    microblaze: Reversed logic in futex cmpxchg
    
    futex_atomic_cmpxchg_inatomic exchanged if the values were
    unequal rather than equal. This caused incorrect behavior
    of robust futexes.
    
    Signed-off-by: Kirk Meyer <kirk.meyer@sencore.com>
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>

commit a87783699b23395c46bbeeb5d28f6db24897bf26
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Wed May 22 10:48:10 2013 +0300

    iwlwifi: dvm: fix zero LQ CMD sending avoidance
    
    In 63b77bf489881747c5118476918cc8c29378ee63
    
    	iwlwifi: dvm: don't send zeroed LQ cmd
    
    I tried to avoid to send zeroed LQ cmd, but I made a (very)
    stupid mistake in the memcmp.
    Since this patch has been ported to stable, the fix should
    go to stable too.
    
    This fixes https://bugzilla.kernel.org/show_bug.cgi?id=58341
    
    Cc: stable@vger.kernel.org
    Reported-by: Hinnerk van Bruinehsen <h.v.bruinehsen@fu-berlin.de>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>

commit ac20976dcaeea3e77e40e9aac8f3799d2a22ea2b
Author: Helmut Schaa <helmut.schaa@googlemail.com>
Date:   Mon May 27 10:43:09 2013 +0200

    mac80211: Allow single vif mac address change with addr_mask
    
    When changing the MAC address of a single vif mac80211 will check if
    the new address fits into the address mask specified by the driver.
    This only needs to be done when using multiple BSSIDs. Hence, check
    the new address only against all other vifs.
    
    Also fix the MAC address assignment on new interfaces if the user
    changed the address of a vif such that perm_addr is not covered by
    addr_mask anymore.
    
    Resolves:
    https://bugzilla.kernel.org/show_bug.cgi?id=57371
    
    Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
    Signed-off-by: Jakub Kicinski <kubakici@wp.pl>
    Reported-by: Alessandro Lannocca <alessandro.lannocca@gmail.com>
    Cc: Alessandro Lannocca <alessandro.lannocca@gmail.com>
    Cc: Bruno Randolf <br1@thinktube.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>

commit c8aa22db0112f640ac6631347f850879c621840b
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri May 24 01:06:09 2013 +0200

    mac80211: close AP_VLAN interfaces before unregistering all
    
    Since Eric's commit efe117ab8 ("Speedup ieee80211_remove_interfaces")
    there's a bug in mac80211 when it unregisters with AP_VLAN interfaces
    up. If the AP_VLAN interface was registered after the AP it belongs
    to (which is the typical case) and then we get into this code path,
    unregister_netdevice_many() will crash because it isn't prepared to
    deal with interfaces being closed in the middle of it. Exactly this
    happens though, because we iterate the list, find the AP master this
    AP_VLAN belongs to and dev_close() the dependent VLANs. After this,
    unregister_netdevice_many() won't pick up the fact that the AP_VLAN
    is already down and will do it again, causing a crash.
    
    Cc: stable@vger.kernel.org [2.6.33+]
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>

commit 1351c5d3b189a487fbacd5cdf2dc3e6faf12c682
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu May 23 23:09:56 2013 +0200

    mac80211: assign AP_VLAN hw queues correctly
    
    A lot of code in mac80211 assumes that the hw queues are
    set up correctly for all interfaces (except for monitor)
    but this isn't true for AP_VLAN interfaces. Fix this by
    copying the AP master configuration when an AP VLAN is
    brought up, after this the AP interface can't change its
    configuration any more and needs to be brought down to
    change it, which also forces AP_VLAN interfaces down, so
    just copying in open() is sufficient.
    
    Reported-by: Jouni Malinen <j@w1.fi>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>

commit 9acf73b7d06eaa3fbfbfafc9c835f8fe0d751eff
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date:   Wed May 22 10:24:37 2013 +0200

    s390/smp: lost IPIs on cpu hotplug
    
    IPIs might be lost when a cpu gets brought offline:
    
    When stop_machine executes its state machine there is a race window
    for the state STOPMACHINE_DISABLE_IRQ where the to be brought offline
    cpu might already have irqs disabled but a different cpu still may
    have irqs enabled.
    If the enabled cpu receives an interrupt and as a result sends an IPI
    to the to be offlined cpu in its bottom halve context, the IPI won't
    be noticed before the cpu is offline.
    
    In fact the race window is much larger since there is no guarantee
    when an IPI will be received.
    
    To fix this check for enqueued but not yet received IPIs in the
    cpu_disable() path and call the respective handlers before the cpu
    is marked offline.
    
    Reported-by: Juergen Doelle <juergen.doelle@de.ibm.com>
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit 4a29b5591faf25555fdf2b717594d50f70c15066
Author: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date:   Fri May 10 17:42:35 2013 +0530

    mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt case
    
    MMC driver probe will abort for DT case because of failed
    platform_get_resource_byname() lookup. Fix it by skipping resource
    lookup byname for device tree build.
    
    Issue is hidden because hwmod populates the IO resources which
    helps to succeed platform_get_resource_byname() and probe.
    
    Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
    Signed-off-by: Balaji T K <balajitk@ti.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>

commit d272fbf0ca4a59339c768d76858f4add6ff36ace
Author: Matt Porter <mporter@ti.com>
Date:   Fri May 10 17:42:34 2013 +0530

    mmc: omap_hsmmc: convert to dma_request_slave_channel_compat
    
    Convert dmaengine channel requests to use
    dma_request_slave_channel_compat(). This supports platforms booting
    with or without DT populated.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
    Acked-by: Tony Lindgren <tony@atomide.com>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Balaji T K <balajitk@ti.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>

commit cf5ae40b3968ca769e683b9b071685ad82ee893c
Author: Tony Lindgren <tony@atomide.com>
Date:   Fri May 10 17:42:33 2013 +0530

    mmc: omap_hsmmc: Fix the DT pbias workaround for MMC controllers 2 to 5
    
    Otherwise SDIO cards won't necessarily work when booted with
    device tree as we will never power down the SDIO cards. This
    means the SDIO card reset does not happen which at least some
    WLAN controllers expect to happen with ifconfig wlan0 down.
    
    The PBIAS voltage is only available for the first controller
    instance, so let's limit the PBIAS workaround to the first
    controller only.
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Tested-by: Luciano Coelho <coelho@ti.com>
    Signed-off-by: Balaji T K <balajitk@ti.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>

commit 728ef3d1939e23e26067608d8d8da9571be14b1d
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri Apr 26 11:27:23 2013 +0300

    mmc: sdhci-pci: add more device ids
    
    Add three more PCI device ids.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>

commit 07a588837be0a18075fedf71e6963b5109abec03
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri Apr 26 11:27:22 2013 +0300

    mmc: sdhci-acpi: add more device ids
    
    Add three more ACPI HIDs.  Also, as some devices must be
    further distinguished by ACPI UID, slot information is now
    associated with HID and UID.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>

commit 1d1ff45871984364056ebfc528ed31ff7f03f970
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri Apr 26 11:27:21 2013 +0300

    mmc: sdhci-acpi: fix initial runtime pm status
    
    Initial runtime pm status is active.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>

commit 8c964df07aaf0e70d1756d204c306f69ca5023b8
Author: Ludovic Desroches <ludovic.desroches@atmel.com>
Date:   Fri Apr 19 09:11:22 2013 +0000

    mmc: atmel-mci: convert to dma_request_slave_channel_compat()
    
    Use generic DMA DT helper. Platforms booting with or without DT populated
    are both supported.
    
    Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
    Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>

commit 361b8482026c926997b1d3d5a045bc9f5bc02b16
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Fri Mar 15 09:49:26 2013 +0100

    mmc: sdhci-esdhc-imx: fix multiblock reads on i.MX53
    
    The eSDHC controller on the i.MX53 needs an additional, non spec
    compliant CMD12 after a multiblock read with a predefined number of
    blocks. Otherwise the internal state machine won't go back to the
    idle state.
    
    This commit effectively reverts 5b6b0ad6 (mmc: sdhci-esdhc-imx:
    fix for mmc cards on i.MX5), which fixed part of the problem by
    making multiblock reads work, however this fix was not sufficient
    when multi- and singleblock reads got intermixed.
    
    This implements the recommended workaround (Freescale i.MX Reference
    Manual, section 29.6.8 "Multi-block Read") by manually sending a
    CMD12 with the RSPTYP bits cleared.
    
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: Chris Ball <cjb@laptop.org>

commit f6825748bdbe381cfffe2dc13ca0b73050428fac
Author: Martin Fuzzey <mfuzzey@parkeon.com>
Date:   Mon Apr 15 17:08:35 2013 +0200

    mmc: sdhci-esdhc-imx: Fix SDIO interrupts
    
    Currently SDIO interrupts do not work on i.MX53 and maybe others.
    
    This was observed with a Marvell 8787 based SDIO wifi adapter
    using the mwifiex driver and firmware from the Marvell git
    repository.
    The symptom was a timeout after firmware download.
    
    Observing the SDIO_DAT1 line showed that an interrupt was requested
    (level 0) but no interrupt was generated in software, the line
    stayed low until a timeout ocurred and the card was reset.
    
    There is a Freescale errata
    	ENGcm11186 "eSDHC misses SDIO interrupt when CINT is disabled"
    
    The workaround suggested by this errata is already implemented and
    involves clearing and then setting the D3CD bit in the host control
    register [see esdhc_writel_le()]
    
    However, when esdhc_writeb_le() is later used to write to
    SDHCI_HOST_CONTROL it always resets the D3CD bit.
    
    To fix this simply add the D3CD bit to the set of bits
    not modified by esdhc_writeb_le().
    
    Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>

commit a622260254ee481747cceaaa8609985b29a31565
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri May 24 05:49:58 2013 +0000

    ip_tunnel: fix kernel panic with icmp_dest_unreach
    
    Daniel Petre reported crashes in icmp_dst_unreach() with following call
    graph:
    
    #3 [ffff88003fc03938] __stack_chk_fail at ffffffff81037f77
    #4 [ffff88003fc03948] icmp_send at ffffffff814d5fec
    #5 [ffff88003fc03ae8] ipv4_link_failure at ffffffff814a1795
    #6 [ffff88003fc03af8] ipgre_tunnel_xmit at ffffffff814e7965
    #7 [ffff88003fc03b78] dev_hard_start_xmit at ffffffff8146e032
    #8 [ffff88003fc03bc8] sch_direct_xmit at ffffffff81487d66
    #9 [ffff88003fc03c08] __qdisc_run at ffffffff81487efd
    #10 [ffff88003fc03c48] dev_queue_xmit at ffffffff8146e5a7
    #11 [ffff88003fc03c88] ip_finish_output at ffffffff814ab596
    
    Daniel found a similar problem mentioned in
     http://lkml.indiana.edu/hypermail/linux/kernel/1007.0/00961.html
    
    And indeed this is the root cause : skb->cb[] contains data fooling IP
    stack.
    
    We must clear IPCB in ip_tunnel_xmit() sooner in case dst_link_failure()
    is called. Or else skb->cb[] might contain garbage from GSO segmentation
    layer.
    
    A similar fix was tested on linux-3.9, but gre code was refactored in
    linux-3.10. I'll send patches for stable kernels as well.
    
    Many thanks to Daniel for providing reports, patches and testing !
    
    Reported-by: Daniel Petre <daniel.petre@rcs-rds.ro>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 0d8c3e77e7fba8c84c871b43f35029daa92acc17
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Wed May 22 23:59:28 2013 +0000

    ptp_pch: fix error handling in pch_probe()
    
    Fix to release resources when ptp_clock_register() fail instead
    of return error code directly.
    
    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 4d2593cc65fa15f2a36313aa8d03a0937226ad49
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Wed May 22 23:09:50 2013 +0000

    qlge: add missing free_netdev() on error in qlge_probe()
    
    Add the missing free_netdev() before return from function
    qlge_probe() in the error handling case.
    
    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Acked-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 39d4ecdb711ba44e0aa0b2f3db74ed5ac97abe21
Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date:   Fri May 24 11:38:24 2013 +0100

    ASoC: wm5110: Correct DSP4R Mixer control name
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Cc: stable@vger.kernel.org

commit c15cddd900e867c5adfb3c79596479dc5975f743
Author: Paul Taysom <taysom@chromium.org>
Date:   Thu May 23 14:31:43 2013 -0700

    ecryptfs: fixed msync to flush data
    
    When msync is called on a memory mapped file, that
    data is not flushed to the disk.
    
    In Linux, msync calls fsync for the file. For ecryptfs,
    fsync just calls the lower level file system's fsync.
    Changed the ecryptfs fsync code to call filemap_write_and_wait
    before calling the lower level fsync.
    
    Addresses the problem described in http://crbug.com/239536
    
    Signed-off-by: Paul Taysom <taysom@chromium.org>
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Cc: stable@vger.kernel.org # v3.6+

commit c3897aa5386faba77e5bbdf94902a1658d3a5b11
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Thu Apr 18 10:02:03 2013 -0700

    xhci: Disable D3cold for buggy TI redrivers.
    
    Some xHCI hosts contain a "redriver" from TI that silently drops port
    status connect changes if the port slips into Compliance Mode.  If the
    port slips into compliance mode while the host is in D0, there will not
    be a port status change event.  If the port slips into compliance mode
    while the host is in D3, the host will not send a PME.  This includes
    when the system is suspended (S3) or hibernated (S4).
    
    If this happens when the system is in S3/S4, there is nothing software
    can do.  Other port status change events that would normally cause the
    host to wake the system from S3/S4 may also be lost.  This includes
    remote wakeup, disconnects and connects on other ports, and overrcurrent
    events.  A decision was made to _NOT_ disable system suspend/hibernate
    on these systems, since users are unlikely to enable wakeup from S3/S4
    for the xHCI host.
    
    Software can deal with this issue when the system is in S0.  A work
    around was put in to poll the port status registers for Compliance Mode.
    The xHCI driver will continue to poll the registers while the host is
    runtime suspended.  Unfortunately, that means we can't allow the PCI
    device to go into D3cold, because power will be removed from the host,
    and the config space will read as all Fs.
    
    Disable D3cold in the xHCI PCI runtime suspend function.
    
    This patch should be backported to kernels as old as 3.2, that
    contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host:
    xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Cc: Huang Ying <ying.huang@intel.com>
    Cc: stable@vger.kernel.org

commit 77df9e0b799b03e1d5d9c68062709af5f637e834
Author: Tony Camuso <tcamuso@redhat.com>
Date:   Thu Feb 21 16:11:27 2013 -0500

    xhci - correct comp_mode_recovery_timer on return from hibernate
    
    Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP
    Hardware) was a workaround for systems using the SN65LVPE502CP,
    controller, but it introduced a bug in resume from hibernate.
    
    The fix created a timer, comp_mode_recovery_timer, which is deleted from
    a timer list when xhci_suspend() is called. However, the hibernate image,
    including the timer list containing the comp_mode_recovery_timer, had
    already been saved before the timer was deleted.
    
    Upon resume from hibernate, the list containing the comp_mode_recovery_timer
    is restored from the image saved to disk, and xhci_resume(), assuming that
    the timer had been deleted by xhci_suspend(), makes a call to
    compliance_mode_recoery_timer_init(), which creates a new instance of the
    comp_mode_recovery_timer and attempts to place it into the same list in which
    it is already active, thus corrupting the list during the list_add() call.
    
    At this point, a call trace is emitted indicating the list corruption.
    Soon afterward, the system locks up, the watchdog times out, and the
    ensuing NMI crashes the system.
    
    The problem did not occur when resuming from suspend. In suspend, the
    image in RAM remains exactly as it was when xhci_suspend() deleted the
    comp_mode_recovery_timer, so there is no problem when xhci_resume()
    creates a new instance of this timer and places it in the still empty
    list.
    
    This patch avoids the problem by deleting the timer in xhci_resume()
    when resuming from hibernate. Now xhci_resume() can safely make the
    call to create a new instance of this timer, whether returning from
    suspend or hibernate.
    
    Thanks to Alan Stern for his help with understanding the problem.
    
    [Sarah reworked this patch to cover the case where the xHCI restore
    register operation fails, and (temp & STS_SRE) is true (and we re-init
    the host, including re-init for the compliance mode), but hibernate is
    false.  The original patch would have caused list corruption in this
    case.]
    
    This patch should be backported to kernels as old as 3.2, that
    contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host:
    xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
    
    Signed-off-by: Tony Camuso <tcamuso@redhat.com>
    Tested-by: Tony Camuso <tcamuso@redhat.com>
    Acked-by: Don Zickus <dzickus@redhat.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Cc: stable@vger.kernel.org

commit 15f504f0c2038b9a0f1569c9ce34def61f0c65be
Author: Tomasz Figa <t.figa@samsung.com>
Date:   Sat May 25 06:49:43 2013 +0900

    ARM: SAMSUNG: Add names to fimd0 IRQ resources
    
    Since commit 1977e6d8 (drm/exynos: change the method for getting the
    interrupt) the Exynos DRM FIMD driver requires IRQ resources to be
    named. This patch fixes probe failure in non-DT cases by adding
    appropriate resource names to fimd0 platform device.
    
    Signed-off-by: Tomasz Figa <t.figa@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>

commit 1ba830c9997214a7fbe4d91cf238793764620e3b
Author: Jungseok Lee <jays.lee@samsung.com>
Date:   Sat May 25 06:33:03 2013 +0900

    ARM: EXYNOS: fix software reset logic for EXYNOS5440 SOC
    
    This patch fixes software reset logic. Software reset applies only to
    powered-on domains in SOC because software reset to all domains causes
    reboot failure.
    
    Signed-off-by: Jungseok Lee <jays.lee@samsung.com>
    Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>

commit 68a433f18c0574b50c5952978ca95b0db7347174
Author: Tomasz Figa <t.figa@samsung.com>
Date:   Sat May 25 06:27:29 2013 +0900

    ARM: EXYNOS: Fix support of Exynos4210 rev0 SoC
    
    This patch extends exynos_init_time() function to handle Exynos4210
    rev0 SoC, which differs in availability of system timers and needs
    different clocksource initialization.
    
    This makes it possible to use exynos_init_time() function as init_time
    callback for all Exynos-based boards, including Universal_C210, which
    originally had to use samsung_timer_init().
    
    Signed-off-by: Tomasz Figa <t.figa@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>

commit 95bbb82f60c80808e5a49d8233c2de8451901531
Author: Gu Zheng <guz.fnst@cn.fujitsu.com>
Date:   Thu May 23 16:14:19 2013 +0800

    fs/jfs: Add check if journaling to disk has been disabled in lbmRead()
    
    Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>

commit e9b376671910d105c5e61103111b96209c729529
Author: Vahram Martirosyan <vmartirosyan@gmail.com>
Date:   Fri May 24 13:57:12 2013 +0500

    jfs: Several bugs in jfs_freeze() and jfs_unfreeze()
    
    The mentioned functions do not pay attention to the error codes returned
    by the functions updateSuper(), lmLogInit() and lmLogShutdown(). It brings
    to system crash later when writing to log.
    
    The patch adds corresponding code to check and return the error codes
    and to print correct error messages in case of errors.
    
    Found by Linux File System Verification project (linuxtesting.org).
    
    Signed-off-by: Vahram Martirosyan <vahram.martirosyan@linuxtesting.org>
    Reviewed-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>

commit d9deef0a3f38bcc1c155e8d9a8b522404e5e648c
Author: Jeff Layton <jlayton@redhat.com>
Date:   Fri May 24 07:40:06 2013 -0400

    cifs: fix composing of mount options for DFS referrals
    
    With the change to ignore the unc= and prefixpath= mount options, there
    is no longer any need to add them to the options string when mounting.
    By the same token, we now need to build a device name that includes the
    prefixpath when mounting.
    
    To make things neater, the delimiters on the devicename are changed
    to '/' since that's preferred when mounting anyway.
    
    v2: fix some comments and don't bother looking at whether there is
        a prepath in the ref->node_name when deciding whether to pass
        a prepath to cifs_build_devname.
    
    v3: rebase on top of potential buffer overrun fix for stable
    
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>

commit 9c9c29e1af2ff0459087876e3800078555794b60
Author: Jeff Layton <jlayton@redhat.com>
Date:   Fri May 24 07:40:05 2013 -0400

    cifs: stop printing the unc= option in /proc/mounts
    
    Since we no longer recognize that option, stop printing it out. The
    devicename is now the canonical source for this info.
    
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>

commit 37d4f99b55d46d9f71f4769faf74c95adb2c1daf
Author: Jeff Layton <jlayton@redhat.com>
Date:   Fri May 24 07:40:05 2013 -0400

    cifs: fix error handling when calling cifs_parse_devname
    
    When we allowed separate unc= and prefixpath= mount options, we could
    ignore EINVAL errors from cifs_parse_devname. Now that they are
    deprecated, we need to check for that as well and fail the mount if it's
    malformed.
    
    Also fix a later error message that refers to the unc= option.
    
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>

commit 539673fff76af73c3aee96e0de10edcc97d84db3
Author: Jeff Layton <jlayton@redhat.com>
Date:   Fri May 24 07:40:04 2013 -0400

    cifs: allow sec=none mounts to work against servers that don't support extended security
    
    In the case of sec=none, we're not sending a username or password, so
    there's little benefit to mandating NTLMSSP auth. Allow it to use
    unencapsulated auth in that case.
    
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>

commit 166faf21bd14bc5c5295a44874bf7f3930c30b20
Author: Jeff Layton <jlayton@redhat.com>
Date:   Fri May 24 07:40:04 2013 -0400

    cifs: fix potential buffer overrun when composing a new options string
    
    Consider the case where we have a very short ip= string in the original
    mount options, and when we chase a referral we end up with a very long
    IPv6 address. Be sure to allow for that possibility when estimating the
    size of the string to allocate.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>

commit 62106e96279f66c52e2123782f9420af9dbe8cbe
Author: Jeff Layton <jlayton@redhat.com>
Date:   Tue May 7 11:28:31 2013 -0400

    cifs: only set ops for inodes in I_NEW state
    
    It's generally not safe to reset the inode ops once they've been set. In
    the case where the inode was originally thought to be a directory and
    then later found to be a DFS referral, this can lead to an oops when we
    try to trigger an inode op on it after changing the ops to the blank
    referral operations.
    
    Cc: <stable@vger.kernel.org>
    Reported-and-Tested-by: Sachin Prabhu <sprabhu@redhat.com>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>

commit 86c157b3f83597e11d8f03a9dece98d1e77a8ce7
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Thu May 23 12:20:56 2013 +0200

    ath9k_hw: improve performance for AR934x v1.3+
    
    AR934x v1.3 no longer needs the DCU backoff reduction workaround for
    preventing rx overruns, but in turn needs the number of usable Tx
    buffers to be reduced slightly.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit a37a99102e4573145aa60a2f78a690cc8def027c
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Thu May 23 12:20:55 2013 +0200

    ath9k_hw: fix host interface reset on AR934x
    
    If a local bus timeout has been detected, the host interface needs to be
    reset to clear the errors. AR934x uses a different synchronous interrupt
    bit to indicate this, so the check needs to be fixed.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 23dd9b2a43698df12f7951e0e5a5fbffd0b3108a
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Thu May 23 12:20:54 2013 +0200

    ath9k_hw: fix spur mitigation issues on AR934x
    
    Do not subtract spur power from noise floor on this chip, as it can lead
    to packet loss and other connectivity issues.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 953dbbed9ee310100bc841cdea8f992d192531c6
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Tue May 21 12:16:56 2013 +0100

    arm64: Do not report user faults for handled signals
    
    Currently user faults (page, undefined instruction) are always reported
    even though the user may have a signal handler for them. This patch adds
    unhandled_signal() check together with printk_ratelimit() for these
    cases.
    
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

commit 726dcaa158b316f02f7dec2cf6dbf61c30a8bf22
Author: Chen Gang <gang.chen@asianux.com>
Date:   Mon May 20 08:12:57 2013 +0100

    arm64: kernel: compiling issue, need 'EXPORT_SYMBOL(clear_page)'
    
    Need 'EXPORT_SYMBOL(clear_page)' if building with allmodconfig.
    
    The related errors:
      ERROR: "clear_page" [fs/ocfs2/dlm/ocfs2_dlm.ko] undefined!
      ERROR: "clear_page" [fs/ntfs/ntfs.ko] undefined!
      ERROR: "clear_page" [fs/gfs2/gfs2.ko] undefined!
      ERROR: "clear_page" [fs/fuse/fuse.ko] undefined!
      ERROR: "clear_page" [fs/ext3/ext3.ko] undefined!
      ERROR: "clear_page" [fs/ext2/ext2.ko] undefined!
      ERROR: "clear_page" [fs/exofs/libore.ko] undefined!
      ERROR: "clear_page" [fs/exofs/exofs.ko] undefined!
      ERROR: "clear_page" [drivers/block/brd.ko] undefined!
    
    Signed-off-by: Chen Gang <gang.chen@asianux.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

commit 88696ae432ce7321540ac53d9caab3de9118b094
Author: Vladimir Murzin <murzin.v@gmail.com>
Date:   Tue Apr 9 22:33:31 2013 +0400

    xhci: fix list access before init
    
    If for whatever reason we fall into fail path in xhci_mem_init()
    before bw table gets initialized we may access the uninitialized lists
    in xhci_mem_cleanup().
    
    Check for bw table before traversing lists in cleanup routine.
    
    This patch should be backported to kernels as old as 3.2, that contain
    the commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe "xhci: Store
    information about roothubs and TTs."
    
    Reported-by: Sergey Dyasly <dserrg@gmail.com>
    Tested-by: Sergey Dyasly <dserrg@gmail.com>
    Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Cc: stable@vger.kernel.org

commit 331de00a64e5027365145bdf51da27b9ce15dfd5
Author: Sergio Aguirre <sergio.a.aguirre.rodriguez@intel.com>
Date:   Thu Apr 4 10:32:13 2013 -0700

    xhci-mem: init list heads at the beginning of init
    
    It is possible that we fail on xhci_mem_init, just before doing
    the INIT_LIST_HEAD, and calling xhci_mem_cleanup.
    
    Problem is that, the list_for_each_entry_safe macro, assumes
    list heads are initialized (not NULL), and dereferences their 'next'
    pointer, causing a kernel panic if this is not yet initialized.
    
    Let's protect from that by moving inits to the beginning.
    
    This patch should be backported to kernels as old as 3.2, that
    contain the commit 9574323c39d1f8359a04843075d89c9f32d8b7e6 "xHCI: test
    USB2 software LPM".
    
    Signed-off-by: Sergio Aguirre <sergio.a.aguirre.rodriguez@intel.com>
    Acked-by: David Cohen <david.a.cohen@intel.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Cc: stable@vger.kernel.org

commit 37523dc5ec2fead0eb5235fd9334f0419013a1f2
Author: Jonas Andersson <jonas@microbit.se>
Date:   Thu May 23 13:38:05 2013 +0200

    ARM: dts: imx: fix clocks for cspi
    
    The CSPI controller has only one clock, but the driver spi-imx.c needs
    clock "per" to calculate bitrate divisor.
    
    Signed-off-by: Jonas Andersson <jonas@microbit.se>
    Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>

commit 7805d000db30a3787a4c969bab6ae4d8a5fd8ce6
Author: Tejun Heo <tj@kernel.org>
Date:   Fri May 24 10:50:24 2013 +0900

    cgroup: fix a subtle bug in descendant pre-order walk
    
    When cgroup_next_descendant_pre() initiates a walk, it checks whether
    the subtree root doesn't have any children and if not returns NULL.
    Later code assumes that the subtree isn't empty.  This is broken
    because the subtree may become empty inbetween, which can lead to the
    traversal escaping the subtree by walking to the sibling of the
    subtree root.
    
    There's no reason to have the early exit path.  Remove it along with
    the later assumption that the subtree isn't empty.  This simplifies
    the code a bit and fixes the subtle bug.
    
    While at it, fix the comment of cgroup_for_each_descendant_pre() which
    was incorrectly referring to ->css_offline() instead of
    ->css_online().
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Cc: stable@vger.kernel.org

commit 4325d724cd91643c727ca4cb063e8bb19989950b
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Thu May 23 15:05:59 2013 +0200

    cfg80211: fix reporting 64-bit station info tx bytes
    
    Copy & paste mistake - STATION_INFO_TX_BYTES64 is the name of the flag,
    not NL80211_STA_INFO_TX_BYTES64.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>

commit 2b436312f0919c05804fed5aa4b7f255db196e7a
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu May 23 21:04:38 2013 +0200

    mac80211: fix queue handling crash
    
    The code I added in "mac80211: don't start new netdev queues
    if driver stopped" crashes for monitor and AP VLAN interfaces
    because while they have a netdev, they don't have queues set
    up by the driver.
    
    To fix the crash, exclude these from queue accounting here
    and just start their netdev queues unconditionally.
    
    For monitor, this is the best we can do, as we can redirect
    frames there to any other interface and don't know which one
    that will since it can be different for each frame.
    
    For AP VLAN interfaces, we can do better later and actually
    properly track the queue status. Not doing this is really a
    separate bug though.
    
    Reported-by: Ilan Peer <ilan.peer@intel.com>
    Reported-by: Jouni Malinen <j@w1.fi>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>

commit cf90bc4830b858487fe4b9b9ecd0031e23ca3e83
Author: Chayan Biswas <Chayan.Biswas@sandisk.com>
Date:   Wed May 22 22:34:49 2013 +0000

    Return the result from user admin command IOCTL even in case of failure
    
    We copy the result to user if the command is completed from the
    controller even if it completes with failure (non-zero) status.
    A return status of < 0 indicates the command was not completed
    by the controller. The user application may expect the error code
    in the result field in case of failure.
    
    Signed-off-by: Chayan Biswas <Chayan.Biswas@sandisk.com>
    Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>

commit c815797663b72e3ac1736f1886538152bc48e4af
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu May 23 18:10:21 2013 +0200

    cfg80211: check wdev->netdev in connection work
    
    If a P2P-Device is present and another virtual interface triggers
    the connection work, the system crash because it tries to check
    if the P2P-Device's netdev (which doesn't exist) is up. Skip any
    wdevs that have no netdev to fix this.
    
    Cc: stable@vger.kernel.org
    Reported-by: YanBo <dreamfly281@gmail.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>

commit f20c783c3ae33c30fd7cf0616db18d30cb6e802b
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Thu May 23 17:23:49 2013 +0200

    regmap: regcache: Fixup locking for custom lock callbacks
    
    The parameter passed to the regmap lock/unlock callbacks needs to be
    map->lock_arg, regcache passes just map. This works fine in the case that no
    custom locking callbacks are used since in this case map->lock_arg equals map,
    but will break when custom locking callbacks are used. The issue was introduced
    in commit 0d4529c5("regmap: make lock/unlock functions customizable") and is
    fixed by this patch.
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit ca1643186d3dce6171d8f171e516b02496360a9e
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Thu May 23 11:51:10 2013 -0400

    tracing: Fix crash when ftrace=nop on the kernel command line
    
    If ftrace=<tracer> is on the kernel command line, when that tracer is
    registered, it will be initiated by tracing_set_tracer() to execute that
    tracer.
    
    The nop tracer is just a stub tracer that is used to have no tracer
    enabled. It is assigned at early bootup as it is the default tracer.
    
    But if ftrace=nop is on the kernel command line, the registering of the
    nop tracer will call tracing_set_tracer() which will try to execute
    the nop tracer. But it expects tr->current_trace to be assigned something
    as it usually is assigned to the nop tracer. As it hasn't been assigned
    to anything yet, it causes the system to crash.
    
    The simple fix is to move the tr->current_trace = nop before registering
    the nop tracer. The functionality is still the same as the nop tracer
    doesn't do anything anyway.
    
    Reported-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

commit a9a6e7a09598013ff97e34ebd84c39d1f51f261a
Author: Maciej W. Rozycki <macro@codesourcery.com>
Date:   Thu May 23 14:31:23 2013 +0000

    MIPS: Trap exception handling fixes
    
    2a0b24f56c2492b932f1aed617ae80fb23500d21 broke Trap exception handling in
    the standard MIPS mode.  Additionally the microMIPS-mode trap code mask is
    wrong, as it's a 4-bit field.  Here's a fix.
    
    Signed-off-by: Maciej W. Rozycki <macro@codesourcery.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/5309/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit d47333ddb234dbc661ab2a4fe019758bd33ba33b
Author: Torsten Schenk <torsten.schenk@zoho.com>
Date:   Thu May 23 13:38:29 2013 +0200

    ALSA: usb-6fire: Modify firmware version check
    
    Check only the uppermost 16 bits instead of the whole 32 bits of
    the version information. Do this because all firmware version tested
    with this version information worked correctly and the strict check
    causes problems for several users.
    
    Signed-off-by: Torsten Schenk <torsten.schenk@zoho.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 4f36ea6eed2081340c7a7aa98c73187ecfccebff
Author: Chen Gang <gang.chen@asianux.com>
Date:   Thu May 23 01:50:46 2013 +0000

    netfilter: ipt_ULOG: fix non-null terminated string in the nf_log path
    
    If nf_log uses ipt_ULOG as logging output, we can deliver non-null
    terminated strings to user-space since the maximum length of the
    prefix that is passed by nf_log is NF_LOG_PREFIXLEN but pm->prefix
    is 32 bytes long (ULOG_PREFIX_LEN).
    
    This is actually happening already from nf_conntrack_tcp if ipt_ULOG
    is used, since it is passing strings longer than 32 bytes.
    
    Signed-off-by: Chen Gang <gang.chen@asianux.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

commit dcb9a7c74acf59679a537e6fcc7a99c12353e7b8
Author: Seung-Woo Kim <sw0312.kim@samsung.com>
Date:   Wed May 22 21:14:17 2013 +0900

    drm/exynos: replace request_threaded_irq with devm function
    
    devm_request_threaded_irq is used instead of request_threaded_irq
    and free_irq is removed.
    
    Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>

commit 7a1b00e0728ff20d6c8e2d6335da05d13d03ef74
Author: Seung-Woo Kim <sw0312.kim@samsung.com>
Date:   Wed May 22 21:14:16 2013 +0900

    drm/exynos: remove unnecessary devm_kfree
    
    devm_kfree does not need for fail case of probe function and for
    remove function.
    
    Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>

commit a3ad6976fe5a306fc6cb9e423ac0ef2f06f79189
Author: Seung-Woo Kim <sw0312.kim@samsung.com>
Date:   Wed May 22 21:14:15 2013 +0900

    drm/exynos: fix build warnings from ipp fimc
    
    Becuase of order of headers, there are build warnings and they are
    fixed with this patch.
    
    Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>

commit d873ab99acd23dcd6860d8e605bc3146a4d4d9a2
Author: Seung-Woo Kim <sw0312.kim@samsung.com>
Date:   Wed May 22 21:14:14 2013 +0900

    drm/exynos: cleanup device pointer usages
    
    Struct device pointer got from platform device pointer is already
    alsigned as variable, but some functions do not use device pointer.
    So this patch replaces thoes usages.
    
    Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>

commit 20cd2640a295cab46bcd08f4788984ca236fc148
Author: Inki Dae <inki.dae@samsung.com>
Date:   Tue May 21 16:55:58 2013 +0900

    drm/exynos: wait for the completion of pending page flip
    
    This patch fixes the issue that drm_vblank_get() is failed.
    
    The issus occurs when next page flip request is tried
    if previous page flip event wasn't completed yet and then
    dpms became off.
    
    So this patch make sure that page flip event is completed
    before dpms goes to off.
    
    Signed-off-by: Inki Dae <inki.dae@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>

commit c5cca97fb915a90b1dcddf737062e67dd8656af8
Author: Rob Clark <rob@ti.com>
Date:   Wed May 22 11:48:40 2013 +0900

    drm/exynos: use drm_send_vblank_event() helper
    
    Rebased.
    
    Signed-off-by: Rob Clark <rob@ti.com>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>

commit 2a7851bffb008ff4882eee673da74718997b4265
Author: Florian Westphal <fw@strlen.de>
Date:   Fri May 17 03:56:10 2013 +0000

    netfilter: add nf_ipv6_ops hook to fix xt_addrtype with IPv6
    
    Quoting https://bugzilla.netfilter.org/show_bug.cgi?id=812:
    
    [ ip6tables -m addrtype ]
    When I tried to use in the nat/PREROUTING it messes up the
    routing cache even if the rule didn't matched at all.
    [..]
    If I remove the --limit-iface-in from the non-working scenario, so just
    use the -m addrtype --dst-type LOCAL it works!
    
    This happens when LOCAL type matching is requested with --limit-iface-in,
    and the default ipv6 route is via the interface the packet we test
    arrived on.
    
    Because xt_addrtype uses ip6_route_output, the ipv6 routing implementation
    creates an unwanted cached entry, and the packet won't make it to the
    real/expected destination.
    
    Silently ignoring --limit-iface-in makes the routing work but it breaks
    rule matching (--dst-type LOCAL with limit-iface-in is supposed to only
    match if the dst address is configured on the incoming interface;
    without --limit-iface-in it will match if the address is reachable
    via lo).
    
    The test should call ipv6_chk_addr() instead.  However, this would add
    a link-time dependency on ipv6.
    
    There are two possible solutions:
    
    1) Revert the commit that moved ipt_addrtype to xt_addrtype,
       and put ipv6 specific code into ip6t_addrtype.
    2) add new "nf_ipv6_ops" struct to register pointers to ipv6 functions.
    
    While the former might seem preferable, Pablo pointed out that there
    are more xt modules with link-time dependeny issues regarding ipv6,
    so lets go for 2).
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

commit 591a0ac7f14aae6bf11b1cb6b5a68480bd644ddb
Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date:   Thu May 23 12:07:50 2013 +0300

    OMAPDSS: Fix crash with DT boot
    
    When booting with DT, there's a crash when omapfb is probed. This is
    caused by the fact that omapdss+DT is not yet supported, and thus
    omapdss is not probed at all. On the other hand, omapfb is always
    probed. When omapfb tries to use omapdss, there's a NULL pointer
    dereference crash. The same error should most likely happen with omapdrm
    and omap_vout also.
    
    To fix this, add an "initialized" state to omapdss. When omapdss has
    been probed, it's marked as initialized. omapfb, omapdrm and omap_vout
    check this state when they are probed to see that omapdss is actually
    there.
    
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

commit 8f657933a3c2086d4731350c98f91a990783c0d3
Author: David Daney <david.daney@cavium.com>
Date:   Wed May 22 22:35:56 2013 +0000

    MIPS: Quit exposing Kconfig symbols in uapi headers.
    
    The kernel's struct pt_regs has many fields conditional on various
    Kconfig variables, we cannot be exporting this garbage to user-space.
    
    Move the kernel's definition to asm/ptrace.h, and put a uapi only
    version in uapi/asm/ptrace.h gated by #ifndef __KERNEL__
    
    Signed-off-by: David Daney <david.daney@cavium.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/5305/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit be8a6d452bda4b1b842e81a99bb86f77a1cb8279
Author: David Daney <david.daney@cavium.com>
Date:   Wed May 22 21:27:22 2013 +0000

    MIPS: Remove duplicate definition of check_for_high_segbits.
    
    In C, one definition is sufficient.
    
    Signed-off-by: David Daney <david.daney@cavium.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/5304/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit ad06156876c0e55a01e13e1f2dd5c7f9262b1dfa
Author: Matthijs Kooijman <matthijs@stdin.nl>
Date:   Wed May 8 12:59:04 2013 +0200

    kbuild: Don't assume dts files live in arch/*/boot/dts
    
    In commit b40b25ff (kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp),
    dts building was changed to always use the C preprocessor. This meant
    that the .dts file passed to dtc is not the original, but the
    preprocessed one.
    
    When compiling with a separate build directory (i.e., with O=), this
    preprocessed file will not live in the same directory as the original.
    When the .dts file includes .dtsi files, dtc will look for them in the
    build directory, not in the source directory and compilation will fail.
    
    The commit referenced above tried to fix this by passing arch/*/boot/dts
    as an include path to dtc. However, for mips, the .dts files are not in
    this directory, so dts compilation on mips breaks for some targets.
    
    Instead of hardcoding this particular include path, this commit just
    uses the directory of the .dts file that is being compiled, which
    effectively restores the previous behaviour wrt includes. For most .dts
    files, this path is just the same as the previous hardcoded
    arch/*/boot/dts path.
    
    This was tested on a mips (rt3052) and an arm (bcm2835) target.
    
    Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl>
    Reviewed-by: Stephen Warren <swarren@nvidia.com>
    Signed-off-by: Michal Marek <mmarek@suse.cz>

commit b5dd0bb43e209455fb83161d4c8774ce2c23f6e2
Author: Michal Simek <michal.simek@xilinx.com>
Date:   Thu May 23 08:04:09 2013 +0200

    microblaze: Use proper casting for inb/inw/inl in io.h
    
    We are going to move to asm-generic/io.h but
    let's fix compilation warnings first for 3.10.
    
    Warning message:
    arch/microblaze/include/asm/io.h:126:26: warning: cast to
     pointer from integer of different size [-Wint-to-pointer-cast]
     #define inb(port)  readb((u8 *)((port)))
    ...
    
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>

commit cc9a3e99949af4bcaf9027fc57f824b595a5fcac
Author: Jiada Wang <jiada_wang@mentor.com>
Date:   Mon May 20 21:51:51 2013 +0900

    ARM i.MX6q: fix for ldb_di_sels
    
    As pll5_video_div has been introduced to represent the clock
    generated from post-divider for video.
    Instead of pll5_video, pll5_video_div should be proper root clock
    for ldb_di_sel.
    
    Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>

commit beaee9cac180e37bbb30d538bcea0ebbcf4fba0e
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Apr 30 10:57:05 2013 +0300

    atmel: printing bogus information
    
    There was an extra ';' character added to the end of the if statement
    which means that it always prints that the /proc entry wasn't created
    even though it was.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: David Howells <dhowells@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 40e2516acb426f349c70e3bada821f3203b69de2
Author: Nicolas Schichan <nschichan@freebox.fr>
Date:   Wed May 22 19:19:27 2013 +0200

    ASoC: cs42l52: fix master playback mute mask.
    
    The mask should define the bits to change in the register, not the
    bits to preserve.
    
    This fixes the inadvertent changes of the "Headphone Analog Gain"
    value during mute/unmute.
    
    Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
    Acked-by: Brian Austin <brian.austin@cirrus.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit 99674c721fd9393030365b66cbbceaa193b0c0fd
Author: Nicolas Schichan <nschichan@freebox.fr>
Date:   Wed May 22 19:19:26 2013 +0200

    ASoC: cs42l52: fix bogus shifts in "Speaker Volume" and "PCM Mixer Volume" controls.
    
    Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
    Acked-by: Brian Austin <brian.austin@cirrus.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit 0b6e81d1658e2aa6b3acc942088c529fee5aa62e
Author: Nicolas Schichan <nschichan@freebox.fr>
Date:   Wed May 22 19:19:25 2013 +0200

    ASoC: cs42l52: microphone bias is controlled by IFACE_CTL2 register.
    
    Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
    Acked-by: Brian Austin <brian.austin@cirrus.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit 08c96abd611beadf2af414a306fe0fb02ba706ff
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sat May 18 21:28:15 2013 +0200

    ath9k: prevent aggregation session deadlocks
    
    Waiting for all subframes of an existing aggregation session to drain
    before allowing mac80211 to start a new one is fragile and deadlocks
    caused by this behavior have been observed.
    
    Since mac80211 has proper synchronization for aggregation session
    start/stop handling, a better approach to session handling is to simply
    allow mac80211 to start a new session at any time. This requires
    changing the code to discard any packets outside of the BlockAck window
    in the A-MPDU software retry code.
    
    This patch implements the above and also simplifies the code.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit bac902d505220544824829affcf9c1b17b57b8ca
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Wed May 22 10:55:41 2013 +0800

    spi: topcliff-pch: fix error return code in pch_spi_probe()
    
    Fix to return -ENOMEM in the platform_device_alloc() error handling
    case instead of 0, as done elsewhere in this function.
    
    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit 3598706b52cb45ba0a9e8aa99ce5ac59140f2b8b
Author: Imre Deak <imre.deak@intel.com>
Date:   Tue May 21 20:03:20 2013 +0300

    drm/i915: avoid premature DP AUX timeouts
    
    During DP AUX communication we might time out 1 jiffy too early, because
    the calculated expiry jiffy value is one less than needed.
    
    This is only one reason for false DP AUX timeouts. For a complete
    solution we also need the following fix, which is now queued for
    mainline: http://marc.info/?l=linux-kernel&m=136748515710837&w=2
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64133
    
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit e054cc3937a4a58e77870d4c922a7b21824b610a
Author: Imre Deak <imre.deak@intel.com>
Date:   Tue May 21 20:03:19 2013 +0300

    drm/i915: avoid premature timeouts in __wait_seqno()
    
    At the moment wait_event_timeout/wait_event_interruptible_timeout may
    time out 1 jiffy too early, as the calculated expiry time is 1 less than
    needed. Besides timing out too early this also means that the
    calculation of the remaining time will be incorrect and we will pass a
    non-zero remaining time to user space in case of a time out. This is one
    reason for the following bugzilla report:
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64270
    
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 2554fc1fa6dc184ca553f73e3796fa59745efa8a
Author: Imre Deak <imre.deak@intel.com>
Date:   Tue May 21 20:03:18 2013 +0300

    drm/i915: use msecs_to_jiffies_timeout instead of open coding the same
    
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit df97729f1bcb5055ba414f08b48364d46c6baef0
Author: Imre Deak <imre.deak@intel.com>
Date:   Tue May 21 20:03:17 2013 +0300

    drm/i915: add msecs_to_jiffies_timeout to guarantee minimum duration
    
    We need this to avoid premature timeouts whenever scheduling a timeout
    based on the current jiffies value. For an explanation see [1].
    The following patches will take the helper into use.
    
    Once the more generic solution proposed in the thread at [1] is accepted
    this patch can be reverted while keeping the follow-up patches.
    
    [1] http://marc.info/?l=linux-kernel&m=136854294730957&w=2
    
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 576ebd74928fd60ae112b33c42b89602015fadbd
Author: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Date:   Tue May 21 16:08:22 2013 +0200

    kernel: Fix s390 absolute memory access for /dev/mem
    
    On s390 the prefix page and absolute zero pages are not correctly
    returned when reading /dev/mem. The reason is that the s390 asm/io.h
    file includes the asm-generic/io.h file which then defines
    xlate_dev_mem_ptr() and therefore overwrites the s390 specific
    version that does the correct swap operation for prefix and absolute
    zero pages. The problem is a regression that was introduced with git
    commit cd248341 (s390/pci: base support).
    
    To fix the problem add "#ifndef xlate_dev_mem_ptr" in asm-generic/io.h
    and "#define xlate_dev_mem_ptr" in asm/io.h. This ensures that the
    s390 version is used. For completeness also add the "#ifndef"
    construct for xlate_dev_kmem_ptr().
    
    Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit abd9a0c36028771a8f397f38bf79bfcf404f957f
Author: Sebastian Ott <sebott@linux.vnet.ibm.com>
Date:   Fri May 17 16:37:59 2013 +0200

    s390/dma: do not call debug_dma after free
    
    In dma_free_coherent call debug_dma_free_coherent before deallocating
    the memory to avoid a possible use after free.
    
    Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
    Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit e3de42b68478a8c95dd27520e9adead2af9477a5
Author: Imre Deak <imre.deak@intel.com>
Date:   Fri May 3 19:44:07 2013 +0200

    drm/i915: force full modeset if the connector is in DPMS OFF mode
    
    Currently the driver's assumed behavior for a modeset with an attached
    FB is that the corresponding connector will be switched to DPMS ON mode
    if it happened to be in DPMS OFF (or another power save mode). This
    wasn't enforced though if only the FB changed, everything else (format,
    connector etc.) remaining the same. In this case we only set the new FB
    base and left the connector in the old power save mode.
    
    Fix this by forcing a full modeset whenever there is an attached FB and
    any affected connector is in a power save mode.
    
    V_2: Run the test for encoders in power save mode outside the the
    test for fb change: user space may have just disabled the encoders
    but left everything else in place. Make sure the connector list is
    not empty before running this test.
    
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Signed-off-by: Egbert Eich <eich@suse.de>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61642
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59834
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59339
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64178
    Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    [danvet: Apply Jani's s/connector_off/is_crtc_connector_off bikeshed.]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 94d019b87859bb984bd6c15db330d404eab3acaa
Author: Rob Clark <rob@ti.com>
Date:   Mon Oct 8 14:50:44 2012 -0500

    drm/exynos: page flip fixes
    
    The event wouldn't be on any list at this point, so nothing to delete
    it from.
    
    Signed-off-by: Rob Clark <rob@ti.com>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>

commit 4c1d8def9d5bbd642782893ccd849963f1811ae6
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Mon May 20 19:32:06 2013 +0200

    drm/exynos: exynos_hdmi: Pass correct pointer to free_irq()
    
    free_irq() expects the same pointer that was passed to request_threaded_irq(),
    otherwise the IRQ is not freed.
    
    The issue was found using the following coccinelle script:
    
    <smpl>
    @r1@
    type T;
    T devid;
    @@
    request_threaded_irq(..., devid)
    
    @r2@
    type r1.T;
    T devid;
    position p;
    @@
    free_irq@p(..., devid)
    
    @@
    position p != r2.p;
    @@
    *free_irq@p(...)
    </smpl>
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Acked-by: Seung-Woo Kim <sw0312.kim@samsung.com>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>

commit f02504587ed5669cc721a1f2351322e6badfe67f
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date:   Mon Apr 29 12:27:06 2013 +0530

    drm/exynos: exynos_drm_ipp: Fix incorrect usage of IS_ERR_OR_NULL
    
    None of these functions actually return a NULL pointer. Hence use
    IS_ERR() instead.
    
    Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>

commit 41eab402b43f1ca3e1279595bc138f5ac2a914f7
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date:   Mon Apr 29 12:27:05 2013 +0530

    drm/exynos: exynos_drm_fbdev: Fix incorrect usage of IS_ERR_OR_NULL
    
    exynos_drm_framebuffer_init() does not return NULL. Use IS_ERR instead.
    
    Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>

commit df7e131f6359f20ed8f0a37db039c4f6420a18c2
Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date:   Tue May 21 23:07:54 2013 +0400

    sata_rcar: clear STOP bit in bmdma_start() method
    
    Iff bmdma_setup() has to stop a DMA transfer before starting a new
    one, then the STOP bit in the ATAPI_CONTROL1 register will remain set
    (it's only cleared when setting the START bit to 1) and then
    bmdma_start() method will set both START and STOP bits simultaneously
    which should abort the transfer being just started.  Avoid that by
    explicitly clearing the STOP bit in bmdma_start() method (in this case
    it will be ignored on write).
    
    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: stable@vger.kernel.org

commit e771451c0a831d96a7c14b0ca8a8ec671d98567b
Author: Vincent Pelletier <plr.vincent@gmail.com>
Date:   Sat May 18 18:44:04 2013 +0200

    libata: make ata_exec_internal_sg honor DMADIR
    
    libata honors DMADIR for regular commands, but not for internal commands
    used (among other) during device initialisation.
    
    This makes SATA-host-to-PATA-device bridges based on Silicon Image SiL3611
    (such as "Abit Serillel 2") end up disabled when used with an ATAPI device
    after a few tries.
    
    Log output of the bridge being hot-plugged with an ATAPI drive:
    
      [ 9631.212901] ata1: exception Emask 0x10 SAct 0x0 SErr 0x40c0000 action 0xe frozen
      [ 9631.212913] ata1: irq_stat 0x00000040, connection status changed
      [ 9631.212923] ata1: SError: { CommWake 10B8B DevExch }
      [ 9631.212939] ata1: hard resetting link
      [ 9632.104962] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
      [ 9632.106393] ata1.00: ATAPI: PIONEER DVD-RW  DVR-115, 1.06, max UDMA/33
      [ 9632.106407] ata1.00: applying bridge limits
      [ 9632.108151] ata1.00: configured for UDMA/33
      [ 9637.105303] ata1.00: qc timeout (cmd 0xa0)
      [ 9637.105324] ata1.00: failed to clear UNIT ATTENTION (err_mask=0x5)
      [ 9637.105335] ata1: hard resetting link
      [ 9638.044599] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
      [ 9638.047878] ata1.00: configured for UDMA/33
      [ 9643.044933] ata1.00: qc timeout (cmd 0xa0)
      [ 9643.044953] ata1.00: failed to clear UNIT ATTENTION (err_mask=0x5)
      [ 9643.044963] ata1: limiting SATA link speed to 1.5 Gbps
      [ 9643.044971] ata1.00: limiting speed to UDMA/33:PIO3
      [ 9643.044979] ata1: hard resetting link
      [ 9643.984225] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
      [ 9643.987471] ata1.00: configured for UDMA/33
      [ 9648.984591] ata1.00: qc timeout (cmd 0xa0)
      [ 9648.984612] ata1.00: failed to clear UNIT ATTENTION (err_mask=0x5)
      [ 9648.984619] ata1.00: disabled
      [ 9649.000593] ata1: hard resetting link
      [ 9649.939902] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
      [ 9649.955864] ata1: EH complete
    
    With this patch, the drive enumerates correctly when libata is loaded with
    atapi_dmadir=1:
    
      [ 9891.810863] ata1: exception Emask 0x10 SAct 0x0 SErr 0x40c0000 action 0xe frozen
      [ 9891.810874] ata1: irq_stat 0x00000040, connection status changed
      [ 9891.810884] ata1: SError: { CommWake 10B8B DevExch }
      [ 9891.810900] ata1: hard resetting link
      [ 9892.762105] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
      [ 9892.763544] ata1.00: ATAPI: PIONEER DVD-RW  DVR-115, 1.06, max UDMA/33, DMADIR
      [ 9892.763558] ata1.00: applying bridge limits
      [ 9892.765393] ata1.00: configured for UDMA/33
      [ 9892.786063] ata1: EH complete
      [ 9892.792062] scsi 0:0:0:0: CD-ROM            PIONEER  DVD-RW  DVR-115  1.06 PQ: 0 ANSI: 5
      [ 9892.798455] sr2: scsi3-mmc drive: 12x/12x writer dvd-ram cd/rw xa/form2 cdda tray
      [ 9892.798837] sr 0:0:0:0: Attached scsi CD-ROM sr2
      [ 9892.799109] sr 0:0:0:0: Attached scsi generic sg6 type 5
    
    Based on a patch by Csaba Halász <csaba.halasz@gmail.com> on linux-ide:
    http://marc.info/?l=linux-ide&m=136121147832295&w=2
    
    tj: minor formatting changes.
    
    Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: stable@vger.kernel.org

commit 0eca56f9467038ee0b798637f03581aaa1186fac
Author: Rob Clark <rob@ti.com>
Date:   Mon Oct 8 19:50:46 2012 +0000

    drm/imx: use drm_send_vblank_event() helper
    
    Also, slightly changes the behavior to always put the vblank irq,
    even if userspace did not request a vblank event.  As far as I
    can tell, the previous code would leak a vblank irq refcnt if
    userspace requested a pageflip without event.
    
    Signed-off-by: Rob Clark <rob@ti.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

commit f7e96d7e28817a66db36e89f25b77bda7dba6da0
Author: Rob Clark <rob@ti.com>
Date:   Mon Oct 8 19:50:45 2012 +0000

    drm/shmob: use drm_send_vblank_event() helper
    
    Signed-off-by: Rob Clark <rob@ti.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

commit 26ae466732c181b7376610fd9241787698179b01
Author: Rob Clark <rob@ti.com>
Date:   Mon Oct 8 19:50:42 2012 +0000

    drm/radeon: use drm_send_vblank_event() helper
    
    Signed-off-by: Rob Clark <rob@ti.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

commit 95d38d144ab4520aea3f8fcfacc5fd62d3bf2697
Author: Rob Clark <rob@ti.com>
Date:   Mon Oct 8 19:50:41 2012 +0000

    drm/nouveau: use drm_send_vblank_event() helper
    
    Signed-off-by: Rob Clark <rob@ti.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

commit e4f2dfbb5e92be4e46c0625f4f8eb101110f756f
Author: Mikael Pettersson <mikpe@it.uu.se>
Date:   Fri Mar 8 15:03:53 2013 +0100

    m68k: implement futex.h to support userspace robust futexes and PI mutexes
    
    Linux/M68K currently doesn't support robust futexes or PI mutexes.
    The problem is that the futex code needs to perform certain ops
    (cmpxchg, set, add, or, andn, xor) atomically on user-space
    addresses, and M68K's lack of a futex.h causes those operations
    to be unsupported and disabled.
    
    This patch adds that support, but only for uniprocessor machines,
    which is adequate for M68K.  For UP it's enough to disable preemption
    to ensure mutual exclusion (futexes don't need to care about other
    hardware agents), and the mandatory pagefault_disable() does just that.
    
    This patch is closely based on the one I co-wrote for UP ARM back
    in August 2008.  The main change is that this patch uses the C
    get_user/put_user accessors instead of inline assembly code with
    exception table fixups.
    
    For non-MMU machines the new futex.h simply redirects to the generic
    futex.h, so there is no functional change for them.
    
    Tested on aranym with the glibc-2.17 test suite: no regressions, and
    a number of mutex/condvar test cases went from failing to succeeding
    (tst-mutexpi{5,5a,6,9}, tst-cond2[45], tst-robust[1-9], tst-robustpi[1-8]).
    Also tested with glibc-2.18 HEAD and a local glibc patch to enable PI
    mutexes: no regressions.
    
    Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
    Acked-by: Andreas Schwab <schwab@linux-m68k.org>
    [geert: Added removal of ""generic-y += futex.h"]
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

commit 796718925159523919a589ecbd6d1811c22ef55f
Author: Daniel Mack <zonque@gmail.com>
Date:   Thu May 16 15:25:01 2013 +0200

    ASoC: davinci: fix sample rotation
    
    McASP serial audio engine needs different rotation values on TX and RX
    channels. Commit dde109fb462 ("ASoC: McASP: Fix data rotation for
    playback. Enables 24bit audio playback") changed the calculation to fix
    the playback format, but broke the capture stream by doing it for both
    TXFMT and RXFMT.
    
    Signed-off-by: Daniel Mack <zonque@gmail.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Cc: stable@vger.kernel.org [3.9 only]

commit ce0d10f887cabf9f16d1cbb60ef013021befbfdf
Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date:   Tue May 21 15:04:07 2013 +0100

    regulator: core: Correct spelling mistake in comment
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit c79b069d72f54ff0589e7615160420553aa4f04e
Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
Date:   Thu May 9 08:43:34 2013 -0300

    [media] exynos4-is: Correct fimc-lite compatible property description
    
    Ensure the compatible property for FIMC-LITE IP blocks is properly
    documented, a cut&paste error fix.
    
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 7accedd2fa059961629fd47212dd7096370c64fb
Author: Axel Lin <axel.lin@ingics.com>
Date:   Tue Apr 30 10:18:23 2013 -0300

    [media] exynos4-is: Fix off-by-one valid range checking for is->config_index
    
    Current code uses is->config_index as array subscript, thus the valid value
    range is 0 ... ARRAY_SIZE(cmd) - 1.
    
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit c6f89116c14144c18295d2a06294788c86fe9e6d
Author: Axel Lin <axel.lin@ingics.com>
Date:   Tue Apr 30 00:42:16 2013 -0300

    [media] s5c73m3: Fix off-by-one valid range checking for fie->index
    
    Current code uses fie->index as array subscript, thus the valid value range
    is 0 ... ARRAY_SIZE(s5c73m3_intervals) - 1.
    
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Acked-by: Andrzej Hajda <a.hajda@samsung.com>
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 8410725333088643f49371396e727cc1e41ccfb5
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date:   Tue Apr 30 02:16:19 2013 -0300

    [media] s3c-camif: Fix incorrect variable type
    
    'rotation' was an 8 bit variable and hence could not have values
    greater than 255. Since we need higher values, change it to 16
    bit type.
    
    Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 2031941502339d548cd51bf34e6ebb8bc3bb2d89
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date:   Fri Apr 26 04:52:57 2013 -0300

    [media] exynos4-is: Fix potential null pointer dereference in mipi-csis.c
    
    When 'node' is NULL, the print statement tries to dereference it.
    Hence replace the variable with the one that is accessible.
    
    Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit a2ac2d792cb6a22eb86ef4e026ba74c3ea6e67ee
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Fri May 10 07:53:08 2013 -0300

    [media] vpfe-capture.c: remove unused label probe_free_lock
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 6e7df1cd373d688486b0b0b6626cb32f59ebdcfa
Author: Hans Verkuil <hverkuil@xs4all.nl>
Date:   Tue May 7 08:06:11 2013 -0300

    [media] DocBook: media: update codec section, drop obsolete 'suspended' state
    
    The Codec section in the V4L2 specification was marked as 'suspended', even
    though codec support has been around for quite some time. Update this
    section, explaining a bit about memory-to-memory devices and pointing to
    the MPEG controls section.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Kamil Debski <k.debski@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit ea457ad9dbf32c8d22cc1cc39b4c1a2e06bf9b89
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu May 2 11:16:26 2013 -0300

    [media] radio-si476x: depend on SND_SOC
    
    It is not possible to select SND_SOC_SI476X if we have not also
    enabled SND_SOC.
    warning: (RADIO_SI476X) selects SND_SOC_SI476X which has unmet
    	 direct dependencies (SOUND && !M68K && !UML && SND && SND_SOC)
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    [hans.verkuil@cisco.com: fixed wrong driver name in subject]
    Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit ab6717886b6af7c1408602948653c63408c46f5e
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Wed May 8 16:23:41 2013 -0300

    [media] v4l2: SI476X MFD - Do not use binary constants
    
    Gcc < 4.3 doesn't understand binary constanrs (0b*):
    drivers/media/radio/radio-si476x.c:862:20: error: invalid suffix "b10000000" on integer constant
    Hence use a hexadecimal constant (0x*) instead.
    
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 96f83b3f270aff148a1fa55f9a464e1bbadeadd4
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Tue May 7 07:51:21 2013 -0300

    [media] davinci: vpfe: fix error return code in vpfe_probe()
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 39e219d9292958460c3229df29995454414ce626
Author: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Date:   Fri May 10 00:48:38 2013 -0300

    [media] davinci: vpfe: fix error path in probe
    
    The error path on failure was calling mutex_unlock(), but there was
    no actuall call before for mutex_lock(). This patch fixes this issue
    by pointing it to proper go label.
    
    Reported-by: Jose Pablo Carballo <jose.carballo@ridgerun.com>
    Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit bdea0d222a21f864a811cf6666532334e622f7c6
Author: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Date:   Tue May 7 01:07:25 2013 -0300

    [media] media: davinci: vpbe: fix layer availability for NV12 format
    
    For NV12 format, even if display data is single image,
    both VIDWIN0 and VIDWIN1 parameters must be used. The start
    address of Y data plane and C data plane is configured in
    VIDEOWIN0ADH/L and VIDEOWIN1ADH/L respectively.
    cuurently only one layer was requested, which is suffice
    for yuv422, but for yuv420(NV12) two layers are required and
    fix the same by requesting for other layer if pix fmt is NV12
    during set_fmt.
    
    Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 2d05eae1c92f93ace0fc6f282c55527d293297dd
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri May 3 17:36:25 2013 +0100

    drm/i915: Propagate errors back from fb set-base
    
    Along the modesetting short cut where we skip trying to do a full
    modeset and instead simply update the framebuffer base registers, we
    failed to handle any errors reported.
    
    This regression has been introduced in
    
    commit 94352cf9a5328bb1a44288e6c2c1276695f8a356
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Thu Jul 5 22:51:56 2012 +0200
    
        drm/i915: push crtc->fb update into pipe_set_base
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 1c98b4871cca4b7ce07e19f92f934d47cf7210b0
Author: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Date:   Mon May 13 18:12:25 2013 -0300

    drm/i915: Adding more reserved PCI IDs for Haswell.
    
    At DDX commit Chris mentioned the tendency we have of finding out more
    PCI IDs only when users report. So Let's add all new reserved Haswell IDs.
    
    This patch also fix GT3 names. I'no not sending in separated patche because
    names are only in few comments and not in variable names.
    
    v2: Fix some mobile ids (by Paulo)
    
    References: http://bugs.freedesktop.org/show_bug.cgi?id=63701
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit e3a6b14ceda0207c3405c6266e5177a85c0db044
Author: Samuel Ortiz <sameo@linux.intel.com>
Date:   Tue Apr 30 23:50:29 2013 +0200

    NFC: mei: Do not disable MEI devices from their remove routine
    
    Enabling and disabling device is exclusively handled by the mei_phy_ops.
    
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

commit 73f3adb9b91efac04e4e7f8379a85400fc57121e
Author: Samuel Ortiz <sameo@linux.intel.com>
Date:   Tue Apr 30 23:48:50 2013 +0200

    NFC: mei_phy: Register event callback when enabling the device
    
    The callback registration starts a waiting read, so it needs to be fired
    everytime the device is enabled. Otherwise following writes will never get
    an answer back.
    
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

commit d999e4db0ac409c582cb15e6b120241ed9105064
Author: Samuel Ortiz <sameo@linux.intel.com>
Date:   Tue Apr 30 23:22:34 2013 +0200

    NFC: mei_phy depends on INTEL_MEI
    
    INTEL_MEI_BUS_NFC never made it upstream, so make it depend on INTEL_MEI.
    
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

commit 7c055881de33b5d8ebb6d12150eaf338a0546199
Author: Paul Bolle <pebolle@tiscali.nl>
Date:   Sun May 12 23:21:24 2013 +0200

    NFC: Remove commented out LLCP related Makefile line
    
    The Kconfig symbol NFC_LLCP was removed in commit 30cc458765 ("NFC: Move
    LLCP code to the NFC top level diirectory"). But the reference to its
    macro in this Makefile was only commented out. Remove it now.
    
    Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

commit be646c2d2ba8e2e56596d72633705f8286698c25
Author: Joern Engel <joern@logfs.org>
Date:   Wed May 15 00:44:07 2013 -0700

    target: Remove unused wait_for_tasks bit in target_wait_for_sess_cmds
    
    Drop unused transport_wait_for_tasks() check in target_wait_for_sess_cmds
    shutdown code, and convert tcm_qla2xxx + ib_srpt fabric drivers.
    
    Cc: Joern Engel <joern@logfs.org>
    Cc: Roland Dreier <roland@kernel.org>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 62cc4d595fe96106ff793cbebbff051179d7619e
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Mon May 20 11:28:35 2013 -0500

    ASoC: wm5110: Add missing speaker initialisation
    
    Add callback to initialise the speaker in the core following the recent
    changes to handling of integration with the thermal interrupts.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit 7ec892ef5f1bd707e2d5ab128069cb6af75c7f07
Author: Vivek Gautam <gautam.vivek@samsung.com>
Date:   Wed Apr 10 19:30:38 2013 +0900

    ARM: dts: Enabling samsung-usb2phy driver for exynos5250
    
    Adding usbphy node for Exynos5250 along with the
    necessary device data to be parsed.
    
    Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
    Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>

commit e1e5762823be84cb97f629bdfecb97af3d187406
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Mon May 20 17:54:35 2013 +0200

    spi: topcliff-pch: Pass correct pointer to free_irq()
    
    free_irq() expects the same pointer that was passed to request_irq(), otherwise
    the IRQ is not freed.
    
    The issue was found using the following coccinelle script:
    
    <smpl>
    @r1@
    type T;
    T devid;
    @@
    request_irq(..., devid)
    
    @r2@
    type r1.T;
    T devid;
    position p;
    @@
    free_irq@p(..., devid)
    
    @@
    position p != r2.p;
    @@
    *free_irq@p(...)
    </smpl>
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit bee6c307800bbb26ba1a855b1841c2f0c4b7622a
Author: Brian Foster <bfoster@redhat.com>
Date:   Fri May 17 15:27:34 2013 -0400

    fuse: update inode size and invalidate attributes on fallocate
    
    An fallocate request without FALLOC_FL_KEEP_SIZE set can extend the
    size of a file. Update the inode size after a successful fallocate.
    
    Also invalidate the inode attributes after a successful fallocate
    to ensure we pick up the latest attribute values (i.e., i_blocks).
    
    Signed-off-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>

commit 3634a6327815d39dd93e5c44a602daae91c66297
Author: Brian Foster <bfoster@redhat.com>
Date:   Fri May 17 09:30:32 2013 -0400

    fuse: truncate pagecache range on hole punch
    
    fuse supports hole punch via the fallocate() FALLOC_FL_PUNCH_HOLE
    interface. When a hole punch is passed through, the page cache
    is not cleared and thus allows reading stale data from the cache.
    
    This is easily demonstrable (using FOPEN_KEEP_CACHE) by reading a
    smallish random data file into cache, punching a hole and creating
    a copy of the file. Drop caches or remount and observe that the
    original file no longer matches the file copied after the hole
    punch. The original file contains a zeroed range and the latter
    file contains stale data.
    
    Protect against writepage requests in progress and punch out the
    associated page cache range after a successful client fs hole
    punch.
    
    Signed-off-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>

commit 2c071ed7c3660992951abe4b560359058ce41f68
Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date:   Mon May 20 08:33:54 2013 +0100

    ASoC: soc-compress: Send correct stream event for capture start
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit 3d15aacbb802af72b4ff0c3ba576536cdb3bace0
Author: Andrew Bresticker <abrestic@chromium.org>
Date:   Sun May 19 22:58:07 2013 -0700

    ASoC: max98090: request IRQF_ONESHOT interrupt
    
    request_threaded_irq() rejects calls which both do not specify a handler
    (indicating that the primary IRQ handler should be used) and do not set
    IRQF_ONESHOT because the combination is unsafe with level-triggered
    interrupts.  It is safe in this case, though, since max98090 IRQs are
    edge-triggered and the interrupts aren't ACK'ed until the codec's IRQ
    status register is read.  Because of this, an IRQF_ONESHOT interrupt
    doesn't really make a difference, but request one anyway in order to make
    request_threaded_irq() happy.
    
    Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit 57a9c7609d7418ce75324df38f66cd7d937a77cb
Author: Clement Chauplannaz <chauplac@gmail.com>
Date:   Sun May 12 21:08:52 2013 +0200

    scripts/config: fix assignment of parameters for short version of --*-after options
    
    When --*-after options are used, two parameters are parsed from the
    command-line before the adequate function is called:
      - the `before' option, after which the new option will be inserted,
      - the name of the option to enable/disable/modularise.
    
    With the short version of --*-after options (namely -E, -D, -M), the
    parsing step is not performed which leads to processing unset variables.
    
    Add options -E, -D, -M to the test that triggers assignment of parameters
    for --*-after options.
    
    Signed-off-by: Clement Chauplannaz <chauplac@gmail.com>
    Acked-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit fbe06b7bae7c9cf6ab05168fce5ee93b2f4bae7c
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Fri May 17 11:49:10 2013 -0700

    x86, range: fix missing merge during add range
    
    Christian found v3.9 does not work with E350 with EFI is enabled.
    
    [    1.658832] Trying to unpack rootfs image as initramfs...
    [    1.679935] BUG: unable to handle kernel paging request at ffff88006e3fd000
    [    1.686940] IP: [<ffffffff813661df>] memset+0x1f/0xb0
    [    1.692010] PGD 1f77067 PUD 1f7a067 PMD 61420067 PTE 0
    
    but early memtest report all memory could be accessed without problem.
    
    early page table is set in following sequence:
    [    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
    [    0.000000] init_memory_mapping: [mem 0x6e600000-0x6e7fffff]
    [    0.000000] init_memory_mapping: [mem 0x6c000000-0x6e5fffff]
    [    0.000000] init_memory_mapping: [mem 0x00100000-0x6bffffff]
    [    0.000000] init_memory_mapping: [mem 0x6e800000-0x6ea07fff]
    but later efi_enter_virtual_mode try set mapping again wrongly.
    [    0.010644] pid_max: default: 32768 minimum: 301
    [    0.015302] init_memory_mapping: [mem 0x640c5000-0x6e3fcfff]
    that means it fails with pfn_range_is_mapped.
    
    It turns out that we have a bug in add_range_with_merge and it does not
    merge range properly when new add one fill the hole between two exsiting
    ranges. In the case when [mem 0x00100000-0x6bffffff] is the hole between
    [mem 0x00000000-0x000fffff] and [mem 0x6c000000-0x6e7fffff].
    
    Fix the add_range_with_merge by calling itself recursively.
    
    Reported-by: "Christian König" <christian.koenig@amd.com>
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Link: http://lkml.kernel.org/r/CAE9FiQVofGoSk7q5-0irjkBxemqK729cND4hov-1QCBJDhxpgQ@mail.gmail.com
    Cc: <stable@vger.kernel.org> v3.9
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

commit 3abef3b3585bbc67d56fdc9c67761a900fb4b69d
Author: Alex Elder <elder@inktank.com>
Date:   Mon May 13 20:35:37 2013 -0500

    rbd: fix cleanup in rbd_add()
    
    Bjorn Helgaas pointed out that a recent commit introduced a
    use-after-free condition in an error path for rbd_add().
    He correctly stated:
    
        I think b536f69a3a5 "rbd: set up devices only for mapped images"
        introduced a use-after-free error in rbd_add():
    	...
        If rbd_dev_device_setup() returns an error, we call
        rbd_dev_image_release(), which ultimately kfrees rbd_dev.
        Then we call rbd_dev_destroy(), which references fields in
        the already-freed rbd_dev struct before kfreeing it again.
    
    The simple fix is to return the error code after the call to
    rbd_dev_image_release().
    
    Closer examination revealed that there's no need to clean up
    rbd_opts in that function, so fix that too.
    
    Update some other comments that have also become out of date.
    
    Reported-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Alex Elder <elder@inktank.com>
    Reviewed-by: Josh Durgin <josh.durgin@inktank.com>

commit 7262cfca430a1a0e0707149af29ae86bc0ded230
Author: Alex Elder <elder@inktank.com>
Date:   Thu May 16 15:04:20 2013 -0500

    rbd: don't destroy ceph_opts in rbd_add()
    
    Whether rbd_client_create() successfully creates a new client or
    not, it takes responsibility for getting the ceph_opts structure
    it's passed destroyed.  If successful, the structure becomes
    associated with the created client; if not, rbd_client_create()
    will destroy it.
    
    Previously, rbd_get_client() would call ceph_destroy_options()
    if rbd_get_client() failed, and that meant it got called twice.
    That led freeing various pointers more than once, which is never a
    good idea.
    
    This resolves:
        http://tracker.ceph.com/issues/4559
    
    Cc: stable@vger.kernel.org # 3.8+
    Reported-by: Dan van der Ster <dan@vanderster.com>
    Signed-off-by: Alex Elder <elder@inktank.com>
    Reviewed-by: Josh Durgin <josh.durgin@inktank.com>

commit 39be95e9c8c0b5668c9f8806ffe29bf9f4bc0f40
Author: Jim Schutt <jaschut@sandia.gov>
Date:   Wed May 15 13:03:35 2013 -0500

    ceph: ceph_pagelist_append might sleep while atomic
    
    Ceph's encode_caps_cb() worked hard to not call __page_cache_alloc()
    while holding a lock, but it's spoiled because ceph_pagelist_addpage()
    always calls kmap(), which might sleep.  Here's the result:
    
    [13439.295457] ceph: mds0 reconnect start
    [13439.300572] BUG: sleeping function called from invalid context at include/linux/highmem.h:58
    [13439.309243] in_atomic(): 1, irqs_disabled(): 0, pid: 12059, name: kworker/1:1
        . . .
    [13439.376225] Call Trace:
    [13439.378757]  [<ffffffff81076f4c>] __might_sleep+0xfc/0x110
    [13439.384353]  [<ffffffffa03f4ce0>] ceph_pagelist_append+0x120/0x1b0 [libceph]
    [13439.391491]  [<ffffffffa0448fe9>] ceph_encode_locks+0x89/0x190 [ceph]
    [13439.398035]  [<ffffffff814ee849>] ? _raw_spin_lock+0x49/0x50
    [13439.403775]  [<ffffffff811cadf5>] ? lock_flocks+0x15/0x20
    [13439.409277]  [<ffffffffa045e2af>] encode_caps_cb+0x41f/0x4a0 [ceph]
    [13439.415622]  [<ffffffff81196748>] ? igrab+0x28/0x70
    [13439.420610]  [<ffffffffa045e9f8>] ? iterate_session_caps+0xe8/0x250 [ceph]
    [13439.427584]  [<ffffffffa045ea25>] iterate_session_caps+0x115/0x250 [ceph]
    [13439.434499]  [<ffffffffa045de90>] ? set_request_path_attr+0x2d0/0x2d0 [ceph]
    [13439.441646]  [<ffffffffa0462888>] send_mds_reconnect+0x238/0x450 [ceph]
    [13439.448363]  [<ffffffffa0464542>] ? ceph_mdsmap_decode+0x5e2/0x770 [ceph]
    [13439.455250]  [<ffffffffa0462e42>] check_new_map+0x352/0x500 [ceph]
    [13439.461534]  [<ffffffffa04631ad>] ceph_mdsc_handle_map+0x1bd/0x260 [ceph]
    [13439.468432]  [<ffffffff814ebc7e>] ? mutex_unlock+0xe/0x10
    [13439.473934]  [<ffffffffa043c612>] extra_mon_dispatch+0x22/0x30 [ceph]
    [13439.480464]  [<ffffffffa03f6c2c>] dispatch+0xbc/0x110 [libceph]
    [13439.486492]  [<ffffffffa03eec3d>] process_message+0x1ad/0x1d0 [libceph]
    [13439.493190]  [<ffffffffa03f1498>] ? read_partial_message+0x3e8/0x520 [libceph]
        . . .
    [13439.587132] ceph: mds0 reconnect success
    [13490.720032] ceph: mds0 caps stale
    [13501.235257] ceph: mds0 recovery completed
    [13501.300419] ceph: mds0 caps renewed
    
    Fix it up by encoding locks into a buffer first, and when the number
    of encoded locks is stable, copy that into a ceph_pagelist.
    
    [elder@inktank.com: abbreviated the stack info a bit.]
    
    Cc: stable@vger.kernel.org # 3.4+
    Signed-off-by: Jim Schutt <jaschut@sandia.gov>
    Reviewed-by: Alex Elder <elder@inktank.com>

commit c420276a532a10ef59849adc2681f45306166b89
Author: Jim Schutt <jaschut@sandia.gov>
Date:   Wed May 15 13:03:35 2013 -0500

    ceph: add cpu_to_le32() calls when encoding a reconnect capability
    
    In his review, Alex Elder mentioned that he hadn't checked that
    num_fcntl_locks and num_flock_locks were properly decoded on the
    server side, from a le32 over-the-wire type to a cpu type.
    I checked, and AFAICS it is done; those interested can consult
        Locker::_do_cap_update()
    in src/mds/Locker.cc and src/include/encoding.h in the Ceph server
    code (git://github.com/ceph/ceph).
    
    I also checked the server side for flock_len decoding, and I believe
    that also happens correctly, by virtue of having been declared
    __le32 in struct ceph_mds_cap_reconnect, in src/include/ceph_fs.h.
    
    Cc: stable@vger.kernel.org # 3.4+
    Signed-off-by: Jim Schutt <jaschut@sandia.gov>
    Reviewed-by: Alex Elder <elder@inktank.com>

commit 14d2f38df67fadee34625fcbd282ee22514c4846
Author: Alex Elder <elder@inktank.com>
Date:   Wed May 15 16:28:33 2013 -0500

    libceph: must hold mutex for reset_changed_osds()
    
    An osd client has a red-black tree describing its osds, and
    occasionally we would get crashes due to one of these trees tree
    becoming corrupt somehow.
    
    The problem turned out to be that reset_changed_osds() was being
    called without protection of the osd client request mutex.  That
    function would call __reset_osd() for any osd that had changed, and
    __reset_osd() would call __remove_osd() for any osd with no
    outstanding requests, and finally __remove_osd() would remove the
    corresponding entry from the red-black tree.  Thus, the tree was
    getting modified without having any lock protection, and was
    vulnerable to problems due to concurrent updates.
    
    This appears to be the only osd tree updating path that has this
    problem.  It can be fairly easily fixed by moving the call up
    a few lines, to just before the request mutex gets dropped
    in kick_requests().
    
    This resolves:
        http://tracker.ceph.com/issues/5043
    
    Cc: stable@vger.kernel.org # 3.4+
    Signed-off-by: Alex Elder <elder@inktank.com>
    Reviewed-by: Sage Weil <sage@inktank.com>

commit 053ab702cc2702f25a97ead087ed344b864785b7
Author: Keith Busch <keith.busch@intel.com>
Date:   Tue Apr 30 11:19:38 2013 -0600

    NVMe: Do not cancel command multiple times
    
    Cancelling an already cancelled command does not do anything, so check
    the command context before cancelling it, continuing if had already been
    cancelled so we do not log the same problem every second if a device
    stops responding.
    
    Signed-off-by: Keith Busch <keith.busch@intel.com>
    Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>

commit 1fbeeba35e1a25f1a7598e0f5d1433c18084e96a
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Fri May 17 15:08:41 2013 +0200

    block: remove refs to XD disks from documentation
    
    Commit d1a6f4f19728d6e90480e53601a90fc9f6a348ad
    "block: delete super ancient PC-XT driver for 1980's hardware"
    deleted the XD disk driver, but there are still a few
    references to it in the documentation directory. Delete
    the remnants and thus also free up the major block device
    13 for reuse.
    
    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>

commit 1287dabd345f447bbe0f7a99fc95ab89bcfc0f5d
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Mon May 13 22:29:04 2013 +0800

    NVMe: fix error return code in nvme_submit_bio_queue()
    
    nvme_submit_flush_data() might overwrite the initialisation of the
    return value with 0, so move the -ENOMEM setting close to the usage.
    
    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>

commit 5460fc03105fbed01fe27aa572d9f65bb410a61d
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon May 13 17:59:50 2013 +0300

    NVMe: check for integer overflow in nvme_map_user_pages()
    
    You need to have CAP_SYS_ADMIN to trigger this overflow but it makes the
    static checkers complain so we should fix it.  The worry is that
    "length" comes from copy_from_user() so we need to check that "length +
    offset" can't overflow.
    
    I also changed the min_t() cast to be unsigned instead of signed.  Now
    that we cap "length" to INT_MAX it doesn't make a difference, but it's a
    little easier for reviewers to know that large values aren't cast to
    negative.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>

commit 5be37bf9c17ffad0590a4044dbb110fe08066923
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon May 13 18:00:42 2013 +0300

    MAINTAINERS: update NVM EXPRESS DRIVER file list
    
    There isn't an nvme.c file any more.  It has been split into multiple
    files.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>

commit 710a143dd870cd660b5ae26bb94b6da854376e91
Author: Vishal Verma <vishal.l.verma@linux.intel.com>
Date:   Mon May 13 14:55:18 2013 -0600

    NVMe: Fix a signedness bug in nvme_trans_modesel_get_mp
    
    nvme_trans_modesel_get_mp() was defined with a unsigned return
    type, but can return signed values.
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Vishal Verma <vishal.l.verma@linux.intel.com>
    Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>

commit 76e0310c2d5a4fb62f674af7dad16f544950fc13
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date:   Tue May 14 08:32:13 2013 +0530

    NVMe: Remove redundant version.h header include
    
    version.h header inclusion is not necessary as detected by
    checkversion.pl.
    
    Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
    Acked-by: Vishal Verma <vishal.l.verma@linux.intel.com>
    Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>

commit dfbe403c5bc859620a2823ec1753369ac11a8bf6
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Fri May 17 13:12:52 2013 +0100

    spi: Move mailing list to vger
    
    Given the spam and other problems with the existing list move to a newly
    created list on vger.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit 6211dd12da609bc6893b9c3182630b494737ec4b
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Fri May 17 13:43:04 2013 +0200

    mac80211: fix direct probe auth
    
    We send direct probe to broadcast address, as some APs do not respond to
    unicast PROBE frames when unassociated. Broadcast frames are not acked,
    so we can not use that for trigger MLME state machine, but we need to
    use old timeout mechanism.
    
    This fixes authentication timed out like below:
    
    [ 1024.671974] wlan6: authenticate with 54:e6:fc:98:63:fe
    [ 1024.694125] wlan6: direct probe to 54:e6:fc:98:63:fe (try 1/3)
    [ 1024.695450] wlan6: direct probe to 54:e6:fc:98:63:fe (try 2/3)
    [ 1024.700586] wlan6: send auth to 54:e6:fc:98:63:fe (try 3/3)
    [ 1024.701441] wlan6: authentication with 54:e6:fc:98:63:fe timed out
    
    With fix, we have:
    
    [ 4524.198978] wlan6: authenticate with 54:e6:fc:98:63:fe
    [ 4524.220692] wlan6: direct probe to 54:e6:fc:98:63:fe (try 1/3)
    [ 4524.421784] wlan6: send auth to 54:e6:fc:98:63:fe (try 2/3)
    [ 4524.423272] wlan6: authenticated
    [ 4524.423811] wlan6: associate with 54:e6:fc:98:63:fe (try 1/3)
    [ 4524.427492] wlan6: RX AssocResp from 54:e6:fc:98:63:fe (capab=0x431 status=0 aid=1)
    
    Cc: stable@vger.kernel.org # 3.9
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>

commit c60855cdb976c632b3bf8922eeab8a0e78edfc04
Author: Aaron Lu <aaron.lu@intel.com>
Date:   Fri May 17 15:47:20 2013 +0800

    blkpm: avoid sleep when holding queue lock
    
    In blk_post_runtime_resume, an autosuspend request will be initiated for
    the device. Since we are holding the queue lock, we can't sleep and thus
    we should use the async version to initiate an autosuspend, i.e.
    pm_request_suspend instead of pm_runtime_suspend, which might sleep.
    
    Signed-off-by: Aaron Lu <aaron.lu@intel.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>

commit fca8c90d519dedd4f4b19901d005c243f7f0bf2e
Author: Chew, Chiau Ee <chiau.ee.chew@intel.com>
Date:   Thu May 16 15:33:29 2013 +0800

    ata_piix: add PCI IDs for Intel BayTail
    
    Adds IDE-mode SATA Device IDs for the Intel BayTrail platform.
    
    Signed-off-by: Chew, Chiau Ee <chiau.ee.chew@intel.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: stable@vger.kernel.org

commit 61bb3fea44b71dd9935227920b036fdb96936f4d
Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Date:   Tue May 14 14:37:10 2013 +0200

    drm/gma500: Add fb gtt offset to fb base
    
    Old code assumed framebuffer starts at base of stolen memory. Since the
    addition of hardware cursors, this might not be true anymore so add the
    gtt offset to the calculation.
    
    Reported-by: Holger Schurig <holgerschurig@gmail.com>
    Tested-by: Holger Schurig <holgerschurig@gmail.com>
    Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>

commit 093c959307f2f5af72b24fdc4af7d4d0263f6eea
Author: Sam Bradshaw <sbradshaw@micron.com>
Date:   Wed May 15 10:09:05 2013 +0200

    mtip32xx: Correctly handle bio->bi_idx != 0 conditions
    
    Stacking drivers may append bvecs to existing bio's, resulting
    in non-zero bi_idx conditions.  This patch counts the loops of
    bio_for_each_segment() rather than inheriting the bi_idx value
    to pass as a segment count to the hardware submission routine.
    
    Signed-off-by: Sam Bradshaw <sbradshaw@micron.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>

commit 974a51a245c2c8bece21cf2d3cbfc8261260f729
Author: Sam Bradshaw <sbradshaw@micron.com>
Date:   Wed May 15 10:04:34 2013 +0200

    mtip32xx: Fix NULL pointer dereference during module unload
    
    An open file-handle to one or more of the driver exported debugfs
    nodes causes raciness in recursive removal during module unload;
    sometimes a stale parent dentry is dereferenced when more than 1
    pci device is present.
    
    Signed-off-by: Sam Bradshaw <sbradshaw@micron.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>

commit f59fce847fc8483508b5028c24e2b1e00523dd88
Author: Kent Overstreet <koverstreet@google.com>
Date:   Wed May 15 00:11:26 2013 -0700

    bcache: Fix error handling in init code
    
    This code appears to have rotted... fix various bugs and do some
    refactoring.
    
    Signed-off-by: Kent Overstreet <koverstreet@google.com>

commit fe0a797a6b42d9ad0ed063eaef705da1eb3c8147
Author: Gabriel <g2p.code+bcache@gmail.com>
Date:   Wed Apr 24 19:51:02 2013 +0200

    bcache: clarify free/available/unused space
    
    Don't describe bcache_available_percent as free space but as
    non-writeback space.  Describe priority_stats in more detail
    and point to that for total bcache occupation.
    
    Signed-off-by: Gabriel de Perthuis <g2p.code+bcache@gmail.com>
    Signed-off-by: Kent Overstreet <koverstreet@google.com>

commit bbb1c3b5ae6c6286a5e018786be88f126d769543
Author: Paul Bolle <pebolle@tiscali.nl>
Date:   Mon May 13 10:35:21 2013 +0200

    bcache: drop "select CLOSURES"
    
    The Kconfig entry for BCACHE selects CLOSURES. But there's no Kconfig
    symbol CLOSURES. That symbol was used in development versions of bcache,
    but was removed when the closures code was no longer provided as a
    kernel library. It can safely be dropped.
    
    Signed-off-by: Paul Bolle <pebolle@tiscali.nl>

commit 867e1162068eb5632c829d453fd65d6089564f55
Author: Emil Goode <emilgoode@gmail.com>
Date:   Thu May 9 22:39:26 2013 +0200

    bcache: Fix incompatible pointer type warning
    
    The function pointer release in struct block_device_operations
    should point to functions declared as void.
    
    Sparse warnings:
    
    drivers/md/bcache/super.c:656:27: warning:
    	incorrect type in initializer (different base types)
    	drivers/md/bcache/super.c:656:27:
    	expected void ( *release )( ... )
    	drivers/md/bcache/super.c:656:27:
    	got int ( static [toplevel] *<noident> )( ... )
    
    drivers/md/bcache/super.c:656:2: warning:
    	initialization from incompatible pointer type [enabled by default]
    
    drivers/md/bcache/super.c:656:2: warning:
    	(near initialization for ‘bcache_ops.release’) [enabled by default]
    
    Signed-off-by: Emil Goode <emilgoode@gmail.com>
    Signed-off-by: Kent Overstreet <koverstreet@google.com>

commit 8c3d3d4b12bf8de8c59fe1eb1bf866a8676ca309
Author: Tejun Heo <tj@kernel.org>
Date:   Tue May 14 11:09:50 2013 -0700

    libata: update "Maintained by:" tags
    
    Jeff moved on to a greener pasture.
    
     s/Maintained by: Jeff Garzik/Maintained by: Tejun Heo/g
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Jeff Garzik <jgarzik@pobox.com>

commit de82b923012ff8790bcfff381eb3ca9069d00f49
Author: Brian Foster <bfoster@redhat.com>
Date:   Tue May 14 11:25:39 2013 -0400

    fuse: allocate for_background dio requests based on io->async state
    
    Commit 8b41e671 introduced explicit background checking for fuse_req
    structures with BUG_ON() checks for the appropriate type of request in
    in the associated send functions. Commit bcba24cc introduced the ability
    to send dio requests as background requests but does not update the
    request allocation based on the type of I/O request. As a result, a
    BUG_ON() triggers in the fuse_request_send_background() background path if
    an async I/O is sent.
    
    Allocate a request based on the async state of the fuse_io_priv to avoid
    the BUG.
    
    Signed-off-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>

commit d6cbf35dac8a3dadb9103379820c96d7c85df3d9
Author: Li Zefan <lizefan@huawei.com>
Date:   Tue May 14 19:44:20 2013 +0800

    cgroup: initialize xattr before calling d_instantiate()
    
    cgroup_create_file() calls d_instantiate(), which may decide to look
    at the xattrs on the file. Smack always does this and SELinux can be
    configured to do so.
    
    But cgroup_add_file() didn't initialize xattrs before calling
    cgroup_create_file(), which finally leads to dereferencing NULL
    dentry->d_fsdata.
    
    This bug has been there since cgroup xattr was introduced.
    
    Cc: <stable@vger.kernel.org> # 3.8.x
    Reported-by: Ivan Bulatovic <combuster@archlinux.us>
    Reported-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>

commit eccaf52fee8305d5207ff110950a82c100e459bc
Author: Lee, Chun-Yi <joeyli.kernel@gmail.com>
Date:   Thu May 2 22:07:01 2013 +0800

    x86, efi: initial the local variable of DataSize to zero
    
    That will be better initial the value of DataSize to zero for the input of
    GetVariable(), otherwise we will feed a random value. The debug log of input
    DataSize like this:
    
    ...
    [  195.915612] EFI Variables Facility v0.08 2004-May-17
    [  195.915819] efi: size: 18446744071581821342
    [  195.915969] efi:  size': 18446744071581821342
    [  195.916324] efi: size: 18446612150714306560
    [  195.916632] efi:  size': 18446612150714306560
    [  195.917159] efi: size: 18446612150714306560
    [  195.917453] efi:  size': 18446612150714306560
    ...
    
    The size' is value that was returned by BIOS.
    
    After applied this patch:
    [   82.442042] EFI Variables Facility v0.08 2004-May-17
    [   82.442202] efi: size: 0
    [   82.442360] efi:  size': 1039
    [   82.443828] efi: size: 0
    [   82.444127] efi:  size': 2616
    [   82.447057] efi: size: 0
    [   82.447356] efi:  size': 5832
    ...
    
    Found on Acer Aspire V3 BIOS, it will not return the size of data if we input a
    non-zero DataSize.
    
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>

commit 972be324fe0adaa67717407510aa067a4ae53d2d
Author: Michal Simek <michal.simek@xilinx.com>
Date:   Tue May 14 09:06:17 2013 +0200

    microblaze: Initialize temp variable to remove compilation warning
    
    Compilation warning:
    arch/microblaze/kernel/cpu/cache.c:148:2: warning:
     'temp' is used uninitialized in this function [-Wuninitialized]
    
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>

commit 286233e604d79f0c7fa04abec2180d5d89a74749
Author: Horia Geanta <horia.geanta@freescale.com>
Date:   Fri May 10 15:08:39 2013 +0300

    crypto: caam - fix inconsistent assoc dma mapping direction
    
    req->assoc is dma mapped BIDIRECTIONAL and unmapped TO_DEVICE.
    Since it is read-only for the device, use TO_DEVICE both for mapping
    and unmapping.
    
    Cc: <stable@vger.kernel.org> # 3.9, 3.8
    Signed-off-by: Horia Geanta <horia.geanta@freescale.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

commit d51df2c5d3c1f2c639708fc644ed67296bb51dc5
Author: Seiji Aguchi <seiji.aguchi@hds.com>
Date:   Fri May 10 20:45:36 2013 +0000

    efivar: fix oops in efivar_update_sysfs_entries() caused by memory reuse
    
    The loop in efivar_update_sysfs_entries() reuses the same allocation for
    entries each time it calls efivar_create_sysfs_entry(entry).  This is
    wrong because efivar_create_sysfs_entry() expects to keep the memory it
    was passed, so the caller may not free it (and may not pass the same
    memory in multiple times).  This leads to the oops below.  Fix by
    getting a new allocation each time we go around the loop.
    
    ---[ end trace ba4907d5c519d111 ]---
    BUG: unable to handle kernel NULL pointer dereference at           (null)
    IP: [<ffffffff8142f81f>] efivar_entry_find+0x14f/0x2d0
    PGD 0
    Oops: 0000 [#2] SMP
    Modules linked in: oops(OF+) ebtable_nat ebtables xt_CHECKSUM [...]
    CPU: 0 PID: 301 Comm: kworker/0:2 Tainted: GF     D    O 3.9.0+ #1
    Hardware name: LENOVO 4291EV7/4291EV7, BIOS 8DET52WW (1.22 ) 09/15/2011
    Workqueue: events efivar_update_sysfs_entries
    task: ffff8801955920c0 ti: ffff88019413e000 task.ti: ffff88019413e000
    RIP: 0010:[<ffffffff8142f81f>]  [<ffffffff8142f81f>] efivar_entry_find+0x14f/0x2d0
    RSP: 0018:ffff88019413fa48  EFLAGS: 00010006
    RAX: 0000000000000000 RBX: ffff880195d87c00 RCX: ffffffff81ab6f60
    RDX: ffff88019413fb88 RSI: 0000000000000400 RDI: ffff880196254000
    RBP: ffff88019413fbd8 R08: 0000000000000000 R09: ffff8800dad99037
    R10: ffff880195d87c00 R11: 0000000000000430 R12: ffffffff81ab6f60
    R13: fffffffffffff7d8 R14: ffff880196254000 R15: 0000000000000000
    FS:  0000000000000000(0000) GS:ffff88019e200000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000000 CR3: 0000000001a0b000 CR4: 00000000000407f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Stack:
     ffff88019413fb78 ffff88019413fb88 ffffffff81e85d60 03000000972b5c00
     ffff88019413fa29 ffffffff81e85d60 ffff88019413fbfb 0000000197087280
     00000000000000fe 0000000000000001 ffffffff81e85dd9 ffff880197087280
    Call Trace:
     [<ffffffff81254371>] ? idr_get_empty_slot+0x131/0x240
     [<ffffffff8125b6d2>] ? put_dec+0x72/0x90
     [<ffffffff81158e40>] ? cache_alloc_refill+0x170/0x2f0
     [<ffffffff81430420>] efivar_update_sysfs_entry+0x150/0x220
     [<ffffffff8103dd29>] ? efi_call2+0x9/0x70
     [<ffffffff8103d787>] ? virt_efi_get_next_variable+0x47/0x1b0
     [<ffffffff8115a8df>] ? kmem_cache_alloc_trace+0x1af/0x1c0
     [<ffffffff81430033>] efivar_init+0x2c3/0x380
     [<ffffffff814302d0>] ? efivar_delete+0xd0/0xd0
     [<ffffffff8143111f>] efivar_update_sysfs_entries+0x6f/0x90
     [<ffffffff810605f3>] process_one_work+0x183/0x490
     [<ffffffff81061780>] worker_thread+0x120/0x3a0
     [<ffffffff81061660>] ? manage_workers+0x160/0x160
     [<ffffffff8106752e>] kthread+0xce/0xe0
     [<ffffffff81067460>] ? kthread_freezable_should_stop+0x70/0x70
     [<ffffffff81543c5c>] ret_from_fork+0x7c/0xb0
     [<ffffffff81067460>] ? kthread_freezable_should_stop+0x70/0x70
    Code: 8d 55 b0 48 8d 45 a0 49 81 ed 28 08 00 00 48 89 95 78 fe [...]
    RIP  [<ffffffff8142f81f>] efivar_entry_find+0x14f/0x2d0
     RSP <ffff88019413fa48>
    CR2: 0000000000000000
    ---[ end trace ba4907d5c519d112 ]---
    
    Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Tomoki Sekiyama <tomoki.sekiyama@hds.com>
    Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>

commit 3fab70c165795431f00ddf9be8b84ddd07bd1f8f
Author: Lingzhu Xiang <lxiang@redhat.com>
Date:   Fri May 10 18:29:21 2013 +0800

    efivarfs: Never return ENOENT from firmware again
    
    Previously in 1fa7e69 efi_status_to_err() translated firmware status
    EFI_NOT_FOUND to -EIO instead of -ENOENT for efivarfs operations to
    avoid confusion. After refactoring in e14ab23, it is also used in other
    places where the translation may be unnecessary.
    
    So move the translation to efivarfs specific code. Also return EOF
    for reading zero-length files, which is what users would expect.
    
    Cc: Josh Boyer <jwboyer@redhat.com>
    Cc: Jeremy Kerr <jk@ozlabs.org>
    Cc: Lee, Chun-Yi <jlee@suse.com>
    Cc: Andy Whitcroft <apw@canonical.com>
    Signed-off-by: Lingzhu Xiang <lxiang@redhat.com>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>

commit 625cdd78d119d5848ac3c47d129bdf5f23f64120
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sat May 11 19:13:49 2013 +0300

    svcauth_gss: fix error code in use_gss_proxy()
    
    This should return zero on success and -EBUSY on error so the type
    needs to be int instead of bool.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

commit 68e850d80df934b9c9c15d8a0956512cb3b6f1fc
Author: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Date:   Thu May 9 12:46:41 2013 +0100

    regmap: debugfs: Check return value of regmap_write()
    
    Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit 3d75095a533aa3bbad652369ffde4c129781b8ec
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date:   Wed May 8 16:35:10 2013 +0530

    regulator: dbx500: Make local symbol static
    
    power_state_active_get is used only in this file. Make it static.
    While at it also move this function definition inside the
    CONFIG_REGULATOR_DEBUG macro as it is called only from within it.
    This also avoids further build warning related to unused definition.
    
    Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit 0391dc17bd5d7d6b1706d0be6472c4b352b57c05
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Apr 29 08:54:14 2013 -0300

    [media] gspca-sonixb: Adjust hstart on sn9c103 + pas202
    
    For some unknown reason we need to increase hstart by 1 on when using the
    PAS202 on the sn9c103 (versus on the sn9c102), otherwise we get the wrong
    colors, due to shifting of the bayer pattern.
    
    Reported-by: Patrizio Bassi <patrizio.bassi@gmail.com>
    Tested-by: Patrizio Bassi <patrizio.bassi@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit cd5de26288604cb8a6f7fba041cc5fb610cbff9e
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Apr 1 18:04:21 2013 -0300

    [media] pwc: Fix comment wrt lock ordering
    
    With all the changes to handle the locking in the v4l2-core rather then at
    the driver level, the order in which the 2 pwc locks need to be taken has
    changed, update the comment in the header file to correctly reflect this.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 31d6eebf7e079cfb5e98e65d5af4c6de093e076c
Author: Robert P. J. Day <rpjday@crashcourse.ca>
Date:   Thu May 2 10:19:11 2013 -0400

    regulator: Fix kernel-doc generation warnings.
    
    Add a couple kernel-doc lines to get rid of kernel-doc generation
    warnings, no functional change.
    
    Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit b358c6cf029cb67b3ed9cc367fb46f1fa3228c5b
Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date:   Tue Apr 30 10:44:51 2013 +0300

    fbdev/ps3fb: fix compile warning
    
    Commit 11bd5933abe0 ("fbdev/ps3fb: use vm_iomap_memory()") introduced
    the following warning:
    
    drivers/video/ps3fb.c: In function 'ps3fb_mmap':
    drivers/video/ps3fb.c:712:2: warning: suggest parentheses around '+' inside '<<' [-Wparentheses]
    
    Fix this by adding the parentheses.
    
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>