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: Lothar Waßmann <LW@KARO-electronics.de>
Reviewed-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>
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: Fabio Estevam <fabio.estevam@freescale.com>
Tested-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Reviewed-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>
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: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9841f37a1c ("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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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
8d48fdf689 "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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is no need for two else-if constructs for the type_1 chip
detection in pl2303_startup(), so merge them.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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: Felipe Balbi <balbi@ti.com>
Conflicts:
drivers/usb/gadget/udc-core.c
drivers/usb/host/ehci-tegra.c
drivers/usb/musb/omap2430.c
drivers/usb/musb/tusb6010.c
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: Felipe Balbi <balbi@ti.com>
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 <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
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: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
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 <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Reinhard Max <max@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <fschaefer.oss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <fschaefer.oss@googlemail.com>
Signed-off-by: Reinhard Max <max@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Reinhard Max <max@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
