- 14 Aug, 2013 18 commits
-
-
Peter Chen authored
It is useless at below cases: - If we implement both usb host and device at chipidea driver. - If we don't need phy->otg. Tested-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peter Chen authored
For boards which have board level vbus control (eg, through gpio), we need to vbus operation according to below rules: - For host, we need open vbus before start hcd, and close it after remove hcd. - For otg, the vbus needs to be on/off when usb role switches. When the host roles begins, it opens vbus; when the host role finishes, it closes vbus. We put vbus operation to host as host is the only vbus user, When we are at host mode, the vbus is on, when we are not at host mode, vbus should be off. Tested-by:
-
Peter Chen authored
The vbus regulator is a common element for USB vbus operation, So, move it from glue layer to core. Tested-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by:
-
Fabio Estevam authored
After the rename to ci_hdrc we ended up with two MODULE_ALIAS entries, so remove the old one. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Reviewed-by:
-
Lothar Waßmann authored
Commit 40dcd0e8 ("usb: chipidea: add PTW, PTS and STS handling") introduced the following code to the ci_hdrc_probe() function: + if (!dev->of_node && dev->parent) + dev->of_node = dev->parent->of_node; This inadvertently associates the ci_hdrc device with the ci_hdrc_imx driver (which created the ci_hdrc device in the first place). This results in ci_hdrc_imx_probe() being run for the ci_hdrc device if ci_hdrc_probe() fails for some reason. ci_hdrc_imx_probe() will happily create a new ci_hdrc platform_device whose probing will likewise fail and trigger a new invocation of ci_hdrc_imx_probe() ... ad nauseam. Signed-off-by:
Lothar Waßmann <LW@KARO-electronics.de> Reviewed-and-tested-by:
-
Lothar Waßmann authored
If a role fails to start, propagate the error code up the call stack from probe. Signed-off-by:
-
Lothar Waßmann authored
This prevents the USB PHY refcount to be decremented below zero upon unloading the ci-hdrc-imx module. Signed-off-by:
-
Lothar Waßmann authored
This patch provides a cleaner solution to the problem described in commit 20a677fd ("usb: chipidea: improve kconfig"). The goal to be achieved is to force USB_CHIPIDEA=m if either USB_EHCI_HCD=m or USB_GADGET=m. If both are 'y' USB_CHIPIDEA may be selected to be 'm' or 'y'. The old patch had the drawback, that USB_CHIPIDEA could be chosen as 'y' though USB_EHCI_HCD or USB_GADGET (or both) were 'm' leading to a situation where USB_CHIPIDEA_HOST or USB_CHIPIDEA_UDC vanished from the config options producing a compilable but dysfunctional driver. Signed-off-by:
-
Peter Chen authored
Remove an unused macro leftover from the old initialization code. Signed-off-by:
-
Fabio Estevam authored
Currently hw_phymode_configure() is located inside hw_device_reset(), which is only called by chipidea udc driver. When operating in host mode, we also need to call hw_phymode_configure() in order to properly configure the PHY mode, so move this function into probe. After this change, USB Host1 port on mx53qsb board is functional. Signed-off-by:
Arnaud Patard <arnaud.patard@rtp-net.org> Reviewed-by:
-
Fabio Estevam authored
'res' is not used anywhere, so let's get rid of it. Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Felipe Balbi authored
if pdata is a NULL pointer we could cause a kernel oops when probing the driver. Make sure to cope with systems which won't pass pdata to the driver. Tested-by:
Paul Zimmerman <paulz@synopsys.com> Reported-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Sean O. Stalley authored
rh_call_control() contains a buffer, tbuf, which it uses to hold USB descriptors. These discriptors are eventually copied into the transfer_buffer in the URB. The buffer in the URB is dynamically defined and is always large enough to hold the amount of data it requests. tbuf is currently statically allocated on the stack with a size of 15 bytes, regardless of the size specified in the URB. This patch dynamically allocates tbuf, and ensures that tbuf is at least as big as the buffer in the URB. If an hcd attempts to write a descriptor containing more than 15 bytes ( such as the Standard BOS Descriptor for hubs, defined in the USB3.0 Spec, section 10.13.1 ) the write would overflow the buffer and corrupt the stack. This patch addresses this behavior. Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Sean O. Stalley <sean.stalley@intel.com> Signed-off-by:
-
Jack Pham authored
commit 9841f37a ("usb: ehci: Add support for SINGLE_STEP_SET_FEATURE test of EHSET") added additional code to the EHCI hub driver but it is anticipated to only have a limited audience (e.g. embedded silicon vendors and integrators). Avoid subjecting all EHCI (and in the future maybe xHCI/OHCI, etc.) HCD users to code bloat by conditionally compiling the EHSET-specific additions with a new Kconfig option, CONFIG_USB_HCD_TEST_MODE. Signed-off-by:
Jack Pham <jackp@codeaurora.org> Acked-by:
-
Frank Schäfer authored
The driver currently knows about 3 different PL2303 chip types: The two legacy chip types type_0 and type_1 (PL2303H ?) and the HX type. The device distinction is currently completely based on the examination of the USB descriptors. During the last years, Prolific has introduced further PL2303 chips, such as the HXD (HX rev. D), TA (which replaced the X/HX chips), SA, RA, EA and TB variants. Unfortunately, all these new chips are currently detected as HX chips, because they are all using the same bMaxPacketSize0 = 0x40 value in the USB device descriptor. At this point it is not clear if these chips are really working with the driver, there are just some positive indicators (like device manufacturers claiming Linux support for these devices or commit 8d48fdf6 "correctly handle baudrates above 115200" which should only be necessary for newer devices, ...) For a complete support of all devices, we need to distinguish between them, because they differ in several functional aspects, such as the maximum supported baud rate (HXD, TB, EA: 12Mbps, HX, TA: 6Mbps, RA: 1Mbps, SA: 115.2kbps), handshaking line support, RS422/485 and GPIO ports support (currently not supported by the driver). And there might be further differences that we don't know yet. This patch improves the chip type detection by evaluating the bcdDevice value of the device descriptor. The values are taken from the datasheets and are safe to use because manufacturers can't change them: 3.00: X/HX, TA 4.00: HXD, EA, RA, SA 5.00: TB The rest of the device descriptors is completely identical, so no further distinction is possible this way. Anyway, Prolifics "checkChipVersion.exe"-tool is definitely able to distinguish for example between the X/HX and the TA chips, so there must be a possibility to improve the distinction further... Signed-off-by:
Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by:
-
Frank Schäfer authored
The chip type distinction is getting more and more relevant and complicating, so always print the chip type. Printing a name string is also much better than just printing an internal index number. Signed-off-by:
-
Frank Schäfer authored
There is no need for two else-if constructs for the type_1 chip detection in pl2303_startup(), so merge them. Signed-off-by:
-
- 13 Aug, 2013 4 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usbGreg Kroah-Hartman authored
Felipe writes: usb: patches for v3.12 merge window All patches here have been pending on linux-usb and sitting in linux-next for a while now. The biggest things in this tag are: DWC3 learned proper usage of threaded IRQ handlers and now we spend very little time in hardirq context. MUSB now has proper support for BeagleBone and Beaglebone Black. Tegra's USB support also got quite a bit of love and is learning to use PHY layer and generic DT attributes. Other than that, the usual pack of cleanups and non-critical fixes follow. Signed-of-by: -
Sebastian Andrzej Siewior authored
Stephen Rothwell reported that this driver does not compile on PowerPC due to this missing include. One could argue why this driver is enabled on PowerPC in the first place but it sure isn't wrong to include headers for used function instead of to rely that they sneak in. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Sebastian Andrzej Siewior authored
Since the musb-gadget code now calls the dma engine properly it is possible to enable it for the TX path in device mode. AM335x Advisory 1.0.13 says that we may lose the toggle bit on multiple RX transfers. There is a workaround in host mode but none in device mode and therefore RX transfers are disabled. Signed-off-by:
-
Sebastian Andrzej Siewior authored
This patch makes use of the two function is_cppi_enabled() and tusb_dma_omap() instead of the ifdef for the proper DMA implementation setup code. It basically shifts the code right by one indention level and adds a few line breaks once the chars are crossed. Signed-off-by:
-
- 12 Aug, 2013 18 commits
-
-
Frank Schäfer authored
I've found some new datasheets which describe some additionally supported standard baud rates and I've verified them with my HX (rev. 3A) device. But adding support for individual (chip type specific) baud rates would add a good amount of extra code (especially when support for further chips will be added to the driver one day), which makes no sense as long as we are not using the direct baud rate encoding method for newer chips. So for now, just drop a comment about these additionally supported baud rates. The second comment is about the baud rate differences between the two encoding methods. In theory, we could optimize the code a bit by comparing the resulting baud rates of both methods and selecting the one which is closer to the requested baud rate. But that seems to be a bit overkill, because the differences are very small and the device likely uses the same baud rate generator for both methods so that the resulting baud rate would be the same. Signed-off-by:
-
Frank Schäfer authored
usb: pl2303: also use the divisor based baud rate encoding method for baud rates < 115200 with HX chips Now that the divisor based baud rate encoding method has been fixed and extended, it can also be used for baud rates < 115200 baud with HX chips. This makes it possible to adjust the baud rate almost continuously instead of just beeing able to select between 16 fixed standard values. Tested with a PL2303HX 04463A (week 46, 2004, rev 3A). Signed-off-by:
-
Frank Schäfer authored
Reinhard Max has done some tests with a PL2303HX (rev A) and a logic analyzer and it seems, that although the PL2303HX is specified for baud rates from 75 to 6M baud, the full divisor range can be used with the divisor based baud rate encoding method. This corresponds to baud rates from 46 to 24M baud. Baud rates down to 46 baud (max. divisor) have been confirmed to work even under heavy/permanent load, so remove the lower limit. Baud rates up to 24M baud should really be tested carefully in "real life" scenarios before removing the upper limit completely. Anyway, the Windows driver allows maximum baud rates of 110% of the specified limit, so for now, increase the upper limit to this value. Signed-off-by:
Reinhard Max <max@suse.de> Signed-off-by:
-
Frank Schäfer authored
Signed-off-by:
-
Frank Schäfer authored
Commit 0c967e7e "USB: serial: pl2303 works at 500kbps" added 500000 baud to the list of supported standard baud rates. But the reason why the driver works with this baud rate is, that since commit 8d48fdf6 "USB: PL2303: correctly handle baudrates above 115200" a second (divisor based) baud rate encoding method is used for values above 115200 baud, which is not limited to a fixed set of standard baud rates. Remove the 500000 baud value from the list of standard baud rates again, because this list is only used with the direct baud rate encoding method and 500000 baud is not supported with this method. Signed-off-by:
-
Frank Schäfer authored
usb: pl2303: do not round to the next nearest standard baud rate for the divisor based baud rate encoding method In opposition to the direct baud rate encoding method, the divisor based method is not limited to a fixed set of standard baud rates. Hence, there is no need to round to the next nearest standard value. Reported-by:
Mastro Gippo <gipmad@gmail.com> Signed-off-by:
-
Frank Schäfer authored
Based on the formula in the code description, Reinhard Max and me have investigated the devices behavior / functional principle of the divisor based baud rate encoding method. It turned out, that (although beeing a good starting point) the current code has some flaws. It doesn't work correctly for a wide range of baud rates and the divisor resolution can be improved. It also doesn't report the actually set baud rate. This patch fixes and improves the code for the divisor based baud rate encoding method a lot. It can now be used for the whole range of baud rates from 46 baud to 24M baud with a very good divisor resolution and userspace can read back the resulting baud rate. It also documents the formula used for encoding and the hardware behavior (including special cases). The basic algorithm, rounding and several code comments/explanations are provided by Reinhard Max. I've added some minor fixes, the handling of the special cases and further code/algorithm descriptions. Signed-off-by:
-
Thomas Pugliese authored
In the disconnect routine for the hwa_hc interface, it calls uwb_pal_unregister to unregister itself from the UWB subsystem. This function attempts to clean up the link to the host controller directory in the device's UWB radio control interface directory. If the disconnect routine for the radio control interface has already run, the uwb directory will be gone so the call to sysfs_remove_link generates a warning. Signed-off-by:
Thomas Pugliese <thomas.pugliese@gmail.com> Signed-off-by:
-
Thomas Pugliese authored
Prevent the USB core from suspending the HWA root hub since bus_suspend and bus_resume are not yet supported. Otherwise the PM system will chew up CPU time constantly attempting to suspend and resume the root hub but never succeeding. Signed-off-by:
-
Thomas Pugliese authored
This patch fixes a kernel panic that can occur when unplugging the HWA dongle while a downstream device is in the process of disconnecting. This involved 2 changes. First, call usb_lock_device_for_reset before usb_reset_device to synchronize the HWA's post_rest and disconnect routines. Second, set the hwarc->neep_urb and hwarc->rd_buffer to NULL when they are freed in the error path in the post_reset routine. This prevents a double free when the disconnect routine is called and attempts to free those resources again. Signed-off-by:
-
Oliver Neukum authored
Both could want to submit the same URB. Some checks of the flag intended to prevent that were missing. Signed-off-by:
Oliver Neukum <oneukum@suse.de> CC: stable@vger.kernel.org Signed-off-by:
-
Thomas Pugliese authored
wa_urb_enqueue_run locks and unlocks its list lock as it traverses the list of queued transfers. This was done to prevent deadlocking due to acquiring locks in reverse order in different places. The problem is that releasing the lock during the list traversal could allow the dequeue routine to corrupt the list while it is being iterated over. This patch moves all list entries to a temp list while holding the list lock, then traverses the temp list with no lock held. Signed-off-by:
-
Thomas Pugliese authored
The hub_status_data function on the wireless USB root hub controller (wusbhc_rh_status_data) always returns a positive value even if no ports have changed. This patch updates wusbhc_rh_status_data to only return a positive value if the root hub status needs to be queried. The current implementation can also leave the upper bits of the port bitmap uninitialized if wusbhc->ports_max is not one less than an even multiple of 8. This patch fixes that as well by initializing the buffer to 0. Signed-off-by:
-
Manu Gautam authored
The USB Embedded High-speed Host Electrical Test (EHSET) defines the SINGLE_STEP_SET_FEATURE test as follows: 1) The host enumerates the test device with VID:0x1A0A, PID:0x0108 2) The host sends the SETUP stage of a GetDescriptor(Device) 3) The device ACKs the request 4) The host issues SOFs for 15 seconds allowing the test operator to raise the scope trigger just above the SOF voltage level 5) The host sends the IN packet 6) The device sends data in response, triggering the scope 7) The host sends an ACK in response to the data This patch adds additional handling to the EHCI hub driver and allows the EHSET driver to initiate this test mode by issuing a a SetFeature request to the root hub with a Test Selector value of 0x06. From there it mimics ehci_urb_enqueue() but separately submits QTDs for the SETUP and DATA/STATUS stages in order to insert a delay in between. Signed-off-by:
Manu Gautam <mgautam@codeaurora.org> Acked-by:
-
Mark Brown authored
If someone provided meaningful error codes from reset() we should tell the user what they were. Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Hans de Goede authored
Correct use of devnum in supports_autosuspend documentation, the sysfs path contains busnum-port.port.port not busnum-devnum (which is the usb bus device address). Signed-off-by:
-
Hans de Goede authored
The config descriptors as read from /proc/bus/usb/BBB/DDD are in *bus* endian format. Correct proc_usb_info.txt to correctly reflect that. Signed-off-by:
-
Hans de Goede authored
While reading the config parsing code I noticed this check is missing, without this check config->desc.wTotalLength can end up with a value larger then the dev->rawdescriptors length for the config, and when userspace then tries to get the rawdescriptors bad things may happen. Signed-off-by:
-
