computing the same isochronous start frame number over and over again. PR: 257082 Sponsored by: NVIDIA Networking Approved by: re (gjb) (cherry picked from commit 8fc2a3c41791b205a107dc2bec16ac7514a57958) (cherry picked from commit f52783fcf5cc60734121d061beef0d4ea47b224a) (cherry picked from commit cf48d1f77126d8de4c03c4dd7c8502be2b5f1954) (cherry picked from commit 99977369433de3eaec6907e51bcabc1dbb088628)
Handle the fact that parts of usb(4) can be compiled into the boot loader, where M_WAITOK does not guarantee a successful allocation. PR: 240545 Submitted by: Andrew Reiter <arr@watson.org> (original version) Reviewed by: hselasky MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D25706
device drivers to correctly predict the default USB transfer frame length. MFC after: 3 days Sponsored by: Mellanox Technologies
Do not count these as errors. MFC after: 1 week Sponsored by: Mellanox Technologies
Bump the FreeBSD version due to structure change to force recompilation of external USB modules. MFC after: 1 week Sponsored by: Mellanox Technologies
above 1Kbyte. It might look like some XHCI(4) controllers do not support when the USB control transfer is split using a link TRB. The next NORMAL TRB after the link TRB is simply failing with XHCI error code 4. The quirk ensures we allocate a 64Kbyte buffer so that the data stage TRB is not broken with a link TRB. Found at: EuroBSDcon 2019 MFC after: 1 week Sponsored by: Mellanox Technologies
Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
mutexes or using any callouts when active. Trying to lock a mutex when KDB is active or the scheduler is stopped can result in infinite wait loops. The same goes for calling callout related functions which in turn lock mutexes. If the USB controller at which a USB keyboard is connected is idle when KDB is entered, polling the USB keyboard via USB will always succeed. Else polling may fail depending on which state the USB subsystem and USB interrupt handler is in. This is unavoidable unless KDB can wait for USB interrupt threads to complete before stalling the CPU(s). Tested by: Bruce Evans <bde@freebsd.org> MFC after: 4 weeks
by reviving the SX control request lock and refining which lock protects the common scratch area in "struct usb_device". The SX control request lock was removed by r246759 because it caused a lock order reversal with the USB enumeration lock inside usbd_transfer_setup() as a function of r246616. It was thought that reducing the number of locks would resolve the LOR, but because some USB device drivers use usbd_do_request_flags() inside callback functions, like in taskqueues, a deadlock may occur when these are drained from device_detach(). By restoring the SX control request lock usbd_do_request_flags() is allowed to complete its execution when a USB device driver is detaching. By using the SX control request lock to protect the scratch area, the LOR introduced by r246616 is also resolved. Bump the FreeBSD version while at it to force recompilation of all USB kernel modules. Found by: avos@ MFC after: 1 week