- 25 8月, 2014 1 次提交
-
-
由 James Forshaw 提交于
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: NJames Forshaw <forshaw@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 21 8月, 2014 1 次提交
-
-
由 Philippe Reynes 提交于
The variable $(PWD) is useless, and it may break the compilation. For example, it breaks the kernel compilation when it's done with buildroot : /home/trem/Codes/armadeus/armadeus/buildroot/output/host/usr/bin/ccache /home/trem/Codes/armadeus/armadeus/buildroot/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -Wp,-MD,drivers/usb/gadget/legacy/.hid.o.d -nostdinc -isystem /home/trem/Codes/armadeus/armadeus/buildroot/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.7.3/include -I./arch/arm/include -Iarch/arm/include/generated -Iinclude -I./arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I./include/uapi -Iinclude/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-dwarf2-cfi-asm -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp -funwind-tables -marm -D__LINUX_ARM_ARCH__=5 -march=armv5te -mtune=arm9tdmi -msoft-float -Uarm -fno-delete-null-pointer-checks -O2 --param=allow-store-data-races=0 -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -fno-var-tracking-assignments -g -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -DCC_HAVE_ASM_GOTO -I/home/trem/Codes/armadeus/armadeus/buildroot/drivers/usb/gadget/ -I/home/trem/Codes/armadeus/armadeus/buildroot/drivers/usb/gadget/udc/ -I/home/trem/Codes/armadeus/armadeus/buildroot/drivers/usb/gadget/function/ -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(hid)" -D"KBUILD_MODNAME=KBUILD_STR(g_hid)" -c -o drivers/usb/gadget/legacy/hid.o drivers/usb/gadget/legacy/hid.c drivers/usb/gadget/epautoconf.c:23:26: erreur fatale: gadget_chips.h : Aucun fichier ou dossier de ce type This compilation line include : ..../buildroot/driver/usb/gadget but the real path is : ..../buildroot/output/build/linux-3.17-rc1/driver/usb/gadget Signed-off-by: NPhilippe Reynes <tremyfr@gmail.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
- 20 8月, 2014 9 次提交
-
-
由 Bryan O'Donoghue 提交于
This patch is to enable the USB gadget device for Intel Quark X1000 Signed-off-by: NBryan O'Donoghue <bryan.odonoghue@intel.com> Signed-off-by: NBing Niu <bing.niu@intel.com> Signed-off-by: NAlvin (Weike) Chen <alvin.chen@intel.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Michael Grzeschik 提交于
If the pending buffers in the queue could not be pushed to the udc endpoint we have to cancel the uvc_queue. Otherwise the gadget will get stuck on this error. This patch calls uvc_queue_cancel if usb_ep_queue failed. Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NMichael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Peter Chen 提交于
linux-2.6/drivers/usb/wusbcore/wa-xfer.c: In function 'wa_buf_in_cb': linux-2.6/drivers/usb/wusbcore/wa-xfer.c:2590: warning: 'rpipe' may be used uninitialized in this function Signed-off-by: NPeter Chen <peter.chen@freescale.com> Suggested-by: NThomas Pugliese <thomas.pugliese@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Chen 提交于
linux-2.6/drivers/usb/core/hub.c: In function 'usb_disconnect': linux-2.6/drivers/usb/core/hub.c:2110: warning: 'hub' may be used uninitialized in this function linux-2.6/drivers/usb/core/hub.c:2111: warning: 'port1' may be used uninitialized in this function Signed-off-by: NPeter Chen <peter.chen@freescale.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Chen 提交于
linux-2.6/drivers/usb/dwc2/gadget.c: In function 's3c_hsotg_irq_enumdone': linux-2.6/drivers/usb/dwc2/gadget.c:1904: warning: 'ep_mps' may be used uninitialized in this function Acked-by: NPaul Zimmerman <Paul.Zimmerman@synopsys.com> Signed-off-by: NPeter Chen <peter.chen@freescale.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Mathias Nyman 提交于
When we manually need to move the TR dequeue pointer we need to set the correct cycle bit as well. Previously we used the trb pointer from the last event received as a base, but this was changed in commit 1f81b6d2 ("usb: xhci: Prefer endpoint context dequeue pointer") to use the dequeue pointer from the endpoint context instead It turns out some Asmedia controllers advance the dequeue pointer stored in the endpoint context past the event triggering TRB, and this messed up the way the cycle bit was calculated. Instead of adding a quirk or complicating the already hard to follow cycle bit code, the whole cycle bit calculation is now simplified and adapted to handle event and endpoint context dequeue pointer differences. Fixes: 1f81b6d2 ("usb: xhci: Prefer endpoint context dequeue pointer") Reported-by: NMaciej Puzio <mx34567@gmail.com> Reported-by: NEvan Langlois <uudruid74@gmail.com> Reviewed-by: NJulius Werner <jwerner@chromium.org> Tested-by: NMaciej Puzio <mx34567@gmail.com> Tested-by: NEvan Langlois <uudruid74@gmail.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Huang Rui 提交于
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: NArindam Nath <arindam.nath@amd.com> Tested-by: NShriraj-Rai P <shriraj-rai.p@amd.com> Cc: <stable@vger.kernel.org> Signed-off-by: NHuang Rui <ray.huang@amd.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
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: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Takashi Iwai 提交于
The commit [5ee0f803: usbcore: don't log on consecutive debounce failures of the same port] added the check of the reliable port, but it also replaced the device argument to dev_err() wrongly, which leads to a NULL dereference. This patch restores the right device, port_dev->dev. Also, since dev_err() itself shows the port number, reduce the port number shown in the error message, essentially reverting to the state before the commit 5ee0f803. [The fix suggested by Hannes, and the error message cleanup suggested by Alan Stern] Fixes: 5ee0f803 ('usbcore: don't log on consecutive debounce failures of the same port') Reported-by: NHannes Reinecke <hare@suse.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 19 8月, 2014 12 次提交
-
-
由 Li RongQing 提交于
This reverts commit a9232076. It introduced a dead lock, and did not fix anything. it made netif_tx_lock() be called in IRQ context, but in softirq context, the same lock is locked without disabling IRQ. In fact, the commit a9232076 did not fix anything, since netif_stop_queue did not free the any resource [ 10.154920] ================================= [ 10.156026] [ INFO: inconsistent lock state ] [ 10.156026] 3.16.0-rc5+ #13 Not tainted [ 10.156026] --------------------------------- [ 10.156026] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. [ 10.156026] swapper/1/0 [HC0[0]:SC1[5]:HE1:SE0] takes: [ 10.156026] (_xmit_ETHER){?.-...}, at: [<80948b6a>] sch_direct_xmit+0x7a/0x250 [ 10.156026] {IN-HARDIRQ-W} state was registered at: [ 10.156026] [<804811f0>] __lock_acquire+0x800/0x17a0 [ 10.156026] [<804828ba>] lock_acquire+0x6a/0xf0 [ 10.156026] [<809ed477>] _raw_spin_lock+0x27/0x40 [ 10.156026] [<8088d508>] gether_disconnect+0x68/0x280 [ 10.156026] [<8088e777>] eem_set_alt+0x37/0xc0 [ 10.156026] [<808847ce>] composite_setup+0x30e/0x1240 [ 10.156026] [<8088b8ae>] pch_udc_isr+0xa6e/0xf50 [ 10.156026] [<8048abe8>] handle_irq_event_percpu+0x38/0x1e0 [ 10.156026] [<8048adc1>] handle_irq_event+0x31/0x50 [ 10.156026] [<8048d94b>] handle_fasteoi_irq+0x6b/0x140 [ 10.156026] [<804040a5>] handle_irq+0x65/0x80 [ 10.156026] [<80403cfc>] do_IRQ+0x3c/0xc0 [ 10.156026] [<809ee6ae>] common_interrupt+0x2e/0x34 [ 10.156026] [<804668c5>] finish_task_switch+0x65/0xd0 [ 10.156026] [<809e89df>] __schedule+0x20f/0x7d0 [ 10.156026] [<809e94aa>] schedule_preempt_disabled+0x2a/0x70 [ 10.156026] [<8047bf03>] cpu_startup_entry+0x143/0x410 [ 10.156026] [<809e2e61>] rest_init+0xa1/0xb0 [ 10.156026] [<80ce2a3b>] start_kernel+0x336/0x33b [ 10.156026] [<80ce22ab>] i386_start_kernel+0x79/0x7d [ 10.156026] irq event stamp: 52070 [ 10.156026] hardirqs last enabled at (52070): [<809375de>] neigh_resolve_output+0xee/0x2a0 [ 10.156026] hardirqs last disabled at (52069): [<809375a8>] neigh_resolve_output+0xb8/0x2a0 [ 10.156026] softirqs last enabled at (52020): [<8044401f>] _local_bh_enable+0x1f/0x50 [ 10.156026] softirqs last disabled at (52021): [<80404036>] do_softirq_own_stack+0x26/0x30 [ 10.156026] [ 10.156026] other info that might help us debug this: [ 10.156026] Possible unsafe locking scenario: [ 10.156026] [ 10.156026] CPU0 [ 10.156026] ---- [ 10.156026] lock(_xmit_ETHER); [ 10.156026] <Interrupt> [ 10.156026] lock(_xmit_ETHER); [ 10.156026] [ 10.156026] *** DEADLOCK *** [ 10.156026] [ 10.156026] 4 locks held by swapper/1/0: [ 10.156026] #0: (((&idev->mc_ifc_timer))){+.-...}, at: [<8044b100>] call_timer_fn+0x0/0x190 [ 10.156026] #1: (rcu_read_lock){......}, at: [<a0577c40>] mld_sendpack+0x0/0x590 [ipv6] [ 10.156026] #2: (rcu_read_lock_bh){......}, at: [<a055680c>] ip6_finish_output2+0x4c/0x7f0 [ipv6] [ 10.156026] #3: (rcu_read_lock_bh){......}, at: [<8092e510>] __dev_queue_xmit+0x0/0x5f0 [ 10.156026] [ 10.156026] stack backtrace: [ 10.156026] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.16.0-rc5+ #13 [ 10.156026] 811dbb10 00000000 9e919d10 809e6785 9e8b8000 9e919d3c 809e561e 80b95511 [ 10.156026] 80b9545a 80b9543d 80b95450 80b95441 80b957e4 9e8b84e0 00000002 8047f7b0 [ 10.156026] 9e919d5c 8048043b 00000002 00000000 9e8b8000 00000001 00000004 9e8b8000 [ 10.156026] Call Trace: [ 10.156026] [<809e6785>] dump_stack+0x48/0x69 [ 10.156026] [<809e561e>] print_usage_bug+0x18f/0x19c [ 10.156026] [<8047f7b0>] ? print_shortest_lock_dependencies+0x170/0x170 [ 10.156026] [<8048043b>] mark_lock+0x53b/0x5f0 [ 10.156026] [<804810cf>] __lock_acquire+0x6df/0x17a0 [ 10.156026] [<804828ba>] lock_acquire+0x6a/0xf0 [ 10.156026] [<80948b6a>] ? sch_direct_xmit+0x7a/0x250 [ 10.156026] [<809ed477>] _raw_spin_lock+0x27/0x40 [ 10.156026] [<80948b6a>] ? sch_direct_xmit+0x7a/0x250 [ 10.156026] [<80948b6a>] sch_direct_xmit+0x7a/0x250 [ 10.156026] [<8092e6bf>] __dev_queue_xmit+0x1af/0x5f0 [ 10.156026] [<80947fc0>] ? ether_setup+0x80/0x80 [ 10.156026] [<8092eb0f>] dev_queue_xmit+0xf/0x20 [ 10.156026] [<8093764c>] neigh_resolve_output+0x15c/0x2a0 [ 10.156026] [<a0556927>] ip6_finish_output2+0x167/0x7f0 [ipv6] [ 10.156026] [<a0559b05>] ip6_finish_output+0x85/0x1c0 [ipv6] [ 10.156026] [<a0559cb7>] ip6_output+0x77/0x240 [ipv6] [ 10.156026] [<a0578163>] mld_sendpack+0x523/0x590 [ipv6] [ 10.156026] [<80480501>] ? mark_held_locks+0x11/0x90 [ 10.156026] [<a057947d>] mld_ifc_timer_expire+0x15d/0x280 [ipv6] [ 10.156026] [<8044b168>] call_timer_fn+0x68/0x190 [ 10.156026] [<a0579320>] ? igmp6_group_added+0x150/0x150 [ipv6] [ 10.156026] [<8044b3fa>] run_timer_softirq+0x16a/0x240 [ 10.156026] [<a0579320>] ? igmp6_group_added+0x150/0x150 [ipv6] [ 10.156026] [<80444984>] __do_softirq+0xd4/0x2f0 [ 10.156026] [<804448b0>] ? tasklet_action+0x100/0x100 [ 10.156026] [<80404036>] do_softirq_own_stack+0x26/0x30 [ 10.156026] <IRQ> [<80444d05>] irq_exit+0x65/0x70 [ 10.156026] [<8042d758>] smp_apic_timer_interrupt+0x38/0x50 [ 10.156026] [<809ee91f>] apic_timer_interrupt+0x2f/0x34 [ 10.156026] [<8048007b>] ? mark_lock+0x17b/0x5f0 [ 10.156026] [<8040a912>] ? default_idle+0x22/0xf0 [ 10.156026] [<8040b13e>] arch_cpu_idle+0xe/0x10 [ 10.156026] [<8047bfc6>] cpu_startup_entry+0x206/0x410 [ 10.156026] [<8042bfbd>] start_secondary+0x19d/0x1e0 Acked-by: NTony Lindgren <tony@atomide.com> Reported-by: NThomas Gleixner <tglx@linutronix.de> Cc: Jeff Westfahl <jeff.westfahl@ni.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: <linux-usb@vger.kernel.org> Signed-off-by: NLi RongQing <roy.qing.li@gmail.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Wei Yongjun 提交于
In case of error, the function devm_ioremap_nocache() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Wei Yongjun 提交于
In case of error, the function devm_ioremap_resource() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Acked-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Wei Yongjun 提交于
In case of error, the function memdup_user() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Dan Carpenter 提交于
"ret" should be signed. It's only used for zero and negative error codes. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Hans Wennborg 提交于
The prefix suggests the number should be printed in hex, so use the %x specifier to do that. Found by using regex suggested by Joe Perches. Signed-off-by: NHans Wennborg <hans@hanshq.net> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Bo Shen 提交于
As, the interrupt for DMA is counted from 1, so need to checked the USBA_NR_DMAS, in old way, it only check (USBA_NR_DMAS - 1), so fix it. Reported-by: NMax Liao <liaops@embest-tech.com> Signed-off-by: NBo Shen <voice.shen@atmel.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Julia Lawall 提交于
Convert a zero return value on error to a negative one, as returned elsewhere in the function. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier ret; expression e1,e2; @@ ( if (\(ret < 0\|ret != 0\)) { ... return ret; } | ret = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // </smpl> Reviewed-by: NJeff Moyer <jmoyer@redhat.com> Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Jingoo Han 提交于
According to the datasheet, PHYPARAM1_PCS_TXDEEMPH is set as 6 bits [5:0]. Thus, the bit mask should be set as 0x3f, instead of 0x1f. Signed-off-by: NJingoo Han <jg1.han@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Alexey Khoroshilov 提交于
After dbgp_bind()-dbgp_unbind() cycle happens, static variable dbgp contains pointers to already deallocated memory (dbgp.serial and dbgp.req). If the next dbgp_bind() fails, for example in usb_ep_alloc_request(), dbgp_bind() calls dbgp_unbind() on failure path, and dbgp_unbind() frees dbgp.serial that still stores a pointer to already deallocated memory. The patch sets pointers to NULL in dbgp_unbind(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Himangi Saraogi 提交于
Using kfree to free data allocated with devm_kzalloc causes double frees. The Coccinelle semantic patch that fixes this problem is as follows: // <smpl> @@ expression x; @@ x = devm_kzalloc(...) ... ?-kfree(x); // </smpl> Reviewed-by: NJingoo Han <jg1.han@samsung.com> Acked-by: NJulia Lawall <julia.lawall@lip6.fr> Signed-off-by: NHimangi Saraogi <himangi774@gmail.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Arjun Sreedharan 提交于
When __usb_find_phy_dev() does not return error and try_module_get() fails, return -ENODEV. Signed-off-by: NArjun Sreedharan <arjun024@gmail.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
- 18 8月, 2014 8 次提交
-
-
由 Jaša Bartelj 提交于
Added support to the ftdi_sio driver for ekey Converter USB which uses an FT232BM chip. Signed-off-by: NJaša Bartelj <jasa.bartelj@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Greg KH 提交于
This adds a new device id to the pl2303 driver for the ZTEK device. Reported-by: NMike Chu <Mike-Chu@prolific.com.tw> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Add device id for Basic Micro ATOM Nano USB2Serial adapters. Reported-by: NNicolas Alt <n.alt@mytum.de> Tested-by: NNicolas Alt <n.alt@mytum.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Remove dublicate Qualcom PID 0x3197 which is already handled by the moto-modem driver since commit 6986a978 ("USB: add new moto_modem driver for some Morotola phones"). Fixes: 799ee924 ("USB: serial: add zte_ev.c driver") Cc: <stable@vger.kernel.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Remove dublicate Gobi PID 0x9008 which is already handled by the qcserial driver since commit f05932c0 ("USB: qcserial: Add extra device IDs"). Fixes: 799ee924 ("USB: serial: add zte_ev.c driver") Cc: <stable@vger.kernel.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
This reverts commit 73228a05 ("USB: option,zte_ev: move most ZTE CDMA devices to zte_ev"). Move the IDs of the devices that were previously driven by the option driver back to that driver. As several users have reported, the zte_ev driver is causing random disconnects as well as reconnect failures. A closer analysis of the zte_ev setup code reveals that it consists of standard CDC requests (SET/GET_LINE_CODING and SET_CONTROL_LINE_STATE) but unfortunately fails to get some of those right. In particular, as reported by Liu Lei, it fails to lower DTR/RTS on close. It also appears that the control requests lack the interface argument. Note that the zte_ev driver is based on code (once) distributed by ZTE that still appears to originally have been reverse-engineered and bolted onto the generic driver. Since line control is already handled properly by the option driver, and the SET/GET_LINE_CODING requests appears to be redundant (amounts to a SET 9600 8N1), this is a first step in ultimately removing the redundant zte_ev driver. Note that AC2726 had already been moved back to option, and that some IDs were in the device table of both drivers prior to the commit being reverted. Reported-by: NLei Liu <liu.lei78@zte.com.cn> Cc: <stable@vger.kernel.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Brennan Ashton 提交于
This VIA Telecom baseband processor is used is used by by u-blox in both the FW2770 and FW2760 products and may be used in others as well. This patch has been tested on both of these modem versions. Signed-off-by: NBrennan Ashton <bashton@brennanashton.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Johan Hovold 提交于
Do not log normal interrupt-urb shutdowns as errors. The option driver has always been logging any nonzero interrupt-urb status as an error, including when the urb is killed during normal operation. Commit 9096f1fb ("USB: usb_wwan: fix potential NULL-deref at resume") moved the interrupt urb submission from port probe and release to open and close, thus potentially increasing the number of these false-positive error messages dramatically. Reported-by: NEd Butler <ressy66@ausics.net> Tested-by: NEd Butler <ressy66@ausics.net> Cc: <stable@vger.kernel.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
- 02 8月, 2014 9 次提交
-
-
由 Oliver Neukum 提交于
usbfs allows user space to pass down an URB which sets URB_SHORT_NOT_OK for output URBs. That causes usbcore to log messages without limit for a nonsensical disallowed combination. The fix is to silently drop the attribute in usbfs. The problem is reported to exist since 3.14 https://www.virtualbox.org/ticket/13085Signed-off-by: NOliver Neukum <oneukum@suse.de> CC: stable@vger.kernel.org Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
So that an user who wants to use uas can see why he is not getting uas. Also move the check down so that we don't warn if there are other reasons why uas cannot work. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Don't complain about controllers without sg support if there are other reasons why uas cannot be used anyways. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
The 7023 product id is the generic product id for the Etron EJ168, it is not specific to the version found on the Asrock P67 motherboard. The same id is e.g. also used on Gigabyte motherboards and on no-name pci-e usb-3 addon cards. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Streams on the EJ168 do not work as they should. I've spend 2 days trying to get them to work, but without success. The first problem is that when ever you ring the stream-ring doorbell, the controller starts executing trbs at the beginning of the first ring segment, event if it ended somewhere else previously. This can be worked around by allowing enqueing only one td (not a problem with how streams are typically used) and then resetting our copies of the enqueueing en dequeueing pointers on a td completion to match what the controller seems to be doing. This way things seem to start working with uas and instead of being able to complete only the very first scsi command, the scsi core can probe the disk. But then things break later on when td-s get enqueued with more then one trb. The controller does seem to increase its dequeue pointer while executing a stream-ring (data transfer events I inserted for debugging do trigger). However execution seems to stop at the final normal trb of a multi trb td, even if there is a data transfer event inserted after the final trb. The first problem alone is a serious deviation from the spec, and esp. dealing with cancellation would have been very tricky if not outright impossible, but the second problem simply is a deal breaker altogether, so this patch simply disables streams. Note this will cause the usb-storage + uas driver pair to automatically switch to using usb-storage instead of uas on these devices, essentially reverting to the 3.14 and earlier behavior when uas was marked CONFIG_BROKEN. https://bugzilla.redhat.com/show_bug.cgi?id=1121288 https://bugzilla.kernel.org/show_bug.cgi?id=80101 Cc: stable@vger.kernel.org # 3.15 Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Some jmicron uas chipsets act up (they disconnect from the bus) when sending more then 32 commands to them at once. Rather then building an ever growing list with usb-id based quirks for devices using this chipset, simply reduce the qdepth to 32 when connected over usb-2. 32 should be plenty to keep things close to maximum possible throughput on usb-2. Cc: stable@vger.kernel.org Tested-and-reported-by: NLaszlo T. <tlacix@gmail.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 James P Michels III 提交于
This patch adds a usb quirk to support devices with interupt endpoints and bInterval values expressed as microframes. The quirk causes the parse endpoint function to modify the reported bInterval to a standards conforming value. There is currently code in the endpoint parser that checks for bIntervals that are outside of the valid range (1-16 for USB 2+ high speed and super speed interupt endpoints). In this case, the code assumes the bInterval is being reported in 1ms frames. As well, the correction is only applied if the original bInterval value is out of the 1-16 range. With this quirk applied to the device, the bInterval will be accurately adjusted from microframes to an exponent. Signed-off-by: NJames P Michels III <james.p.michels@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Patrick Riphagen 提交于
This adds support for new Xsens devices, using Xsens' own Vendor ID. Signed-off-by: NPatrick Riphagen <patrick.riphagen@xsens.com> Signed-off-by: NFrans Klaver <frans.klaver@xsens.com> Cc: Johan Hovold <johan@kernel.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-