Without CONFIG_PM, we get a new build warning here:
drivers/usb/renesas_usbhs/common.c:860:12: error: 'usbhsc_resume' defined but not used [-Werror=unused-function]
static int usbhsc_resume(struct device *dev)
^~~~~~~~~~~~~
drivers/usb/renesas_usbhs/common.c:844:12: error: 'usbhsc_suspend' defined but not used [-Werror=unused-function]
static int usbhsc_suspend(struct device *dev)
^~~~~~~~~~~~~~
Fixes: d54d334e75 ("usb: renesas_usbhs: Use SIMPLE_DEV_PM_OPS macro")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
register_root_hub() calls memset() setting usb_dev->bus->devmap.
devicemap to 0 during hcd probe function (usb_hcd_pci_probe). But
in previous function which is also the procedure of usb_hcd_pci_probe(),
usb_bus_init() already initialized bus->devmap calling memset().
Furthermore, register_root_hub() is called only once in kernel.
So, calling memset() which resets usb_bus->devmap.devicemap in
register_root_hub() is redundant.
Signed-off-by: Suwan Kim <suwan.kim027@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
So it looks like folks are interested in dwc3 again. Almost 64% of the
changes are in dwc3 this time around with some other bits in gadget
functions and dwc2.
There are two important parts here: a. removal of the waitqueue from
dwc3's dequeue implementation, which will guarantee that gadget
functions can dequeue from any context and; b. better method for
starting isochronous transfers to avoid, as much as possible, missed
isoc frames.
Apart from these, we have the usual set of non-critical fixes and new
features all over the place.
-----BEGIN PGP SIGNATURE-----
iQJRBAABCAA7FiEElLzh7wn96CXwjh2IzL64meEamQYFAlwQ7sQdHGZlbGlwZS5i
YWxiaUBsaW51eC5pbnRlbC5jb20ACgkQzL64meEamQbioA//fSpx5SV7undE1skG
lgjx7Uv2lqnU1kJxhTtyH54tZVhGMmaz4mDVJ3bRk4xotdh3BGQ7nRuui9PDGZmC
81bSjRBVvHXG0xtQQ1AjNc6vTf5h2MVRAZ4U2dp7pkNOgkoWQSakyH3Tz4Brhpfh
UWHLaVYrCb2R68b1pmQbJ6ckSkOu9Wt1yj3SJxvSOkRdbSgb9+khTNZJyyWuGort
zw6pcK33AuLwfOuz7qk8Wihqwi6BOgSrCGU8UfspBRfGhZrw3DSTnS3wYZjdR0QF
2/jwoBwt59i2hpFsMHmMYGU+307oVQ6Y9b/PXpnj4KqIG2CROB8eirDFkToxe4hC
Udy06IA70HUTBKzFmK1gCKZCZW3t2sB+zHtoVHJ8EARlFHWdLxLp83hA9p2Llfon
41iKnkf9CTiO2koEEzuOUOQW+KctIawryiUi4m+C5ZhJBKNk4GvIpXAg1JC9QX9E
GyqEICkg1dvc3GG5HYjPU7xq8mEdcHVOrHoiUci4zo9hMh6nHt7dboNeXQ13LNU9
joEqLvKEhUsm0J7cKWYOpxlHmNWGWNgqRas4Mot9zLUP7yYrxqLT5b2hD3PcjPl4
Jl+rbm4/2YMztWAnCU85EEPwVgJx9k7uyAEtXtQaWUValsVsWUWI1/F//IjYeLZI
AUx1euoarbCp6mXIoHLsOHV02uc=
=n8VS
-----END PGP SIGNATURE-----
Merge tag 'usb-for-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next
Felipe writes:
USB changes for v4.21
So it looks like folks are interested in dwc3 again. Almost 64% of the
changes are in dwc3 this time around with some other bits in gadget
functions and dwc2.
There are two important parts here: a. removal of the waitqueue from
dwc3's dequeue implementation, which will guarantee that gadget
functions can dequeue from any context and; b. better method for
starting isochronous transfers to avoid, as much as possible, missed
isoc frames.
Apart from these, we have the usual set of non-critical fixes and new
features all over the place.
* tag 'usb-for-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb: (56 commits)
usb: dwc2: Fix disable all EP's on disconnect
usb: dwc3: gadget: Disable CSP for stream OUT ep
usb: dwc2: disable power_down on Amlogic devices
Revert "usb: dwc3: pci: Use devm functions to get the phy GPIOs"
USB: gadget: udc: s3c2410_udc: convert to DEFINE_SHOW_ATTRIBUTE
usb: mtu3: fix dbginfo in qmu_tx_zlp_error_handler
usb: dwc3: trace: add missing break statement to make compiler happy
usb: dwc3: gadget: Report isoc transfer frame number
usb: gadget: Introduce frame_number to usb_request
usb: renesas_usbhs: Use SIMPLE_DEV_PM_OPS macro
usb: renesas_usbhs: Remove dummy runtime PM callbacks
usb: dwc2: host: use hrtimer for NAK retries
usb: mtu3: clear SOFTCONN when clear USB3_EN if work as HS mode
usb: mtu3: enable SETUPENDISR interrupt
usb: mtu3: fix the issue about SetFeature(U1/U2_Enable)
usb: mtu3: enable hardware remote wakeup from L1 automatically
usb: mtu3: remove QMU checksum
usb/mtu3: power down device ip at setup
usb: dwc2: Disable power down feature on Samsung SoCs
usb: dwc3: Correct the logic for checking TRB full in __dwc3_prepare_one_trb()
...
Disabling all EP's allow to reset EP's to initial state.
Introduced new function dwc2_hsotg_ep_disable_lock() which
before calling dwc2_hsotg_ep_disable() function acquire
hsotg->lock and release on exiting.
From dwc2_hsotg_ep_disable() function removed acquiring
hsotg->lock.
In dwc2_hsotg_core_init_disconnected() function when USB
reset interrupt asserted disabling all ep’s by
dwc2_hsotg_ep_disable() function.
This updates eliminating sparse imbalance warnings.
Reverted changes in dwc2_hostg_disconnect() function.
Introduced new function dwc2_hsotg_ep_disable_lock().
Changed dwc2_hsotg_ep_ops. Now disable point to
dwc2_hsotg_ep_disable_lock() function.
In functions dwc2_hsotg_udc_stop() and dwc2_hsotg_suspend()
dwc2_hsotg_ep_disable() function replaced by
dwc2_hsotg_ep_disable_lock() function.
In dwc2_hsotg_ep_disable() function removed acquiring
of hsotg->lock.
Fixes: dccf1bad4b ("usb: dwc2: Disable all EP's on disconnect")
Signed-off-by: Minas Harutyunyan <hminas@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Up to now the polarity of the over current pin was hard coded to active
high. Use the already defined device tree properties to configure polarity
on i.MX25, too. In difference to i.MX6/7 use active high behavior if the
polarity is unspecified to keep compatibility to existing device trees.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
The polarity of the over current detection pin isn't configured on i.MX6/7
if it's unspecified in the device tree. So the actual configuration depends
on bootloader behavior which is bad.
So encourage users to fix their device tree by issuing a warning in this
case.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
The status quo on i.MX6 is that if "over-current-active-high" is
specified in the device tree this is configured as expected. If
the property is missing polarity isn't changed and so the
polarity is kept as setup by the bootloader. Reset default is
active high, so active low can only be used with help by the
bootloader. On i.MX7 it is similar, but there disabling of
over current detection has a similar inconsistency.
This patch introduces a new property that allows to explicitly
configure for active low over current detection and consistently
sets this up. In the absence of an explicit configuration the
bit is kept as is. On i.MX7 over current detection is used unless
disabled in the device tree.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
The chipidea controller has some special requirements during
suspend/resume, override common ehci->hub_control to implement
it.
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
To support imx HSIC, there are some special requirement:
- The HSIC pad is 1.2v, it may need to supply from external
- The data/strobe pin needs to be pulled down first, and after
host mode is initialized, the strobe pin needs to be pulled up
- During the USB suspend/resume, special setting is needed
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
NXP (Freecale) imx HSIC design has some special requirements, add
some flags at host code to handle them.
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
In stream mode, when fast-forwarding TRBs, the stream number
is not cleared causing the new stream to not get assigned. So
we don't want controller to carry on transfers when short packet
is received. So disable the CSP for stream capable endpoint.
This is based on the 3.30a Programming guide, where table 3-1
device descriptor structure field definitions says for CSP bit
If this bit is 0, the controller generates an XferComplete event
and remove the stream. So if we keep CSP as 1 then switching between
streams would not happen as in stream mode, when fast-forwarding
TRBs, the stream number is not cleared causing the new stream to not get
assigned.
Signed-off-by: Tejas Joglekar <joglekar@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/usb/serial/mos7840.c: In function 'mos7840_send_cmd_write_baud_rate':
drivers/usb/serial/mos7840.c:1584:16: warning:
variable 'number' set but not used [-Wunused-but-set-variable]
drivers/usb/serial/mos7840.c: In function 'mos7840_change_port_settings':
drivers/usb/serial/mos7840.c:1695:21: warning:
variable 'serial' set but not used [-Wunused-but-set-variable]
'number' never used since introduction in commit 3f5429746d ("USB: Moschip
7840 USB-Serial Driver")
'serial' not used since commit 5833041f1b ("USB: serial: remove unnecessary
reinitialisations of urb->dev")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Disable power_down by setting the parameter to
DWC2_POWER_DOWN_PARAM_NONE. This fixes a problem on various Amlogic
Meson SoCs where USB devices are only recognized when plugged in before
booting Linux. A hot-plugged USB device was not detected even though the
device got power (my USB thumb drive for example has an LED which lit
up).
A similar fix was implemented for Rockchip SoCs in commit c216765d3a
("usb: dwc2: disable power_down on rockchip devices"). That commit
suggests that a change in the dwc2 driver is the cause because the
default value for the "hibernate" parameter (which then got renamed to
"power_down" to support other modes) was changed in the v4.17 merge
window with:
commit 6d23ee9caa ("Merge tag 'usb-for-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-testing").
Cc: <stable@vger.kernel.org> # 4.19
Acked-by: Minas Harutyunyan <hminas@synopsys.com>
Suggested-by: Christian Hewitt <christianshewitt@gmail.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Refactoring, no functional changes.
But worth mentioning that checking for port link resume state is now behind
a additional port power check.
This is fine as ports can't be in resume state if port power bit is not
set.
xhci spec section 4.19.1.1.6 figure 34 shows that port power bit must be
set for all 'Enable' substates, including U0,U1,U2,U3 (suspended), Resume,
and RExit states.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Move U0 link state handing to USB3 and USB2 specific functions
Note that
bus_state->resuming_ports:
bus_state->resume_done[]:
are only used for USB2, and don't need to cleared for USB3 ports
No functional changes
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Group the code where the wPortstatus and wPortChange bits
are set into one place.
No functional changes
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mostly refactoring, with the exception that USB_PORT_STAT_L1 link state
is reported if xhci port link is in U2 AND port is powered.
Previously we did not check if the port was powered, but according to
xhci spec 4.19.1.1.6 All the 'Enabled' states, including
USB_PORT_STAT_L1 (U2), U1, U0 and U3 must have Port power bit set.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that each root hub has their own bus_state strucure the
hcd_undex() used to get the correct bus_state strucure is
no longer needed.
No functional changes
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Move the bus_state structure under struct usb_hub.
We need a bus_state strucure for each roothub to keep track of suspend
related info for each port.
Instead of keeping an array of two bus_state structures right under
struct xhci, it makes more sense move them to the xhci_hub structure.
No functional changes.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It is introduced for the pre-0.96 xHC controllers, and the driver only
support HW LPM for 1.0 and later controllers.It's not actually used now
and is thought not to be used in the future any more, so just remove it.
Signed-off-by: Zeng Tao <prime.zeng@hisilicon.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 211f658b7b ("usb: dwc3: pci: Use devm functions to get
the phy GPIOs") changed the code to claim the PHY GPIOs permanently
for Intel Baytrail devices.
This causes issues when the actual PHY driver attempts to claim the
same GPIO descriptors. For example, tusb1210 now fails to probe with:
tusb1210: probe of dwc3.0.auto.ulpi failed with error -16 (EBUSY)
dwc3-pci needs to turn on the PHY once before dwc3 is loaded, but
usually the PHY driver will then hold the GPIOs to turn off the
PHY when requested (e.g. during suspend).
To fix the problem, this reverts the commit to restore the old
behavior to put the GPIOs immediately after usage.
Link: https://www.spinics.net/lists/linux-usb/msg174681.html
Cc: stable@vger.kernel.org
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/usb/mtu3/mtu3_qmu.c: In function 'qmu_tx_zlp_error_handler':
drivers/usb/mtu3/mtu3_qmu.c:385:22: warning:
variable 'req' set but not used [-Wunused-but-set-variable]
It seems dbginfo original intention is print 'req' other than 'mreq'
Acked-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
The missed break statement in the outer switch makes the code fall through
always and thus always same value will be printed.
Besides that, compiler warns about missed fall through marker:
drivers/usb/dwc3/./trace.h: In function ‘trace_raw_output_dwc3_log_trb’:
drivers/usb/dwc3/./trace.h:246:4: warning: this statement may fall through [-Wimplicit-fallthrough=]
switch (pcm) {
^~~~~~
Add the missing break statement to work correctly without compilation
warnings.
Fixes: fa8d965d73 ("usb: dwc3: trace: pretty print high-bandwidth transfers too")
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Here's a fix for a reported USB-console regression in 4.18 which
revealed a long-standing bug in the console implementation.
The patch has been in linux-next over night with no reported issues.
Signed-off-by: Johan Hovold <johan@kernel.org>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQHbPq+cpGvN/peuzMLxc3C7H1lCAUCXAlOXAAKCRALxc3C7H1l
COC9AP4jozobKxNIgbmP6LAwz34Zv19qZyhi2hOzM0Less5o+QD+PLKS4yFPErNq
L6jm+cb1RE3rW9bjrbphoT7PvQoa3QM=
=QA9N
-----END PGP SIGNATURE-----
Merge tag 'usb-serial-4.20-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
Johan writes:
USB-serial fix for v4.20-rc6
Here's a fix for a reported USB-console regression in 4.18 which
revealed a long-standing bug in the console implementation.
The patch has been in linux-next over night with no reported issues.
Signed-off-by: Johan Hovold <johan@kernel.org>
* tag 'usb-serial-4.20-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
USB: serial: console: fix reported terminal settings
Don't allow USB3 U1 or U2 if the latency to wake up from the U-state
reaches the service interval for a periodic endpoint.
This is according to xhci 1.1 specification section 4.23.5.2 extra note:
"Software shall ensure that a device is prevented from entering a U-state
where its worst case exit latency approaches the ESIT."
Allowing too long exit latencies for periodic endpoint confuses xHC
internal scheduling, and new devices may fail to enumerate with a
"Not enough bandwidth for new device state" error from the host.
Cc: <stable@vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Occasionally AMD SNPS 3.0 xHC does not respond to
CSS when set, also it does not flag anything on SRE and HCE
to point the internal xHC errors on USBSTS register. This stalls
the entire system wide suspend and there is no point in stalling
just because of xHC CSS is not responding.
To work around this problem, if the xHC does not flag
anything on SRE and HCE, we can skip the CSS
timeout and allow the system to continue the suspend. Once the
system resume happens we can internally reset the controller
using XHCI_RESET_ON_RESUME quirk
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: Sandeep Singh <Sandeep.Singh@amd.com>
cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com>
Cc: <stable@vger.kernel.org>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When reading an extra descriptor, we need to properly check the minimum
and maximum size allowed, to prevent from invalid data being sent by a
device.
Reported-by: Hui Peng <benquike@gmail.com>
Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
Co-developed-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Hui Peng <benquike@gmail.com>
Signed-off-by: Mathias Payer <mathias.payer@nebelwelt.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The USB-serial console implementation has never reported the actual
terminal settings used. Despite storing the corresponding cflags in its
struct console, these were never honoured on later tty open() where the
tty termios would be left initialised to the driver defaults.
Unlike the serial console implementation, the USB-serial code calls
subdriver open() already at console setup. While calling set_termios()
and write() before open() looks like it could work for some USB-serial
drivers, others definitely do not expect this, so modelling this after
serial core is going to be intrusive, if at all possible.
Instead, use a (renamed) tty helper to save the termios data used at
console setup so that the tty termios reflects the actual terminal
settings after a subsequent tty open().
Note that the calls to tty_init_termios() (tty_driver_install()) and
tty_save_termios() are serialised using the disconnect mutex.
This specifically fixes a regression that was triggered by a recent
change adding software flow control to the pl2303 driver: a getty trying
to disable flow control while leaving the baud rate unchanged would now
also set the baud rate to the driver default (prior to the flow-control
change this had been a noop).
Fixes: 7041d9c3f0 ("USB: serial: pl2303: add support for tx xon/xoff flow control")
Cc: stable <stable@vger.kernel.org> # 4.18
Cc: Florian Zumbiehl <florz@florz.de>
Reported-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
The spinlock was inside the urb completion function which is only
called once per display and is then resubmitted from this function.
There was no other place where this lock was used.
Signed-off-by: Alexander Theissen <alex.theissen@me.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver does allocate a DMA address with usb_alloc_coherent but did
not set the appropriate flag to signal that transfer_dma is set to a
valid value.
Signed-off-by: Alexander Theissen <alex.theissen@me.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some lower volume SanDisk Ultra Flair in 16GB, which the VID:PID is
in 0781:5591, will aggressively request LPM of U1/U2 during runtime,
when using this thumb drive as the OS installation key we found the
device will generate failure during U1 exit path making it dropped
from the USB bus, this causes a corrupted installation in system at
the end.
i.e.,
[ 166.918296] hub 2-0:1.0: state 7 ports 7 chg 0000 evt 0004
[ 166.918327] usb usb2-port2: link state change
[ 166.918337] usb usb2-port2: do warm reset
[ 166.970039] usb usb2-port2: not warm reset yet, waiting 50ms
[ 167.022040] usb usb2-port2: not warm reset yet, waiting 200ms
[ 167.276043] usb usb2-port2: status 02c0, change 0041, 5.0 Gb/s
[ 167.276050] usb 2-2: USB disconnect, device number 2
[ 167.276058] usb 2-2: unregistering device
[ 167.276060] usb 2-2: unregistering interface 2-2:1.0
[ 167.276170] xhci_hcd 0000:00:15.0: shutdown urb ffffa3c7cc695cc0 ep1in-bulk
[ 167.284055] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[ 167.284064] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 33 04 90 00 01 00 00
...
Analyzed the USB trace in the link layer we realized it is because
of the 6-ms timer of tRecoveryConfigurationTimeout which documented
on the USB 3.2 Revision 1.0, the section 7.5.10.4.2 of "Exit from
Recovery.Configuration"; device initiates U1 exit -> Recovery.Active
-> Recovery.Configuration, then the host timer timeout makes the link
transits to eSS.Inactive -> Rx.Detect follows by a Warm Reset.
Interestingly, the other higher volume of SanDisk Ultra Flair sharing
the same VID:PID, such as 64GB, would not request LPM during runtime,
it sticks at U0 always, thus disabling LPM does not affect those thumb
drives at all.
The same odd occures in SanDisk Ultra Fit 16GB, VID:PID in 0781:5583.
Signed-off-by: Harry Pan <harry.pan@intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Syzbot and KASAN found the following invalid-free bug in
port_over_current_notify():
--------------------------------------------------------------------------
BUG: KASAN: double-free or invalid-free in port_over_current_notify
drivers/usb/core/hub.c:5192 [inline]
BUG: KASAN: double-free or invalid-free in port_event
drivers/usb/core/hub.c:5241 [inline]
BUG: KASAN: double-free or invalid-free in hub_event+0xd97/0x4140
drivers/usb/core/hub.c:5384
CPU: 1 PID: 32710 Comm: kworker/1:3 Not tainted 4.20.0-rc3+ #129
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x244/0x39d lib/dump_stack.c:113
print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
kasan_report_invalid_free+0x64/0xa0 mm/kasan/report.c:336
__kasan_slab_free+0x13a/0x150 mm/kasan/kasan.c:501
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xcf/0x230 mm/slab.c:3817
port_over_current_notify drivers/usb/core/hub.c:5192 [inline]
port_event drivers/usb/core/hub.c:5241 [inline]
hub_event+0xd97/0x4140 drivers/usb/core/hub.c:5384
process_one_work+0xc90/0x1c40 kernel/workqueue.c:2153
worker_thread+0x17f/0x1390 kernel/workqueue.c:2296
kthread+0x35a/0x440 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
--------------------------------------------------------------------------
The problem is caused by use of a static array to store
environment-string pointers. When the routine is called by multiple
threads concurrently, the pointers from one thread can overwrite those
from another.
The solution is to use an ordinary automatic array instead of a static
array.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: syzbot+98881958e1410ec7e53c@syzkaller.appspotmail.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add another Apple Cinema Display to the list of supported displays.
Signed-off-by: Alexander Theissen <alex.theissen@me.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since we are going to use the same in Designware USB 3 driver,
rename the property to be consistent across the drivers.
No functional change intended.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Implement the new frame_number API to report the isochronous interval
frame number. This patch checks and reports the interval in which the
isoc transfer was transmitted or received via the Isoc-First TRB SOF
number field.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
When the controller supports SS mode, but works as HS mode, the
SOFTCONN will not be cleared automatically when clear USB3_EN
by default, this cause an issue that can't disconnect from host,
so clear SOFTCONN when clear USB3_EN when the class driver want
to disable the D+ pullup.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the controller receives a new SETUP during SETUP data stage,
and will generate SETUPENDISR interrupt, the driver should abort
the current SETUP command and process the new one.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix the issue: device doesn't accept LGO_U1/U2:
1. set SW_U1/U2_ACCEPT_ENABLE to eanble controller to accept LGO_U1/U2
by default;
2. enable/disable controller to initiate requests for transition into
U1/U2 by SW_U1/U2_REQUEST_ENABLE instead of SW_U1/U2_ACCEPT_ENABLE;
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Enable hardware remote wakeup from L1 automatically based on the FIFO
status, instead of manual way.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The QMU checksum calculation is redundant, mostly used by debug,
so remove it here.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Originally, when dr_mode is USB_DR_MODE_HOST, it didn't power down device ip,
so host ip sleep will fail at ssusb_host_disable.
Power down device ip at ssusb_host_setup.
Signed-off-by: Hsin-Yi, Wang <hsinyi@chromium.org>
Acked-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Modify the wait delay utilize the high resolution timer API to allow for
more precisely scheduled callbacks.
A previous commit added a 1ms retry delay after multiple consecutive
NAKed transactions using jiffies. On systems with a low timer interrupt
frequency, this delay may be significantly longer than specified,
resulting in misbehavior with some USB devices.
This scenario was reached on a Raspberry Pi 3B with a Macally FDD-USB
floppy drive (identified as 0424:0fdc Standard Microsystems Corp.
Floppy, based on the USB97CFDC USB FDC). With the relay delay, the drive
would be unable to mount a disk, replying with NAKs until the device was
reset.
Using ktime, the delta between starting the timer (in dwc2_hcd_qh_add)
and the callback function can be determined. With the original delay
implementation, this value was consistently approximately 12ms. (output
in us).
<idle>-0 [000] ..s. 1600.559974: dwc2_wait_timer_fn: wait_timer delta: 11976
<idle>-0 [000] ..s. 1600.571974: dwc2_wait_timer_fn: wait_timer delta: 11977
<idle>-0 [000] ..s. 1600.583974: dwc2_wait_timer_fn: wait_timer delta: 11976
<idle>-0 [000] ..s. 1600.595974: dwc2_wait_timer_fn: wait_timer delta: 11977
After converting the relay delay to using a higher resolution timer, the
delay was much closer to 1ms.
<idle>-0 [000] d.h. 1956.553017: dwc2_wait_timer_fn: wait_timer delta: 1002
<idle>-0 [000] d.h. 1956.554114: dwc2_wait_timer_fn: wait_timer delta: 1002
<idle>-0 [000] d.h. 1957.542660: dwc2_wait_timer_fn: wait_timer delta: 1004
<idle>-0 [000] d.h. 1957.543701: dwc2_wait_timer_fn: wait_timer delta: 1002
The floppy drive operates properly with delays up to approximately 5ms,
and sends NAKs for any delays that are longer.
Fixes: 38d2b5fb75 ("usb: dwc2: host: Don't retry NAKed transactions right away")
Cc: <stable@vger.kernel.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Minas Harutyunyan <hminas@synopsys.com>
Signed-off-by: Terin Stock <terin@terinstock.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
When initializing a hub we want to give a USB3 port in link training
the same debounce delay time before autosuspening the hub as already
trained, connected enabled ports.
USB3 ports won't reach the enabled state with "current connect status" and
"connect status change" bits set until the USB3 link training finishes.
Catching the port in link training (polling) and adding the debounce delay
prevents unnecessary failed attempts to autosuspend the hub.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When the controller supports SS mode, but works as HS mode, the
SOFTCONN will not be cleared automatically when clear USB3_EN
by default, this cause an issue that can't disconnect from host,
so clear SOFTCONN when clear USB3_EN when the class driver want
to disable the D+ pullup.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
If the controller receives a new SETUP during SETUP data stage,
and will generate SETUPENDISR interrupt, the driver should abort
the current SETUP command and process the new one.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Fix the issue: device doesn't accept LGO_U1/U2:
1. set SW_U1/U2_ACCEPT_ENABLE to eanble controller to accept LGO_U1/U2
by default;
2. enable/disable controller to initiate requests for transition into
U1/U2 by SW_U1/U2_REQUEST_ENABLE instead of SW_U1/U2_ACCEPT_ENABLE;
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Enable hardware remote wakeup from L1 automatically based on the FIFO
status, instead of manual way.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
The QMU checksum calculation is redundant, mostly used by debug,
so remove it here.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Originally, when dr_mode is USB_DR_MODE_HOST, it didn't power down device ip,
so host ip sleep will fail at ssusb_host_disable.
Power down device ip at ssusb_host_setup.
Acked-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Hsin-Yi, Wang <hsinyi@chromium.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Power down feature of DWC2 module integrated in Samsung SoCs doesn't work
properly or needs some additional handling in PHY or SoC glue layer, so
disable it for now. Without disabling power down, DWC2 causes random memory
trashes and fails enumeration if there is no USB link to host on driver
probe.
Fixes: 03ea6d6e9e ("usb: dwc2: Enable power down")
Acked-by: Minas Harutyunyan <hminas@synopsys.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Availability of TRB's is calculated using dwc3_calc_trbs_left(), which
determines total available TRB's based on the HWO bit set in a TRB.
In the present code, __dwc3_prepare_one_trb() is called with a TRB which
needs to be prepared for transfer. This __dwc3_prepare_one_trb() calls
dwc3_calc_trbs_left() to determine total available TRBs and set IOC bit
if the total available TRBs are zero. Since the present working TRB (which
is passed as an argument to __dwc3_prepare_one_trb() ) doesn't yet have
the HWO bit set before calling dwc3_calc_trbs_left(), there are chances
that dwc3_calc_trbs_left() wrongly calculates this present working TRB
as free(since the HWO bit is not yet set) and returns the total available
TRBs as greater than zero (including the present working TRB). This could
be a problem.
This patch corrects the above mentioned problem in __dwc3_prepare_one_trb()
by increementing the dep->trb_enqueue at the last (after preparing the TRB)
instead of increementing at the start and setting the IOC bit only if the
total available TRBs returned by dwc3_calc_trbs_left() is 1 . Since we are
increementing the dep->trb_enqueue at the last, the present working TRB is
also considered as available by dwc3_calc_trbs_left() and non zero value is
returned . So, according to the modified logic, when the total available
TRBs is equal to 1 that means the total available TRBs in the pool are 0.
Signed-off-by: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
Reviewed-by: Thinh Nguyen <thinhn@synopsys.com>
Tested-by: Tejas Joglekar <tejas.joglekar@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
The stream capable endpoints require stream id to be given
when issuing START TRANSFER. While issuing no-op trb the
stream id is not yet known, so don't issue no-op trb's on
stream capable endpoints.
Signed-off-by: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
For stream capable endpoints, stream id related information
needs to be updated into DEPCMD while issuing START TRANSFER.
This patch does the same.
Signed-off-by: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Add a new PID 0x7843 to the driver.
Let the new products be able to set up 3 serial ports with the driver.
Note that this depends on e8603076f5 ("USB: serial: mos7840: clean up
register handling").
Signed-off-by: JackyChou <jackychou@asix.com.tw>
[ johan: mention dependency in case anyone wants to backport this ]
Signed-off-by: Johan Hovold <johan@kernel.org>
In the read/write function, set port 2 independently in the 2-port case.
When setting the offset of port registers, the offset between port 1 and
other ports is different, so port 1 is set independently.
Then in the rest of ports, the port 2 between 2-ports case and 4-ports case
is different, so port 2 in 2-ports case is set independently.
Specifically, port 2 in the 2-port case maps to the registers used by
port 3 in the 4-port case.
Signed-off-by: JackyChou <jackychou@asix.com.tw>
[ johan: simplify register-offset handling at port probe, add a comment
and amend commit message ]
Signed-off-by: Johan Hovold <johan@kernel.org>
The ACPI device with INT3515 _HID is representing a complex USB PD
hardware infrastructure which includes several I2C slave ICs.
We add an ID to the I2C multi instantiate list to enumerate
all I2C slaves correctly.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In this second set of fixes for the current -rc cycle, we have some
regressions fixes for the old omap_udc driver done by Aaro Koskinen.
We're also reverting an old patch on dwc3 which is, now, known to
break USB certification in some cases.
We have a fix on u_ether for an unsafe list iteration.
-----BEGIN PGP SIGNATURE-----
iQJRBAABCAA7FiEElLzh7wn96CXwjh2IzL64meEamQYFAlv/quMdHGZlbGlwZS5i
YWxiaUBsaW51eC5pbnRlbC5jb20ACgkQzL64meEamQZIZg//f3aKa9ndfOXfUI60
GRN9orxj8qRnXhEP0AgjCH6tjdl0PzCcZFD2URkuQWtcbSDEvVzteirpWio4ysUX
pD24Tl+KHX9Sv1HcdDSHoQXduoyxbsOactYRdPlY6AsBM4oRlvjEpGIFhk8Sk1+y
8gCdL04Z5opCUi3grmXdzp7yBkThKNsJGzDnQO6sqp/S2LLjwnKDHjSwkxhq8aCu
0qaRYm1IEWV7pUi1Vjy+1xacbEz6ag2nsergGsJRoT647Hizgx57k9EoT9Yhlhjt
LQ/ZnCNp91hvZpjb7cnIx1bSv/wuIN4dlrRuP3chGXvOUYYXZStLGfmr7hROZ6BD
/LhiO5RzLYNjruoktr/mlArLM14u3aPKh0H5mq1vyJ1HFUfcdcEvD379UrFEBaEO
SEoPa/ZKifLQK3taQtU3nZLdhBUTmJWgXLtw9NqkMe8R5SuiUBQ2Rzc7XCrhhrBn
xp/iQBYejsRNhGoK8cPz8/lqb4eO7gRMj6zmz57K/yU4VwKFoz2DY440/u10v6oH
q+mtcBRQPq0bX25jdWi0LB3OGgSUObbZSCnpN2pUtKfN8RK7Sqv+ZTMlo82Mx56t
OWhbef84y6HbIiiNXdD+1GwJNqaz7+JqTP4DpSpGtpHuujvj3d/A1PgWYFxAZ8LQ
LW59BUmSCACC/BRQMrWY7+39xHc=
=MIKU
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v4.20-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
USB: fixes for v4.20-rc4
In this second set of fixes for the current -rc cycle, we have some
regressions fixes for the old omap_udc driver done by Aaro Koskinen.
We're also reverting an old patch on dwc3 which is, now, known to
break USB certification in some cases.
We have a fix on u_ether for an unsafe list iteration.
* tag 'fixes-for-v4.20-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb:
usb: gadget: u_ether: fix unsafe list iteration
USB: omap_udc: fix rejection of out transfers when DMA is used
USB: omap_udc: fix USB gadget functionality on Palm Tungsten E
USB: omap_udc: fix omap_udc_start() on 15xx machines
USB: omap_udc: fix crashes on probe error and module removal
USB: omap_udc: use devm_request_irq()
Revert "usb: dwc3: gadget: skip Set/Clear Halt when invalid"
iscsi_target_mod is the only LIO fabric where fabric_ops.name differs from
the fabric_ops.fabric_name string. fabric_ops.name is used when matching
target/$fabric ConfigFS create paths, so rename it .fabric_alias and
fallback to target/$fabric vs .fabric_name comparison if .fabric_alias
isn't initialised. iscsi_target_mod is the only fabric module to set
.fabric_alias . All other fabric modules rely on .fabric_name matching and
can drop the duplicate string.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
All fabrics return a const string. In all cases *except* iSCSI the
get_fabric_name() string matches fabric_ops.name.
Both fabric_ops.get_fabric_name() and fabric_ops.name are user-facing, with
the former being used for PR/ALUA state and the latter for ConfigFS
(config/target/$name), so we unfortunately need to keep both strings around
for now. Replace the useless .get_fabric_name() accessor function with a
const string fabric_name member variable.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
list_for_each_entry_safe() is not safe for deleting entries from the
list if the spin lock, which protects it, is released and reacquired during
the list iteration. Fix this issue by replacing this construction with
a simple check if list is empty and removing the first entry in each
iteration. This is almost equivalent to a revert of the commit mentioned in
the Fixes: tag.
This patch fixes following issue:
--->8---
Unable to handle kernel NULL pointer dereference at virtual address 00000104
pgd = (ptrval)
[00000104] *pgd=00000000
Internal error: Oops: 817 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 1 PID: 84 Comm: kworker/1:1 Not tainted 4.20.0-rc2-next-20181114-00009-g8266b35ec404 #1061
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
Workqueue: events eth_work
PC is at rx_fill+0x60/0xac
LR is at _raw_spin_lock_irqsave+0x50/0x5c
pc : [<c065fee0>] lr : [<c0a056b8>] psr: 80000093
sp : ee7fbee8 ip : 00000100 fp : 00000000
r10: 006000c0 r9 : c10b0ab0 r8 : ee7eb5c0
r7 : ee7eb614 r6 : ee7eb5ec r5 : 000000dc r4 : ee12ac00
r3 : ee12ac24 r2 : 00000200 r1 : 60000013 r0 : ee7eb5ec
Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 6d5dc04a DAC: 00000051
Process kworker/1:1 (pid: 84, stack limit = 0x(ptrval))
Stack: (0xee7fbee8 to 0xee7fc000)
...
[<c065fee0>] (rx_fill) from [<c0143b7c>] (process_one_work+0x200/0x738)
[<c0143b7c>] (process_one_work) from [<c0144118>] (worker_thread+0x2c/0x4c8)
[<c0144118>] (worker_thread) from [<c014a8a4>] (kthread+0x128/0x164)
[<c014a8a4>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20)
Exception stack(0xee7fbfb0 to 0xee7fbff8)
...
---[ end trace 64480bc835eba7d6 ]---
Fixes: fea14e68ff ("usb: gadget: u_ether: use better list accessors")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Gadget driver may take an unbounded amount of time to queue requests
after XferNotReady. This is important for isochronous endpoints which
need to be started for a specific (micro-)frame.
If we fail to start a transfer for isochronous endpoint, let's try
queueing to a future interval and see if that helps. We will stop trying
if we fail a start transfer for 5 intervals in the future.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Commit 387f869d25 ("usb: gadget: u_ether: conditionally align
transfer size") started aligning transfer size only if requested,
breaking omap_udc DMA mode. Set quirk_ep_out_aligned_size to restore
the old behaviour.
Fixes: 387f869d25 ("usb: gadget: u_ether: conditionally align transfer size")
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
On Palm TE nothing happens when you try to use gadget drivers and plug
the USB cable. Fix by adding the board to the vbus sense quirk list.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
On OMAP 15xx machines there are no transceivers, and omap_udc_start()
always fails as it forgot to adjust the default return value.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
We currently crash if usb_add_gadget_udc_release() fails, since the
udc->done is not initialized until in the remove function.
Furthermore, on module removal the udc data is accessed although
the release function is already triggered by usb_del_gadget_udc()
early in the function.
Fix by rewriting the release and remove functions, basically moving
all the cleanup into the release function, and doing the completion
only in the module removal case.
The patch fixes omap_udc module probe with a failing gadged, and also
allows the removal of omap_udc. Tested by running "modprobe omap_udc;
modprobe -r omap_udc" in a loop.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
The current code fails to release the third irq on the error path
(observed by reading the code), and we get also multiple WARNs with
failing gadget drivers due to duplicate IRQ releases. Fix by using
devm_request_irq().
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Running out of requests on isochronous endpoints is part of normal
operation. We don't really need to know about it every time it
happens.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
They are much more useful in hexadecimal than in decimal. Moreover,
generic commands are already logged in hex.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Sometimes, errors happen when kicking transfers from
__dwc3_gadget_start_isoc(). In those cases, we need to pass along the
error so gadget driver can make informed decisions.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Cherry G230 Stream 2.0 (G85-231) and 3.0 (G85-232) need this quirk to
function correctly. This fixes a but where double pressing numlock locks
up the device completely with need to replug the keyboard.
Signed-off-by: Michael Niewöhner <linux@mniewoehner.de>
Tested-by: Michael Niewöhner <linux@mniewoehner.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There are two new Realtek card readers require ums-realtek to work
correctly.
Add the new IDs to support them.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that we have a list of cancelled requests, we can skip over TRBs
when END_TRANSFER command completes.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Whenever we have a request in flight, we can move it to the cancelled
list and later simply iterate over that list and skip over any TRBs we
find.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Extract the logic for skipping over TRBs to its own function. This
makes the code slightly more readable and makes it easier to move this
call to its final resting place as a following patch.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Now that we track how many TRBs a request uses, it's easier to skip
over them in case of a call to usb_ep_dequeue(). Let's do so and
simplify the code a bit.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Both flags are used for the same purpose in dwc3: appending an extra
TRB at the end to deal with controller requirements. By combining both
flags into one, we make it clear that the situation is the same and
that they should be treated equally.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
In DWC_usb31 version 1.70a-ea06 and prior, for highspeed and fullspeed
isochronous IN, BIT[15:14] of the 16-bit microframe number reported by
the XferNotReady event are invalid. The driver uses this number to
schedule the isochronous transfer and passes it to the START TRANSFER
command. Because this number is invalid, the command may fail. If
BIT[15:14] matches the internal 16-bit microframe, the START TRANSFER
command will pass and the transfer will start at the scheduled time, if
it is off by 1, the command will still pass, but the transfer will start
2 seconds in the future. For all other conditions, the START TRANSFER
command will fail with bus-expiry.
In order to workaround this issue, we can test for the correct
combination of BIT[15:14] by sending START TRANSFER commands with
different values of BIT[15:14]: 'b00, 'b01, 'b10, and 'b11. Each
combination is 2^14 uframe apart (or 2 seconds). 4 seconds into the
future will result in a bus-expiry status. As the result, within the 4
possible combinations for BIT[15:14], there will be 2 successful and 2
failure START COMMAND status. One of the 2 successful command status
will result in a 2-second delay start. The smaller BIT[15:14] value is
the correct combination.
Since there are only 4 outcomes and the results are ordered, we can
simply test 2 START TRANSFER commands with BIT[15:14] combinations 'b00
and 'b01 to deduce the smaller successful combination.
Let test0 = test status for combination 'b00 and test1 = test status for
'b01 of BIT[15:14]. The correct combination is as follow:
if test0 fails and test1 passes, BIT[15:14] is 'b01
if test0 fails and test1 fails, BIT[15:14] is 'b10
if test0 passes and test1 fails, BIT[15:14] is 'b11
if test0 passes and test1 passes, BIT[15:14] is 'b00
Synopsys STAR 9001202023: Wrong microframe number for isochronous IN
endpoints.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Add a new field to dwc3 structure to track VERSIONTYPE. The VERSIONTYPE
is represented in ASCII in the 32-bit VERSIONTYPE register. In
DWC_usb31, sub releases for each version are tracked with VERSIONTYPE
such as "ea01" and "ea02".
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Some protocols implemented in userspace with FunctionFS might require large
buffers, e.g. 64kB or more. Currently the said memory is allocated with
kmalloc, which might fail should system memory be highly fragmented.
On the other hand, some UDC hardware allows scatter-gather operation and
this patch takes advantage of this capability: if the requested buffer
is larger than PAGE_SIZE and the UDC allows scatter-gather operation, then
the buffer is allocated with vmalloc and a scatterlist describing it is
created and passed to usb request.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Nothing to remap, only check length.
Define a minimal structure for CCID descriptor only used to check length.
As this descriptor shares the same value as HID descriptors, keep track and
compare current interface's class to expected HID and CCID standard values.
Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Trivial fix to spelling mistake in comment
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
The vb2_ops structure can be const as it is only stored in the ops
field of a vb2_queue structure and this field is const.
Done with the help of Coccinelle.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Set GLPMCFG_LPM_ACCEPT_CTRL_ISOC bit in GLPMCFG register
to accept LPM token during ISOC transfers when TxFIFO is
not empty.
- Added two definitions.
#define GLPMCFG_LPM_ACCEPT_CTRL_CONTROL BIT(21)
#define GLPMCFG_LPM_ACCEPT_CTRL_ISOC BIT(22)
This patch uses GLPMCFG_LPM_ACCEPT_CTRL_ISOC.
GLPMCFG_LPM_ACCEPT_CTRL_CONTROL is defined for further use.
- Added setting GLPMCFG_LPM_ACCEPT_CTRL_ISOC bit in GLPMCFG
register in dwc2_gadget_init_lpm function.
Signed-off-by: Artur Petrosyan <arturp@synopsys.com>
Signed-off-by: Minas Harutyunyan <hminas@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
According to the databook DCTL_RMTWKUPSIG bit
is defined in DCTL register not in DCFG.
Updated setting DCTL_RMTWKUPSIG bit to DCTL
register.
Fixes: 187c5298a1 ("usb: dwc2: gadget: Add handler for WkupAlert interrupt")
Signed-off-by: Artur Petrosyan <arturp@synopsys.com>
Signed-off-by: Minas Harutyunyan <hminas@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
DWC_usb31 and DWC_usb3 v3.30a and higher do not support OTG mode. If
the controller supports DRD but the dr_mode is not specified or set to
OTG, then set the mode to peripheral.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
This patch adds a safety connection way for "forced_b_device" with
"workaround_for_vbus" like below:
< Example for R-Car E3 Ebisu >
# modprobe <any usb gadget driver>
# echo 1 > /sys/kernel/debug/ee020000.usb/b_device
(connect a usb cable to host side.)
# echo 2 > /sys/kernel/debug/ee020000.usb/b_device
Previous code should have connected a usb cable before the "b_device"
is set to 1 on the Ebisu board. However, if xHCI driver on the board
is probed, it causes some troubles:
- Conflicts USB VBUS/signals between the board and another host.
- "Cannot enable. Maybe the USB cable is bad?" might happen on
both the board and another host with a usb hub.
- Cannot enumerate a usb gadget correctly because an interruption
of VBUS change happens unexpectedly.
Reported-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Allow extcon device, found by name, to provide DR status for USB.
This is needed, for example, in case of Intel Merrifield platform,
where the Intel Basin Cove PMIC provides an extcon device to communicate
the detected role.
Note, that the "linux,extcon-name" property name is only for kernel
internal use by X86/ACPI platform code and as such is not documented
in the device tree bindings.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Switch to device property for 'extcon' handling.
No functional change intended.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
It's not very useful to repeat a bunch of probe deferral errors. And
it's also not very useful to log "failed" without telling the error
code.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
