summaryrefslogtreecommitdiffstats
path: root/sys/dev/usb/xhci.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* remove unused xhci_cmd_evaluate_ctx()jsg2021-02-241-22/+1
| | | | ok mpi@
* Do proper accounting of zero length TDs. Currently a specific numbermglocker2020-12-241-1/+4
| | | | | | | | | | | | of zero length TDs can cause our free TRBs to run out, causing xhci(4) to return USBD_NOMEM to the USB stack. The issue was reported by Jonathon Fletcher <jonathon.fletcher () gmail ! com> -- Thanks! Reviewed/suggestions by patrick@. ok mpi@
* In xhci_device_isoc_start() do first check if the transfer ismglocker2020-07-311-8/+8
| | | | | | | | | | | in-progress before we do check for the pipe being halted. This fixes some kind of race condition for isoc devices during device close when xp->halted gets set while usbd_start_next() still tries to dequeue in-progress transfers which will report 'usbd_start_next: error=13' (USBD_IOERROR). ok mpi@
* Don't nest a enum declaration inside a struct declaration, and anywayderaadt2020-07-291-6/+4
| | | | | | since the enum isn't tied to the type (because want smaller storage) is better to use #define ok kettenis mglocker
* Fix a problem related to isochronous transfers appearing in certainmglocker2020-07-281-9/+32
| | | | | | | | | | | | | constellations resulting in bogus frame sizes being returned by xhci(4). E.g. for uvideo(4) devices erroneous video streams were reported. The problem occurs when multi-trb TDs are queued and being processed as a zero-length or short transfer. Those cases were not handled in the current isochronous code path, which this patch is adding. Feedback and testing done by many on tech@. Thanks! ok mpi@
* When a transfer times out, the TRB should be aborted, too. But stillgerhard2020-06-301-8/+21
| | | | | | | | the completion interrupt may already be pending while aborting. Hence, in xhci_event_command() ignore events from a TRB that is not the expected one. And don't let xhci_abort_command() yield the CPU. ok mpi@
* Acknowledge xhci(4) interrupts before calling usb_schedsoftintr().patrick2020-06-241-5/+5
| | | | | | | | | | | | | | | | | On powerdown (halt -p), sd(4)'s suspend function tries to powerdown a USB mass storage using a STOP command. In that case we are already cold and splhigh(), so that the xhci is supposed to run in polling- mode. usb_schedsoftintr() behaves differently when running in polling-mode. Instead of scheduling a soft interrupt, it immediately dequeues from the event queue. But dequeueing means touching the xhci registers. Apparently we need to acknowledge the interrupts before touching those registers, the hardware doesn't like it otherwise and we will never get an interrupt status for the second transfer. ok gerhard@
* Move the responsibility of syncing the data buffers from the USBpatrick2020-04-031-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | stack into the USB controller driver, since not all of the xfers actually use DMA and some invalidations might even be harmful. The important part is to sync before handing the buffer to the controller, and to sync on a successful transfer before handing it back to the USB stack. For isoc transfers it's easier to sync the complete length of the transfer, since the buffer to flush is not filled in a contiguous fashion. For dwc2 there's a common point which takes care of the start of transfers from or to devices, where we can make sure that our buffers are synced. On completion, there's a common point before handing it off to the USB stack. For ehci there are three places which take care of the start of transfers from or to devices, where one already does the sync, while the two other places still need the sync. There are two completion handler (isoc and non-isoc), where one already has a comment asking for the need of a sync. The done handler for intr xfers does a sync that is not needed anymore after adding the sync in the completion handler. For ohci there are three places which take care of the start of transfers from or to devices, where all of them were still in need of the sync. For completion, there is one place for isoc xfers and two places for handling successful generic xfers. For uhci there are two places which take care of the start of transfers from or to device, where all of them were still in need of the sync. For completion, there is one handler for both isoc and non-isoc xfers where syncs need to occur. For xhci there are three places which take care of the start of transfers from or to device, where all of them were still in need of the sync. For completion, there is one handler for isoc and one for non-isoc xfers where syncs need to occur. With this we can revert the workaround that implicitly allocated buffers are COHERENT, since now control transfers fulfilled by the driver code (instead of the controller doing DMA) are not flushed into oblivion anymore. Tested by Janne Johansson with dwc2 (octeon) Tested by kettenis@ with xhci(4) (octeon) Tested by patrick@ with ehci(4) on a Cubox-i (armv7) Tested by patrick@ with xhci(4) on an i.MX8MQ (arm64) Tested by tobhe@ with dwc2 on a rPi 3b (arm64) ok kettenis@
* Fix endian swapping of trb_flags and trb_status in xhci(4).visa2020-03-021-9/+10
| | | | | | | | | This corrects computation of xfer->actlen, allowing xhci(4) to work again on octeon and other big endian architectures. Reported by Allen Smith OK patrick@
* use the UE_GET_XFERTYPE macro where applicablejasper2020-02-221-2/+2
| | | | ok mpi@
* Add a zero length TD, rather than adding a zero length TRB to thekrw2020-01-221-11/+32
| | | | | | | | | | | | | | | original TD, when a transfer is a multiple of the max packet size. The zero length TD will have a NULL xfer pointer. As a result "NULL xfer pointer" situations become perfectly normal. So change the log_warnx() that issues that verbiage to a log_debug(). Note that the original transfer will complete and report its result up the USB stack before the zero length transfer is executed. Fixes (at least) urtwn(4) interfaces. Feeback, cluebats, fixes and ok patrick@
* Ensure XHCI_SCTX_DCI() always contains a valid number, i.e. the DCI ofkrw2020-01-131-10/+21
| | | | | | | | | | | | | the highest active endpoint context. Don't zap other fields when setting XHCI_SCTX_DCI(). Fixes (at least) Etron EJ168 USB 3.0 Host Controllers vs USB 2 devices. Inspired by hselasky FreeBSD revision 243780. Feedback from kn@, ok beck@ (previous iteration) patrick@
* On short transfers with multiple TRBs in a TD we get two events.patrick2019-11-281-3/+4
| | | | | | | | | | One on the TRB that went short, and one for the last TRB in a TD. We already set actlen only once so that the last TRB in a TD does not override it, but some controllers throw another short event instead of a success event, so we have to add the same check there as well. ok gerhard@ mglocker@
* Fix off-by-one TRB issue in bulk transfers larger than 64k.mglocker2019-11-181-2/+2
| | | | | | This makes udl(4) on xhci(4) work fine. Help and ok patrick@
* Fix actual length calculation of short transfers in xhci(4). So farpatrick2019-11-181-8/+37
| | | | | | | | | | | | | | | we have subtracted the remaining length from the total transfer length, which essentially means that we assume that all TRBs have successfully been transferred apart from the remainder. Actually we might get a short completion in the middle of a chain of TRBs, which means that all TRBs until this TRB have completed successfully apart from a remainder. Thus we have to count the length of all TRBs until and including the one that we went short on, and remove the remainder. All following TRBs in the same transfer must be ignored. Found by and fixed with gerhard@ ok mglocker@
* Use MSEC_TO_NSEC() to define XHCI_CMD_TIMEOUT & use it w/ tsleep_nsec(9).mpi2019-10-061-4/+3
| | | | ok visa@, kn@
* Do not consider the pipe as halted if the device is gone.mpi2019-06-131-1/+3
| | | | Analysed by and ok claudio@
* Fix NULL check with wrong pointer in xhci_event_xfer_isoc(); CID 1480287stsp2019-05-211-2/+2
| | | | ok ratchov@
* Decrease verbosity when XHCI_DEBUG is defined.ratchov2019-04-301-3/+3
| | | | ok mpi
* Handle missed service errors, specific to isochronous transfers.ratchov2019-04-101-1/+52
| | | | | | | | | After each MSE, ensuire usbd_complete_transfer() is called for each missed transfer, for which there's no transfer completion event. Fixes crashes and deadlocks in upper layers caused by the missing completion. ok deraadt, patrick; help from mpi, patrick, gmlocker
* Since an isoc endpoint never halts, move to remaining error handlingmglocker2019-03-171-58/+48
| | | | | | code in xhci_event_xfer() to the generic handler function. suggested and ok mpi@
* Move the handler code in the xhci_event_xfer() switch case in two separatemglocker2019-03-171-40/+66
| | | | | | | | functions for isoc and !isoc xfers. Suggested by mpi@. ok patrick@, stsp@
* Remove obsolete semicolon at end of case switch.mglocker2019-03-171-2/+2
|
* Merge the duplicate code to handle isoc SHORT and SUCCESS xfer eventsmglocker2019-03-161-83/+54
| | | | | | to one single function. ok mpi@
* Improve and enable isochronous transfers in xhci(4). Each isochronouspatrick2019-03-151-58/+193
| | | | | | | | | | | | | | | | frame has to be enqueued as Transfer Descriptor. This means each frame starts with an isoch TRB and may also contain further normal TRBs. The TDs each throw at least one interrupt for a successful completion or possibly more in case of a short xfer. We have to account the amount of data transfered for each frame using the completion of the matching TD and its TRBs. Thanks to stsp@ for initiating this, and many more thanks to mglocker@ for reworking and cleaning up my initial diff. Further improvements can happen in-tree now. Tested by mglocker@, phessler@ and stsp@ ok mglocker@, stsp@
* The max burst size that is encoded in wMaxPacketSize is zero based,patrick2019-03-151-3/+3
| | | | | | | as in: Since there's always one transfer, 0 means 1. Thus we have to add 1 (not OR) to get to the desired number. ok mglocker@ mpi@ stsp@
* Fix typo in debug print: wih -> withpatrick2019-03-121-3/+3
| | | | ok mpi@
* Add missing bus powered bit, from aalm@mpi2019-03-111-2/+2
|
* Since ring->index points to the next free slot, once we reach index zeropatrick2019-03-011-14/+17
| | | | | | | | | we know that the last non-link TRB has been written and we can look at the flags to set the chain bit in the link TRB. Since we will now toggle the cycle bit on the first TRB of a ring, set it on the ring reset. Tested by jcs@, jsg@ and visa@ "commit it" jcs@
* Make xhci_ring_produce() check the previous TRB to find out if itpatrick2019-02-271-72/+78
| | | | | | | | | | | | | needs the Chain Bit set or not instead of using the last parameter, which is used to mark the last TRB in a USB transfer, not in a TD. To make that work we need to setup the recently acquired TRB before calling xhci_xfer_get_trb() the next time. Thus setting up the initial TRB has to happen right away. To kick the transfer off we simply flip the toggle bit on the first TRB right at the end. Fixes regression for jcs@, dhill@ and stsp@ Initially discussed with mpi@ ok stsp@
* Transfers that span multiple TRBs which wrap around the ring andpatrick2019-02-211-5/+9
| | | | | | | | | | | | thus have the Link TRB inbetween must have the Chain Bit set in the Link TRB. Otherwise xHCI controllers might think that the transfer ends at that point. Fixes an issue that was most prominently seen as Invalid CSW error when using umass0 on octeon and i.MX8M. Tested by visa@ ok mpi@
* Print xhci version in hex, from sc.dying at gmail.mpi2019-02-011-2/+2
|
* If we cannot stop the endpoint when aborting a transfer assume thatmpi2018-09-061-2/+7
| | | | | | | | the device is gone and give back the descriptor to the stack. Without this usbd_abort_pipe() could end up in an infinite loop. Issue reported by Tom Murphy.
* Serialize synchronous commands with a rwlock.mpi2018-09-051-8/+34
| | | | | | | Prevent triggering an assert if two drivers try to submit a command at the same time. Issue reported by Tom Murphy.
* typos, from Michael W. Bombardieri.mpi2018-07-161-5/+5
|
* Add bus DMA barriers to ensure the hardware does not see a TRB cycle bitvisa2018-05-131-5/+19
| | | | | | flip before the rest of the TRB is updated. OK dlg@, pirofti@, mpi@
* Print xHCI revision in dmesg.mpi2018-05-081-7/+4
| | | | ok patrick@, kettenis@
* Unsigned values are always >= 0, fix Coverity 1468443.mpi2018-04-291-2/+2
|
* Print more debug informations in the event xfer handler.mpi2018-04-281-5/+10
|
* Introduce an helper function to extract endpoint's max burst value.mpi2018-04-271-19/+72
| | | | | | | | | Use this helper to calculate the Transfer Burst Count (TBC) and Transfer Last Burst Packet Count (TLBPC) required for isochronous support. Note that SS companion descriptors are still not read. While here print the ETE and IST values in debug mode.
* Print index as unsigned.mpi2018-04-271-5/+5
|
* Fix an off-by-one in xhci_xfer_tdsize().mpi2018-04-271-7/+5
| | | | | | While here use UE_GET_SIZE() coherently. ok pirofti@, stsp@, visa@
* Reduce differences between isoch & bulk/intr routines.mpi2018-04-261-21/+20
| | | | ok stsp@
* Follows section 6.2.3.6 to compute endpoint interval.mpi2018-04-261-32/+58
| | | | ok stsp@
* Add support for isochronous transfers to xhci(4).stsp2017-09-081-25/+202
| | | | | | | | | This is just a step forward which allows further progress to happen in-tree. The isochronous code path remains disabled for now. Playing audio over xhci(4) does not work properly yet, and I haven't even tested video input. Based on a work-in-progress diff by mpi@ from 2015. ok mpi@
* Revert previous: "Fix a remaining length miscalculation in xhci(4)."stsp2017-09-041-2/+2
| | | | It made one of my machines get stuck during boot.
* Fix a remaining length miscalculation in xhci(4).stsp2017-09-011-2/+2
| | | | | | | | | | | | | Each TRB contains a remaining TD size, which allows hardware to tell whether additional TRBs follow within the current transfer without reading ahead. The length of the first TRB was subtracted from the total length before calculating the remaining TD sizes. This is wrong because remaining TD sizes are relative to the size of the entire transfer, including the first TRB. Our current USB code does not trigger this bug because there is no code in upper layers yet which triggers use of multiple TRBs per transfer. ok mpi@
* Use memcpy instead of casts to copy 8 bytes of data to avoid unalignedkettenis2017-07-301-2/+2
| | | | | | access. ok visa@, mpi@, deraadt@
* double ;;. xhci one found by geoffhillderaadt2017-06-221-2/+2
|
* Fix a use-after-free when sending root hub control transfers.mpi2017-03-101-2/+2
| | | | | | | | | | | *_root_ctrl_start() routines are synchronous and all end up calling usb_transfer_complete() in the non-error case. After calling this function it is unsafe to dereference ``xfer'' since the transfer callback has been called. So returning USBD_IN_PROGRESS is wrong in this case since transfers are always completed at this point. So return USBD_NORMAL_COMPLETION or the corresponding error code if something wrong happen.
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.