- 15 Nov, 2011 7 commits
-
-
Felipe Balbi authored
Fix the following compile warning: | drivers/usb/storage/ene_ub6250.c: In function ‘ms_scsi_write’: | drivers/usb/storage/ene_ub6250.c:1728:6: warning: ‘result’ may \ | be used uninitialized in this function [-Wuninitialized] | drivers/usb/storage/ene_ub6250.c:1795:77: warning: ‘offset’ may \ | be used uninitialized in this function [-Wuninitialized] Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
VU Tuan Duc authored
Add VendorID/ProductID for USB 3G dongle Model VT1000 of Viettel. Signed-off-by:
VU Tuan Duc <ducvt@viettel.com.vn> Signed-off-by:
-
wangyanqing authored
I get report from customer that his usb-serial converter doesn't work well,it sometimes work, but sometimes it doesn't. The usb-serial converter's id: vendor_id product_id 0x4348 0x5523 Then I search the usb-serial codes, and there are two drivers announce support this device, pl2303 and ch341, commit 026dfaf1 cause it. Through many times to test, ch341 works well with this device, and pl2303 doesn't work quite often(it just work quite little). ch341 works well with this device, so we doesn't need pl2303 to support.I try to revert 026dfaf1 first, but it failed. So I prepare this patch by hand to revert it. Signed-off-by:
Wang YanQing <Udknight@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Tomoya MORINAGA authored
On October 1 in 2011, OKI SEMICONDUCTOR Co., Ltd. changed the company name in to LAPIS Semiconductor Co., Ltd. Signed-off-by:
Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com> Signed-off-by:
-
Tomoya MORINAGA authored
ML7831 is companion chip for Intel Atom E6xx series. Signed-off-by:
-
Alan Stern authored
The 8020i protocol (also 8070i and QIC-157) uses 12-byte commands; shorter commands must be padded. Simon Detheridge reports that his 3-TB USB disk drive claims to use the 8020i protocol (which is normally meant for ATAPI devices like CD drives), and because of its large size, the disk drive requires the use of 16-byte commands. However the usb_stor_pad12_command() routine in usb-storage always sets the command length to 12, making the drive impossible to use. Since the SFF-8020i specification allows for 16-byte commands in future extensions, we may as well accept them. This patch (as1490) changes usb_stor_pad12_command() to leave commands larger than 12 bytes alone rather than truncating them. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Simon Detheridge <simon@widgit.com> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
sordna authored
The following patch contains additional affected webcam models, on top of the patches commited to linux-next 2394d67e and 5b253d88Signed-off-by:
sordna <sordna@gmail.com> Cc: Oliver Neukum <oliver@neukum.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
- 14 Nov, 2011 33 commits
-
-
Shaohui Xie authored
Below are codes for accessing usb sysif_regs in driver: usb_sys_regs = (struct usb_sys_interface *) ((u32)dr_regs + USB_DR_SYS_OFFSET); these codes work in 32-bit, but in 64-bit, use u32 to type cast the address of ioremap is not right, and accessing members of 'usb_sys_regs' will cause call trace, so use (void *) for both 32-bit and 64-bit. Signed-off-by:
Shaohui Xie <Shaohui.Xie@freescale.com> Signed-off-by:
-
Jean-Christophe PLAGNIOL-VILLARD authored
in commit aa6e52a3 we introduce the support of overcurrent notification but the set and get of the power without checking if the gpio is valid or not Signed-off-by:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Acked-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Havard Skinnemoen authored
There's a race between the USB disconnect handler and the TTY close handler which may cause the acm object to be freed while it's still being used. This may lead to things like http://article.gmane.org/gmane.linux.usb.general/54250 and https://lkml.org/lkml/2011/5/29/64 This is the simplest fix I could come up with. Holding on to open_mutex while closing the TTY device prevents acm_disconnect() from freeing the acm object between acm->port.count drops to 0 and the TTY side of the cleanups are finalized. Signed-off-by:
Havard Skinnemoen <hskinnemoen@google.com> Cc: Oliver Neukum <oliver@neukum.name> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Josh Boyer authored
We've had another report of the "chipmunk" sound on a Logitech C600 webcam. This patch resolves the issue. Cc: stable <stable@vger.kernel.org> Signed-off-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
-
Thomas Poussevin authored
The current TT scheduling doesn't allow to play and then record on a full-speed device connected to a high speed hub. The IN iso stream can only start on the first uframe (0-2 for a 165 us) because of CSPLIT transactions. For the OUT iso stream there no such restriction. uframe 0-5 are possible. The idea of this patch is that the first uframe are precious (for IN TT iso stream) and we should allocate the last uframes first if possible. For that we reverse the order of uframe allocation (last uframe first). Here an example : hid interrupt stream ---------------------------------------------------------------------- uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ---------------------------------------------------------------------- max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 | ---------------------------------------------------------------------- used usecs on a frame | 13 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ---------------------------------------------------------------------- iso OUT stream ---------------------------------------------------------------------- uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ---------------------------------------------------------------------- max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 | ---------------------------------------------------------------------- used usecs on a frame | 13 | 125 | 39 | 0 | 0 | 0 | 0 | 0 | ---------------------------------------------------------------------- There no place for iso IN stream (uframe 0-2 are used) and we got "cannot submit datapipe for urb 0, error -28: not enough bandwidth" error. With the patch this become. iso OUT stream ---------------------------------------------------------------------- uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ---------------------------------------------------------------------- max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 | ---------------------------------------------------------------------- used usecs on a frame | 13 | 0 | 0 | 0 | 125 | 39 | 0 | 0 | ---------------------------------------------------------------------- iso IN stream ---------------------------------------------------------------------- uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ---------------------------------------------------------------------- max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 | ---------------------------------------------------------------------- used usecs on a frame | 13 | 0 | 125 | 40 | 125 | 39 | 0 | 0 | ---------------------------------------------------------------------- Signed-off-by:
Matthieu Castet <matthieu.castet@parrot.com> Signed-off-by:
Thomas Poussevin <thomas.poussevin@parrot.com> Signed-off-by:
-
Alan Stern authored
This patch (as1494) fixes a problem in xhci-hcd's resume routine. When the controller is runtime-resumed, this can only mean that one of the two root hubs has made a wakeup request and therefore needs to be resumed as well. Rather than try to determine which root hub requires attention (which might be difficult in the case where a new non-SuperSpeed device has been plugged in), the patch simply resumes both root hubs. Without this change, there is a race: The controller might be put back to sleep before it can activate its IRQ line, and the wakeup condition might never get handled. The patch also simplifies the logic in xhci_resume a little, combining some repeated flag settings into a single pair of statements. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Alan Stern authored
This patch (as1491) works around a bug in GCC-3.4.6, which is still supposed to be supported. The number of microseconds in the udelay() call in quirk_usb_disable_ehci() is fixed at 100, but the compiler doesn't understand this and generates a link-time error. So we replace the otherwise unused variable "delta" with a simple constant 100. This same pattern is already used in other delay loops in that source file. Signed-off-by:
Konrad Rzepecki <krzepecki@dentonet.pl> Tested-by:
-
Bart Hartgers authored
This patch for the usb serial ark3116 driver fixes an initialisation ordering bug that gets triggered on hotplug when using at least recent debian/ubuntu userspace. Without it, ark3116 serial cables don't work. Signed-off-by:
Bart Hartgers <bart.hartgers@gmail.com> Tested-by: law_ence.dev@ntlworld.com Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Felipe Balbi authored
commit de477254 (include: replace linux/module.h with "struct module" wherever possible) introduced a compilation breaked when it removed <linux/module.h> from <linux/device.h> which musb glue layers were (mistakenly) relying on. Include that header to fix the compile error. Signed-off-by:
-
Sebastian Andrzej Siewior authored
Without this the gadget will never be able to allocate a stream capable endpoint. The manual says that the stream id is a 16bit id. It does not talk about an upper limit in any other way. So I think 15 is a reasonable limit :) Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Kuninori Morimoto authored
new endpoint should start from DATA0, but mod_host didn't care it. This patch fix it. Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
-
Kuninori Morimoto authored
Signed-off-by:
-
Kuninori Morimoto authored
renesas_usbhs is caring pipe type and its direction. but current usbhs_endpoint_alloc() didn't check direction. this patch modify it. Signed-off-by:
-
Marc Kleine-Budde authored
Since commit "193ab2a6 usb: gadget: allow multiple gadgets to be built" the udc controllers can be compiled as a module. The ci13xxx_msm driver is missing the MODULE_LICENSE statement, so loading fails with: ci13xxx_msm: module license 'unspecified' taints kernel. ci13xxx_msm: Unknown symbol dev_set_name (err 0) ci13xxx_msm: Unknown symbol platform_get_irq (err 0) ci13xxx_msm: Unknown symbol device_unregister (err 0) ci13xxx_msm: Unknown symbol usb_add_gadget_udc (err 0) ci13xxx_msm: Unknown symbol put_device (err 0) ci13xxx_msm: Unknown symbol platform_driver_register (err 0) ci13xxx_msm: Unknown symbol platform_get_resource (err 0) ci13xxx_msm: Unknown symbol device_register (err 0) ci13xxx_msm: Unknown symbol usb_del_gadget_udc (err 0) This patch adds the missing MODULE_LICENSE statement with GPL v2 according to the header of the driver. Tested-by:
Pavankumar Kondeti <pkondeti@codeaurora.org> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Marc Kleine-Budde authored
This patch fixes the following compile errors that show up if switching on the debug trace code: drivers/usb/gadget/ci13xxx_udc.c: In function 'ci13xxx_wakeup': drivers/usb/gadget/ci13xxx_udc.c:2517:3: error: 'dev' undeclared (first use in this function) drivers/usb/gadget/ci13xxx_udc.c:2517:3: note: each undeclared identifier is reported only once for each function it appears in drivers/usb/gadget/ci13xxx_udc.c: In function 'udc_probe': drivers/usb/gadget/ci13xxx_udc.c:2867:2: error: 'name' undeclared (first use in this function) Tested-by:
-
Marc Kleine-Budde authored
The inline documentation of _gadget_stop_activity() states that the function should be called holding the udc->lock. This however will result in a deadlock, because _gadget_stop_activity() takes the udc->lock. During normal operation _gadget_stop_activity() is always called unlocked, but in ci13xxx_stop() it's called locked, this results in the following deadlock during rmmod of a gadget driver. This patch fixes the deadlock by calling _gadget_stop_activity() always unlocked, the inline documentation is adjusted accordingly. ============================================= [ INFO: possible recursive locking detected ] 3.1.0-rc6+ #159 --------------------------------------------- rmmod/121 is trying to acquire lock: (udc_lock){-.-...}, at: [<c0229048>] _gadget_stop_activity+0x18/0x154 but task is already holding lock: (udc_lock){-.-...}, at: [<c02291e0>] ci13xxx_stop+0x5c/0x164 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(udc_lock); lock(udc_lock); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by rmmod/121: #0: (udc_lock#2){+.+.+.}, at: [<c02286c0>] usb_gadget_unregister_driver+0x34/0x88 #1: (udc_lock){-.-...}, at: [<c02291e0>] ci13xxx_stop+0x5c/0x164 stack backtrace: [<c000d41c>] (unwind_backtrace+0x0/0xf0) from [<c0056f94>] (check_deadlock.clone.24+0x284/0x2c4) [<c0056f94>] (check_deadlock.clone.24+0x284/0x2c4) from [<c00589ac>] (validate_chain.clone.25+0x430/0x6fc) [<c00589ac>] (validate_chain.clone.25+0x430/0x6fc) from [<c0059bac>] (__lock_acquire+0x494/0x8f0) [<c0059bac>] (__lock_acquire+0x494/0x8f0) from [<c005a698>] (lock_acquire+0x98/0x1a8) [<c005a698>] (lock_acquire+0x98/0x1a8) from [<c02f12a4>] (_raw_spin_lock_irqsave+0x64/0xa0) [<c02f12a4>] (_raw_spin_lock_irqsave+0x64/0xa0) from [<c0229048>] (_gadget_stop_activity+0x18/0x154) [<c0229048>] (_gadget_stop_activity+0x18/0x154) from [<c0229234>] (ci13xxx_stop+0xb0/0x164) [<c0229234>] (ci13xxx_stop+0xb0/0x164) from [<c022867c>] (usb_gadget_remove_driver+0x88/0x98) [<c022867c>] (usb_gadget_remove_driver+0x88/0x98) from [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88) [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88) from [<c0065f2c>] (sys_delete_module+0x1fc/0x26c) [<c0065f2c>] (sys_delete_module+0x1fc/0x26c) from [<c00092a0>] (ret_fast_syscall+0x0/0x38) BUG: spinlock lockup on CPU#0, rmmod/121, c05b1644 [<c000d41c>] (unwind_backtrace+0x0/0xf0) from [<c01da000>] (do_raw_spin_lock+0x128/0x144) [<c01da000>] (do_raw_spin_lock+0x128/0x144) from [<c02f12c8>] (_raw_spin_lock_irqsave+0x88/0xa0) [<c02f12c8>] (_raw_spin_lock_irqsave+0x88/0xa0) from [<c0229048>] (_gadget_stop_activity+0x18/0x154) [<c0229048>] (_gadget_stop_activity+0x18/0x154) from [<c0229234>] (ci13xxx_stop+0xb0/0x164) [<c0229234>] (ci13xxx_stop+0xb0/0x164) from [<c022867c>] (usb_gadget_remove_driver+0x88/0x98) [<c022867c>] (usb_gadget_remove_driver+0x88/0x98) from [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88) [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88) from [<c0065f2c>] (sys_delete_module+0x1fc/0x26c) [<c0065f2c>] (sys_delete_module+0x1fc/0x26c) from [<c00092a0>] (ret_fast_syscall+0x0/0x38) Tested-by: -
Michael Grzeschik authored
The current driver sets the request's dma addr (mReq->req.dma) to 0 to mark the DMA address as not valid. However some gadget drivers (e.g. gadgetfs) set the request's dma addr to DMA_ADDR_INVALID to mark the address as invalid. This leads to bogus data send because the ci13xxx_udc driver assumes the request has already been mapped. This patch fixes the problem, by using DMA_ADDR_INVALID instead of 0 to mark the request's DMA address as invalid. Tested-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by:
-
Marc Kleine-Budde authored
Under certain circumstances lockdep finds an inconsistent lock state in gadgetfs. The problem can be reproduced with a hardware using the ci13xxx_udc driver and the gadgetfs test program (needs a patch to support the ci13xxx_udc, though): http://www.linux-usb.org/gadget/usb.c Start the test program, wait to initialize, then press Ctrl+c. This patch fixes the following problem by using spin_lock_irqsave() instead of spin_lock(). ================================= [ INFO: inconsistent lock state ] 3.1.0-rc6+ #158 --------------------------------- inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. usb/113 [HC0[0]:SC0[0]:HE1:SE1] takes: (&(&dev->lock)->rlock){?.....}, at: [<bf000340>] gadgetfs_disconnect+0x14/0x80 [gadgetfs] {IN-HARDIRQ-W} state was registered at: [<c00596b8>] mark_irqflags+0x14c/0x1ac [<c0059bf8>] __lock_acquire+0x4e0/0x8f0 [<c005a698>] lock_acquire+0x98/0x1a8 [<c02f10e0>] _raw_spin_lock+0x54/0x8c [<bf000340>] gadgetfs_disconnect+0x14/0x80 [gadgetfs] [<c0229104>] _gadget_stop_activity+0xd4/0x154 [<c022b130>] isr_reset_handler+0x34/0x1c0 [<c022c320>] udc_irq+0x204/0x228 [<c0069018>] handle_irq_event_percpu+0x64/0x3a0 [<c0069390>] handle_irq_event+0x3c/0x5c [<c006ae5c>] handle_level_irq+0x8c/0x10c [<c0068a34>] generic_handle_irq+0x30/0x44 [<c0009b2c>] handle_IRQ+0x30/0x84 [<c0008ef8>] __irq_svc+0x38/0x60 [<c0009c58>] default_idle+0x30/0x34 [<c0009e30>] cpu_idle+0x9c/0xd8 [<c04056f4>] start_kernel+0x278/0x2bc irq event stamp: 6412 hardirqs last enabled at (6412): [<c02f1cd0>] _raw_spin_unlock_irqrestore+0x30/0x5c hardirqs last disabled at (6411): [<c02f1278>] _raw_spin_lock_irqsave+0x20/0xa0 softirqs last enabled at (6381): [<c002833c>] irq_exit+0xa0/0xa8 softirqs last disabled at (6372): [<c002833c>] irq_exit+0xa0/0xa8 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&dev->lock)->rlock); <Interrupt> lock(&(&dev->lock)->rlock); *** DEADLOCK *** 1 lock held by usb/113: #0: (udc_lock#2){+.+.+.}, at: [<c02286c0>] usb_gadget_unregister_driver+0x34/0x88 stack backtrace: [<c000d41c>] (unwind_backtrace+0x0/0xf0) from [<c0058e98>] (print_usage_bug+0x144/0x1c4) [<c0058e98>] (print_usage_bug+0x144/0x1c4) from [<c0059144>] (mark_lock_irq+0x22c/0x274) [<c0059144>] (mark_lock_irq+0x22c/0x274) from [<c00592d4>] (mark_lock+0x148/0x3e0) [<c00592d4>] (mark_lock+0x148/0x3e0) from [<c0059668>] (mark_irqflags+0xfc/0x1ac) [<c0059668>] (mark_irqflags+0xfc/0x1ac) from [<c0059bf8>] (__lock_acquire+0x4e0/0x8f0) [<c0059bf8>] (__lock_acquire+0x4e0/0x8f0) from [<c005a698>] (lock_acquire+0x98/0x1a8) [<c005a698>] (lock_acquire+0x98/0x1a8) from [<c02f10e0>] (_raw_spin_lock+0x54/0x8c) [<c02f10e0>] (_raw_spin_lock+0x54/0x8c) from [<bf000340>] (gadgetfs_disconnect+0x14/0x80 [gadgetfs]) [<bf000340>] (gadgetfs_disconnect+0x14/0x80 [gadgetfs]) from [<c0229104>] (_gadget_stop_activity+0xd4/0x154) [<c0229104>] (_gadget_stop_activity+0xd4/0x154) from [<c0229240>] (ci13xxx_stop+0xbc/0x17c) [<c0229240>] (ci13xxx_stop+0xbc/0x17c) from [<c022867c>] (usb_gadget_remove_driver+0x88/0x98) [<c022867c>] (usb_gadget_remove_driver+0x88/0x98) from [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88) [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88) from [<bf0003e8>] (dev_release+0x14/0x48 [gadgetfs]) [<bf0003e8>] (dev_release+0x14/0x48 [gadgetfs]) from [<c00cc158>] (__fput+0xa4/0x1f0) [<c00cc158>] (__fput+0xa4/0x1f0) from [<c00c7f28>] (filp_close+0x5c/0x74) [<c00c7f28>] (filp_close+0x5c/0x74) from [<c00c7fe8>] (sys_close+0xa8/0x150) [<c00c7fe8>] (sys_close+0xa8/0x150) from [<c00092a0>] (ret_fast_syscall+0x0/0x38) Tested-by:
-
Daniel Mack authored
The dynamic jack allocation of the MIDI gadget currently links all external jacks to one single instance of an embedded jack. According to the spec, this is only valid if these streams always carry the same data stream, as described in the USB MIDI 1.0 spec, chapter 3.3.1. Also, genius Windows 7(tm) terminates it's life cycle instantly with a blue screen of death once a device with more than one input and output port with the current implementation is connected. While at it, and because it grew again by this change, allocate the temporary function pointer list on the heap, not on the stack. Signed-off-by:
Daniel Mack <zonque@gmail.com> Signed-off-by:
-
Paul Zimmerman authored
The USB-IF CV compliance tester is getting stricter, and it would be valid for it to fail a mass-storage device that accepts an invalid USB_BULK_RESET_REQUEST request. Although it doesn't do that yet, let's be proactive and fix that now. Suggested by Alan Stern. Signed-off-by:
Paul Zimmerman <paulz@synopsys.com> Signed-off-by:
-
Paul Zimmerman authored
The latest USB-IF CV tester checks for a valid length for this request. Signed-off-by:
-
Kuninori Morimoto authored
Fix up the following section mismatch warnings: WARNING: drivers/usb/renesas_usbhs/renesas_usbhs.o(.text+0xf5d): Section mismatch in reference from the function usbhs_mod_probe() to the function .devinit.text:usbhs_mod_host_probe() The function usbhs_mod_probe() references the function __devinit usbhs_mod_host_probe(). This is often because usbhs_mod_probe lacks a __devinit annotation or the annotation of usbhs_mod_host_probe is wrong. WARNING: drivers/usb/renesas_usbhs/renesas_usbhs.o(.text+0xfd7): Section mismatch in reference from the function usbhs_mod_probe() to the function .devexit.text:usbhs_mod_host_remove() The function usbhs_mod_probe() references a function in an exit section. Often the function usbhs_mod_host_remove() has valid usage outside the exit section and the fix is to remove the __devexit annotation of usbhs_mod_host_remove. WARNING: drivers/usb/renesas_usbhs/renesas_usbhs.o(.text+0x1005): Section mismatch in reference from the function usbhs_mod_remove() to the function .devexit.text:usbhs_mod_host_remove() The function usbhs_mod_remove() references a function in an exit section. Often the function usbhs_mod_host_remove() has valid usage outside the exit section and the fix is to remove the __devexit annotation of usbhs_mod_host_remove. Signed-off-by:
-
Kuninori Morimoto authored
this patch fixup bogus conversion of 8a9775ab (usb: gadget: renesas_usbhs: fix compile warning) Signed-off-by:
-
Kuninori Morimoto authored
Since renesas_usbhs mod_host didn't use struct completion as static object, the warning of lockdep came out. This patch fixup this issue. Signed-off-by:
-
Alexander Aring authored
Fix compile error in file drivers/usb/gadget/fsl_udc_core.c. drivers/usb/gadget/fsl_udc_core.c: In function 'portscx_device_speed': drivers/usb/gadget/fsl_udc_core.c:1720: error: 'speed' undeclared (first use in this function) Introduced in commit e538dfda (usb: Provide usb_speed_string() function) Signed-off-by:
Alexander Aring <a.aring@phytec.de> Acked-by:
Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
-
Yoshihiro Shimoda authored
The "BCLR" in CFIFOCTR/DnFIFOCTR can flush the fifo of "CPU side" only. To flush the fifo of "SIE side", we have to use the "ACLRM" in PIPEnCTR. Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
-
Yoshihiro Shimoda authored
The udc-newstyle needs device_register in probe() of platform_device. If it doesn't call, kernel panic happens in the sysfs_create_dir() when we run modprobe a gadget driver. [ balbi@ti.com : fix compile warning introduced by this patch ] Signed-off-by:
-
Luciano Coelho authored
USB_MUSB_HDRC depends on USB_GADGET_DUALSPEED. If HDRC is selected but DUALSPEED is not, the kernel oopses: [ 3.132781] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 3.141296] pgd = c0004000 [ 3.144134] [00000000] *pgd=00000000 [ 3.147918] Internal error: Oops: 5 [#1] SMP [ 3.152404] Modules linked in: [ 3.155609] CPU: 0 Not tainted (3.1.0-rc9-wl+ #417) [ 3.161132] PC is at composite_setup+0x738/0xbb4 [ 3.165985] LR is at vprintk+0x400/0x47c [ 3.170135] pc : [<c031df90>] lr : [<c004c150>] psr: 60000093 [ 3.170135] sp : c065dd50 ip : dfb1f0fc fp : c065ddbc [ 3.182220] r10: 00000000 r9 : df8fcae8 r8 : df8fcaa0 [ 3.187713] r7 : 00000000 r6 : df8eaa20 r5 : dfae8ea0 r4 : 00000000 [ 3.194580] r3 : df8fcae8 r2 : 00010002 r1 : c065dc40 r0 : 00000047 [ 3.201446] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [ 3.209228] Control: 10c53c7d Table: 8000404a DAC: 00000015 [ 3.215270] Process swapper (pid: 0, stack limit = 0xc065c2f8) [ 3.221405] Stack: (0xc065dd50 to 0xc065e000) [...] [ 3.415405] [<c031df90>] (composite_setup+0x738/0xbb4) from [<c0310d18>] (musb_g_ep0_irq+0x9d0/0xaf8) [ 3.425109] [<c0310d18>] (musb_g_ep0_irq+0x9d0/0xaf8) from [<c030fb04>] (musb_interrupt+0xb48/0xc74) [ 3.434722] [<c030fb04>] (musb_interrupt+0xb48/0xc74) from [<c030fc98>] (generic_interrupt+0x68/0x80) [ 3.444458] [<c030fc98>] (generic_interrupt+0x68/0x80) from [<c0095204>] (handle_irq_event_percpu+0x9c/0x234) [ 3.454925] [<c0095204>] (handle_irq_event_percpu+0x9c/0x234) from [<c00953e8>] (handle_irq_event+0x4c/0x6c) [ 3.465270] [<c00953e8>] (handle_irq_event+0x4c/0x6c) from [<c0097e10>] (handle_fasteoi_irq+0xd8/0x110) [ 3.475158] [<c0097e10>] (handle_fasteoi_irq+0xd8/0x110) from [<c0094d2c>] (generic_handle_irq+0x34/0x3c) [ 3.485260] [<c0094d2c>] (generic_handle_irq+0x34/0x3c) from [<c0014ae4>] (handle_IRQ+0x88/0xc8) [ 3.494537] [<c0014ae4>] (handle_IRQ+0x88/0xc8) from [<c00085b0>] (asm_do_IRQ+0x18/0x1c) [ 3.503051] [<c00085b0>] (asm_do_IRQ+0x18/0x1c) from [<c0429e78>] (__irq_svc+0x38/0xc0) This patch changes Kconfig so that USB_GADGET_DUALSPEED is selected automatically by USB_MUSB_HDRC. Signed-off-by:
Luciano Coelho <coelho@ti.com> Signed-off-by:
-
Mian Yousaf Kaukab authored
ARCH_U8500 covers both MACH_U8500 and MACH_U5500 Reported-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Felipe Balbi authored
Those are simply giving information about the current state of the UDC, nothing really fancy. We can let everybody read those. Signed-off-by:
-
Felipe Balbi authored
usb_gadget_disconnect() is responsible of removing data pullups. Before doing that we must, first, tell gadget driver we're disconnecting (by calling disconnect method on gadget driver structure), unbind the gadget driver and stop the controller. Signed-off-by:
-
Felipe Balbi authored
that has already being done by udc-core.c. It's unnecessary and might cause issues with some gadget drivers. Tested: Ajay Kumar Gupta <ajay.gupta@ti.com> Signed-off-by:
-
Felipe Balbi authored
We should not be using dev_get_drvdata() because we never call dev_set_drvdata(). Let's use container_of() as all other sysfs attributes. Signed-off-by:
-
