The syzbot fuzzer found a lockdep violation in the rio500 driver:
======================================================
WARNING: possible circular locking dependency detected
5.3.0-rc2+ #23 Not tainted
------------------------------------------------------
syz-executor.2/20386 is trying to acquire lock:
00000000772249c6 (rio500_mutex){+.+.}, at: open_rio+0x16/0xc0
drivers/usb/misc/rio500.c:64
but task is already holding lock:
00000000d3e8f4b9 (minor_rwsem){++++}, at: usb_open+0x23/0x270
drivers/usb/core/file.c:39
which lock already depends on the new lock.
The problem is that the driver's open_rio() routine is called while
the usbcore's minor_rwsem is locked for reading, and it acquires the
rio500_mutex; whereas conversely, probe_rio() and disconnect_rio()
first acquire the rio500_mutex and then call usb_register_dev() or
usb_deregister_dev(), which lock minor_rwsem for writing.
The correct ordering of acquisition should be: minor_rwsem first, then
rio500_mutex (since the locking in open_rio() cannot be changed).
Thus, the probe and disconnect routines should avoid holding
rio500_mutex while doing their registration and deregistration.
This patch adjusts the code in those two routines to do just that. It
also relies on the fact that the probe and disconnect routines are
protected by the device mutex, so the initial test of rio->present
needs no extra locking.
Reported-by: syzbot+7bbcbe9c9ff0cd49592a@syzkaller.appspotmail.com
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Fixes: d710734b06 ("USB: rio500: simplify locking")
Acked-by: Oliver Neukum <oneukum@suse.com>
CC: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1908081329240.1319-100000@iolanthe.rowland.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Admitting that there can be only one device allows us to drop any
pretense about locking one device or a table of devices.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Because extcon is not allowed for new bindings, and the
dual role switch is supported by USB Role Switch,
especially for Type-C drivers, so register a USB Role
Switch to support the new way
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/1567070558-29417-12-git-send-email-chunfeng.yun@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Due to the requirement of usb-connector.txt binding, the old way
using extcon to support USB Dual-Role switch is now deprecated
when use Type-B connector.
This patch introduces a USB GPIO based connection detection driver,
used to support Type-B connector which typically uses an input GPIO
to detect USB ID pin, and try to replace the function provided
by the extcon-usb-gpio driver
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Tested-by: Nagarjuna Kristam <nkristam@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/1567070558-29417-11-git-send-email-chunfeng.yun@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Create Kconfig file for USB common core, and move USB_LED_TRIG
and USB_ULPI_BUS configs into the new file from the parent Kconfig,
it will help to add new configs later.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/1567070558-29417-10-git-send-email-chunfeng.yun@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
when the USB host controller is the parent of the connector,
usually type-B, sometimes don't need the graph, so we should
check whether it's parent registers usb-role-switch or not
firstly, and get it if exists.
Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/1567070558-29417-9-git-send-email-chunfeng.yun@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The fwnode_usb_role_switch_get() function is exactly the
same as usb_role_switch_get(), except that it takes struct
fwnode_handle as parameter instead of struct device.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Tested-by: Biju Das <biju.das@bp.renesas.com>
Link: https://lore.kernel.org/r/1567070558-29417-8-git-send-email-chunfeng.yun@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There are bugs on vhci with usb 3.0 storage device. In USB, each SG
list entry buffer should be divisible by the bulk max packet size.
But with native SG support, this problem doesn't matter because the
SG buffer is treated as contiguous buffer. But without native SG
support, USB storage driver breaks SG list into several URBs and the
error occurs because of a buffer size of URB that cannot be divided
by the bulk max packet size. The error situation is as follows.
When USB Storage driver requests 31.5 KB data and has SG list which
has 3584 bytes buffer followed by 7 4096 bytes buffer for some
reason. USB Storage driver splits this SG list into several URBs
because VHCI doesn't support SG and sends them separately. So the
first URB buffer size is 3584 bytes. When receiving data from device,
USB 3.0 device sends data packet of 1024 bytes size because the max
packet size of BULK pipe is 1024 bytes. So device sends 4096 bytes.
But the first URB buffer has only 3584 bytes buffer size. So host
controller terminates the transfer even though there is more data to
receive. So, vhci needs to support SG transfer to prevent this error.
In this patch, vhci supports SG regardless of whether the server's
host controller supports SG or not, because stub driver splits SG
list into several URBs if the server's host controller doesn't
support SG.
To support SG, vhci sets URB_DMA_MAP_SG flag in urb->transfer_flags
if URB has SG list and this flag will tell stub driver to use SG
list. After receiving urb from stub driver, vhci clear URB_DMA_MAP_SG
flag to avoid unnecessary DMA unmapping in HCD.
vhci sends each SG list entry to stub driver. Then, stub driver sees
the total length of the buffer and allocates SG table and pages
according to the total buffer length calling sgl_alloc(). After stub
driver receives completed URB, it again sends each SG list entry to
vhci.
If the server's host controller doesn't support SG, stub driver
breaks a single SG request into several URBs and submits them to
the server's host controller. When all the split URBs are completed,
stub driver reassembles the URBs into a single return command and
sends it to vhci.
Moreover, in the situation where vhci supports SG, but stub driver
does not, or vice versa, usbip works normally. Because there is no
protocol modification, there is no problem in communication between
server and client even if the one has a kernel without SG support.
In the case of vhci supports SG and stub driver doesn't, because
vhci sends only the total length of the buffer to stub driver as
it did before the patch applied, stub driver only needs to allocate
the required length of buffers using only kmalloc() regardless of
whether vhci supports SG or not. But stub driver has to allocate
buffer with kmalloc() as much as the total length of SG buffer which
is quite huge when vhci sends SG request, so it has overhead in
buffer allocation in this situation.
If stub driver needs to send data buffer to vhci because of IN pipe,
stub driver also sends only total length of buffer as metadata and
then sends real data as vhci does. Then vhci receive data from stub
driver and store it to the corresponding buffer of SG list entry.
And for the case of stub driver supports SG and vhci doesn't, since
the USB storage driver checks that vhci doesn't support SG and sends
the request to stub driver by splitting the SG list into multiple
URBs, stub driver allocates a buffer for each URB with kmalloc() as
it did before this patch.
* Test environment
Test uses two difference machines and two different kernel version
to make mismatch situation between the client and the server where
vhci supports SG, but stub driver does not, or vice versa. All tests
are conducted in both full SG support that both vhci and stub support
SG and half SG support that is the mismatch situation. Test kernel
version is 5.3-rc6 with commit "usb: add a HCD_DMA flag instead of
guestimating DMA capabilities" to avoid unnecessary DMA mapping and
unmapping.
- Test kernel version
- 5.3-rc6 with SG support
- 5.1.20-200.fc29.x86_64 without SG support
* SG support test
- Test devices
- Super-speed storage device - SanDisk Ultra USB 3.0
- High-speed storage device - SMI corporation USB 2.0 flash drive
- Test description
Test read and write operation of mass storage device that uses the
BULK transfer. In test, the client reads and writes files whose size
is over 1G and it works normally.
* Regression test
- Test devices
- Super-speed device - Logitech Brio webcam
- High-speed device - Logitech C920 HD Pro webcam
- Full-speed device - Logitech bluetooth mouse
- Britz BR-Orion speaker
- Low-speed device - Logitech wired mouse
- Test description
Moving and click test for mouse. To test the webcam, use gnome-cheese.
To test the speaker, play music and video on the client. All works
normally.
* VUDC compatibility test
VUDC also works well with this patch. Tests are done with two USB
gadget created by CONFIGFS USB gadget. Both use the BULK pipe.
1. Serial gadget
2. Mass storage gadget
- Serial gadget test
Serial gadget on the host sends and receives data using cat command
on the /dev/ttyGS<N>. The client uses minicom to communicate with
the serial gadget.
- Mass storage gadget test
After connecting the gadget with vhci, use "dd" to test read and
write operation on the client side.
Read - dd if=/dev/sd<N> iflag=direct of=/dev/null bs=1G count=1
Write - dd if=<my file path> iflag=direct of=/dev/sd<N> bs=1G count=1
Signed-off-by: Suwan Kim <suwan.kim027@gmail.com>
Acked-by: Shuah khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20190828032741.12234-1-suwan.kim027@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Enable static DRD mode in Intel platforms which guarantees
successful role switch all the time. This fixes issues like
software role switch failure after cold boot and issue with
role switch when USB 3.0 cable is used. But, do not enable
static DRD mode for Cherrytrail devices which rely on firmware
for role switch.
Signed-off-by: Saranya Gopal <saranya.gopal@intel.com>
Signed-off-by: Balaji Manoharan <m.balaji@intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/1567079760-24822-2-git-send-email-saranya.gopal@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In platforms like Cherrytrail, 'SW switch enable' bit
should not be enabled for role switch. This patch
adds a property to Intel USB Role Switch platform driver
to denote that SW switch should be disabled in
Cherrytrail devices.
Signed-off-by: Saranya Gopal <saranya.gopal@intel.com>
Signed-off-by: Balaji Manoharan <m.balaji@intel.com>
Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/1567079760-24822-1-git-send-email-saranya.gopal@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Calls to USB2 generic PHY calibrate() method has been moved to HCD core,
which now successfully handles generic PHYs and their calibration after
every HCD reset. This fixes all the timing issues related to PHY
calibration done directly from DWC3 driver: incorrect operation after
system suspend/resume or USB3.0 detection failure when XHCI-plat driver
compiled as separate module.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Jochen Sprickerhof <jochen@sprickerhof.de>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Link: https://lore.kernel.org/r/20190829053028.32438-3-m.szyprowski@samsung.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some PHYs (for example Exynos5 USB3.0 DRD PHY) require calibration to be
done after every USB HCD reset. Generic PHY framework has been already
extended with phy_calibrate() function in commit 36914111e6 ("drivers:
phy: add calibrate method"). This patch adds support for it to generic
PHY handling code in USB HCD core.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Jochen Sprickerhof <jochen@sprickerhof.de>
Link: https://lore.kernel.org/r/20190829053028.32438-2-m.szyprowski@samsung.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch uses xhci_plat_priv.quirks to simplify. The previous
code had conditions to set some quirks in xhci_rcar_init_quirk().
But, the xhci_rcar_init_quirk() is called at the same conditions.
So, no behavior change.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/1567425698-27560-4-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To simplify adding xhci->quirks instead of the .init_quirk()
function, this patch adds a new parameter "quirks" into
the struct xhci_plat_priv.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/1567425698-27560-2-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xhci re-enables a slot on transaction error in set_address using
xhci_disable_slot() + xhci_alloc_dev().
But in this case, xhci_alloc_dev() creates debugfs entries upon an
existing device without cleaning up old entries, thus memory leaks.
So this patch simply moves calling xhci_debugfs_free_dev() from
xhci_free_dev() to xhci_disable_slot().
[added "possible" to header as this is about failure codepath -Mathias]
Signed-off-by: Ikjoon Jang <ikjn@chromium.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/1567172356-12915-5-git-send-email-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Software can set a Transfer State Preserve (TSP) flag to maintain
data toggle and sequence number when issuing a reset endpoint
command.
xhci driver is using TSP for soft retry, we want to show TSP usage
in tracing as well
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/1567172356-12915-4-git-send-email-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is no need to use GFP_ATOMIC to allocate 'req'. GFP_KERNEL should be
enough and is already used for another allocation juste a few lines below.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/1567172356-12915-3-git-send-email-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the 'kmalloc()' fails, we need to undo the previous
'dbc_alloc_request()' call.
Because of the more similar function name, it is more logical to use
'dbc_free_request()' instead of 'xhci_dbc_free_req()'.
Both are equivalent here because:
static void xhci_dbc_free_req(struct dbc_ep *dep, struct dbc_request *req)
{
kfree(req->buf);
dbc_free_request(dep, req);
}
and 'req->buf' is known to be NULL at this point
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/1567172356-12915-2-git-send-email-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently the check on a non-zero return code in ret is false because
ret has been initialized to zero. I believe that ret should be assigned
to the return from the call to readl_poll_timeout_atomic before the
check on ret. Since ret is being re-assinged the original initialization
of ret to zero can be removed.
Addresses-Coverity: ("'Constant' variable guards dead code")
Fixes: 7733f6c32e ("usb: cdns3: Add Cadence USB3 DRD Driver")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20190902145035.18200-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the case where an allocation fails for priv_ep ret is
assigned -ENOMEM and the code exits via the exit path 'err'.
The exit path returns -ENOMEM without using variable ret, so
the assingment is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20190902184334.27406-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If CONFIG_REGMAP_I2C is not set, building fails:
drivers/usb/typec/tps6598x.o: In function `tps6598x_probe':
tps6598x.c:(.text+0x5f0): undefined reference to `__devm_regmap_init_i2c'
Select REGMAP_I2C to fix this.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 0a4c005bd1 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20190903121026.22148-1-yuehaibing@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/usb/cdns3/gadget.c: In function '__cdns3_gadget_init':
drivers/usb/cdns3/gadget.c:2665:23: warning:
variable 'priv_dev' set but not used [-Wunused-but-set-variable]
drivers/usb/cdns3/gadget.c: In function cdns3_start_all_request:
drivers/usb/cdns3/gadget.c:357:24: warning:
variable priv_req set but not used [-Wunused-but-set-variable]
They are never used, so can be removed.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190903120445.22204-1-yuehaibing@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/usb/cdns3/ep0.c: In function cdns3_ep0_feature_handle_device:
drivers/usb/cdns3/ep0.c:290:6: warning: variable wIndex set but not used [-Wunused-but-set-variable]
drivers/usb/cdns3/ep0.c:289:6: warning: variable wValue set but not used [-Wunused-but-set-variable]
wIndex is never used, so remove it.
wValue should be use in the switch statement.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 7733f6c32e ("usb: cdns3: Add Cadence USB3 DRD Driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190903120615.19504-1-yuehaibing@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These wrappers have never seen use and have been commented out
for a long time. Remove them for good.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20190903084615.19161-6-hch@lst.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that we have the local memory pool implemented there is no
need to use dma_declare_coherent_memory.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20190903084615.19161-5-hch@lst.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The dma_mask on its own doesn't mean much. Instead check for the actual
flag.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20190903084615.19161-4-hch@lst.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This driver doesn't support normal DMA, only direct access to its
local memory. Remove the HCD_DMA flag to properly express that fact.
Fixes: 7b81cb6bdd ("usb: add a HCD_DMA flag instead of guestimating DMA capabilities")
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20190903084615.19161-3-hch@lst.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This driver doesn't support normal DMA, only direct access to its
local memory. Remove the HCD_DMA flag to properly express that fact.
Fixes: 7b81cb6bdd ("usb: add a HCD_DMA flag instead of guestimating DMA capabilities")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20190903084615.19161-2-hch@lst.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
With only 45 non-merge commits, we have a small merge window from the
Gadget perspective.
The biggest change here is the addition of the Cadence USB3 DRD
Driver. All other changes are small, non-critical fixes or smaller new
features like the improvement to BESL handling in dwc3.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
-----BEGIN PGP SIGNATURE-----
iQJRBAABCAA7FiEElLzh7wn96CXwjh2IzL64meEamQYFAl1o58UdHGZlbGlwZS5i
YWxiaUBsaW51eC5pbnRlbC5jb20ACgkQzL64meEamQaKtxAAvvrwvleA7lZwInU2
FariXyI7+ihPAUDtlEHA+kHclpUw4hyWPc5rg0Mk7CH5gbtqodj9Uo4vbWtM5EaR
EN6AJTn90KlygBXlw2pJAb6GBiJ2hMK8K5Gl5gdowRg4LExLYdLZCgCDueAv1p2o
2vg7LSJbHaeC0pv+L97W6/YH7q4fdacGjFm/49ROrChCwNNJygoXchO2+eAcXNlo
uMzx2QxF3cHOMeSxSGnXC5VsZYAk6VftXgAiGvVZ5+6EgPIA5b07JovDhn0nAoDR
1aVQTqWDzdcd/tkJKEMBi16mOaeLDzsnGmsr+/2vzPzLJaWKPKwZ/FgGTyBXzDfM
qEVrj2zWioH+6oOE3G5Ar3j1dgBqbgWhTfO47UWjgdQww5HeKZJqewJh19h5t/uS
hxxSFgwNMVIo4B8DJc5J/vIbDsQbk1LsXkT2b3B/UaNYXQuKBdiv4jVpUgLJX+FF
mN46SsfLVBpaYANcBPlgC8zGoOzWJFXgoh0qffxnQ6/Egvh55k0xVL/YPRgHiiw5
FbaGAlnJo9ue9vadzInde0X4SZnpBIQ5WR9fyHYm8fKDT1neB97F3yhZxhJ3apxN
0PM9P7auGtmjYYLAfIIL9687c3BNvDk8YvLehxXI4YqVHUZF3YNAz/DPrnCG2O5D
W33pwIhL1swIZCFRtGWpokGiN+o=
=KUJN
-----END PGP SIGNATURE-----
Merge tag 'usb-for-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next
Felipe writes:
USB: Changes for v5.4 merge window
With only 45 non-merge commits, we have a small merge window from the
Gadget perspective.
The biggest change here is the addition of the Cadence USB3 DRD
Driver. All other changes are small, non-critical fixes or smaller new
features like the improvement to BESL handling in dwc3.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
* tag 'usb-for-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb: (45 commits)
usb: gadget: net2280: Add workaround for AB chip Errata 11
usb: gadget: net2280: Move all "ll" registers in one structure
usb: dwc3: gadget: Workaround Mirosoft's BESL check
usb:cdns3 Fix for stuck packets in on-chip OUT buffer.
usb: cdns3: Add Cadence USB3 DRD Driver
usb: common: Simplify usb_decode_get_set_descriptor function.
usb: common: Patch simplify usb_decode_set_clear_feature function.
usb: common: Separated decoding functions from dwc3 driver.
dt-bindings: add binding for USBSS-DRD controller.
usb: gadget: composite: Set recommended BESL values
usb: dwc3: gadget: Set BESL config parameter
usb: dwc3: Separate field holding multiple properties
usb: gadget: Export recommended BESL values
usb: phy: phy-fsl-usb: Make structure fsl_otg_initdata constant
usb: udc: lpc32xx: silence fall-through warning
usb: dwc3: meson-g12a: fix suspend resume regulator unbalanced disables
usb: udc: lpc32xx: remove set but not used 3 variables
usb: gadget: udc: core: Fix segfault if udc_bind_to_driver() for pending driver fails
usb: dwc3: st: Add of_dev_put() in probe function
usb: dwc3: st: Add of_node_put() before return in probe function
...
The errata description is:
Workaround for Default Duration of LFPS Handshake Signaling for
Device-Initiated U1 Exit is too short.
The default duration of the LFPS handshake generated by USB3380 for a device-initiated U1-exit may not be
long enough for certain SuperSpeed downstream ports (SuperSpeed hubs/hosts) to recognize. This could lead
to USB3380 entering the recovery state pre-maturely and ending up in the SS.Inactive state.
I have observed various enumeration failures, seemingly related to
lost transactions or SETUP status phases on modern hosts (typically
thunderbolt capable systems) without this workaround.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
The split into multiple structures of the "ll" register bank is
impractical. It makes it hard to add ll_lfps_timers_2 which is
at offset 0x794, which is outside of the existing "lfps" structure
and would require us to add yet another one.
Instead, move all the "ll" registers into a single usb338x_ll_regs
structure, and add ll_lfps_timers_2 while at it. It will be used
in a subsequent patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
While testing our host system using Microsoft's usb stack against our
gadget for various BESL values, we found an issue with their usb stack
when the recommended baseline BESL value is 0 (125us) or when the deep
BESL is 1 or less. The Windows host will issue a usb reset immediately
after it receives the extended BOS descriptor and the enumeration will
fail after a few attempts.
To keep compatibility with Microsoft's host usb stack, let's workaround
this issue by using the recommended baseline BESL of 1 (or 150us)
and clamp the deep BESL value within 2 to 15.
This was tested against Windows 10 build 18956.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Controller for OUT endpoints has shared on-chip buffers for all incoming
packets, including ep0out. It's FIFO buffer, so packets must be handled
by DMA in correct order. If the first packet in the buffer will not be
handled, then the following packets directed for other endpoints and
functions will be blocked.
Additionally the packets directed to one endpoint can block entire on-chip
buffers. In this case transfer to other endpoints also will blocked.
To resolve this issue after raising the descriptor missing interrupt
driver prepares internal usb_request object and use it to arm DMA
transfer.
The problematic situation was observed in case when endpoint has
been enabled but no usb_request were queued. Driver try detects
such endpoints and will use this workaround only for these endpoint.
Driver use limited number of buffer. This number can be set by macro
CDNS_WA2_NUM_BUFFERS.
Such blocking situation was observed on ACM gadget. For this function
host send OUT data packet but ACM function is not prepared for
this packet. It's cause that buffer placed in on chip memory block
transfer to other endpoints.
Issue has been fixed for DEV_VER_V2 version of controller.
Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
This patch introduce new Cadence USBSS DRD driver to Linux kernel.
The Cadence USBSS DRD Controller is a highly configurable IP Core which
can be instantiated as Dual-Role Device (DRD), Peripheral Only and
Host Only (XHCI)configurations.
The current driver has been validated with FPGA platform. We have
support for PCIe bus, which is used on FPGA prototyping.
The host side of USBSS-DRD controller is compliant with XHCI
specification, so it works with standard XHCI Linux driver.
Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Patch moves switch responsible for decoding descriptor type
outside snprintf. It improves code readability a little.
Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Patch adds usb_decode_test_mode and usb_decode_device_feature functions,
which allow to make more readable and simplify the
usb_decode_set_clear_feature function.
Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Patch moves some decoding functions from driver/usb/dwc3/debug.h driver
to driver/usb/common/debug.c file. These moved functions include:
dwc3_decode_get_status
dwc3_decode_set_clear_feature
dwc3_decode_set_address
dwc3_decode_get_set_descriptor
dwc3_decode_get_configuration
dwc3_decode_set_configuration
dwc3_decode_get_intf
dwc3_decode_set_intf
dwc3_decode_synch_frame
dwc3_decode_set_sel
dwc3_decode_set_isoch_delay
dwc3_decode_ctrl
These functions are used also in inroduced cdns3 driver.
All functions prefixes were changed from dwc3 to usb.
Also, function's parameters has been extended according to the name
of fields in standard SETUP packet.
Additionally, patch adds usb_decode_ctrl function to
include/linux/usb/ch9.h file.
Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Some SoCs may have an optional clock xhci_ck (125M or 200M), it
usually uses the same PLL as sys_ck, so support it.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Link: https://lore.kernel.org/r/1566542425-20082-2-git-send-email-chunfeng.yun@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In case of a disconnect an ongoing flush() has to be made fail.
Nevertheless we cannot be sure that any pending URB has already
finished, so although they will never succeed, they still must
not be touched.
The clean solution for this is to check for WDM_IN_USE
and WDM_DISCONNECTED in flush(). There is no point in ever
clearing WDM_IN_USE, as no further writes make sense.
The issue is as old as the driver.
Fixes: afba937e54 ("USB: CDC WDM driver")
Reported-by: syzbot+d232cca6ec42c2edb3fc@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190827103436.21143-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It's spelled "renesas", not "renensas".
Due to this typo, RZ/G1M and RZ/G1N were not covered by the check.
Fixes: 2dc240a330 ("usb: host: xhci: rcar: retire use of xhci_plat_type_is()")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20190827125112.12192-1-geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Falcon microcontroller that runs the XUSB firmware and which is
responsible for exposing the XHCI interface can address only 40 bits of
memory. Typically that's not a problem because Tegra devices don't have
enough system memory to exceed those 40 bits.
However, if the ARM SMMU is enable on Tegra186 and later, the addresses
passed to the XUSB controller can be anywhere in the 48-bit IOV address
space of the ARM SMMU. Since the DMA/IOMMU API starts allocating from
the top of the IOVA space, the Falcon microcontroller is not able to
load the firmware successfully.
Fix this by setting the DMA mask to 40 bits, which will force the DMA
API to map the buffer for the firmware to an IOVA that is addressable by
the Falcon.
Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/1566989697-13049-1-git-send-email-nkristam@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Auto-delink requires writing special registers to ums-realtek devices.
Unconditionally enable auto-delink may break newer devices.
So only enable auto-delink by default for the original three IDs,
0x0138, 0x0158 and 0x0159.
Realtek is working on a patch to properly support auto-delink for other
IDs.
BugLink: https://bugs.launchpad.net/bugs/1838886
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>
Link: https://lore.kernel.org/r/20190827173450.13572-2-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The option named "auto_delink_en" is a bit misleading, as setting it to
false doesn't really disable auto-delink but let auto-delink be firmware
controlled.
Update the description to reflect the real usage of this parameter.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190827173450.13572-1-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes an issue that the following error is
possible to happen when ohci hardware causes an interruption
and the system is shutting down at the same time.
[ 34.851754] usb 2-1: USB disconnect, device number 2
[ 35.166658] irq 156: nobody cared (try booting with the "irqpoll" option)
[ 35.173445] CPU: 0 PID: 22 Comm: kworker/0:1 Not tainted 5.3.0-rc5 #85
[ 35.179964] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)
[ 35.187886] Workqueue: usb_hub_wq hub_event
[ 35.192063] Call trace:
[ 35.194509] dump_backtrace+0x0/0x150
[ 35.198165] show_stack+0x14/0x20
[ 35.201475] dump_stack+0xa0/0xc4
[ 35.204785] __report_bad_irq+0x34/0xe8
[ 35.208614] note_interrupt+0x2cc/0x318
[ 35.212446] handle_irq_event_percpu+0x5c/0x88
[ 35.216883] handle_irq_event+0x48/0x78
[ 35.220712] handle_fasteoi_irq+0xb4/0x188
[ 35.224802] generic_handle_irq+0x24/0x38
[ 35.228804] __handle_domain_irq+0x5c/0xb0
[ 35.232893] gic_handle_irq+0x58/0xa8
[ 35.236548] el1_irq+0xb8/0x180
[ 35.239681] __do_softirq+0x94/0x23c
[ 35.243253] irq_exit+0xd0/0xd8
[ 35.246387] __handle_domain_irq+0x60/0xb0
[ 35.250475] gic_handle_irq+0x58/0xa8
[ 35.254130] el1_irq+0xb8/0x180
[ 35.257268] kernfs_find_ns+0x5c/0x120
[ 35.261010] kernfs_find_and_get_ns+0x3c/0x60
[ 35.265361] sysfs_unmerge_group+0x20/0x68
[ 35.269454] dpm_sysfs_remove+0x2c/0x68
[ 35.273284] device_del+0x80/0x370
[ 35.276683] hid_destroy_device+0x28/0x60
[ 35.280686] usbhid_disconnect+0x4c/0x80
[ 35.284602] usb_unbind_interface+0x6c/0x268
[ 35.288867] device_release_driver_internal+0xe4/0x1b0
[ 35.293998] device_release_driver+0x14/0x20
[ 35.298261] bus_remove_device+0x110/0x128
[ 35.302350] device_del+0x148/0x370
[ 35.305832] usb_disable_device+0x8c/0x1d0
[ 35.309921] usb_disconnect+0xc8/0x2d0
[ 35.313663] hub_event+0x6e0/0x1128
[ 35.317146] process_one_work+0x1e0/0x320
[ 35.321148] worker_thread+0x40/0x450
[ 35.324805] kthread+0x124/0x128
[ 35.328027] ret_from_fork+0x10/0x18
[ 35.331594] handlers:
[ 35.333862] [<0000000079300c1d>] usb_hcd_irq
[ 35.338126] [<0000000079300c1d>] usb_hcd_irq
[ 35.342389] Disabling IRQ #156
ohci_shutdown() disables all the interrupt and rh_state is set to
OHCI_RH_HALTED. In other hand, ohci_irq() is possible to enable
OHCI_INTR_SF and OHCI_INTR_MIE on ohci_irq(). Note that OHCI_INTR_SF
is possible to be set by start_ed_unlink() which is called:
ohci_irq()
-> process_done_list()
-> takeback_td()
-> start_ed_unlink()
So, ohci_irq() has the following condition, the issue happens by
&ohci->regs->intrenable = OHCI_INTR_MIE | OHCI_INTR_SF and
ohci->rh_state = OHCI_RH_HALTED:
/* interrupt for some other device? */
if (ints == 0 || unlikely(ohci->rh_state == OHCI_RH_HALTED))
return IRQ_NOTMINE;
To fix the issue, ohci_shutdown() holds the spin lock while disabling
the interruption and changing the rh_state flag to prevent reenable
the OHCI_INTR_MIE unexpectedly. Note that io_watchdog_func() also
calls the ohci_shutdown() and it already held the spin lock, so that
the patch makes a new function as _ohci_shutdown().
This patch is inspired by a Renesas R-Car Gen3 BSP patch
from Tho Vu.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/1566877910-6020-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using managed device resources in usb_hcd_pci_probe() allows devm usage for
resource subranges, such as the mmio resource for the platform device
created to control host/device mode mux, which is a xhci extended
capability, and sits inside the xhci mmio region.
If managed device resources are not used then "parent" resource
is released before subrange at driver removal as .remove callback is
called before the devres list of resources for this device is walked
and released.
This has been observed with the xhci extended capability driver causing a
use-after-free which is now fixed.
An additional nice benefit is that error handling on driver initialisation
is simplified much.
Signed-off-by: Carsten Schmid <carsten_schmid@mentor.com>
Tested-by: Carsten Schmid <carsten_schmid@mentor.com>
Reviewed-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Fixes: fa31b3cb2a ("xhci: Add Intel extended cap / otg phy mux handling")
Cc: <stable@vger.kernel.org> # v4.19+
Link: https://lore.kernel.org/r/1566569488679.31808@mentor.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
