Skip to content
Commits on Mar 15, 2015
  1. @ssvb

    arm: Use top 4 bits of machine id for u-boot compatibility check

    ssvb committed Feb 20, 2015
    This implements ensuring compatibility between the mainline u-boot and the legacy
    sunxi-3.4 kernels, proposed earlier at
        http://lists.denx.de/pipermail/u-boot/2014-October/191777.html
    
    Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
  2. @jwrdegoede @ssvb

    sun5i: clock: Do not change PLL6 frequency

    jwrdegoede committed with ssvb Feb 21, 2015
    Keep the PLL6 frequency as it is set by the bootloader, it may be used as
    parent for the mbus, and if we change it we may be changing the mbus frequency,
    all peripherals (*) using pll6 are already capable of dealing with it running at
    a different frequency.
    
    *) Only mmc uses pll6 as a parent by default
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
  3. @jwrdegoede @ssvb

    sunxi: axp152: Keep VDD-INT/VDD-DLL at bootloader set value

    jwrdegoede committed with ssvb Feb 21, 2015
    Some fex files contain wrong values, causing stability issues.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Commits on Nov 24, 2014
  1. @jwrdegoede @ssvb

    sunxi: nand: Fix nand clk calculation

    jwrdegoede committed with ssvb Oct 15, 2014
    Before the u-boot dram cleanup u-boot would always set PLL5 factor m to
    2 (reg value 1) and div p to 1, and get_cmu_clk in the nand code
    would calculate the pll5p clk like this:
    
    clk = 24 * factor_n * factor_k / div_p / factor_m;
    
    aka:
    
    clk = 24 * factor_n * factor_k / (div_p * factor_m);
    
    This is wrong however, factor_m is not used to calculate pll5p, and div_p is
    not a straight divider, but it divides by 2 ^ div_p. Since with the m == 2 and
    p == 1 settings used before the dram cleanup, this happend to do the right
    thing in the form of dividing by 2. But with the new dram code div_p is 0,
    and then the old get_cmu_clk code fails with a divide by 0 error.
    
    This commit fixes this, by changing the clk calculation to the correct form of:
    
    clk = (24 * factor_n * factor_k) >> div_p;
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
  2. @jwrdegoede @ssvb

    sunxi: axp152: Keep DRAM / Vddr at bootloader set value

    jwrdegoede committed with ssvb Oct 15, 2014
    Some fex files contain wrong values, causing stability issues.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Commits on Nov 23, 2014
  1. @rellla @ssvb

    arm:sunxi:defconfig: Enable CONFIG_FHANDLE required for systemd >= 209

    rellla committed with ssvb Nov 10, 2014
    Signed-off-by: Andreas Baierl<ichgeh@imkreisrum.de>
    Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
  2. @rellla @ssvb

    arm:sunxi:defconfig: Re-Enable symmetric multiprocessing for sun7i

    rellla committed with ssvb Nov 10, 2014
    Signed-off-by: Andreas Baierl<ichgeh@imkreisrum.de>
    Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Commits on Oct 23, 2014
  1. @rellla @amery
  2. @rellla @amery

    Sunxi SATA driver should be built in-kernel in order to allow root fi…

    rellla committed with amery Oct 13, 2014
    …lesystems on sata per default.
  3. @tisdall @amery

    remove sunxi_nand from sun7i_defconfig

    tisdall committed with amery Oct 23, 2014
    There's a known issue with sunxi_nand on A20 devices where
    it will try to read a NAND chip and then make modifications
    such that it becomes corrupted.  Until this situation is
    resolved, the module should _not_ be included in the defconfig
    for A20 devices.
    
    Signed-off-by: Tim Tisdall <tisdall@gmail.com>
    Acked-by: Luc Verhaegen <libv@skynet.be>
Commits on Oct 22, 2014
  1. @amery

    SUNXI-GMAC driver logs every vlan frame...

    Eddy Beaupre committed with amery Jun 4, 2014
    Hello!
    
    Don't know if i'm the only one who's using vlan with sunxi-gmac, but the
    current driver is terribly spammy for the logs, it log every single vlan
    frame at the INFO level. Personally i don't think that information is
    useful at all but if you want to keep it enable, it should log it at the
    DEBUG level instead. So i propose this little simple modification to the
    source (or better, remove the whole line.):
  2. @amery

    Revert "driver-core: cpu: export total_cpus to fix CPU_FREQ_STAT=m bu…

    amery committed Oct 22, 2014
    …ild"
    
    This reverts commit 83af551.
  3. @amery
  4. @amery
  5. @amery

    Merge tag 'v3.4.104' into reference-3.4

    amery committed Oct 22, 2014
    This is the 3.4.104 stable release
Commits on Oct 21, 2014
  1. cpufreq: Avoid using global variable total_cpus

    Ruchi Kandoi committed Oct 21, 2014
    The change is to compile on kernels where cpufreq stats are compiled as
    a module (CONFIG_CPU_FREQ_STAT=m), because total_cpus is not exported for
    module use.
    
    Reported-By: Emilio López <elopez93@gmail.com>
    Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
    Change-Id: I4f3c74f0fac5e8d9449655b26bf3b407b0fe4290
Commits on Oct 16, 2014
  1. power: Avoids bogus error messages for the suspend aborts.

    Ruchi Kandoi committed Oct 14, 2014
    Avoids printing bogus error message "tasks refusing to freeze", in cases
    where pending wakeup source caused the suspend abort.
    
    Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
    Change-Id: I913ad290f501b31cd536d039834c8d24c6f16928
Commits on Oct 14, 2014
  1. @ssvb

    sunxi: Calculate PLL5P clock divisors for G2D, ACE and DEBE

    ssvb committed Oct 4, 2014
    When PLL5P is used as a parent clock for some of the peripherals,
    the current code just selects some hardcoded divisors. This happens
    to work, but only under assumption that the PLL5P clock speed is
    somewhere between 360MHz and 480MHz (the typical DRAM clock speeds).
    
    However with some tweaks for the DRAM parameters, it is possible to
    clock DRAM up to 600MHz and more on some devices:
    
        http://lists.denx.de/pipermail/u-boot/2014-July/183981.html
    
    And this introduces concerns about the hardcoded divisors in the
    kernel, which may cause some peripherals to operate at abnormally
    high clock speeds if the PLL5 clock speed is too fast (PLL5 is used
    for clocking DRAM).
    
    Moreover, it makes sense to avoid pre-dividing PLL5P and make it run
    even faster than DRAM. This provides better granularity of the clock
    speed selection for MBUS, G2D and everything else that is using PLL5P
    as the parent clock. but running PLL5P faster means that the hardcoded
    divisors become even more inappropriate.
    
    This patch improves the clock divisors selection for G2D, ACE and
    DEBE to insure that they can work correctly with any PLL5P clock
    speed.
    
    Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
    Acked-by: Hans de Goede <hdegoede@redhat.com>
  2. @ssvb

    sunxi: axp209: Protect dcdc3 voltage from modification

    ssvb committed Sep 19, 2014
    The dcdc3 voltage is expected to be set by the bootloader and the right
    voltage depends on the DRAM settings (higher clock speed needs more
    voltage). Allowing to use the 'dcdc3_vol' parameter from the FEX file
    only introduces an unnecessary fragile dependency between the settings
    in u-boot and the settings in FEX. So now we ignore this parameter in
    FEX and keep the original dcdc3 voltage set by the bootloader.
    
    The dmesg log now looks like this:
    
    [    2.212941] axp20_ldo1: 1300 mV
    [    2.221370] axp20_ldo2: 1800 <--> 3300 mV at 3000 mV
    [    2.231662] axp20_ldo3: 700 <--> 3500 mV at 2800 mV
    [    2.241747] axp20_ldo4: 1250 <--> 3300 mV at 2800 mV
    [    2.251906] axp20_buck2: 700 <--> 2275 mV at 1400 mV
    [    2.263430] somebody is trying to set dcdc3 range to (1300000, 1300000) uV
    [    2.275327] but we keep dcdc3 = 1250000 uV from the bootloader
    [    2.285406] axp20_buck3: 700 <--> 3500 mV at 1250 mV
    [    2.295299] axp20_ldoio0: 1800 <--> 3300 mV at 2800 mV
    
    Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
    Acked-by: Hans de Goede <hdegoede@redhat.com>
  3. @paulkocialkowski @ssvb

    sun4i-keyboard: 250Hz LRADC sampling

    paulkocialkowski committed with ssvb Oct 8, 2014
    This is required to have fast enough key presses with sun4i-keyboard
    (actually used on sun4i, sun5i and sun7i) on CWM recovery, an Android
    initramfs that allows easy flashing of the devices. With any lower
    sampling rate, close key presses are not distinguished and reported
    as one long press.
    
    Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
    Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Commits on Oct 2, 2014
  1. @dvdhrm

    HID: input: generic hidinput_input_event handler

    dvdhrm committed with Michael Wright Jul 15, 2013
    The hidinput_input_event() callback converts input events written from
    userspace into HID reports and sends them to the device. We currently
    implement this in every HID transport driver, even though most of them do
    the same.
    
    This provides a generic hidinput_input_event() implementation which is
    mostly copied from usbhid. It uses a delayed worker to allow multiple LED
    events to be collected into a single output event.
    We use the custom ->request() transport driver callback to allow drivers
    to adjust the outgoing report and handle the request asynchronously. If no
    custom ->request() callback is available, we fall back to the generic raw
    output report handler (which is synchronous).
    
    Drivers can still provide custom hidinput_input_event() handlers (see
    logitech-dj) if the generic implementation doesn't fit their needs.
    
    Conflicts:
    	drivers/hid/hid-input.c
    
    Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Michael Wright <michaelwr@google.com>
    Change-Id: I89ccc3f675b3e8a7bbd812a6ebe12588d737cfd6
Commits on Sep 25, 2014
  1. @lizf-os

    Linux 3.4.104

    lizf-os committed Sep 25, 2014
  2. @lizf-os

    alpha: add io{read,write}{16,32}be functions

    Michael Cree committed with lizf-os Nov 30, 2011
    commit 25534eb upstream.
    
    These functions are used in some PCI drivers with big-endian
    MMIO space.
    
    Admittedly it is almost certain that no one this side of the
    Moon would use such a card in an Alpha but it does get us
    closer to being able to build allyesconfig or allmodconfig,
    and it enables the Debian default generic config to build.
    
    Tested-by: Raúl Porcel <armin76@gentoo.org>
    Signed-off-by: Michael Cree <mcree@orcon.net.nz>
    Signed-off-by: Matt Turner <mattst88@gmail.com>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  3. @jankara @lizf-os

    ext2: Fix fs corruption in ext2_get_xip_mem()

    jankara committed with lizf-os Nov 5, 2013
    commit 7ba3ec5 upstream.
    
    Commit 8e3dffc "Ext2: mark inode dirty after the function
    dquot_free_block_nodirty is called" unveiled a bug in __ext2_get_block()
    called from ext2_get_xip_mem(). That function called ext2_get_block()
    mistakenly asking it to map 0 blocks while 1 was intended. Before the
    above mentioned commit things worked out fine by luck but after that commit
    we started returning that we allocated 0 blocks while we in fact
    allocated 1 block and thus allocation was looping until all blocks in
    the filesystem were exhausted.
    
    Fix the problem by properly asking for one block and also add assertion
    in ext2_get_blocks() to catch similar problems.
    
    Reported-and-tested-by: Andiry Xu <andiry.xu@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Cc: Wang Nan <wangnan0@huawei.com>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  4. @lizf-os

    alpha: Fix fall-out from disintegrating asm/system.h

    Michael Cree committed with lizf-os Aug 19, 2012
    commit d1b5153 upstream.
    
    Commit ec22120 ("Disintegrate asm/system.h for Alpha") removed
    asm/system.h however arch/alpha/oprofile/common.c requires definitions
    that were shifted from asm/system.h to asm/special_insns.h.  Include
    that.
    
    Signed-off-by: Michael Cree <mcree@orcon.net.nz>
    Acked-by: Matt Turner <mattst88@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  5. @gxt @lizf-os

    UniCore32-bugfix: fix mismatch return value of __xchg_bad_pointer

    gxt committed with lizf-os Jun 14, 2012
    commit 195d457 upstream.
    
    When disintegrate system.h, I left an error in asm/cmpxchg.h, which
    will result in following error:
    
    arch/unicore32/include/asm/cmpxchg.h: In function '__xchg':
    arch/unicore32/include/asm/cmpxchg.h:38: error: void value not ignored as it ought to be
    
    Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  6. @gxt @lizf-os

    UniCore32-bugfix: Remove definitions in asm/bug.h to solve difference…

    gxt committed with lizf-os Jun 14, 2012
    … between native and cross compiler
    
    commit 10e1e99 upstream.
    
    For kernel/bound.c being compiled by native compiler, it will generate following errors in gcc 4.4.3:
      CC      kernel/bounds.s
    In file included from include/linux/bug.h:4,
                     from include/linux/page-flags.h:9,
                     from kernel/bounds.c:9:
    arch/unicore32/include/asm/bug.h:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
    arch/unicore32/include/asm/bug.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
    
    So, we moved definitions in asm/bug.h to arch/unicore32/kernel/setup.h to solve the problem.
    
    Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  7. @fengguang @lizf-os

    unicore32: select generic atomic64_t support

    fengguang committed with lizf-os Oct 4, 2012
    commit 82e54a6 upstream.
    
    It's required for the core fs/namespace.c and many other basic features.
    
    Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
    Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  8. @paulgortmaker @lizf-os

    8250_pci: fix warnings in backport of Broadcom TruManage support

    paulgortmaker committed with lizf-os Aug 25, 2014
    commit 7400ce7 (v3.4.92-76-g7400ce7ee959)
    was a backport of commit ebebd49 upstream
    ("8250/16?50: Add support for Broadcom TruManage redirected serial port")
    
    However, in the context of 3.4.x kernels, the pci setup code was
    expecting a struct uart_port and not a struct uart_8250_port, leading to
    the following concerning warnings:
    
    drivers/tty/serial/8250/8250_pci.c: In function ‘pci_brcm_trumanage_setup’:
    drivers/tty/serial/8250/8250_pci.c:1086:2: warning: passing argument 3 of ‘pci_default_setup’ from incompatible pointer type [enabled by default]
      int ret = pci_default_setup(priv, board, port, idx);
      ^
    drivers/tty/serial/8250/8250_pci.c:1036:1: note: expected ‘struct uart_port *’ but argument is of type ‘struct uart_8250_port *’
     pci_default_setup(struct serial_private *priv,
     ^
    drivers/tty/serial/8250/8250_pci.c: At top level:
    drivers/tty/serial/8250/8250_pci.c:1746:3: warning: initialization from incompatible pointer type [enabled by default]
       .setup  = pci_brcm_trumanage_setup,
       ^
    drivers/tty/serial/8250/8250_pci.c:1746:3: warning: (near initialization for ‘pci_serial_quirks[56].setup’) [enabled by default]
    
    I'd also expect the initialization to not function correctly, and
    perhaps dereference random garbage due to this.  Since the uart_port
    is a field within the uart_8250_port, the adaptation to fix these
    warnings is a straightforward removal of a layer of indirection.
    
    Cc: Stephen Hurd <shurd@broadcom.com>
    Cc: Michael Chan <mchan@broadcom.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Cc: Rui Xiang <rui.xiang@huawei.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  9. @lizf-os

    slab/mempolicy: always use local policy from interrupt context

    Andi Kleen committed with lizf-os Jun 9, 2012
    commit e7b691b upstream.
    
    slab_node() could access current->mempolicy from interrupt context.
    However there's a race condition during exit where the mempolicy
    is first freed and then the pointer zeroed.
    
    Using this from interrupts seems bogus anyways. The interrupt
    will interrupt a random process and therefore get a random
    mempolicy. Many times, this will be idle's, which noone can change.
    
    Just disable this here and always use local for slab
    from interrupts. I also cleaned up the callers of slab_node a bit
    which always passed the same argument.
    
    I believe the original mempolicy code did that in fact,
    so it's likely a regression.
    
    v2: send version with correct logic
    v3: simplify. fix typo.
    Reported-by: Arun Sharma <asharma@fb.com>
    Cc: penberg@kernel.org
    Cc: cl@linux.com
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    [tdmackey@twitter.com: Rework control flow based on feedback from
    cl@linux.com, fix logic, and cleanup current task_struct reference]
    Acked-by: David Rientjes <rientjes@google.com>
    Acked-by: Christoph Lameter <cl@linux.com>
    Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Signed-off-by: David Mackey <tdmackey@twitter.com>
    Signed-off-by: Pekka Enberg <penberg@kernel.org>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  10. @skristiansson @lizf-os

    openrisc: add missing header inclusion

    skristiansson committed with lizf-os Feb 26, 2013
    commit 160d837 upstream.
    
    Prevents build issue with updated toolchain
    
    Reported-by: Jack Thomasson <jkt@moonlitsw.com>
    Tested-by: Christian Svensson <blue@cmd.nu>
    Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
    Signed-off-by: Jonas Bonn <jonas@southpole.se>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  11. @ralfbaechle @lizf-os

    MIPS: Fix accessing to per-cpu data when flushing the cache

    ralfbaechle committed with lizf-os Sep 17, 2013
    commit ff52205 upstream.
    
    This fixes the following issue
    
    BUG: using smp_processor_id() in preemptible [00000000] code: kjournald/1761
    caller is blast_dcache32+0x30/0x254
    Call Trace:
    [<8047f02c>] dump_stack+0x8/0x34
    [<802e7e40>] debug_smp_processor_id+0xe0/0xf0
    [<80114d94>] blast_dcache32+0x30/0x254
    [<80118484>] r4k_dma_cache_wback_inv+0x200/0x288
    [<80110ff0>] mips_dma_map_sg+0x108/0x180
    [<80355098>] ide_dma_prepare+0xf0/0x1b8
    [<8034eaa4>] do_rw_taskfile+0x1e8/0x33c
    [<8035951c>] ide_do_rw_disk+0x298/0x3e4
    [<8034a3c4>] do_ide_request+0x2e0/0x704
    [<802bb0dc>] __blk_run_queue+0x44/0x64
    [<802be000>] queue_unplugged.isra.36+0x1c/0x54
    [<802beb94>] blk_flush_plug_list+0x18c/0x24c
    [<802bec6c>] blk_finish_plug+0x18/0x48
    [<8026554c>] journal_commit_transaction+0x3b8/0x151c
    [<80269648>] kjournald+0xec/0x238
    [<8014ac00>] kthread+0xb8/0xc0
    [<8010268c>] ret_from_kernel_thread+0x14/0x1c
    
    Caches in most systems are identical - but not always, so we can't avoid
    the use of smp_call_function() by just looking at the boot CPU's data,
    have to fiddle with preemption instead.
    
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Cc: Markos Chandras <markos.chandras@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/5835
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  12. @ffainelli @lizf-os

    MIPS: perf: Fix build error caused by unused counters_per_cpu_to_total()

    ffainelli committed with lizf-os Jul 19, 2012
    commit 6c37c95 upstream.
    
    cc1: warnings being treated as errors
    arch/mips/kernel/perf_event_mipsxx.c:166: error: 'counters_per_cpu_to_total' defined but not used
    make[2]: *** [arch/mips/kernel/perf_event_mipsxx.o] Error 1
    make[2]: *** Waiting for unfinished jobs....
    
    It was first introduced by 8209156 [MIPS:
    perf: Add support for 64-bit perf counters.] in 3.2.
    
    Signed-off-by: Florian Fainelli <florian@openwrt.org>
    Cc: linux-mips@linux-mips.org
    Cc: david.daney@cavium.com
    Patchwork: https://patchwork.linux-mips.org/patch/3357/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  13. @jhovold @lizf-os

    USB: serial: fix potential heap buffer overflow

    jhovold committed with lizf-os Aug 27, 2014
    commit 5654699 upstream.
    
    Make sure to verify the number of ports requested by subdriver to avoid
    writing beyond the end of fixed-size array in interface data.
    
    The current usb-serial implementation is limited to eight ports per
    interface but failed to verify that the number of ports requested by a
    subdriver (which could have been determined from device descriptors) did
    not exceed this limit.
    
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [lizf: Backported to 3.4: s/ddev/\&interface->dev/]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  14. @jhovold @lizf-os

    USB: serial: fix potential stack buffer overflow

    jhovold committed with lizf-os Aug 27, 2014
    commit d979e9f upstream.
    
    Make sure to verify the maximum number of endpoints per type to avoid
    writing beyond the end of a stack-allocated array.
    
    The current usb-serial implementation is limited to eight ports per
    interface but failed to verify that the number of endpoints of a certain
    type reported by a device did not exceed this limit.
    
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [lizf: Backported to 3.4: adjust context]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
Something went wrong with that request. Please try again.