- 11 Jan, 2013 29 commits
-
-
Christian Lamparter authored
commit 4010fe21 upstream. This patch adds USBIDs for: - DrayTek Vigor 530 - Zoom 4410a It also adds a note about Gemtek WUBI-100GW and SparkLAN WL-682 USBID conflict [WUBI-100GW is a ISL3886+NET2280 (LM86 firmare) solution, whereas WL-682 is a ISL3887 (LM87 firmware)] device. Source: <http://www.wikidevi.com/wiki/Intersil/p54/usb/windows> Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tomasz Guszkowski authored
commit 3194b7fc upstream. Added USB ID for T-Com Sinus 154 data II. Signed-off-by:
Tomasz Guszkowski <tsg@o2.pl> Acked-by:
-
Jussi Kivilinna authored
commit 4c3de592 upstream. Incorrect use of usb_alloc_coherent memory as input buffer to usb_control_msg can cause problems in arch DMA code, for example kernel BUG at 'arch/arm/include/asm/dma-mapping.h:321' on ARM (linux-3.4). Change _usb_writeN_sync use kmalloc'd buffer instead. Signed-off-by:
Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Dan Williams authored
commit 0370acd4 upstream. Signed-off-by:
Dan Williams <dcbw@redhat.com> Acked-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David Henningsson authored
commit 6d3cd5d4 upstream. The mute LED is in this case connected to the Mic1 VREF. The machine also exposes the following string in BIOS: "HP_Mute_LED_0_A", so if more machines are coming, it probably makes sense to try to do something more generic, like for the IDT codec. BugLink: https://bugs.launchpad.net/bugs/1096789Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit 8ae5865e upstream. Fix the quirk entry for HP Pavilion dv7 in order to make the bass speaker working. Reported-and-tested-by:
Tomas Pospisek <tpo2@sourcepole.ch> Signed-off-by:
-
Takashi Iwai authored
commit b78562b1 upstream. The workaround to force VREF50 for dallas/hp model with ALC861VD was introduced in commit 8fdcb6fe, but it contained wrong pincap override bits. This patch fixes to exclude VREF80 pincap bit correctly. Signed-off-by:
-
Takashi Iwai authored
commit 6169b673 upstream. We've seen the broken HDMI *video* output on some machines with GM965, and the debugging session pointed that the culprit is the disabled audio output pins. Toggling these pins dynamically on demand caused flickering of HDMI TV. This patch changes the behavior to keep the pin ON constantly. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51421Signed-off-by:
-
Takashi Iwai authored
commit 63a077e2 upstream. Acer Aspire One 522 has the infamous digital mic unit that needs the phase inversion fixup for stereo. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=715737Signed-off-by:
-
Takashi Iwai authored
commit 6eb827d2 upstream. The runtime_idle callback is the right place to check the suspend capability, but currently we do it wrongly in the runtime_suspend callback. This leads to a kernel error message like: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11 and the runtime PM core would even repeat the attempts. Reported-and-tested-by:
Borislav Petkov <bp@alien8.de> Signed-off-by:
-
Takashi Iwai authored
commit f5f16541 upstream. The commit [88a8516a: ALSA: usbaudio: implement USB autosuspend] added the support of autopm for USB MIDI output, but it didn't take the MIDI input into account. This patch adds the following for fixing the autopm: - Manage the URB start at the first MIDI input stream open, instead of the time of instance creation - Move autopm code to the common substream_open() - Make snd_usbmidi_input_start/_stop() more robust and add the running state check Reviewd-by:
Clemens Ladisch <clemens@ladisch.de> Tested-by:
-
Takashi Iwai authored
commit 59866da9 upstream. Add a similar protection against the disconnection race and the invalid use of usb instance after disconnection, as well as we've done for the USB audio PCM. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51201Reviewd-by:
-
Hugh Dickins authored
commit f2a07f40 upstream. Recently I suggested using "mount -o remount,mpol=local /tmp" in NUMA mempolicy testing. Very nasty. Reading /proc/mounts, /proc/pid/mounts or /proc/pid/mountinfo may then corrupt one bit of kernel memory, often in a page table (causing "Bad swap" or "Bad page map" warning or "Bad pagetable" oops), sometimes in a vm_area_struct or rbnode or somewhere worse. "mpol=prefer" and "mpol=prefer:Node" are equally toxic. Recent NUMA enhancements are not to blame: this dates back to 2.6.35, when commit e17f74af "mempolicy: don't call mpol_set_nodemask() when no_context" skipped mpol_parse_str()'s call to mpol_set_nodemask(), which used to initialize v.preferred_node, or set MPOL_F_LOCAL in flags. With slab poisoning, you can then rely on mpol_to_str() to set the bit for node 0x6b6b, probably in the next page above the caller's stack. mpol_parse_str() is only called from shmem_parse_options(): no_context is always true, so call it unused for now, and remove !no_context code. Set v.nodes or v.preferred_node or MPOL_F_LOCAL as mpol_to_str() might expect. Then mpol_to_str() can ignore its no_context argument also, the mpol being appropriately initialized whether contextualized or not. Rename its no_context unused too, and let subsequent patch remove them (that's not needed for stable backporting, which would involve rejects). I don't understand why MPOL_LOCAL is described as a pseudo-policy: it's a reasonable policy which suffers from a confusing implementation in terms of MPOL_PREFERRED with MPOL_F_LOCAL. I believe this would be much more robust if MPOL_LOCAL were recognized in switch statements throughout, MPOL_F_LOCAL deleted, and MPOL_PREFERRED use the (possibly empty) nodes mask like everyone else, instead of its preferred_node variant (I presume an optimization from the days before MPOL_LOCAL). But that would take me too long to get right and fully tested. Signed-off-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Christoffer Dall authored
commit ad4b3fb7 upstream. Unfortunately with !CONFIG_PAGEFLAGS_EXTENDED, (!PageHead) is false, and (PageHead) is true, for tail pages. If this is indeed the intended behavior, which I doubt because it breaks cache cleaning on some ARM systems, then the nomenclature is highly problematic. This patch makes sure PageHead is only true for head pages and PageTail is only true for tail pages, and neither is true for non-compound pages. [ This buglet seems ancient - seems to have been introduced back in Apr 2008 in commit 6a1e7f77: "pageflags: convert to the use of new macros". And the reason nobody noticed is because the PageHead() tests are almost all about just sanity-checking, and only used on pages that are actual page heads. The fact that the old code returned true for tail pages too was thus not really noticeable. - Linus ] Signed-off-by:
Christoffer Dall <cdall@cs.columbia.edu> Acked-by:
Andrea Arcangeli <aarcange@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Will Deacon <Will.Deacon@arm.com> Cc: Steve Capper <Steve.Capper@arm.com> Cc: Christoph Lameter <cl@linux.com> Signed-off-by:
-
Sonny Rao authored
commit c8b74c2f upstream. The system uses global_dirtyable_memory() to calculate number of dirtyable pages/pages that can be allocated to the page cache. A bug causes an underflow thus making the page count look like a big unsigned number. This in turn confuses the dirty writeback throttling to aggressively write back pages as they become dirty (usually 1 page at a time). This generally only affects systems with highmem because the underflowed count gets subtracted from the global count of dirtyable memory. The problem was introduced with v3.2-4896-gab8fabd4 Fix is to ensure we don't get an underflowed total of either highmem or global dirtyable memory. Signed-off-by:
Sonny Rao <sonnyrao@chromium.org> Signed-off-by:
Puneet Kumar <puneetster@chromium.org> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Tested-by:
Damien Wyart <damien.wyart@free.fr> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Will Deacon authored
commit b92b1b89 upstream. Virtio devices may attempt to add descriptors to a virtqueue from atomic context using GFP_ATOMIC allocation. This is problematic because such allocations can fall outside of the lowmem mapping, causing virt_to_phys to report bogus physical addresses which are subsequently passed to userspace via the buffers for the virtual device. This patch masks out __GFP_HIGH and __GFP_HIGHMEM from the requested flags when allocating descriptors for a virtqueue. If an atomic allocation is requested and later fails, we will return -ENOSPC which will be handled by the driver. Signed-off-by:
Will Deacon <will.deacon@arm.com> Cc: Sasha Levin <levinsasha928@gmail.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Will Deacon authored
commit b9cdc88d upstream. When using a virtio transport, the 9p net device may pass the physical address of a kernel buffer to userspace via a scatterlist inside a virtqueue. If the kernel buffer is mapped outside of the linear mapping (e.g. highmem), then virt_to_page will return a bogus value and we will populate the scatterlist with junk. This patch uses kmap_to_page when populating the page array for a kernel buffer. Signed-off-by:
-
Will Deacon authored
commit f0263d2d upstream. Some virtio device drivers (9p) need to translate high virtual addresses to physical addresses, which are inserted into the virtqueue for processing by userspace. This patch exports the kmap_to_page symbol, so that the affected drivers can be compiled as modules. Signed-off-by:
-
Ondrej Zary authored
commit ad686524 upstream. Some MSI laptop BIOSes are broken - INT 15h code uses port 92h to enable A20 line but resume code assumes that KBC was used. The laptop will not resume from S3 otherwise but powers off after a while and then powers on again stuck with a blank screen. Fix it by enabling A20 using KBC in i8042_platform_init for x86. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=12878Signed-off-by:
Ondrej Zary <linux@rainbow-software.org> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Rafael J. Wysocki <rjw@sisk.pl> Link: http://lkml.kernel.org/r/201212112218.06551.linux@rainbow-software.orgSigned-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Will Deacon authored
commit 304ef4e8 upstream. To allow debuggers to unwind through signal frames, we create a fake stack unwinding prologue containing the link register and frame pointer of the interrupted context. The signal frame is then offset by 16 bytes to make room for the two saved registers which are pushed onto the frame of the *interrupted* context, rather than placed directly above the signal stack. This doesn't work when an alternative signal stack is set up for a SEGV handler, which is raised in response to RLIMIT_STACK being reached. In this case, we try to push the unwinding prologue onto the full stack and subsequently take a fault which we fail to resolve, causing setup_return to return -EFAULT and handle_signal to force_sigsegv on the current task. This patch fixes the problem by including the unwinding prologue as part of the rt_sigframe definition, which is populated during setup_sigframe, ensuring that it always ends up on the signal stack. Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Catalin Marinas authored
commit 33eaa58f upstream. The AArch64 Linux port relies on the mm code to wrprotect clean ptes. This however is not the case with newly created ptes and PAGE_SHARED(_EXEC) is writable but !dirty. Signed-off-by:
-
Kees Cook authored
commit b66c5984 upstream. If a series of scripts are executed, each triggering module loading via unprintable bytes in the script header, kernel stack contents can leak into the command line. Normally execution of binfmt_script and binfmt_misc happens recursively. However, when modules are enabled, and unprintable bytes exist in the bprm->buf, execution will restart after attempting to load matching binfmt modules. Unfortunately, the logic in binfmt_script and binfmt_misc does not expect to get restarted. They leave bprm->interp pointing to their local stack. This means on restart bprm->interp is left pointing into unused stack memory which can then be copied into the userspace argv areas. After additional study, it seems that both recursion and restart remains the desirable way to handle exec with scripts, misc, and modules. As such, we need to protect the changes to interp. This changes the logic to require allocation for any changes to the bprm->interp. To avoid adding a new kmalloc to every exec, the default value is left as-is. Only when passing through binfmt_script or binfmt_misc does an allocation take place. For a proof of concept, see DoTest.sh from: http://www.halfdog.net/Security/2012/LinuxKernelBinfmtScriptStackDataDisclosure/Signed-off-by:
Kees Cook <keescook@chromium.org> Cc: halfdog <me@halfdog.net> Cc: P J P <ppandit@redhat.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Robin Holt authored
commit 891348ca upstream. We found a user code which was raising a divide-by-zero trap. That trap would lead to XPC connections between system-partitions being torn down due to the die_chain notifier callouts it received. This also revealed a different issue where multiple callers into xpc_die_deactivate() would all attempt to do the disconnect in parallel which would sometimes lock up but often overwhelm the console on very large machines as each would print at least one line of output at the end of the deactivate. I reviewed all the users of the die_chain notifier and changed the code to ignore the notifier callouts for reasons which will not actually lead to a system to continue on to call die(). [akpm@linux-foundation.org: fix ia64] Signed-off-by:
Robin Holt <holt@sgi.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Alan Cox authored
commit cdc87c5a upstream. TEST_ALPHA() is broken and always returns 0. [akpm@linux-foundation.org: return false for '@' as well, per Bjorn] Signed-off-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Felix Fietkau authored
commit 78f18df4 upstream. ieee80211_free_txskb() needs to be used instead of dev_kfree_skb_any for tx packets passed to the driver from mac80211 Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Larry Finger authored
commit 576d28a7 upstream. Recent versions of udev cause synchronous firmware loading from the probe routine to fail because the request to user space times out. The original fix for b43legacy (commit a3ea2c76) moved the firmware load from the probe routine to a work queue, but it still used synchronous firmware loading. This method is OK when b43legacy is built as a module; however, it fails when the driver is compiled into the kernel. This version changes the code to load the initial firmware file using request_firmware_nowait(). A completion event is used to hold the work queue until that file is available. The remaining firmware files are read synchronously. Signed-off-by:
-
Chuansheng Liu authored
commit bd9eb7fb upstream. There is one race that both request_firmware() with the same firmware name. The race scenerio is as below: CPU1 CPU2 request_firmware() --> _request_firmware_load() return err another request_firmware() is coming --> _request_firmware_cleanup is called --> _request_firmware_prepare --> release_firmware ---> fw_lookup_and_allocate_buf --> spin_lock(&fwc->lock) ... __fw_lookup_buf() return true fw_free_buf() will be called --> ... kref_put --> decrease the refcount to 0 kref_get(&tmp->ref) ==> it will trigger warning due to refcount == 0 __fw_free_buf() --> ... spin_unlock(&fwc->lock) spin_lock(&fwc->lock) list_del(&buf->list) spin_unlock(&fwc->lock) kfree(buf) After that, the freed buf will be used. The key race is decreasing refcount to 0 and list_del is not protected together by fwc->lock, and it is possible another thread try to get it between refcount==0 and list_del. Fix it here to protect it together. Acked-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
liu chuansheng <chuansheng.liu@intel.com> Signed-off-by:
-
Chuansheng Liu authored
commit ce2fcbd9 upstream. There is a race as below when calling request_firmware(): CPU1 CPU2 write 0 > loading mutex_lock(&fw_lock) ... set_bit FW_STATUS_DONE class_timeout is coming set_bit FW_STATUS_ABORT complete_all &completion ... mutex_unlock(&fw_lock) In this time, the bit FW_STATUS_DONE and FW_STATUS_ABORT are set, and request_firmware() will return failure due to condition in _request_firmware_load(): if (!buf->size || test_bit(FW_STATUS_ABORT, &buf->status)) retval = -ENOENT; But from the above scenerio, it should be a successful requesting. So we need judge if the bit FW_STATUS_DONE is already set before calling fw_load_abort() in timeout function. As Ming's proposal, we need change the timer into sched_work to benefit from using &fw_lock mutex also. Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit f8e8f97c ] Dmitry Kravkov reported packet drops for GRE packets since GRO support was added. There is a race in gro_cell_poll() because we call napi_complete() without any synchronization with a concurrent gro_cells_receive() Once bug was triggered, we queued packets but did not schedule NAPI poll. We can fix this issue using the spinlock protected the napi_skbs queue, as we have to hold it to perform skb dequeue anyway. As we open-code skb_dequeue(), we no longer need to mask IRQS, as both producer and consumer run under BH context. Bug added in commit c9e6bc64 (net: add gro_cells infrastructure) Reported-by:
Dmitry Kravkov <dmitry@broadcom.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Tested-by:
-
- 17 Dec, 2012 11 commits
-
-
Greg Kroah-Hartman authored
-
Kevin McKinney authored
commit 4f29ef05 upstream. This patch adds two new products and modifies the device id table to include them. In addition, product of 0xbccd - BCM_USB_PRODUCT_ID_SM250 is removed because Beceem, ZTE, Sprint use this id for block devices. Reported-by:
Muhammad Minhazul Haque <mdminhazulhaque@gmail.com> Signed-off-by:
Kevin McKinney <klmckinney1@gmail.com> Signed-off-by:
-
Eric Dumazet authored
commit 878d7439 upstream. Commit 29c00b4a (rcu: Add event-tracing for RCU callback invocation) added a regression in rcu_do_batch() Under stress, RCU is supposed to allow to process all items in queue, instead of a batch of 10 items (blimit), but an integer overflow makes the effective limit being 1. So, unless there is frequent idle periods (during which RCU ignores batch limits), RCU can be forced into a state where it cannot keep up with the callback-generation rate, eventually resulting in OOM. This commit therefore converts a few variables in rcu_do_batch() from int to long to fix this problem, along with the module parameters controlling the batch limits. Signed-off-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by:
-
Alan Stern authored
commit 2656a9ab upstream. This patch (as1632b) fixes a bug in ehci-hcd. The USB core uses urb->hcpriv to determine whether or not an URB is active; host controller drivers are supposed to set this pointer to a non-NULL value when an URB is queued. However ehci-hcd sets it to NULL for isochronous URBs, which defeats the check in usbcore. In itself this isn't a big deal. But people have recently found that certain sequences of actions will cause the snd-usb-audio driver to reuse URBs without waiting for them to complete. In the absence of proper checking by usbcore, the URBs get added to their endpoint list twice. This leads to list corruption and a system freeze. The patch makes ehci-hcd assign a meaningful value to urb->hcpriv for isochronous URBs. Improving robustness always helps. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Artem S. Tashkinov <t.artem@lycos.com> Reported-by:
Christof Meerwald <cmeerw@cmeerw.org> Signed-off-by:
-
Zheng Liu authored
commit 12f8f74b upstream. Recently I build perf and get a build error on builtin-test.c. The error is as following: $ make CC perf.o CC builtin-test.o cc1: warnings being treated as errors builtin-test.c: In function ‘sched__get_first_possible_cpu’: builtin-test.c:977: warning: implicit declaration of function ‘CPU_ALLOC’ builtin-test.c:977: warning: nested extern declaration of ‘CPU_ALLOC’ builtin-test.c:977: warning: assignment makes pointer from integer without a cast builtin-test.c:978: warning: implicit declaration of function ‘CPU_ALLOC_SIZE’ builtin-test.c:978: warning: nested extern declaration of ‘CPU_ALLOC_SIZE’ builtin-test.c:979: warning: implicit declaration of function ‘CPU_ZERO_S’ builtin-test.c:979: warning: nested extern declaration of ‘CPU_ZERO_S’ builtin-test.c:982: warning: implicit declaration of function ‘CPU_FREE’ builtin-test.c:982: warning: nested extern declaration of ‘CPU_FREE’ builtin-test.c:992: warning: implicit declaration of function ‘CPU_ISSET_S’ builtin-test.c:992: warning: nested extern declaration of ‘CPU_ISSET_S’ builtin-test.c:998: warning: implicit declaration of function ‘CPU_CLR_S’ builtin-test.c:998: warning: nested extern declaration of ‘CPU_CLR_S’ make: *** [builtin-test.o] Error 1 This problem is introduced in 3e7c439a. CPU_ALLOC and related macros are missing in sched__get_first_possible_cpu function. In 54489c18, commiter mentioned that CPU_ALLOC has been removed. So CPU_ALLOC calls in this function are removed to let perf to be built. Signed-off-by:
Vinson Lee <vlee@twitter.com> Signed-off-by:
Zheng Liu <wenqing.lz@taobao.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Vinson Lee <vlee@twitter.com> Cc: Zheng Liu <wenqing.lz@taobao.com> Link: http://lkml.kernel.org/r/1352422726-31114-1-git-send-email-vlee@twitter.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Dan Williams authored
commit ba2d8ce9 upstream. Some devices (ex Nokia C7) simply don't respond at all when data is sent to some of their USB interfaces. The data gets stuck in the TTYs queue and sits there until close(2), which them blocks because closing_wait defaults to 30 seconds (even though the fd is O_NONBLOCK). This is rarely desired. Implement the standard mechanism to adjust closing_wait and let applications handle it how they want to. See also 02303f73 for usb_wwan.c. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Tested-by:
Aleksander Morgado <aleksander@gnu.org> Signed-off-by:
-
Steven Rostedt authored
commit 9366c1ba upstream. The function rb_check_pages() was added to make sure the ring buffer's pages were sane. This check is done when the ring buffer size is modified as well as when the iterator is released (closing the "trace" file), as that was considered a non fast path and a good place to do a sanity check. The problem is that the check does not have any locks around it. If one process were to read the trace file, and another were to read the raw binary file, the check could happen while the reader is reading the file. The issues with this is that the check requires to clear the HEAD page before doing the full check and it restores it afterward. But readers require the HEAD page to exist before it can read the buffer, otherwise it gives a nasty warning and disables the buffer. By adding the reader lock around the check, this keeps the race from happening. Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Steven Rostedt authored
commit 54f7be5b upstream. The function rb_set_head_page() searches the list of ring buffer pages for a the page that has the HEAD page flag set. If it does not find it, it will do a WARN_ON(), disable the ring buffer and return NULL, as this should never happen. But if this bug happens to happen, not all callers of this function can handle a NULL pointer being returned from it. That needs to be fixed. Signed-off-by:
-
Dan Carpenter authored
commit 70f77b3f upstream. There is a typo here where '&' is used instead of '|' and it turns the statement into a noop. The original code is equivalent to: iter->flags &= ~((1 << 2) & (1 << 4)); Link: http://lkml.kernel.org/r/20120609161027.GD6488@elgon.mountainSigned-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Sarah Sharp authored
commit bba18e33 upstream. Ali reports that plugging a device into the Fresco Logic xHCI host with PCI device ID 1400 produces an IRQ error: do_IRQ: 3.176 No irq handler for vector (irq -1) Other early Fresco Logic host revisions don't support MSI, even though their PCI config space claims they do. Extend the quirk to disabling MSI to this chipset revision. Also enable the short transfer quirk, since it's likely this revision also has that quirk, and it should be harmless to enable. 04:00.0 0c03: 1b73:1400 (rev 01) (prog-if 30 [XHCI]) Subsystem: 1d5c:1000 Physical Slot: 3 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 51 Region 0: Memory at d4600000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000feeff00c Data: 41b1 Capabilities: [80] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <2us, L1 <32us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Kernel driver in use: xhci_hcd This patch should be backported to stable kernels as old as 2.6.36, that contain the commit f5182b41 "xhci: Disable MSI for some Fresco Logic hosts." Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by:
A Sh <smr.ash1991@gmail.com> Tested-by:
-
Alan Stern authored
commit 50ce5c06 upstream. This patch (as1636) is a partial workaround for a hardware bug affecting OHCI controllers by NVIDIA at least, maybe others too. When the controller retires a Transfer Descriptor, it is supposed to add the TD onto the Done Queue. But sometimes this doesn't happen, with the result that ohci-hcd never realizes the corresponding transfer has finished. Symptoms can vary; a typical result is that USB audio stops working after a while. The patch works around the problem by recognizing that TDs are always processed in order. Therefore, if a later TD is found on the Done Queue than all the earlier TDs for the same endpoint must be finished as well. Unfortunately this won't solve the problem in cases where the missing TD is the last one in the endpoint's queue. A complete fix would require a signficant amount of change to the driver. Signed-off-by:
-
