Permalink
Switch branches/tags
Nothing to show
Commits on Nov 17, 2014
Commits on Nov 3, 2014
  1. Merge tag 'v3.4.104' into ax8008

    jaapdejong committed Nov 3, 2014
    This is the 3.4.104 stable release
    
    # gpg: Signature made Thu 25 Sep 2014 05:49:19 AM CEST using DSA key ID 1D54CED3
    # gpg: Can't check signature: public key not found
Commits on Oct 30, 2014
  1. Merge pull request #1 from nedap/develop-jdj-fixes-for-new-hardware

    jaapdejong committed Oct 30, 2014
    Develop jdj fixes for new hardware
Commits on Oct 27, 2014
  1. support mmc revisions <= 6

    jaapdejong committed Oct 27, 2014
Commits on Sep 25, 2014
  1. Linux 3.4.104

    lizf-os committed Sep 25, 2014
  2. alpha: add io{read,write}{16,32}be functions

    Michael Cree authored and lizf-os committed Nov 30, 2011
    commit 25534eb7707821b796fd84f7115367e02f36aa60 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. ext2: Fix fs corruption in ext2_get_xip_mem()

    jankara authored and lizf-os committed Nov 5, 2013
    commit 7ba3ec5749ddb61f79f7be17b5fd7720eebc52de upstream.
    
    Commit 8e3dffc651cb "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. alpha: Fix fall-out from disintegrating asm/system.h

    Michael Cree authored and lizf-os committed Aug 19, 2012
    commit d1b5153f3ec83789b71d64efaf2a880c8fe6358e 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. UniCore32-bugfix: fix mismatch return value of __xchg_bad_pointer

    gxt authored and lizf-os committed Jun 14, 2012
    commit 195d4577d1d7ab1f0398b3190547c116b56f435f 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. UniCore32-bugfix: Remove definitions in asm/bug.h to solve difference…

    gxt authored and lizf-os committed Jun 14, 2012
    … between native and cross compiler
    
    commit 10e1e99e55378a65529c48753703c069aebce7af 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. unicore32: select generic atomic64_t support

    fengguang authored and lizf-os committed Oct 5, 2012
    commit 82e54a6aaf8aec971fb16afa3a4404e238a1b98b 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. 8250_pci: fix warnings in backport of Broadcom TruManage support

    paulgortmaker authored and lizf-os committed Aug 25, 2014
    commit 7400ce7 (v3.4.92-76-g7400ce7ee959)
    was a backport of commit ebebd49a8eab5e9aa1b1f8f1614ccc3c2120f886 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. slab/mempolicy: always use local policy from interrupt context

    Andi Kleen authored and lizf-os committed Jun 9, 2012
    commit e7b691b085fda913830e5280ae6f724b2a63c824 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. openrisc: add missing header inclusion

    skristiansson authored and lizf-os committed Feb 26, 2013
    commit 160d83781a32e94a1e337efd6722939001e62398 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. MIPS: Fix accessing to per-cpu data when flushing the cache

    ralfbaechle authored and lizf-os committed Sep 17, 2013
    commit ff522058bd717506b2fa066fa564657f2b86477e 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. MIPS: perf: Fix build error caused by unused counters_per_cpu_to_total()

    ffainelli authored and lizf-os committed Jul 19, 2012
    commit 6c37c9580409af7dc664bb6af0a85d540d63aeea 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. USB: serial: fix potential heap buffer overflow

    jhovold authored and lizf-os committed Aug 27, 2014
    commit 5654699fb38512bdbfc0f892ce54fce75bdc2bab 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. USB: serial: fix potential stack buffer overflow

    jhovold authored and lizf-os committed Aug 27, 2014
    commit d979e9f9ecab04c1ecca741370e30a8a498893f5 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>
  15. ARM: 8129/1: errata: work around Cortex-A15 erratum 830321 using dumm…

    Mark Rutland authored and lizf-os committed Aug 15, 2014
    …y strex
    
    commit 2c32c65e3726c773760038910be30cce1b4d4149 upstream.
    
    On revisions of Cortex-A15 prior to r3p3, a CLREX instruction at PL1 may
    falsely trigger a watchpoint exception, leading to potential data aborts
    during exception return and/or livelock.
    
    This patch resolves the issue in the following ways:
    
      - Replacing our uses of CLREX with a dummy STREX sequence instead (as
        we did for v6 CPUs).
    
      - Removing the clrex code from v7_exit_coherency_flush and derivatives,
        since this only exists as a minor performance improvement when
        non-cached exclusives are in use (Linux doesn't use these).
    
    Benchmarking on a variety of ARM cores revealed no measurable
    performance difference with this change applied, so the change is
    performed unconditionally and no new Kconfig entry is added.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    [lizf: Backported to 3.4:
     - Drop changes to arch/arm/include/asm/cacheflush.h and
       arch/arm/mach-exynos/mcpm-exynos.c]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  16. ARM: 8128/1: abort: don't clear the exclusive monitors

    Mark Rutland authored and lizf-os committed Aug 15, 2014
    commit 85868313177700d20644263a782351262d2aff84 upstream.
    
    The ARMv6 and ARMv7 early abort handlers clear the exclusive monitors
    upon entry to the kernel, but this is redundant:
    
      - We clear the monitors on every exception return since commit
        200b812 ("Clear the exclusive monitor when returning from an
        exception"), so this is not necessary to ensure the monitors are
        cleared before returning from a fault handler.
    
      - Any dummy STREX will target a temporary scratch area in memory, and
        may succeed or fail without corrupting useful data. Its status value
        will not be used.
    
      - Any other STREX in the kernel must be preceded by an LDREX, which
        will initialise the monitors consistently and will not depend on the
        earlier state of the monitors.
    
    Therefore we have no reason to care about the initial state of the
    exclusive monitors when a data abort is taken, and clearing the monitors
    prior to exception return (as we already do) is sufficient.
    
    This patch removes the redundant clearing of the exclusive monitors from
    the early abort handlers.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  17. HID: picolcd: sanity check report size in raw_event() callback

    Jiri Kosina authored and lizf-os committed Aug 27, 2014
    commit 844817e47eef14141cf59b8d5ac08dd11c0a9189 upstream.
    
    The report passed to us from transport driver could potentially be
    arbitrarily large, therefore we better sanity-check it so that raw_data
    that we hold in picolcd_pending structure are always kept within proper
    bounds.
    
    Reported-by: Steven Vittitoe <scvitti@google.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [lizf: Backported to 3.4: adjust filename]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  18. HID: magicmouse: sanity check report size in raw_event() callback

    Jiri Kosina authored and lizf-os committed Aug 27, 2014
    commit c54def7bd64d7c0b6993336abcffb8444795bf38 upstream.
    
    The report passed to us from transport driver could potentially be
    arbitrarily large, therefore we better sanity-check it so that
    magicmouse_emit_touch() gets only valid values of raw_id.
    
    Reported-by: Steven Vittitoe <scvitti@google.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  19. NFSv4: Fix problems with close in the presence of a delegation

    trondmypd authored and lizf-os committed Aug 26, 2014
    commit aee7af356e151494d5014f57b33460b162f181b5 upstream.
    
    In the presence of delegations, we can no longer assume that the
    state->n_rdwr, state->n_rdonly, state->n_wronly reflect the open
    stateid share mode, and so we need to calculate the initial value
    for calldata->arg.fmode using the state->flags.
    
    Reported-by: James Drews <drews@engr.wisc.edu>
    Fixes: 88069f7 (NFSv41: Fix a potential state leakage when...)
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    [lizf: Backport to 3.4: adjust context]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  20. USB: sisusb: add device id for Magic Control USB video

    shemminger authored and lizf-os committed Aug 26, 2014
    commit 5b6b80aeb21091ed3030b9b6aae597d81326f1aa upstream.
    
    I have a j5 create (JUA210) USB 2 video device and adding it device id
    to SIS USB video gets it to work.
    
    Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  21. HID: logitech-dj: prevent false errors to be shown

    Benjamin Tissoires authored and lizf-os committed Aug 22, 2014
    commit 5abfe85c1d4694d5d4bbd13ecc166262b937adf0 upstream.
    
    Commit "HID: logitech: perform bounds checking on device_id early
    enough" unfortunately leaks some errors to dmesg which are not real
    ones:
    - if the report is not a DJ one, then there is not point in checking
      the device_id
    - the receiver (index 0) can also receive some notifications which
      can be safely ignored given the current implementation
    
    Move out the test regarding the report_id and also discards
    printing errors when the receiver got notified.
    
    Fixes: ad3e14d7c5268c2e24477c6ef54bbdf88add5d36
    
    Reported-and-tested-by: Markus Trippelsdorf <markus@trippelsdorf.de>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  22. USB: whiteheat: Added bounds checking for bulk command response

    James Forshaw authored and lizf-os committed Aug 23, 2014
    commit 6817ae225cd650fb1c3295d769298c38b1eba818 upstream.
    
    This patch fixes a potential security issue in the whiteheat USB driver
    which might allow a local attacker to cause kernel memory corrpution. This
    is due to an unchecked memcpy into a fixed size buffer (of 64 bytes). On
    EHCI and XHCI busses it's possible to craft responses greater than 64
    bytes leading a buffer overflow.
    
    Signed-off-by: James Forshaw <forshaw@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [lizf: Backported to 3.4: adjust context]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  23. usb: xhci: amd chipset also needs short TX quirk

    huangrui authored and lizf-os committed Aug 19, 2014
    commit 2597fe99bb0259387111d0431691f5daac84f5a5 upstream.
    
    AMD xHC also needs short tx quirk after tested on most of chipset
    generations. That's because there is the same incorrect behavior like
    Fresco Logic host. Please see below message with on USB webcam
    attached on xHC host:
    
    [  139.262944] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
    [  139.266934] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
    [  139.270913] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
    [  139.274937] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
    [  139.278914] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
    [  139.282936] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
    [  139.286915] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
    [  139.290938] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
    [  139.294913] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
    [  139.298917] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
    
    Reported-by: Arindam Nath <arindam.nath@amd.com>
    Tested-by: Shriraj-Rai P <shriraj-rai.p@amd.com>
    Signed-off-by: Huang Rui <ray.huang@amd.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [lizf: Backported to 3.4: adjust context]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  24. xhci: Treat not finding the event_seg on COMP_STOP the same as COMP_S…

    jwrdegoede authored and lizf-os committed Aug 19, 2014
    …TOP_INVAL
    
    commit 9a54886342e227433aebc9d374f8ae268a836475 upstream.
    
    When using a Renesas uPD720231 chipset usb-3 uas to sata bridge with a 120G
    Crucial M500 ssd, model string: Crucial_ CT120M500SSD1, together with a
    the integrated Intel xhci controller on a Haswell laptop:
    
    00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04)
    
    The following error gets logged to dmesg:
    
    xhci error: Transfer event TRB DMA ptr not part of current TD
    
    Treating COMP_STOP the same as COMP_STOP_INVAL when no event_seg gets found
    fixes this.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  25. USB: ftdi_sio: Added PID for new ekey device

    bartmanus authored and lizf-os committed Aug 16, 2014
    commit 646907f5bfb0782c731ae9ff6fb63471a3566132 upstream.
    
    Added support to the ftdi_sio driver for ekey Converter USB which
    uses an FT232BM chip.
    
    Signed-off-by: Jaša Bartelj <jasa.bartelj@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    [lizf: Backported to 3.4: adjust context]
    Signed-off-by: Zefan Li <lizefan@huawei.com>