Linux 3.0.73

commit e7e5d6bd5c282272501531bb362245a48f64e163
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Apr 12 09:18:32 2013 -0700

    Linux 3.0.73

commit 5c077afc739a302afb26fe3cea445c4974ab1457
Author: Tim Gardner <tim.gardner@canonical.com>
Date:   Mon Feb 18 12:56:28 2013 -0700

    rt2x00: rt2x00pci_regbusy_read() - only print register access failure once

    commit 83589b30f1e1dc9898986293c9336b8ce1705dec upstream.

    BugLink: http://bugs.launchpad.net/bugs/1128840

    It appears that when this register read fails it never recovers, so
    I think there is no need to repeat the same error message ad infinitum.

    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Cc: Ivo van Doorn <IvDoorn@gmail.com>
    Cc: Gertjan van Wingerde <gwingerde@gmail.com>
    Cc: Helmut Schaa <helmut.schaa@googlemail.com>
    Cc: "John W. Linville" <linville@tuxdriver.com>
    Cc: linux-wireless@vger.kernel.org
    Cc: users@rt2x00.serialmonkey.com
    Cc: netdev@vger.kernel.org
    Cc: stable@vger.kernel.org
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ea64c49dc38aa94552c3fa1d81b0901bbfbccd1
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Apr 10 15:21:39 2013 -0700

    Revert "mwifiex: cancel cmd timer and free curr_cmd in shutdown process

    revert commit b9f1f48ce20a1b923429c216669d03b5a900a8cf which is commit
    084c7189acb3f969c855536166042e27f5dd703f upstream.

    It shouldn't have been applied to the 3.0-stable tree.

    Reported-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Marco Cesarano <marco@marvell.com>
    Reported-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab82a79e3cb3c52e635620a65a016eddbf9db144
Author: Dave Hansen <dave@linux.vnet.ibm.com>
Date:   Wed Jan 30 16:56:16 2013 -0800

    x86-32, mm: Rip out x86_32 NUMA remapping code

    commit f03574f2d5b2d6229dcdf2d322848065f72953c7 upstream.

    This code was an optimization for 32-bit NUMA systems.

    It has probably been the cause of a number of subtle bugs over
    the years, although the conditions to excite them would have
    been hard to trigger.  Essentially, we remap part of the kernel
    linear mapping area, and then sometimes part of that area gets
    freed back in to the bootmem allocator.  If those pages get
    used by kernel data structures (say mem_map[] or a dentry),
    there's no big deal.  But, if anyone ever tried to use the
    linear mapping for these pages _and_ cared about their physical
    address, bad things happen.

    For instance, say you passed __GFP_ZERO to the page allocator
    and then happened to get handed one of these pages, it zero the
    remapped page, but it would make a pte to the _old_ page.
    There are probably a hundred other ways that it could screw
    with things.

    We don't need to hang on to performance optimizations for
    these old boxes any more.  All my 32-bit NUMA systems are long
    dead and buried, and I probably had access to more than most
    people.

    This code is causing real things to break today:

    	https://lkml.org/lkml/2013/1/9/376

    I looked in to actually fixing this, but it requires surgery
    to way too much brittle code, as well as stuff like
    per_cpu_ptr_to_phys().

    [ hpa: Cc: this for -stable, since it is a memory corruption issue.
      However, an alternative is to simply mark NUMA as depends BROKEN
      rather than EXPERIMENTAL in the X86_32 subclause... ]

    Link: http://lkml.kernel.org/r/20130131005616.1C79F411@kernel.stglabs.ibm.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05fc9336dbfe557067f472074c123d9474393f02
Author: Jan Stancek <jstancek@redhat.com>
Date:   Mon Apr 8 13:00:02 2013 -0700

    mm: prevent mmap_cache race in find_vma()

    commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c upstream.

    find_vma() can be called by multiple threads with read lock
    held on mm->mmap_sem and any of them can update mm->mmap_cache.
    Prevent compiler from re-fetching mm->mmap_cache, because other
    readers could update it in the meantime:

                   thread 1                             thread 2
                                            |
      find_vma()                            |  find_vma()
        struct vm_area_struct *vma = NULL;  |
        vma = mm->mmap_cache;               |
        if (!(vma && vma->vm_end > addr     |
            && vma->vm_start <= addr)) {    |
                                            |    mm->mmap_cache = vma;
        return vma;                         |
         ^^ compiler may optimize this      |
            local variable out and re-read  |
            mm->mmap_cache                  |

    This issue can be reproduced with gcc-4.8.0-1 on s390x by running
    mallocstress testcase from LTP, which triggers:

      kernel BUG at mm/rmap.c:1088!
        Call Trace:
         ([<000003d100c57000>] 0x3d100c57000)
          [<000000000023a1c0>] do_wp_page+0x2fc/0xa88
          [<000000000023baae>] handle_pte_fault+0x41a/0xac8
          [<000000000023d832>] handle_mm_fault+0x17a/0x268
          [<000000000060507a>] do_protection_exception+0x1e2/0x394
          [<0000000000603a04>] pgm_check_handler+0x138/0x13c
          [<000003fffcf1f07a>] 0x3fffcf1f07a
        Last Breaking-Event-Address:
          [<000000000024755e>] page_add_new_anon_rmap+0xc2/0x168

    Thanks to Jakub Jelinek for his insight on gcc and helping to
    track this down.

    Signed-off-by: Jan Stancek <jstancek@redhat.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: adjust context, indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3ca0ec19faf219a76242f15eab08cc51ad13831
Author: Richard Guy Briggs <rbriggs@redhat.com>
Date:   Tue Feb 12 19:39:44 2013 +0000

    thermal: return an error on failure to register thermal class

    commit da28d966f6aa942ae836d09729f76a1647932309 upstream.

    The return code from the registration of the thermal class is used to
    unallocate resources, but this failure isn't passed back to the caller of
    thermal_init.  Return this failure back to the caller.

    This bug was introduced in changeset 4cb18728 which overwrote the return code
    when the variable was re-used to catch the return code of the registration of
    the genetlink thermal socket family.

    Signed-off-by: Richard Guy Briggs <rbriggs@redhat.com>
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Cc: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04607dffcda852ff2d98192144733a41d0643022
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Apr 3 21:53:57 2013 +0200

    block: avoid using uninitialized value in from queue_var_store

    commit c678ef5286ddb5cf70384ad5af286b0afc9b73e1 upstream.

    As found by gcc-4.8, the QUEUE_SYSFS_BIT_FNS macro creates functions
    that use a value generated by queue_var_store independent of whether
    that value was set or not.

    block/blk-sysfs.c: In function 'queue_store_nonrot':
    block/blk-sysfs.c:244:385: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized]

    Unlike most other such warnings, this one is not a false positive,
    writing any non-number string into the sysfs files indeed has
    an undefined result, rather than returning an error.

    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ef51ab472a28f8c8206512ad02dd0b9bf1d0c61
Author: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Date:   Thu Mar 28 21:54:03 2013 +0200

    crypto: gcm - fix assumption that assoc has one segment

    commit d3dde52209ab571e4e2ec26c66f85ad1355f7475 upstream.

    rfc4543(gcm(*)) code for GMAC assumes that assoc scatterlist always contains
    only one segment and only makes use of this first segment. However ipsec passes
    assoc with three segments when using 'extended sequence number' thus in this
    case rfc4543(gcm(*)) fails to function correctly. Patch fixes this issue.

    Reported-by: Chaoxing Lin <Chaoxing.Lin@ultra-3eti.com>
    Tested-by: Chaoxing Lin <Chaoxing.Lin@ultra-3eti.com>
    Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17229e4f8ef6a7cb514d7d4d67197cd6a8b06eca
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Apr 9 10:48:33 2013 -0700

    spinlocks and preemption points need to be at least compiler barriers

    commit 386afc91144b36b42117b0092893f15bc8798a80 upstream.

    In UP and non-preempt respectively, the spinlocks and preemption
    disable/enable points are stubbed out entirely, because there is no
    regular code that can ever hit the kind of concurrency they are meant to
    protect against.

    However, while there is no regular code that can cause scheduling, we
    _do_ end up having some exceptional (literally!) code that can do so,
    and that we need to make sure does not ever get moved into the critical
    region by the compiler.

    In particular, get_user() and put_user() is generally implemented as
    inline asm statements (even if the inline asm may then make a call
    instruction to call out-of-line), and can obviously cause a page fault
    and IO as a result.  If that inline asm has been scheduled into the
    middle of a preemption-safe (or spinlock-protected) code region, we
    obviously lose.

    Now, admittedly this is *very* unlikely to actually ever happen, and
    we've not seen examples of actual bugs related to this.  But partly
    exactly because it's so hard to trigger and the resulting bug is so
    subtle, we should be extra careful to get this right.

    So make sure that even when preemption is disabled, and we don't have to
    generate any actual *code* to explicitly tell the system that we are in
    a preemption-disabled region, we need to at least tell the compiler not
    to move things around the critical region.

    This patch grew out of the same discussion that caused commits
    79e5f05edcbf ("ARC: Add implicit compiler barrier to raw_local_irq*
    functions") and 3e2e0d2c222b ("tile: comment assumption about
    __insn_mtspr for <asm/irqflags.h>") to come about.

    Note for stable: use discretion when/if applying this.  As mentioned,
    this bug may never have actually bitten anybody, and gcc may never have
    done the required code motion for it to possibly ever trigger in
    practice.

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Steven Rostedt <srostedt@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a7adba6f5b486e00f03d88d185a25ec4c1b6175
Author: Michael Wolf <mjw@linux.vnet.ibm.com>
Date:   Fri Apr 5 10:41:40 2013 +0000

    powerpc: pSeries_lpar_hpte_remove fails from Adjunct partition being performed before the ANDCOND test

    commit 9fb2640159f9d4f5a2a9d60e490482d4cbecafdb upstream.

    Some versions of pHyp will perform the adjunct partition test before the
    ANDCOND test.  The result of this is that H_RESOURCE can be returned and
    cause the BUG_ON condition to occur. The HPTE is not removed.  So add a
    check for H_RESOURCE, it is ok if this HPTE is not removed as
    pSeries_lpar_hpte_remove is looking for an HPTE to remove and not a
    specific HPTE to remove.  So it is ok to just move on to the next slot
    and try again.

    Signed-off-by: Michael Wolf <mjw@linux.vnet.ibm.com>
    Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d510800edaf1e0e48f8778114682a1586fc9aaa9
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date:   Tue Mar 26 17:53:03 2013 +0100

    ftrace: Consistently restore trace function on sysctl enabling

    commit 5000c418840b309251c5887f0b56503aae30f84c upstream.

    If we reenable ftrace via syctl, we currently set ftrace_trace_function
    based on the previous simplistic algorithm. This is inconsistent with
    what update_ftrace_function does. So better call that helper instead.

    Link: http://lkml.kernel.org/r/5151D26F.1070702@siemens.com

    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48631b65db235d68acbde42a1cb6804afbfd283e
Author: Jay Estabrook <jay.estabrook@gmail.com>
Date:   Sun Apr 7 21:36:09 2013 +1200

    alpha: Add irongate_io to PCI bus resources

    commit aa8b4be3ac049c8b1df2a87e4d1d902ccfc1f7a9 upstream.

    Fixes a NULL pointer dereference at boot on UP1500.

    Reviewed-and-Tested-by: Matt Turner <mattst88@gmail.com>
    Signed-off-by: Jay Estabrook <jay.estabrook@gmail.com>
    Signed-off-by: Matt Turner <mattst88@gmail.com>
    Signed-off-by: Michael Cree <mcree@orcon.net.nz>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c55f9197cfc3d968c64ed4e7762214c04090426e
Author: Shan Hai <shan.hai@windriver.com>
Date:   Mon Mar 18 10:30:44 2013 +0800

    libata: Set max sector to 65535 for Slimtype DVD A DS8A8SH drive

    commit a32450e127fc6e5ca6d958ceb3cfea4d30a00846 upstream.

    The Slimtype DVD A  DS8A8SH drive locks up when max sector is smaller than
    65535, and the blow backtrace is observed on locking up:

    INFO: task flush-8:32:1130 blocked for more than 120 seconds.
    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    flush-8:32      D ffffffff8180cf60     0  1130      2 0x00000000
     ffff880273aef618 0000000000000046 0000000000000005 ffff880273aee000
     ffff880273aee000 ffff880273aeffd8 ffff880273aee010 ffff880273aee000
     ffff880273aeffd8 ffff880273aee000 ffff88026e842ea0 ffff880274a10000
    Call Trace:
     [<ffffffff8168fc2d>] schedule+0x5d/0x70
     [<ffffffff8168fccc>] io_schedule+0x8c/0xd0
     [<ffffffff81324461>] get_request+0x731/0x7d0
     [<ffffffff8133dc60>] ? cfq_allow_merge+0x50/0x90
     [<ffffffff81083aa0>] ? wake_up_bit+0x40/0x40
     [<ffffffff81320443>] ? bio_attempt_back_merge+0x33/0x110
     [<ffffffff813248ea>] blk_queue_bio+0x23a/0x3f0
     [<ffffffff81322176>] generic_make_request+0xc6/0x120
     [<ffffffff81322308>] submit_bio+0x138/0x160
     [<ffffffff811d7596>] ? bio_alloc_bioset+0x96/0x120
     [<ffffffff811d1f61>] submit_bh+0x1f1/0x220
     [<ffffffff811d48b8>] __block_write_full_page+0x228/0x340
     [<ffffffff811d3650>] ? attach_nobh_buffers+0xc0/0xc0
     [<ffffffff811d8960>] ? I_BDEV+0x10/0x10
     [<ffffffff811d8960>] ? I_BDEV+0x10/0x10
     [<ffffffff811d4ab6>] block_write_full_page_endio+0xe6/0x100
     [<ffffffff811d4ae5>] block_write_full_page+0x15/0x20
     [<ffffffff811d9268>] blkdev_writepage+0x18/0x20
     [<ffffffff81142527>] __writepage+0x17/0x40
     [<ffffffff811438ba>] write_cache_pages+0x34a/0x4a0
     [<ffffffff81142510>] ? set_page_dirty+0x70/0x70
     [<ffffffff81143a61>] generic_writepages+0x51/0x80
     [<ffffffff81143ab0>] do_writepages+0x20/0x50
     [<ffffffff811c9ed6>] __writeback_single_inode+0xa6/0x2b0
     [<ffffffff811ca861>] writeback_sb_inodes+0x311/0x4d0
     [<ffffffff811caaa6>] __writeback_inodes_wb+0x86/0xd0
     [<ffffffff811cad43>] wb_writeback+0x1a3/0x330
     [<ffffffff816916cf>] ? _raw_spin_lock_irqsave+0x3f/0x50
     [<ffffffff811b8362>] ? get_nr_inodes+0x52/0x70
     [<ffffffff811cb0ac>] wb_do_writeback+0x1dc/0x260
     [<ffffffff8168dd34>] ? schedule_timeout+0x204/0x240
     [<ffffffff811cb232>] bdi_writeback_thread+0x102/0x2b0
     [<ffffffff811cb130>] ? wb_do_writeback+0x260/0x260
     [<ffffffff81083550>] kthread+0xc0/0xd0
     [<ffffffff81083490>] ? kthread_worker_fn+0x1b0/0x1b0
     [<ffffffff8169a3ec>] ret_from_fork+0x7c/0xb0
     [<ffffffff81083490>] ? kthread_worker_fn+0x1b0/0x1b0

     The above trace was triggered by
       "dd if=/dev/zero of=/dev/sr0 bs=2048 count=32768"

     It was previously working by accident, since another bug introduced
     by 4dce8ba94c7 (libata: Use 'bool' return value for ata_id_XXX) caused
     all drives to use maxsect=65535.

    Signed-off-by: Shan Hai <shan.hai@windriver.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 878315cbf04dde3f93bf796f1835ae8d07604ba7
Author: Shan Hai <shan.hai@windriver.com>
Date:   Mon Mar 18 10:30:43 2013 +0800

    libata: Use integer return value for atapi_command_packet_set

    commit d8668fcb0b257d9fdcfbe5c172a99b8d85e1cd82 upstream.

    The function returns type of ATAPI drives so it should return integer value.
    The commit 4dce8ba94c7 (libata: Use 'bool' return value for ata_id_XXX) since
    v2.6.39 changed the type of return value from int to bool, the change would
    cause all of the ATAPI class drives to be treated as TYPE_TAPE and the
    max_sectors of the drives to be set to 65535 because of the commit
    f8d8e5799b7(libata: increase 128 KB / cmd limit for ATAPI tape drives), for the
    function would return true for all ATAPI class drives and the TYPE_TAPE is
    defined as 0x01.

    Signed-off-by: Shan Hai <shan.hai@windriver.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a58e3e13f5f8c03a88195c45771b2ef3a7a53f75
Author: Todd Poynor <toddpoynor@google.com>
Date:   Fri Apr 5 16:38:53 2013 -0700

    ext4: fixup 64-bit divides in 3.0-stable backport of upstream fix

    Replace C division operators with div64_u64 for divides introduced in:
    commit 503f4bdcc078e7abee273a85ce322de81b18a224
    ext4: use atomic64_t for the per-flexbg free_clusters count

    Specific to the 3.0-stable backport of the upstream patch.

    Signed-off-by: Todd Poynor <toddpoynor@google.com>
    Reviewed-by: "Theodore Ts'o" <tytso@mit.edu>
    Cc: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
    Cc: Lukas Czerner <lczerner@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba2ae99cf346c740e64241f77c5d54eca55f0d91
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Thu Apr 4 11:47:13 2013 +0200

    ALSA: hda - fix typo in proc output

    commit aeb3a97222832e5457c4b72d72235098ce4bfe8d upstream.

    Rename "Digitial In" to "Digital In". This function is only used for
    proc output, so should not cause any problems to change.

    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e4010695a44d36c2f5cd5bbe0724d32f31c1590
Author: Mengdong Lin <mengdong.lin@intel.com>
Date:   Thu Mar 28 05:20:22 2013 -0400

    ALSA: hda - bug fix on return value when getting HDMI ELD info

    commit 2ef5692efad330b67a234e2c49edad38538751e7 upstream.

    In function snd_hdmi_get_eld(), the variable 'ret' should be initialized to 0.
    Otherwise it will be returned uninitialized as non-zero after ELD info is got
    successfully. Thus hdmi_present_sense() will always assume ELD info is invalid
    by mistake, and /proc file system cannot show the proper ELD info.

    Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
    Acked-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06cc39593b0a9fed3f8ecbed6d30d8c3368ccbe0
Author: Jan Kara <jack@suse.cz>
Date:   Fri Mar 29 15:39:16 2013 +0100

    reiserfs: Fix warning and inode leak when deleting inode with xattrs

    commit 35e5cbc0af240778e61113286c019837e06aeec6 upstream.

    After commit 21d8a15a (lookup_one_len: don't accept . and ..) reiserfs
    started failing to delete xattrs from inode. This was due to a buggy
    test for '.' and '..' in fill_with_dentries() which resulted in passing
    '.' and '..' entries to lookup_one_len() in some cases. That returned
    error and so we failed to iterate over all xattrs of and inode.

    Fix the test in fill_with_dentries() along the lines of the one in
    lookup_one_len().

    Reported-by: Pawel Zawora <pzawora@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ae92500b8c8b67f02071c38ee0d54701e036e59
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Thu Mar 14 10:49:23 2013 +0200

    UBIFS: make space fixup work in the remount case

    commit 67e753ca41782913d805ff4a8a2b0f60b26b7915 upstream.

    The UBIFS space fixup is a useful feature which allows to fixup the "broken"
    flash space at the time of the first mount. The "broken" space is usually the
    result of using a "dumb" industrial flasher which is not able to skip empty
    NAND pages and just writes all 0xFFs to the empty space, which has grave
    side-effects for UBIFS when UBIFS trise to write useful data to those empty
    pages.

    The fix-up feature works roughly like this:
    1. mkfs.ubifs sets the fixup flag in UBIFS superblock when creating the image
       (see -F option)
    2. when the file-system is mounted for the first time, UBIFS notices the fixup
       flag and re-writes the entire media atomically, which may take really a lot
       of time.
    3. UBIFS clears the fixup flag in the superblock.

    This works fine when the file system is mounted R/W for the very first time.
    But it did not really work in the case when we first mount the file-system R/O,
    and then re-mount R/W. The reason was that we started the fixup procedure too
    late, which we cannot really do because we have to fixup the space before it
    starts being used.

    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Reported-by: Mark Jackson <mpfj-list@mimc.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d20371d4ba4674524ad5f017f16ae68d63bf15a
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Fri Mar 15 11:26:15 2013 +0100

    ASoC: dma-sh7760: Fix compile error

    commit 417a1178f1bf3cdc606376b3ded3a22489fbb3eb upstream.

    The dma-sh7760 currently fails with the following compile error:
    	sound/soc/sh/dma-sh7760.c:346:2: error: unknown field 'pcm_ops' specified in initializer
    	sound/soc/sh/dma-sh7760.c:346:2: warning: initialization from incompatible pointer type
    	sound/soc/sh/dma-sh7760.c:347:2: error: unknown field 'pcm_new' specified in initializer
    	sound/soc/sh/dma-sh7760.c:347:2: warning: initialization makes integer from pointer without a cast
    	sound/soc/sh/dma-sh7760.c:348:2: error: unknown field 'pcm_free' specified in initializer
    	sound/soc/sh/dma-sh7760.c:348:2: warning: initialization from incompatible pointer type
    	sound/soc/sh/dma-sh7760.c: In function 'sh7760_soc_platform_probe':
    	sound/soc/sh/dma-sh7760.c:353:2: warning: passing argument 2 of 'snd_soc_register_platform' from incompatible pointer type
    	include/sound/soc.h:368:5: note: expected 'struct snd_soc_platform_driver *' but argument is of type 'struct snd_soc_platform *'

    This is due the misnaming of the snd_soc_platform_driver type name and 'ops'
    field. The issue was introduced in commit f0fba2a("ASoC: multi-component - ASoC
    Multi-Component Support").

    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>