to Linux hidraw compatibility API. Respective Linux commit f43d3870cafa made by Dean Camera message is: Currently the hidraw module can only read and write feature HID reports on demand, via dedicated ioctls. Input reports are read from the device through the read() interface, while output reports are written through the write interface(). This is insufficient; it is desirable in many situations to be able to read and write input and output reports through the control interface to cover additional scenarios: - Reading an input report by its report ID, to get initial state - Writing an input report, to set initial input state in the device - Reading an output report by its report ID, to obtain current state - Writing an output report by its report ID, out of band This patch adds these missing ioctl requests to read and write the remaining HID report types. Note that not all HID backends will neccesarily support this (e.g. while the USB link layer supports setting Input reports, others may not). FreeBSD native uhid(4) compatible API already has similar ioctls. MFC after: 3 days (cherry picked from commit fd6690e2d5cd5b15fce2c74ab0cac77a83514f6a)
10ms seems to be too strict for some configurations, so increase to 20ms. Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/1327 (cherry picked from commit e152944f1a16a4ff33b4e20b813ce4a54b884b90)
Only set the GETMAXLUN quirk when it causes an error, but don't set it when it returns 0. Since we reset the device when we set any quirk, only set this quirk when it generates an error so umass will avoid it. When the command works, there's no reason for umass to avoid it at all. MFC After: 1 week Sponsored by: Netflix (cherry picked from commit b0375f78e32acd7947d28126a5e165f8139a5a23)
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)
PR: 284643 Reviewed by: adrian Approved by: emaste (mentor) MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D48948 (cherry picked from commit 4b77a9a80cf8a9cba5607d8d8fa0742334dcf0f4)
ELECOM EDC-QUA3C is a USB3.1 Gen1 Type-A/C 2.5GBASE-T network adapter. This also works as a cdce(4) device by: usbconfig -d X.Y set_config 1 or usbconfig -d X.Y set_config 2 Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> MFC after: 2 weeks Pull Request: https://github.com/freebsd/freebsd-src/pull/1578 (cherry picked from commit dc273058cb0b6bef075e77272afc66f1a1fd3889)
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)
USB_GET_REPORT ioctl is documented to update ugd_actlen on return with the number of bytes copied. It does not do this. Reviewed by: wulf PR: 282790 MFC after: 1 week (cherry picked from commit 0b5d86b38ae9aec92ef96b9227a404a2df3c9234)