Multi-channel devices need to encode the channel selector in their
control requests and newer single-channel chip types use the same
request format.
Set the channel index also for these single-channel types so that the
index can be used to determine the baudrate request format instead of
listing types explicitly.
Note that FT232H and FTX accept either 0 or 1 as selector for their
single channel, presumably for backward compatibility reasons.
Signed-off-by: Johan Hovold <johan@kernel.org>
The driver exposes two attributes for all chip types but FT232A, which
doesn't have a configurable latency timer, and SIO, which (probably)
doesn't support the event-char mechanism either.
Explicitly test for the exceptions rather than list each and every
supported device type in the attribute helpers.
Signed-off-by: Johan Hovold <johan@kernel.org>
All chip types but the original SIO (FT8U100AX) return a two-byte modem
status and there's no need to explicitly list every other type in the
handler.
Signed-off-by: Johan Hovold <johan@kernel.org>
Clean up and tighten the device-type detection, which is based on
bcdDevice.
Don't make assumptions about unknown (future) types (currently assumed
to be either FT2232C or FT-X depending on bNumInterfaces) and instead
log an error and refuse to bind so that we can add proper support when
needed.
Note that the bcdDevice values have been provided by FTDI.
Signed-off-by: Johan Hovold <johan@kernel.org>
Multi-channel devices require a channel selector to be included in
control requests.
Replace "interface" with the less ambiguous "channel", which is the
terminology used for newer devices, in the corresponding defines and
variables.
Signed-off-by: Johan Hovold <johan@kernel.org>
Shorten the chip type enum and string representation for A, B and R chip
types so that they don't include the IC package type in the name.
Signed-off-by: Johan Hovold <johan@kernel.org>
Clean up the chip type enum by dropping the explicit values and moving
the definition to the implementation to make it easier to add further
types.
Signed-off-by: Johan Hovold <johan@kernel.org>
The 300 bps rate of SIO devices has been mapped to 9600 bps since
2003... Let's fix the regression.
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
This reverts commit 8cb339f1c1 as it
throws up a bunch of sparse warnings as reported by the kernel test
robot.
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/202209020044.CX2PfZzM-lkp@intel.com
Fixes: 8cb339f1c1 ("usb: gadget: udc-xilinx: replace memcpy with memcpy_toio")
Cc: stable@vger.kernel.org
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Piyush Mehta <piyush.mehta@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB external storage device(0x0b05:1932), use gnome-disk-utility tools
to test usb write < 30MB/s.
if does not to load module of uas for this device, can increase the
write speed from 20MB/s to >40MB/s.
Suggested-by: Matthias Kaehlcke <mka@chromium.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Hu Xiaoying <huxiaoying@kylinos.cn>
Link: https://lore.kernel.org/r/20220901045737.3438046-1-huxiaoying@kylinos.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here are a couple of fixes for two long-standing issues with some older
ch341 devices and a number of new device ids.
All have been in linux-next with no reported issues.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQHbPq+cpGvN/peuzMLxc3C7H1lCAUCYxB1GAAKCRALxc3C7H1l
CHefAQCxSTeNfnnRHFC/pHlUFa+4U5tVc8zFnwMcnGcZN79dqAEAkjqdLpH8N3tu
baNUP/l1OH86CL4/Rog/hpbBGzJijQg=
=X+Na
-----END PGP SIGNATURE-----
Merge tag 'usb-serial-6.0-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
Johan writes:
"USB-serial fixes for 6.0-rc4
Here are a couple of fixes for two long-standing issues with some older
ch341 devices and a number of new device ids.
All have been in linux-next with no reported issues."
* tag 'usb-serial-6.0-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
USB: serial: ch341: fix disabled rx timer on older devices
USB: serial: ch341: fix lost character on LCR updates
USB: serial: cp210x: add Decagon UCA device id
USB: serial: option: add support for Cinterion MV32-WA/WB RmNet mode
USB: serial: ftdi_sio: add Omron CS1W-CIF31 device id
USB: serial: option: add Quectel EM060K modem
USB: serial: option: add support for OPPO R11 diag port
At least one older CH341 appears to have the RX timer enable bit
inverted so that setting it disables the RX timer and prevents the FIFO
from emptying until it is full.
Only set the RX timer enable bit for devices with version newer than
0x27 (even though this probably affects all pre-0x30 devices).
Reported-by: Jonathan Woithe <jwoithe@just42.net>
Tested-by: Jonathan Woithe <jwoithe@just42.net>
Link: https://lore.kernel.org/r/Ys1iPTfiZRWj2gXs@marvin.atrad.com.au
Fixes: 4e46c410e0 ("USB: serial: ch341: reinitialize chip on reconfiguration")
Cc: stable@vger.kernel.org # 4.10
Signed-off-by: Johan Hovold <johan@kernel.org>
Disable LCR updates for pre-0x30 devices which use a different (unknown)
protocol for line control and where the current register write causes
the next received character to be lost.
Note that updating LCR using the INIT command has no effect on these
devices either.
Reported-by: Jonathan Woithe <jwoithe@just42.net>
Tested-by: Jonathan Woithe <jwoithe@just42.net>
Link: https://lore.kernel.org/r/Ys1iPTfiZRWj2gXs@marvin.atrad.com.au
Fixes: 4e46c410e0 ("USB: serial: ch341: reinitialize chip on reconfiguration")
Fixes: 55fa15b598 ("USB: serial: ch341: fix baud rate and line-control handling")
Cc: stable@vger.kernel.org # 4.10
Signed-off-by: Johan Hovold <johan@kernel.org>
This reverts commit 3d5f70949f.
The quirk does not work properly, more work is needed to determine what
should be done here.
Reported-by: Oliver Neukum <oneukum@suse.com>
Cc: Jean-Francois Le Fillatre <jflf_kernel@gmx.com>
Cc: stable <stable@kernel.org>
Fixes: 3d5f70949f ("usb: add quirks for Lenovo OneLink+ Dock")
Link: https://lore.kernel.org/r/9a17ea86-079f-510d-e919-01bc53a6d09f@gmx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ISO OUT endpoint is enabled during queuing first usb request
in transfer ring and disabled when TRBERR is reported by controller.
After TRBERR and before next transfer added to TR driver must again
reenable endpoint but does not.
To solve this issue during processing TRBERR event driver must
set the flag EP_UPDATE_EP_TRBADDR in priv_ep->flags field.
Fixes: 7733f6c32e ("usb: cdns3: Add Cadence USB3 DRD Driver")
cc: <stable@vger.kernel.org>
Acked-by: Peter Chen <peter.chen@kernel.org>
Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Link: https://lore.kernel.org/r/20220825062137.5766-1-pawell@cadence.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The TRB_SMM flag indicates that DMA has completed the TD service with
this TRB. Usually it’s a last TRB in TD. In case of ISOC transfer for
bInterval > 1 each ISOC transfer contains more than one TD associated
with usb request (one TD per ITP). In such case the TRB_SMM flag will
be set in every TD and driver will recognize the end of transfer after
processing the first TD with TRB_SMM. In result driver stops updating
request->actual and returns incorrect actual length.
To fix this issue driver additionally must check TRB_CHAIN which is not
used for isochronous transfers.
Fixes: 249f0a25e8 ("usb: cdns3: gadget: handle sg list use case at completion correctly")
cc: <stable@vger.kernel.org>
Acked-by: Peter Chen <peter.chen@kernel.org>
Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Link: https://lore.kernel.org/r/20220825062207.5824-1-pawell@cadence.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
During cdrom emulation, the response to read_toc command must contain
the cdrom address as the number of sectors (2048 byte sized blocks)
represented either as an absolute value (when MSF bit is '0') or in
terms of PMin/PSec/PFrame (when MSF bit is set to '1'). Incase of
cdrom, the fsg_lun_open call sets the sector size to 2048 bytes.
When MAC OS sends a read_toc request with MSF set to '1', the
store_cdrom_address assumes that the address being provided is the
LUN size represented in 512 byte sized blocks instead of 2048. It
tries to modify the address further to convert it to 2048 byte sized
blocks and store it in MSF format. This results in data transfer
failures as the cdrom address being provided in the read_toc response
is incorrect.
Fixes: 3f565a363c ("usb: gadget: storage: adapt logic block size to bound block devices")
Cc: stable@vger.kernel.org
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
Link: https://lore.kernel.org/r/1661570110-19127-1-git-send-email-quic_kriskura@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Automatic kernel fuzzing revealed a recursive locking violation in
usb-storage:
============================================
WARNING: possible recursive locking detected
5.18.0 #3 Not tainted
--------------------------------------------
kworker/1:3/1205 is trying to acquire lock:
ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at:
usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230
but task is already holding lock:
ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at:
usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230
...
stack backtrace:
CPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Workqueue: usb_hub_wq hub_event
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_deadlock_bug kernel/locking/lockdep.c:2988 [inline]
check_deadlock kernel/locking/lockdep.c:3031 [inline]
validate_chain kernel/locking/lockdep.c:3816 [inline]
__lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053
lock_acquire kernel/locking/lockdep.c:5665 [inline]
lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630
__mutex_lock_common kernel/locking/mutex.c:603 [inline]
__mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747
usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230
usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109
r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622
usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458
device_remove drivers/base/dd.c:545 [inline]
device_remove+0x11f/0x170 drivers/base/dd.c:537
__device_release_driver drivers/base/dd.c:1222 [inline]
device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248
usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627
usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118
usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114
This turned out not to be an error in usb-storage but rather a nested
device reset attempt. That is, as the rtl8712 driver was being
unbound from a composite device in preparation for an unrelated USB
reset (that driver does not have pre_reset or post_reset callbacks),
its ->remove routine called usb_reset_device() -- thus nesting one
reset call within another.
Performing a reset as part of disconnect processing is a questionable
practice at best. However, the bug report points out that the USB
core does not have any protection against nested resets. Adding a
reset_in_progress flag and testing it will prevent such errors in the
future.
Link: https://lore.kernel.org/all/CAB7eexKUpvX-JNiLzhXBDWgfg2T9e9_0Tw4HQ6keN==voRbP0g@mail.gmail.com/
Cc: stable@vger.kernel.org
Reported-and-tested-by: Rondreis <linhaoguo86@gmail.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/YwkflDxvg0KWqyZK@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A recent commit expanding the scope of the udc_lock mutex in the
gadget core managed to cause an obscure and slightly bizarre lockdep
violation. In abbreviated form:
======================================================
WARNING: possible circular locking dependency detected
5.19.0-rc7+ #12510 Not tainted
------------------------------------------------------
udevadm/312 is trying to acquire lock:
ffff80000aae1058 (udc_lock){+.+.}-{3:3}, at: usb_udc_uevent+0x54/0xe0
but task is already holding lock:
ffff000002277548 (kn->active#4){++++}-{0:0}, at: kernfs_seq_start+0x34/0xe0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (kn->active#4){++++}-{0:0}:
lock_acquire+0x68/0x84
__kernfs_remove+0x268/0x380
kernfs_remove_by_name_ns+0x58/0xac
sysfs_remove_file_ns+0x18/0x24
device_del+0x15c/0x440
-> #2 (device_links_lock){+.+.}-{3:3}:
lock_acquire+0x68/0x84
__mutex_lock+0x9c/0x430
mutex_lock_nested+0x38/0x64
device_link_remove+0x3c/0xa0
_regulator_put.part.0+0x168/0x190
regulator_put+0x3c/0x54
devm_regulator_release+0x14/0x20
-> #1 (regulator_list_mutex){+.+.}-{3:3}:
lock_acquire+0x68/0x84
__mutex_lock+0x9c/0x430
mutex_lock_nested+0x38/0x64
regulator_lock_dependent+0x54/0x284
regulator_enable+0x34/0x80
phy_power_on+0x24/0x130
__dwc2_lowlevel_hw_enable+0x100/0x130
dwc2_lowlevel_hw_enable+0x18/0x40
dwc2_hsotg_udc_start+0x6c/0x2f0
gadget_bind_driver+0x124/0x1f4
-> #0 (udc_lock){+.+.}-{3:3}:
__lock_acquire+0x1298/0x20cc
lock_acquire.part.0+0xe0/0x230
lock_acquire+0x68/0x84
__mutex_lock+0x9c/0x430
mutex_lock_nested+0x38/0x64
usb_udc_uevent+0x54/0xe0
Evidently this was caused by the scope of udc_mutex being too large.
The mutex is only meant to protect udc->driver along with a few other
things. As far as I can tell, there's no reason for the mutex to be
held while the gadget core calls a gadget driver's ->bind or ->unbind
routine, or while a UDC is being started or stopped. (This accounts
for link #1 in the chain above, where the mutex is held while the
dwc2_hsotg_udc is started as part of driver probing.)
Gadget drivers' ->disconnect callbacks are problematic. Even though
usb_gadget_disconnect() will now acquire the udc_mutex, there's a
window in usb_gadget_bind_driver() between the times when the mutex is
released and the ->bind callback is invoked. If a disconnect occurred
during that window, we could call the driver's ->disconnect routine
before its ->bind routine. To prevent this from happening, it will be
necessary to prevent a UDC from connecting while it has no gadget
driver. This should be done already but it doesn't seem to be;
currently usb_gadget_connect() has no check for this. Such a check
will have to be added later.
Some degree of mutual exclusion is required in soft_connect_store(),
which can dereference udc->driver at arbitrary times since it is a
sysfs callback. The solution here is to acquire the gadget's device
lock rather than the udc_mutex. Since the driver core guarantees that
the device lock is always held during driver binding and unbinding,
this will make the accesses in soft_connect_store() mutually exclusive
with any changes to udc->driver.
Lastly, it turns out there is one place which should hold the
udc_mutex but currently does not: The function_show() routine needs
protection while it dereferences udc->driver. The missing lock and
unlock calls are added.
Link: https://lore.kernel.org/all/b2ba4245-9917-e399-94c8-03a383e7070e@samsung.com/
Fixes: 2191c00855 ("USB: gadget: Fix use-after-free Read in usb_udc_uevent()")
Cc: Felipe Balbi <balbi@kernel.org>
Cc: stable@vger.kernel.org
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/YwkfhdxA/I2nOcK7@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since 1599069a62 ("phy: core: Warn when phy_power_on is called before
phy_init") the driver complains. In my case (Amlogic SoC) the warning
is: phy phy-fe03e000.phy.2: phy_power_on was called before phy_init
So change the order of the two calls. The same change has to be done
to the order of phy_exit() and phy_power_off().
Fixes: 09a75e8577 ("usb: dwc2: refactor common low-level hw code to platform.c")
Cc: stable@vger.kernel.org
Acked-by: Minas Harutyunyan <hminas@synopsys.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/dfcc6b40-2274-4e86-e73c-5c5e6aa3e046@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Retimer device class is left dangling when the typec module
is unloaded. Attempts to reload the module failed with warning:
"sysfs: cannot create duplicate filename '/class/retimer'"
Fixing the issue by unregistering the class properly.
Fixes: ddaf8d96f9 ("usb: typec: Add support for retimers")
Reviewed-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20220825140411.10743-1-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The dwc3 driver manages its PHYs itself so the USB core PHY management
needs to be disabled.
Use the struct xhci_plat_priv hack added by commits 46034a999c ("usb:
host: xhci-plat: add platform data support") and f768e71891 ("usb:
host: xhci-plat: add priv quirk for skip PHY initialization") to
propagate the setting for now.
Fixes: 4e88d4c083 ("usb: add a flag to skip PHY initialization to struct usb_hcd")
Fixes: 178a0bce05 ("usb: core: hcd: integrate the PHY wrapper into the HCD core")
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Cc: stable <stable@kernel.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20220825131836.19769-1-johan+linaro@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Lenovo OneLink+ Dock contains two VL812 USB3.0 controllers:
17ef:1018 upstream
17ef:1019 downstream
Those two controllers both have problems with some USB3.0 devices,
particularly self-powered ones. Typical error messages include:
Timeout while waiting for setup device command
device not accepting address X, error -62
unable to enumerate USB device
By process of elimination the controllers themselves were identified as
the cause of the problem. Through trial and error the issue was solved
by using USB_QUIRK_RESET_RESUME for both chips.
Signed-off-by: Jean-Francois Le Fillatre <jflf_kernel@gmx.com>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20220824191320.17883-1-jflf_kernel@gmx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
works perfectly with:
modprobe ftdi_sio
echo "0590 00b2" | tee
/sys/module/ftdi_sio/drivers/usb-serial\:ftdi_sio/new_id > /dev/null
but doing this every reboot is a pain in the ass.
Signed-off-by: Niek Nooijens <niek.nooijens@omron.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
This reverts commit 83810f84ec.
Turning off port power in shutdown did cause issues such as a laptop not
proprly powering off, and some specific usb devies failing to enumerate the
subsequent boot after a warm reset.
So revert this.
Fixes: 83810f84ec ("xhci: turn off port power in shutdown")
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20220825150840.132216-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After xHC controller is started, either in probe or resume, it can take
a while before any of the connected usb devices are visible to the roothub
due to link training.
It's possible xhci driver loads, sees no acivity and suspends the host
before the USB device is visible.
In one testcase with a hotplugged xHC controller the host finally detected
the connected USB device and generated a wake 500ms after host initial
start.
If hosts didn't suspend the device duringe training it probablty wouldn't
take up to 500ms to detect it, but looking at specs reveal USB3 link
training has a couple long timeout values, such as 120ms
RxDetectQuietTimeout, and 360ms PollingLFPSTimeout.
So Add a 500ms grace period that keeps polling the roothub for 500ms after
start, preventing runtime suspend until USB devices are detected.
Cc: stable@vger.kernel.org
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20220825150840.132216-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The remove path in xhci platform driver tries to remove and put both main
and shared hcds even if only a main hcd exists (one roothub)
This causes a null pointer dereference in reboot for those controllers.
Check that the shared_hcd exists before trying to remove it.
Fixes: e0fe986972 ("usb: host: xhci-plat: prepare operation w/o shared hcd")
Reported-by: Alexey Sheplyakov <asheplyakov@basealt.ru>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20220825150840.132216-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The recent commit 87d0e2f41b ("usb: typec: ucsi: add a common
function ucsi_unregister_connectors()") introduced a regression that
caused NULL dereference at reading the power supply sysfs. It's a
stale sysfs entry that should have been removed but remains with NULL
ops. The commit changed the error handling to skip the entries after
a NULL con->wq, and this leaves the power device unreleased.
For addressing the regression, the straight revert is applied here.
Further code improvements can be done from the scratch again.
Link: https://bugzilla.suse.com/show_bug.cgi?id=1202386
Link: https://lore.kernel.org/r/87r11cmbx0.wl-tiwai@suse.de
Fixes: 87d0e2f41b ("usb: typec: ucsi: add a common function ucsi_unregister_connectors()")
Cc: <stable@vger.kernel.org>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20220823065455.32579-1-tiwai@suse.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The dwc3_qcom_read_usb2_speed() helper is now only called when the
controller is acting as host, but the compiler will warn that the hcd
variable is unused in gadget-only W=1 builds.
Fixes: c06795f114 ("usb: dwc3: qcom: fix gadget-only builds")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20220822100550.3039-1-johan+linaro@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On page 362 of the USB3.2 specification (
https://usb.org/sites/default/files/usb_32_20210125.zip),
The 'SuperSpeed Endpoint Companion Descriptor' shall only be returned
by Enhanced SuperSpeed devices that are operating at Gen X speed.
Each endpoint described in an interface is followed by a 'SuperSpeed
Endpoint Companion Descriptor'.
If users use SuperSpeed UDC, host can't recognize the device if endpoint
doesn't have 'SuperSpeed Endpoint Companion Descriptor' followed.
Currently in the uac2 driver code:
1. ss_epout_desc_comp follows ss_epout_desc;
2. ss_epin_fback_desc_comp follows ss_epin_fback_desc;
3. ss_epin_desc_comp follows ss_epin_desc;
4. Only ss_ep_int_desc endpoint doesn't have 'SuperSpeed Endpoint
Companion Descriptor' followed, so we should add it.
Fixes: eaf6cbe099 ("usb: gadget: f_uac2: add volume and mute support")
Cc: stable <stable@kernel.org>
Signed-off-by: Jing Leng <jleng@ambarella.com>
Signed-off-by: Jack Pham <quic_jackp@quicinc.com>
Link: https://lore.kernel.org/r/20220721014815.14453-1-quic_jackp@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This happens when @udev->reset_resume is set to true, when usb resume,
the flow as below:
- hub_resume
- usb_disable_interface
- usb_disable_endpoint
- usb_hcd_disable_endpoint
- xhci_endpoint_disable // it set @ep->hcpriv to NULL
Then when reset usb device, it will drop allocated endpoints,
the flow as below:
- usb_reset_and_verify_device
- usb_hcd_alloc_bandwidth
- xhci_mtk_drop_ep
but @ep->hcpriv is already set to NULL, the bandwidth will be not
released anymore.
Due to the added endponts are stored in hash table, we can drop the check
of @ep->hcpriv.
Fixes: 4ce186665e ("usb: xhci-mtk: Do not use xhci's virt_dev in drop_endpoint")
Cc: stable <stable@kernel.org>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/20220819080556.32215-2-chunfeng.yun@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently uses the worst case byte budgets on FS/LS bus bandwidth,
for example, for an isochronos IN endpoint with 192 bytes budget, it
will consume the whole 5 uframes(188 * 5) while the actual FS bus
budget should be just 192 bytes. It cause that many usb audio headsets
with 3 interfaces (audio input, audio output, and HID) cannot be
configured.
To improve it, changes to use "approximate" best case budget for FS/LS
bandwidth management. For the same endpoint from the above example,
the approximate best case budget is now reduced to (188 * 2) bytes.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20220819080556.32215-1-chunfeng.yun@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix incorrect pin assignment values when connecting to a monitor with
Type-C receptacle instead of a plug.
According to specification, an UFP_D receptacle's pin assignment
should came from the UFP_D pin assignments field (bit 23:16), while
an UFP_D plug's assignments are described in the DFP_D pin assignments
(bit 15:8) during Mode Discovery.
For example the LG 27 UL850-W is a monitor with Type-C receptacle.
The monitor responds to MODE DISCOVERY command with following
DisplayPort Capability flag:
dp->alt->vdo=0x140045
The existing logic only take cares of UPF_D plug case,
and would take the bit 15:8 for this 0x140045 case.
This results in an non-existing pin assignment 0x0 in
dp_altmode_configure.
To fix this problem a new set of macros are introduced
to take plug/receptacle differences into consideration.
Fixes: 0e3bb7d689 ("usb: typec: Add driver for DisplayPort alternate mode")
Cc: stable@vger.kernel.org
Co-developed-by: Pablo Sun <pablo.sun@mediatek.com>
Co-developed-by: Macpaul Lin <macpaul.lin@mediatek.com>
Reviewed-by: Guillaume Ranquet <granquet@baylibre.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Pablo Sun <pablo.sun@mediatek.com>
Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
Link: https://lore.kernel.org/r/20220804034803.19486-1-macpaul.lin@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
onboard_hub_power_off() currently has a delay after asserting the
reset of the hub. There is already a delay in onboard_hub_power_on()
before de-asserting the reset, which ensures that the reset is
asserted for the required time, so the delay in _power_off() is not
needed.
Skip the reset GPIO check before calling gpiod_set_value_cansleep(),
the function returns early when the GPIO descriptor is NULL.
Reviewed-By: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/20220805111836.1.Id5a4dc0a2c046236116693aa55672295513a0f2a@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Relocate the pullups_connected check until after it is ensured that there
are no runtime PM transitions. If another context triggered the DWC3
core's runtime resume, it may have already enabled the Run/Stop. Do not
re-run the entire pullup sequence again, as it may issue a core soft
reset while Run/Stop is already set.
This patch depends on
commit 69e131d1ac ("usb: dwc3: gadget: Prevent repeat pullup()")
Fixes: 77adb8bdf4 ("usb: dwc3: gadget: Allow runtime suspend if UDC unbinded")
Cc: stable <stable@kernel.org>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220728020647.9377-1-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This adds the necessary PCI device ID for the controller
inside the Intel Raptor Lake CPU block. The controllers that
are part of the PCH (chipset) have separate device IDs.
Cc: stable@vger.kernel.org
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20220815123334.87526-1-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This adds the necessary ACPI ID for Intel Meteor Lake
IOM devices.
The callback function is_memory() is modified so that it
also checks if the resource descriptor passed to it is a
memory type "Address Space Resource Descriptor".
On Intel Meteor Lake the ACPI memory resource is not
described using the "32-bit Memory Range Descriptor" because
the memory is outside of the 32-bit address space. The
memory resource is described using the "Address Space
Resource Descriptor" instead.
Intel Meteor Lake is the first platform to describe the
memory resource for this device with Address Space Resource
Descriptor, but it most likely will not be the last.
Therefore the change to the is_memory() callback function
is made generic.
Signed-off-by: Utkarsh Patel <utkarsh.h.patel@intel.com>
Cc: stable@vger.kernel.org
[ heikki: Rewrote the commit message. ]
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20220816101629.69054-2-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Clean up the suspend callbacks by separating the error and success paths
to improve readability.
Also drop a related redundant initialisation.
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20220804151001.23612-10-johan+linaro@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It is the Qualcomm glue wakeup interrupts that may be able to wake the
system from suspend and this can now be described in the devicetree.
Move the wakeup-source property handling over from the core driver and
instead propagate the capability setting to the core device during
probe.
This is needed as there is currently no way for the core driver to query
the wakeup setting of the glue device, but it is the core driver that
manages the PHY power state during suspend.
Also don't leave the PHYs enabled when system wakeup has been disabled
through sysfs.
Fixes: 649f5c842b ("usb: dwc3: core: Host wake up support from system suspend")
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20220804151001.23612-9-johan+linaro@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A recent commit implementing wakeup support in host mode instead broke
suspend for peripheral and OTG mode.
The hack that was added in the suspend path to determine the speed of
any device connected to the USB2 bus not only accesses internal driver
data for a child device, but also dereferences a NULL pointer or
accesses freed data when the controller is not acting as host.
There's no quick fix to the layering violation, but since reverting
would leave us with broken suspend in host mode with wakeup triggering
immediately, let's keep the hack for now.
Fix the immediate issues by only checking the host bus speed and
enabling wakeup interrupts when acting as host.
Fixes: 6895ea55c3 ("usb: dwc3: qcom: Configure wakeup interrupts during suspend")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20220804151001.23612-7-johan+linaro@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A device must enable wakeups during runtime suspend regardless of
whether it is capable and allowed to wake the system up from system
suspend.
Fixes: 2664deb093 ("usb: dwc3: qcom: Honor wakeup enabled/disabled state")
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20220804151001.23612-6-johan+linaro@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Qualcomm dwc3 runtime-PM implementation checks the xhci
platform-device pointer in the wakeup-interrupt handler to determine
whether the controller is in host mode and if so triggers a resume.
After a role switch in OTG mode the xhci platform-device would have been
freed and the next wakeup from runtime suspend would access the freed
memory.
Note that role switching is executed from a freezable workqueue, which
guarantees that the pointer is stable during suspend.
Also note that runtime PM has been broken since commit 2664deb093
("usb: dwc3: qcom: Honor wakeup enabled/disabled state"), which
incidentally also prevents this issue from being triggered.
Fixes: a4333c3a6b ("usb: dwc3: Add Qualcomm DWC3 glue driver")
Cc: stable@vger.kernel.org # 4.18
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20220804151001.23612-5-johan+linaro@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
