These includes were for __FBSD_RCSID() macro. They weren't formatted
like the rest of the tree so weren't trimmed automatically when that
script was run. Trim them now.
MFC After: 1 week
Sponsored by: Netflix
(cherry picked from commit ca48e43ba9ee73a07cdbad8365117793b01273bb)
The termios layer wants some level of guarantee that we've actually
submitted param changes to the hardware when our functions return, so we
need to do a little more waiting to avoid violating those guarantees.
This is especially important as some hardware has some minimum timing
specifications around this stuff, and without being less asynchronous
the software dealing with these devices can't reasonably operate the
hardware without more excessive delays than they should need.
More specifically, we make sure that:
- The command to start transfers is finished before we toggle DTR/RTS
- The status_change command finishes before we return, which may change
some fields in the softc that we need for a subsequent call into
usb_serial
- cfg_param finishes before we re-enable transfers, and we ensure that
RTS is appropriately toggled before we return to userland
This has been observed to fix some flakiness in connecting to some
ESP32 devices.
Tested by: kenrap from Libera
Reviewed by: imp, kib
(cherry picked from commit 36a80f4264350a2f4f0686eb91ae7f5943d40327)
ucom_queue_command will issue commands for open/close, then wait on them
to be finished. In the spirit of playing it safe, allow
ucom_queue_command's wait to be interrupted in case the usb process gets
jammed up waiting on the hardware -- we can at least recover the user
thread that initiated it, even if we can't recover the usb process.
Reviewed by: imp, kib
(cherry picked from commit 729eb176a465cedc55c5980f116d87be592421f1)
There's only one error that we can get back right now, but future
changes will add some more cases that we need to watch out for. Start
by returning errors and propagating them back.
Reviewed by: kib
(cherry picked from commit 51f3d0874f6216907c8971c4af9d6be6c93edf7b)
9600 was a standard baud rate decades ago, but 115200 is now more common
so choose defaults that are useful to the largest number of users.
Note that boot0sio does not support rates above 9600 so it remains
unchanged.
Reviewed by: bz, imp, manu
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36295
After removing the -FreeBSD and -NetBSD, we're left with a nuber of
BSD-2-Clause AND BSD-2-Clause, so tidy that up.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
The SPDX folks have obsoleted the BSD-2-Clause-NetBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
Also add the EM160R to the man page, noting the work-around
required to make it function properly in PPP mode.
MFC-After: 1 week
Sponsored by: Metify Inc.
Sponsored by: Klara Inc.
Add initialization for new Huawei 4G E3372_NCM, E3372v153_NCM,
E5573Cs322_NCM, E5573Cs322_ECM, and E5573Cs322_ACM.
Remove now-obsolete Huawei 3G E3131 init sequence. These devices are
obsolete, share IDs with new devices and the 3G networks are shutdown.
These old devices work correctly via the 4G code while still allowing
the shared IDs to work differently for the new devices.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/633
Some devices have CDC_CM descriptors that would point us to
the wrong interfaces. Add a quirk to ignore those (prefering the
CDC_UNION descriptor effectively)
Reviewed by: manu
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37942
To avoid data loss, make sure both the receive and transmit data toggles
get reset, before trying to read or write any data.
MFC after: 1 week
Sponsored by: NVIDIA Networking
To avoid issues starting any USB transfers before the open
function is complete.
Differential Revision: https://reviews.freebsd.org/D36391
MFC after: 1 week
Sponsored by: NVIDIA Networking
Some controllers like the XHCI(4) loose track of the data toggle value when
USB receive transfers are cancelled at close. This in turn can lead to to
data loss after the next open.
To avoid data loss, make sure both the receive and transmit data toggles
get reset, before trying to read or write any data.
Differential Revision: https://reviews.freebsd.org/D36391
Submitted by: Dave Baukus <daveb@spectralogic.com>
MFC after: 1 week
Sponsored by: NVIDIA Networking
Seems like a copy-paste error, or at least this made more sense when the
sio(4) driver still existed. This modifies the debug port name displayed
at boot, but otherwise has no functional change.
Reviewed by: hselasky
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D33278
After switching the dongle to the Huawei alternate mode(modem mode)
with usb_modeswitch the serial interfaces had all of their ids set to
0xFF.
After modifying umodem to work with that it attached successfully and
I've managed to configure device with standard AT commands to get
internet connection.
folder, only keeping the zero length packet API introduced in sys/dev/usb
after more reports of USB serial devices not supporting ZLPs.
Reported by: mav@
MFC after: 1 week
Sponsored by: NVIDIA Networking
port devices. If it gets eaten it is fine. Many USB device side implementations
don't properly support the clear endpoint halt command and if they do, data is lost
because the transmit FIFO is typically reset when this command is received.
Tested by: jmg
MFC after: 1 week
Sponsored by: NVIDIA Networking
