These updates add support for Moxa UPort 1100-series devices through a
new mxu11x0 driver.
The cp210x driver gains proper support for cp2108 devices by working
around a couple of firmware bugs, and generic wait-until-sent support
(e.g. for tcdrain) is also added.
Included are also some general clean ups.
Signed-off-by: Johan Hovold <johan@kernel.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJWhQifAAoJEEEN5E/e4bSV5QoQAIu6882YOuChh7T/aKUmIUKY
CKBmt02IWW0w2IUjfsYSMRwLKYywbss10gv6nF0QgwlLzCy2bhh+YAf12lFDyT6n
ItUSbuTIDLBtlGjUQaTBPDHkqZ9VkkKDnh/WTEzm13wuhVwdu6Lw/NAqWF5lQVSf
u4pQTDS1YkFD2I7YYCYijYfCVXJD2EztGC4oaWt7LbyRPwPGnlosW7s6RZbb4Bk1
rQeHN/3LQ4lKJ+lfA87PH31Nh4mhw9FsNYjjNfBczAE/uHuRkROJXG2FOjptHEoJ
zT04mx1sMCkQY7d9yit19/b+yHjwYorjFK/2pbkzU8YkkdfsXiZCVGXywiZzROKp
8DNtS+7oK/O5GeTo/5cQTC58/MEYAqgDhwDOwNj1HoP8PICzES3uKLuEC1dWzUWF
VblZaAdaVg259Yim2XxSKiovujDJAR0OwApDCdCankJYcBbtYKgvz+wThFUo00f+
A568bPR3hGm38AZp1GVZa4FCR9pKEiK+5amyKBo5CBYcnkGbHUBZIKdVIrfXlb+T
Pm4xOCrfwznJhviGqiuscOjPODoeIAkNofe8AKgEgbt6U3UOLa8XZxrhia4dqIe+
UoUiPt4pmL41JHNPRpte4IWTz4PW4w2KQZe4rGgXjzVmtpLKH9jrVkfWomi4oXqT
tfXq//igbK+Nq3RwZ1+m
=tyK5
-----END PGP SIGNATURE-----
Merge tag 'usb-serial-4.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next
Johan writes:
USB-serial updates for v4.5-rc1
These updates add support for Moxa UPort 1100-series devices through a
new mxu11x0 driver.
The cp210x driver gains proper support for cp2108 devices by working
around a couple of firmware bugs, and generic wait-until-sent support
(e.g. for tcdrain) is also added.
Included are also some general clean ups.
Signed-off-by: Johan Hovold <johan@kernel.org>
Drop redundant function name from a few error messages.
Drop redundant error message when generic open fails.
Signed-off-by: Johan Hovold <johan@kernel.org>
Make sure to release the private data before returning -ENODEV after
having downloaded the firmware during first probe.
Clean up the error paths while at it.
Signed-off-by: Johan Hovold <johan@kernel.org>
Fix memory leak in port-probe error path by verifying the interrupt-in
urb before allocating the private data.
Signed-off-by: Johan Hovold <johan@kernel.org>
Add a driver which supports :
- UPort 1110 : 1 port RS-232 USB to Serial Hub.
- UPort 1130 : 1 port RS-422/485 USB to Serial Hub.
- UPort 1130I : 1 port RS-422/485 USB to Serial Hub with Isolation.
- UPort 1150 : 1 port RS-232/422/485 USB to Serial Hub.
- UPort 1150I : 1 port RS-232/422/485 USB to Serial Hub with Isolation.
This driver is based on GPL MOXA driver written by Hen Huang and available
on MOXA website. The original driver was based on io_ti serial driver.
Signed-off-by: Mathieu OTHACEHE <m.othacehe@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
- Delete static debug for chipidea driver.
- Suspend USB core when A device tries to switch to peripheral mode,
at former design, it just stopped SoF simply but USB core doesn't know it.
- Several small changes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWfLjWAAoJEEhZKYFQ1nG7R/cH/3xP4nz3pDDOpsX6U8Q1V81D
K7118WeAOx64sdGRZ3bsEjNko4NI1j2jcQU2Zgtx/I5Q0lJfNm4linNNWJHKEb/m
1VJVxFJXP6lwWImVWNJbyvhzel8mlgaNza+ZabUOAFmSig9q3yHUq5lDqzPVLZWY
z7lYQS+sOsCorsQierXiRxSRvkipB32NpdfhEXkj6P6Ji2a1UDDRA7F3f9k9t8QR
iI1T5+gbJL/3eo+ToOdlGciIUjoa4bK5b0Iz+QeU2eSOqjuVcu4tZO5IJbH/o10Z
dAhcDOr0DPEGzfpwihevyX3HcRKTKHPlzo2GdW5TJ5e7vm5C43fGHB0GgpIJBWw=
=7ZBY
-----END PGP SIGNATURE-----
Merge tag 'usb-ci-v4.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-testing
Peter writes:
The chipidea changes for v4.5-rc1
- Delete static debug for chipidea driver.
- Suspend USB core when A device tries to switch to peripheral mode,
at former design, it just stopped SoF simply but USB core doesn't know it.
- Several small changes.
A ton of improvements to dwc2 have been made. The
driver should be a lot more stable on v4.5 then ever
before.
Our good old dwc3 got a few cleanups and misc fixes
and also added support to Xilinx's integration of
this IP.
Yoshihiro Shimoda gives us support for a new USB3
peripheral controller from Renesas.
Other than these, the usual misc fixes all over the
place.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWes7RAAoJEIaOsuA1yqREC5cP/jzIWxyHj5rNPr8VGnjzd4Wh
wcsxGmTLHA+c5FFer0+hnj8DXSELyYV2Lcfng1pkPuGWAsPzdd9FvNV/9Q1RmqPG
R96JB9N3dnDY7erJZkmpDOJvGg+p/Ec6GmFkrTVWQeXTwlkI1mdvaZwV9iFQfmb0
V/gdQWdlmbTarmwPLxEpaDN+JDB9Gm6RdyK/B5pC8ZeF9S42aQIFCrfOfjP3OiZj
o5Q6Gv2YxElSKscObLFyltfgb05YD/yO0al/wm7p0lGXdsaMMokjyxrbibnoFNic
Z5lexn8DqJ/yjy9w5K3Tj+b4nSfokUibUB3r0Cwbv6di7g0gUNclUwg79X8tSoDS
T2hkpmpAIvb2z80wlLFpGptfC39JoLtzAkxfBbnu025QxFeI4AknzQuXiW8UgvSO
/t1Aq6jg3j+GTuU+BiBnLjEPBZSsh/b7qIpreaXIIb7A01e2T7QT5i8kB7Zk5d5F
4aLBH/QHHXS+RGJmY9qgW6wee0XcaCysCUctwVuPY1fGukPrIFxjhPnJtjjqKnW7
41RCTwv2DKmm6CV5xVXYfSMVkmWBrNlpjugZkYH9yRbAzwPA/H/A5iPJwoOnGshn
VNuFJOBKJJFR0u072LidgMWZ7AaeBmWnageAU1sFr8iXWiWESwaAjI4ouPNVugPI
PxYdhPlc+lHBPXDrPh8p
=8vM4
-----END PGP SIGNATURE-----
Merge tag 'usb-for-v4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next
Felipe writes:
usb: patches for v4.5
A ton of improvements to dwc2 have been made. The
driver should be a lot more stable on v4.5 then ever
before.
Our good old dwc3 got a few cleanups and misc fixes
and also added support to Xilinx's integration of
this IP.
Yoshihiro Shimoda gives us support for a new USB3
peripheral controller from Renesas.
Other than these, the usual misc fixes all over the
place.
Directly manipulate the controller regsiter to suspend the usb bus
for HNP is not the proper way, this should be done through the usbcore
by usb autosuspend. So to start HNP, autosuspend support should be
added for OTG devices interface driver if it's not enabled.
Signed-off-by: Li Jun <jun.li@freescale.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Set ci->hcd and ci->otg.host to be null in host_stop since the
hcd already freed.
Signed-off-by: Li Jun <jun.li@freescale.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
call to of_find_property() before of_property_read_u32() is unnecessary.
of_property_read_u32() anyway calls to of_find_property() only.
Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
disable wakeup irq during shutdown, otherwise kexec fails for
kernels that setup irq handlers before resetting the hardware
Signed-off-by: Andreas Fenkart <andreas.fenkart@dev.digitalstrom.org>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Since this configuration option has deleted, cleans up all
its references.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Reported-by: Valentin Rothberg <valentinrothberg@gmail.com>
Since we need to mount debugfs to show/store the things we
want to debug, it is duplicated to add another configuration
to enable it. Meanwhile, with CONFIG_USB_CHIPIDEA_DEBUG,
we can't support chipidea debugfs at runtime.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Cc: Jun Li <jun.li@freescale.com>
_hardware_enqueue() didn't check for errors when using
add_td_to_list() which can fail if dma_pool_alloc fails, thus
causing a kernel panic when lastnode->ptr is NULL.
Signed-off-by: Felipe F. Tonello <eu@felipetonello.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Update comments to reflect current state of functions.
Signed-off-by: Felipe F. Tonello <eu@felipetonello.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
if we have a !PM kernel build, our runtime
suspend/resume callbacks will be left defined but
unused. Add a ifdef CONFIG_PM guard.
Signed-off-by: Felipe Balbi <balbi@ti.com>
If the request->length is zero, a ZLP should already be sent due to that
and another ZLP is not needed to terminate the transfer.
Fixes: 04c03d10e5 ("usb: dwc3: gadget: handle request->zero")
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
R-Car H3 has USB3.0 peripheral controllers. This controller's has the
following features:
- Supports super, high and full speed
- Contains 30 pipes for bulk or interrupt transfer
- Contains dedicated DMA controller
This driver doesn't support the dedicated DMAC for now.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
In specific conditions (involving usb hubs) dwc2 devices can create a
lot of interrupts, even to the point of overwhelming devices running
at low frequencies. Some devices need to do special clock handling
at shutdown-time which may bring the system clock below the threshold
of being able to handle the dwc2 interrupts. Disabling dwc2-irqs
in a shutdown callbacks prevents reboots/poweroffs from getting stuck
in such cases.
The hsotg struct already contains an unused irq element, so we can
just use it to store the irq number for the shutdown callback.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Heiko Stuebner <heiko.stuebner@collabora.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Use list_for_each_entry_safe() instead of list_for_each_safe() to
simplify the code.
Signed-off-by: Geliang Tang <geliangtang@163.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The phy's init routine must be called before it can be used. Do so in
musb_init_controller and the matching shutdown in musb_remove.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The "enumspd" field is located in register DSTS[2:1], but the code
which checks the bitfield does not shift the value accordingly. This
in turn causes incorrect detection of gadget link partner speed in
dwc2_hsotg_irq_enumdone() .
Shift the value accordingly to fix the problem with speed detection.
Acked-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Remove call to dwc2_hsotg_init() from dwc2_gadget_init(). The
gadget_init function should not access any device registers because the
mode isn't guaranteed here.
Also, this is already called elsewhere before anything starts on the
gadget so it is not necessary here.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reset already happens before this so just force the dr_mode.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The delay for force mode is only 25ms according to the databook.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The dwc2_core_reset() function exists in the core so use that one
instead.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Use the previously cached hw params in the gadget. This saves a reset
and force mode in the gadget initialization during probe and makes
getting the hardware parameters consistent between gadget and host.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Adds separate functions to get the host and device specific hardware
parameters. The functions check whether the parameters need to be read
at all, depending on dr_mode, and forces the mode only if necessary.
This saves some delays during probe. This also adds two device mode
parameters that will be used by the gadget.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Added functions to set force mode for host and device. These functions
will check the current mode and only force if needed thus avoiding
unnecessary force mode delays. However clearing the mode is currently
done unconditionally and with the delay in place. This is needed during
the connector ID status change interrupt in order to ensure that the
mode has changed properly. This preserves the old behavior only for this
case. The warning comment about this is moved into the clear mode
condition.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The reset is required to get reset values of the hardware parameters but
the force mode is not. Move the base reset into dwc2_get_hwparams() and
do the reset and force mode afterwards.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
These functions should go in core.h where they can be called from core,
device, or host.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The dr_mode parameter was being checked against how the dwc2 module
was being configured at compile time. But it wasn't checked against
the hardware capabilities, nor were the hardware capabilities checked
against the compilation parameters.
This commit adds those checks and adjusts dr_mode to an appropriate
value, if needed. If the hardware capabilities and module compilation
do not match then we fail as it wouldn't be possible to run properly.
The hardware, module, and dr_mode, can each be set to host, device,
or otg. Check that all these values are compatible and adjust the
value of dr_mode if possible.
The following table summarizes the behavior:
actual
HW MOD dr_mode dr_mode
------------------------------
HST HST any : HST
HST DEV any : ---
HST OTG any : HST
DEV HST any : ---
DEV DEV any : DEV
DEV OTG any : DEV
OTG HST any : HST
OTG DEV any : DEV
OTG OTG any : dr_mode
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Added functions to query the GHWCFG2.OTG_MODE. This tells us whether the
controller hardware is configured for OTG, device-only, or host-only.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
dwc2_core_reset() was previously renamed to
dwc2_core_reset_and_dr_force_mode(). Now add back dwc2_core_reset() which
performs only a basic core reset without forcing the mode.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Renamed dwc2_core_reset() to dwc2_core_reset_and_force_dr_mode(). This
describes what it is doing more accurately. This is in preparation of
introducing a plain dwc2_core_reset() function that only performs the
reset and doesn't force the mode.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
According to the databook, the core soft reset should be done before
checking for AHBIDLE. The gadget version of core reset had it correct
but the hcd version did not. This fixes the hcd version.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Calls to dwc2_core_reset() are currently very slow, taking at least
150ms (possibly more). It behooves us to take as many of these calls
out as possible.
It turns out that the calls in dwc2_fs_phy_init() and dwc2_hs_phy_init()
should (as documented in the code) only be needed if we need to do a PHY
SELECT. That means that if we see that we can avoid the PHY SELECT then
we can avoid the reset.
This patch appears to successfully bypass two resets (one per USB
device) on rk3288-based ARM Chromebooks.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
I found that the probe function of dwc2 driver takes much time
when kernel boot up. There are many long delays in the probe
function these take almost 1 second.
This patch trying to reduce unnecessary delay time.
In dwc2_core_reset() I see it use two at least 20ms delays to
wait AHB idle and core soft reset, but dwc2 data book said that
dwc2 core soft reset and AHB idle just need a few clocks (I think
it refers to AHB clock, and AHB clock run at 150MHz in my RK3288
board), so 20ms is too long, delay 1us for wait AHB idle and soft
reset is enough.
And in dwc2_get_hwparams() it takes 150ms to wait ForceHostMode
and ForceDeviceMode valid but in data book it said software must
wait at least 25ms before the change to take effect, so I reduce
this time to 25ms~50ms. By the way, is there any state bit show
that the force mode take effect ? Could we poll curmod bit for
figuring out if the change take effect ?
It seems that usleep_range() at boot time will pick the longest
value in the range. In dwc2_core_reset() there is a very long
delay takes 200ms, and this function run twice when probe, could
any one tell me is this delay time resonable ?
I have tried this patch in my RK3288-evb board. It works well.
Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
On some host-only DWC2 ports (like the one in rk3288) when we set
GUSBCFG_FORCEHOSTMODE in GUSBCFG and then read back, we don't see the
bit set. Presumably that's because the port is always forced to HOST
mode so there's no reason to implement these status bits.
Since we know dwc2_core_reset() is always called before
dwc2_get_hwparams() and we know dwc2_core_reset() should have set
GUSBCFG_FORCEHOSTMODE whenever hsotg->dr_mode == USB_DR_MODE_HOST, we
can just check hsotg->dr_mode to decide that we can skip the delays in
dwc2_get_hwparams().
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
In (usb: dwc2: reset dwc2 core before dwc2_get_hwparams()) we added an
extra reset to the probe path for the dwc2 USB controllers. This
allowed proper detection of parameters even if the firmware had already
used the USB part.
Unfortunately, this extra reset is quite slow and is affecting boot
speed. We can avoid the double-reset by skipping the extra reset that
would happen just after the one we added. Logic that explains why this
is safe:
* As of the CL mentioned above, we now always call dwc2_core_reset() in
dwc2_driver_probe() before dwc2_hcd_init().
* The only caller of dwc2_hcd_init() is dwc2_driver_probe(), so we're
guaranteed that dwc2_core_reset() was called before dwc2_hdc_init().
* dwc2_hdc_init() is the only caller that passes an irq other than -1 to
dwc2_core_init(). Thus if dwc2_core_init() is called with an irq
other than -1 we're guaranteed that dwc2_core_reset was called before
dwc2_core_init().
...this allows us to remove the dwc2_core_reset() in dwc2_core_init() if
irq is not < 0.
Note that since "irq" wasn't used in the function dwc2_core_init()
anyway and since select_phy was always set at exactly the same times we
could avoid the reset, we remove "irq" and rename "select_phy" to
"initial_setup" and adjust the callers accordingly.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
We initiate dwc2 usb controller in BIOS, dwc2_core_reset() should
be called before dwc2_get_hwparams() to reset core registers to
default value. Without this the FIFO setting might be incorrect
because calculating FIFO size need power-on value of
GRXFSIZ/GNPTXFSIZ/HPTXFSIZ registers.
This patch could avoid warnning massage like in rk3288 platform:
[ 2.074764] dwc2 ff580000.usb: 256 invalid for
host_perio_tx_fifo_size. Check HW configuration.
Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Previously dwc2_get_hwparams() was changing GUSBCFG and not putting it
back the way it was (specifically it set and cleared FORCEHOSTMODE).
Since we want to move dwc2_core_reset() _before_ dwc2_get_hwparams() we
should make sure dwc2_get_hwparams() isn't messing with things in a
permanent way.
Since we're now looking at GUSBCFG, it's obvious that we shouldn't need
all the extra delays if FORCEHOSTMODE was already set. This will avoid
some delays for any ports that have forced host mode.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
When receiving GINTSTS_GINNAKEFF or GINTSTS_GOUTNAKEFF interrupt,
DCTL will be overwritten with DCTL_CGOUTNAK or DCTL_CGNPINNAK values.
Instead of overwriting it, write only needed bits.
It could cause an issue if GINTSTS_GINNAKEFF or GINTSTS_GOUTNAKEFF
interrupt is received after dwc2 disabled pullup by writing
DCTL_SFTDISCON bit.
Pullup will then be re-enabled whereas it should not.
Acked-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Gregory Herrero <gregory.herrero@intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
To stop an out endpoint, software should set sets the Global OUT NAK,
but not the Global Non-periodic IN NAK. This driver bug leads the out-ep
failed be in disabled state with below error.
dwc2_hsotg_ep_stop_xfr: timeout DOEPCTL.EPDisable
Acked-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Du, Changbin <changbin.du@intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
It dose not work when we want to use the usb-to-serial port based
on one usb gadget as a console. Thus this patch adds the console
initialization to support this request.
To avoid the re-entrance when transferring data with usb endpoint,
it introduces a kthread to do the IO transmission.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
We want the USB and PHY fixes in here as well to make things easier for
testing and development.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
