- 19 Jul, 2011 2 commits
-
-
Alan Stern authored
This patch (as1480) fixes a rather obscure bug in ehci-hcd. The qh_update() routine needs to know the number and direction of the endpoint corresponding to its QH argument. The number can be taken directly from the QH data structure, but the direction isn't stored there. The direction is taken instead from the first qTD linked to the QH. However, it turns out that for interrupt transfers, qh_update() gets called before the qTDs are linked to the QH. As a result, qh_update() computes a bogus direction value, which messes up the endpoint toggle handling. Under the right combination of circumstances this causes usb_reset_endpoint() not to work correctly, which causes packets to be dropped and communications to fail. Now, it's silly for the QH structure not to have direct access to all the descriptor information for the corresponding endpoint. Ultimately it may get a pointer to the usb_host_endpoint structure; for now, adding a copy of the direction flag solves the immediate problem. This allows the Spyder2 color-calibration system (a low-speed USB device that sends all its interrupt data packets with the toggle set to 0 and hance requires constant use of usb_reset_endpoint) to work when connected through a high-speed hub. Thanks to Graeme Gill for supplying the hardware that allowed me to track down this bug. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Graeme Gill <graeme@argyllcms.com> CC: <stable@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Wolfgang Denk authored
Add ID 4348:5523 for WinChipHead USB->RS 232 adapter with Prolifec PL2303 chipset Signed-off-by:
Wolfgang Denk <wd@denx.de> Cc: stable <stable@kernel.org> Signed-off-by:
-
- 16 Jul, 2011 1 commit
-
-
Alan Stern authored
The NVIDIA series of OHCI controllers continues to be troublesome. A few people using the MCP67 chipset have reported that even with the most recent kernels, the OHCI controller fails to handle new connections and spams the system log with "unable to enumerate USB port" messages. This is different from the other problems previously reported for NVIDIA OHCI controllers, although it is probably related. It turns out that the MCP67 controller does not like to be kept in the RESET state very long. After only a few seconds, it decides not to work any more. This patch (as1479) changes the PCI initialization quirk code so that NVIDIA controllers are switched into the SUSPEND state after 50 ms of RESET. With no interrupts enabled and all the downstream devices reset, and thus unable to send wakeup requests, this should be perfectly safe (even for non-NVIDIA hardware). The removal code in ohci-hcd hasn't been changed; it will still leave the controller in the RESET state. As a result, if someone unloads ohci-hcd and then reloads it, the controller won't work again until the system is rebooted. If anybody complains about this, the removal code can be updated similarly. This fixes Bugzilla #22052. Tested-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: stable <stable@kernel.org> Signed-off-by:
-
- 08 Jul, 2011 32 commits
-
-
Greg Kroah-Hartman authored
* 'for-next' of master.kernel.org:/pub/scm/linux/kernel/git/balbi/usb: usb: gadget: m66592-udc: add pullup function usb: gadget: m66592-udc: add function for external controller usb: gadget: r8a66597-udc: add pullup function usb: gadget: zero: add superspeed support usb: gadget: add SS descriptors to Ethernet gadget usb: gadget: r8a66597-udc: add support for TEST_MODE usb: gadget: m66592-udc: add support for TEST_MODE usb: gadget: r8a66597-udc: Make BUSWAIT configurable through platform data usb: gadget: r8a66597-udc: fix cannot connect after rmmod gadget driver usb: update email address in r8a66597-udc and m66592-udc usb: musb: restore INDEX register in resume path usb: gadget: fix up depencies usb: gadget: fusb300_udc: fix compile warnings usb: gadget: ci13xx_udc.c: fix compile warning usb: gadget: net2272: fix compile warnings usb: gadget: langwell_udc: fix compile warnings usb: gadget: fusb300_udc: drop dead code
-
Felipe Balbi authored
* gadget: usb: gadget: m66592-udc: add pullup function usb: gadget: m66592-udc: add function for external controller usb: gadget: r8a66597-udc: add pullup function usb: gadget: zero: add superspeed support usb: gadget: add SS descriptors to Ethernet gadget usb: gadget: r8a66597-udc: add support for TEST_MODE usb: gadget: m66592-udc: add support for TEST_MODE usb: gadget: r8a66597-udc: Make BUSWAIT configurable through platform data usb: gadget: r8a66597-udc: fix cannot connect after rmmod gadget driver usb: update email address in r8a66597-udc and m66592-udc usb: musb: restore INDEX register in resume path usb: gadget: fix up depencies usb: gadget: fusb300_udc: fix compile warnings usb: gadget: ci13xx_udc.c: fix compile warning usb: gadget: net2272: fix compile warnings usb: gadget: langwell_udc: fix compile warnings usb: gadget: fusb300_udc: drop dead code
-
Yoshihiro Shimoda authored
Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Yoshihiro Shimoda authored
M66592 has the pin of WR0 and WR1. So, if one write-pin of CPU connects to the pins, we have to change the setting of FIFOSEL register in the controller. If we don't change the setting, the controller cannot send the data of odd length. Signed-off-by:
-
Yoshihiro Shimoda authored
Signed-off-by:
-
Kuninori Morimoto authored
Some SuperH/board has multi USBHS on it. This patch supports multi register for renesas_usbhs Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
-
Kuninori Morimoto authored
Signed-off-by:
-
Kuninori Morimoto authored
Signed-off-by:
-
Michał Sroczyński authored
PL2303: correctly handle baudrates above 115200 Signed-off-by:
Michal Sroczynski <msroczyn@gmail.com> Signed-off-by:
-
Kuninori Morimoto authored
This is typo fix of 749da5f8 (USB: straighten out port feature vs. port status usage) Signed-off-by:
-
Kuninori Morimoto authored
This patch rescues renesas_usbhs compile from commit 193ab2a6 (usb: gadget: allow multiple gadgets to be built) CONFIG_USB_RENESAS_USBHS compile renesas_usbhs main code which is shared between Host/Gadget. CONFIG_USB_RENESAS_USBHS_UDC add mod_gadget to it. It had lost USB_GADGET_DUALSPEED Signed-off-by:
-
Kuninori Morimoto authored
This patch add/modify comment-out of renesas_usbhs. On this process, usbhs_pkt_init was moved because it was placed under usbhsf_null_handler which has no relationship it Signed-off-by:
-
Yoshihiro Shimoda authored
Signed-off-by:
-
Yoshihiro Shimoda authored
R8A66597 has the pin of WR0 and WR1. So, if one write-pin of CPU connects to the pins, we have to change the setting of FIFOSEL register in the controller. If we don't change the setting, the controller cannot send the data of odd length. Signed-off-by:
-
Sergei Shtylyov authored
MAX4967 USB power supply chip we use on our boards signals over-current when power is not enabled; once it's enabled, over-current signal returns to normal. That unfortunately caused the endless stream of "over-current change on port" messages. The EHCI root hub code reacts on every over-current signal change with powering off the port -- such change event is generated the moment the port power is enabled, so once enabled the power is immediately cut off. I think we should only cut off power when we're seeing the active over-current signal, so I'm adding such check to that code. I also think that the fact that we've cut off the port power should be reflected in the result of GetPortStatus request immediately, hence I'm adding a PORTSCn register readback after write... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Cc: stable@kernel.org Acked-by:
-
Tobias Klauser authored
Do not bail out with an error in mon_text_init() if debugfs is not available, instead just return 0 and let mon_init() go ahead with loading the binary API. Return -ENOMEM in case debugfs_create_dir() fails for other reasons. Later, it is enough to check for mon_dir not set. Signed-off-by:
Tobias Klauser <tklauser@distanz.ch> Signed-off-by:
Pete Zaitcev <zaitcev@redhat.com> Signed-off-by:
-
Alan Stern authored
This patch (as1477) fixes a problem affecting a few types of EHCI controller. Contrary to what one might expect, these controllers automatically stop their internal frame counter when no ports are enabled. Since ehci-hcd currently relies on the frame counter for determining when it should unlink QHs from the async schedule, those controllers run into trouble: The frame counter stops and the QHs never get unlinked. Some systems have also experienced other problems traced back to commit b9638011 (USB: ehci-hcd unlink speedups), which made the original switch from using the system clock to using the frame counter. It never became clear what the reason was for these problems, but evidently it is related to use of the frame counter. To fix all these problems, this patch more or less reverts that commit and goes back to using the system clock. But this can't be done cleanly because other changes have since been made to the scan_async() subroutine. One of these changes involved the tricky logic that tries to avoid rescanning QHs that have already been seen when the scanning loop is restarted, which happens whenever an URB is given back. Switching back to clock-based unlinks would make this logic even more complicated. Therefore the new code doesn't rescan the entire async list whenever a giveback occurs. Instead it rescans only the current QH and continues on from there. This requires the use of a separate pointer to keep track of the next QH to scan, since the current QH may be unlinked while the scanning is in progress. That new pointer must be global, so that it can be adjusted forward whenever the _next_ QH gets unlinked. (uhci-hcd uses this same trick.) Simplification of the scanning loop removes a level of indentation, which accounts for the size of the patch. The amount of code changed is relatively small, and it isn't exactly a reversion of the b9638011 commit. This fixes Bugzilla #32432. Signed-off-by:
Matej Kenda <matejken@gmail.com> Signed-off-by:
-
Anisse Astier authored
Add another variant of the Pegatron tablet used by Ordissimo, and apparently RM Slate 100, to the list of models that should skip the negociation for the handoff of the EHCI controller. Signed-off-by:
Anisse Astier <anisse@astier.eu> Signed-off-by:
-
Anisse Astier authored
In commit 3610ea53 (ehci: workaround for pci quirk timeout on ExoPC), a workaround was added to skip the negociation for the handoff of the EHCI controller. Refactor the DMI detection code to use standard dmi_check_system function. Signed-off-by:
-
Kirill Smelkov authored
There are cases, when 80% max isochronous bandwidth is too limiting. For example I have two USB video capture cards which stream uncompressed video, and to stream full NTSC + PAL videos we'd need NTSC 640x480 YUV422 @30fps ~17.6 MB/s PAL 720x576 YUV422 @25fps ~19.7 MB/s isoc bandwidth. Now, due to limited alt settings in capture devices NTSC one ends up streaming with max_pkt_size=2688 and PAL with max_pkt_size=2892, both with interval=1. In terms of microframe time allocation this gives NTSC ~53us PAL ~57us and together ~110us > 100us == 80% of 125us uframe time. So those two devices can't work together simultaneously because the'd over allocate isochronous bandwidth. 80% seemed a bit arbitrary to me, and I've tried to raise it to 90% and both devices started to work together, so I though sometimes it would be a good idea for users to override hardcoded default of max 80% isoc bandwidth. After all, isn't it a user who should decide how to load the bus? If I can live with 10% or even 5% bulk bandwidth that should be ok. I'm a USB newcomer, but that 80% set in stone by USB 2.0 specification seems to be chosen pretty arbitrary to me, just to serve as a reasonable default. NOTE 1 ~~~~~~ for two streams with max_pkt_size=3072 (worst case) both time allocation would be 60us+60us=120us which is 96% periodic bandwidth leaving 4% for bulk and control. Alan Stern suggested that bulk then would be problematic (less than 300*8 bittimes left per microframe), but I think that is still enough for control traffic. NOTE 2 ~~~~~~ Sarah Sharp expressed concern that maxing out periodic bandwidth could lead to vendor-specific hardware bugs on host controllers, because > It's entirely possible that you'll run into > vendor-specific bugs if you try to pack the schedule with isochronous > transfers. I don't think any hardware designer would seriously test or > validate their hardware with a schedule that is basically a violation of > the USB bus spec (more than 80% for periodic transfers). So far I've only tested this patch on my HP Mini 5103 with N10 chipset kirr@mini:~$ lspci 00:00.0 Host bridge: Intel Corporation N10 Family DMI Bridge 00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated Graphics Controller 00:02.1 Display controller: Intel Corporation N10 Family Integrated Graphics Controller 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02) 00:1c.3 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 4 (rev 02) 00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation NM10 Family LPC Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation N10/ICH7 Family SATA AHCI Controller (rev 02) 01:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01) 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8059 PCI-E Gigabit Ethernet Controller (rev 11) and the system works stable with 110us/uframe (~88%) isoc bandwith allocated for above-mentioned isochronous transfers. NOTE 3 ~~~~~~ This feature is off by default. I mean max periodic bandwidth is set to 100us/uframe by default exactly as it was before the patch. So only those of us who need the extreme settings are taking the risk - normal users who do not alter uframe_periodic_max sysfs attribute should not see any change at all. NOTE 4 ~~~~~~ I've tried to update documentation in Documentation/ABI/ thoroughly, but only "TBD" was put into Documentation/usb/ehci.txt -- the text there seems to be outdated and much needing refreshing, before it could be amended. Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:Kirill Smelkov <kirr@mns.spb.ru> Acked-by:
-
Kirill Smelkov authored
The only sysfs attr implemented so far is "companion" from ehci-hub.c, but in the next patch we are going to add another sysfs file, so prior to that let's structure things and move already-in-there sysfs code to separate file. NOTE: All the code I'm moving into this new file was written by Alan Stern (in 57e06c11 "EHCI: force high-speed devices to run at full speed"; Jan 16 2007), that's why I'm putting Copyright (C) 2007 by Alan Stern there after explicit request from the author. Signed-off-by:
-
Chris Forbes authored
Added missing const qualifier as flagged by checkpatch.pl Signed-off-by:
Chris Forbes <chrisf@ijw.co.nz> Signed-off-by:
-
Chris Forbes authored
Replaced __attribute__ ((packed)) with __packed; Signed-off-by:
-
Matthieu CASTET authored
Signed-off-by:
Matthieu CASTET <castet.matthieu@free.fr> Tested-by:
Pavankumar Kondeti <pkondeti@codeaurora.org> Signed-off-by:
-
Amit Blay authored
This patch adds SuperSpeed descriptors to the g_zero gadget. The SuperSpeed descriptors were added both for f_soursesink and f_loopback function drivers. Signed-off-by:
Tatyana Brokhman <tlinder@codeaurora.org> Signed-off-by:
Amit Blay <ablay@codeaurora.org> Signed-off-by:
-
Paul Zimmerman authored
Add SuperSpeed descriptors to the Network USB function drivers. This has been lightly tested using a Linux host. I was able to ssh from device to host and host to device, no obvious problems seen. Signed-off-by:
Paul Zimmerman <paulz@synopsys.com> Signed-off-by:
-
Yoshihiro Shimoda authored
The USB high speed device must support the TEST_MODE, but the driver didn't support it. When we sent the SET_FEATURE for TEST_MODE to the driver, the request was successful, but the module didn't enter the TEST_MODE. Signed-off-by:
-
Yoshihiro Shimoda authored
The USB high speed device must support the TEST_MODE, but the driver didn't support it. When we sent the SET_FEATURE for TEST_MODE to the driver, the request was successful, but the module didn't enter the TEST_MODE. Signed-off-by:
-
Yoshihiro Shimoda authored
BUSWAIT is a 4-bit-wide value that controls the number of access waits from the CPU to on-chip USB module. b'0000 inserts 0 wait (2 access cycles) and b'1111 inserts 15 waits (17 access cycles, hardware initial value), respectively. BUSWAIT value depends on peripheral clock frequency supplied to on-chip of each CPU, hence should be configurable through platform data. Note that this patch assumes that b'0000 (0 wait, 2 access cycles) is rerely used and considered as invalid. If valid 'buswait' data is not provided by platform, initial b'1111 (15 waits, 17 access cycles) will be applied as a safe default. Signed-off-by:
-
Yoshihiro Shimoda authored
When we run rmmod a gadget driver, the driver will call disable_controller(). Then, because the bit of USBE in SYSCFG0 was cleared in on_chip=1 mode, we could not connect the usb when we run insmod a gadget driver next time. This patch also cleans up probe() and ->stop() about unnecessary init_controller(). Signed-off-by:
-
Yoshihiro Shimoda authored
Signed-off-by:
-
Ajay Kumar Gupta authored
Restoring the missing INDEX register value in musb_restore_context(). Without this suspend resume functionality is broken with offmode enabled. Cc: stable@kernel.org Acked-by:
Anand Gadiyar <gadiyar@ti.com> Signed-off-by:
Ajay Kumar Gupta <ajay.gupta@ti.com> Signed-off-by:
-
- 05 Jul, 2011 5 commits
-
-
Sebastian Andrzej Siewior authored
Both fusb300 and langwell udcs seem to only work with 32-bit address space. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Sebastian Andrzej Siewior authored
- remove pointer u32 abuse in fusb300_fill_idma_prdtbl(). It is assigned the dma_addr to a pointer and then back. Poor families may have to recycle variables but we don't - don't free req.buf in error case. We don't do it in the ok case so it is probably wrong to do it in error case. - return in error case. There is no reason to continue without data and performing ops on an invalid pointer. - The if (d) statement is bogus since an invalid DMA pointer is ~0 on some architecutres. And since we return for the invalid case we don't need it. Signed-off-by:
-
Sebastian Andrzej Siewior authored
Fix the following compile warning: | usb/gadget/ci13xxx_udc.c: In function 'show_registers': | usb/gadget/ci13xxx_udc.c:1242:1: warning: the frame size of 2064 bytes is larger than 1024 bytes Signed-off-by:
-
Felipe Balbi authored
This patch fixes the following compile warnings: drivers/usb/gadget/net2272.c: In function ‘net2272_kick_dma’: drivers/usb/gadget/net2272.c:740:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Wformat] drivers/usb/gadget/net2272.c: In function ‘net2272_queue’: drivers/usb/gadget/net2272.c:859:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 8 has type ‘dma_addr_t’ [-Wformat] Signed-off-by: -
Felipe Balbi authored
This patch fixes the following compile warnings: drivers/usb/gadget/langwell_udc.c: In function ‘queue_dtd’: drivers/usb/gadget/langwell_udc.c:596:2: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] drivers/usb/gadget/langwell_udc.c: In function ‘langwell_udc_probe’: drivers/usb/gadget/langwell_udc.c:3274:2: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘size_t’ [-Wformat] drivers/usb/gadget/langwell_udc.c:3289:2: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘size_t’ [-Wformat] drivers/usb/gadget/langwell_udc.c: In function ‘langwell_udc_resume’: drivers/usb/gadget/langwell_udc.c:3473:2: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘size_t’ [-Wformat] drivers/usb/gadget/langwell_udc.c:3487:2: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘size_t’ [-Wformat] Signed-off-by:
-
