summaryrefslogtreecommitdiffstats
path: root/sys/dev/usb/usbdi.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* After the rev. 1.108 commit we see some issues with ugen(4) behaviour,mglocker2021-02-031-1/+5
| | | | | | | | | | which finally makes umb(4) fail, since ugen(4) attaches to one of the umb(4) interfaces, fails, and marks the whole device dying. Therefore make usbd_device2interface_handle() backwards compatible again. Problem reported by Mikolaj Kucharski. ok edd@
* Align the mixed naming for the variables used to reference tomglocker2021-02-011-7/+7
| | | | | | | | | bInterfaceNumber and bAlternateSetting as following: ifaceidx -> ifaceno altidx -> altno Suggested and ok mpi@
* Don't rely on USB interfaces being at compliant indices.edd2021-01-291-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When obtaining an interface handle, we currently rely on the device being properly USB compliant, and thus the interface being at the correct index in the interfaces array. However, some devices present their indices incorrectly. For example, the following audio device exposes interfaces 0, 1 and 3, in that order (skipping interface 2 entirely): uaudio2 at uhub4 port 4 configuration 1 interface 3 "E+ Corp. DAC Audio" rev 1.10/0.01 addr 2 uaudio2: class v1, full-speed, async, channels: 2 play, 0 rec, 3 ctls This means that that the audio stream interface (number 3) is not found at the expected index of 2, and this causes looking up the handle to fail. This change makes usbd_device2interface_handle() search for the right interface, instead of assuming it will be at the right index. Although this is a little slower, note that this routine not very frequently called and there are typically not hundreds of interfaces on a typical USB device. This fixes the above E+ Corp device, and one other uaudio device reported broken by a user. With input from, tested by, and OK ratchov@, mglocker@ and kettenis@. Many thanks!
* The usb configuration descriptor parameter providing the number ofmglocker2021-01-271-2/+2
| | | | | | available device interfaces is called 'bNumInterfaces'. ok phessler@, thfr@ (who provided the man page diff)
* Move the responsibility of syncing the data buffers from the USBpatrick2020-04-031-23/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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@
* USB control requests to the root hub differ from those to devices. Forpatrick2020-04-011-2/+3
| | | | | | | | | | | | | | | | | devices we have proper DMA transfers, so that the DMA syncs before and after transfers are necessary. For the root hub, we seem to fulfill those requests ourselves, e.g. by using memcpy. The POSTREAD DMA sync on a read will invalidate the caches for the buffer, and unless our root hub code explicitly flushed the data to memory, it's possible that our memcpy got removed from history. Until a better solution is implemented, like moving the DMA syncs from the USB subsystem into the controller driver, allocate all buffers that are not explicitly allocated using USB_DMA_COHERENT. The IO buffers continue to be allocated as non-coherent. Regression found by jsg@ ok kettenis@
* Instead of passing the flags as part of a struct that's supposed to bepatrick2020-03-211-3/+3
| | | | | | | filled by the callee, change the usb_allocmem() API to take another argument for the flags. ok mpi@
* use the UE_GET_XFERTYPE macro where applicablejasper2020-02-221-2/+2
| | | | ok mpi@
* Mark recycled USB `xfer' as NOT_STARTED to not confuse HCD abort methods.mpi2019-10-211-1/+2
| | | | | | Prevent an infinite loop when aborting ulpt(4)'s pipe after an I/O error. Found by and ok stsp@
* tsleep(9) to tsleep_nsec(9) conversions.mpi2019-10-061-3/+3
| | | | ok visa@, kn@, cheloha@
* Use "%s", __func__ in DPRINTF() to reduce grep noise.mpi2018-11-181-17/+17
|
* free(9) sizes for endpoints array.mpi2018-11-101-4/+5
| | | | ok okan@, tedu@, visa@
* Fail early when transfers aren't completed in order.mpi2018-04-291-5/+3
| | | | ok pirofti@, visa@
* Add support for dumping USB transfers via bpf(4) using USBPcap headers.mpi2018-02-031-4/+9
| | | | ok deraadt@, dlg@
* Disable a splsoftassert() at least until ohci(4) has been fixed.mpi2017-09-211-1/+4
| | | | | | | | | | | This assert triggers because of the floor check on amd64/sparc64 when ohci(4) processes its root-hub status change transfers at IPL_BIO. Previous to the removal of IPL_SOFTNET, the SPLUSBCHECK macro didn't do anything, so it is safe to disable this check. Issue reported by espie@ and krw@
* Replace remaining SPLUSBCHECK by a splsoftassert(IPL_SOFTUSB).mpi2017-05-151-3/+3
| | | | USB is the last real user of IPL_SOFTNET.
* It is unsafe to dereference ``xfer'' after calling the callback as itmpi2017-05-101-5/+12
| | | | | | | | | | | might free it. Prevent a use-after-free in various aynchronous cases. Found while looking at another user-after-free pointed out by ehrhardt@. Committing now to find if other drivers rely on this use-after-free. tb@ confirmed ubcmtp(4) is now fixed.
* Revert r1.61 and partially 1.60. The resulting logic is currently ampi2017-05-101-10/+1
| | | | | | | | | | noop and prevent us from fixing real use-after-free. Since xfer->status is reset by *_device_intr_done(), checking for USBD_IOERROR cannot be true. Problem reported by tb@ because ubcmtp(4) triggers some I/O errors when multiple fingers are used.
* Remove a DIAGNOSTIC test for a NULL pipe value inside a transfer,jsg2017-05-051-7/+1
| | | | mpi says a transfer can't exist without a pipe. ok mpi@
* A pile of sizes to free(9). In test for a few days in snapshots.deraadt2017-04-081-3/+2
| | | | | Errors will result in nice clean panic messages so we know what's wrong. Reviewed by dhill visa natano jsg.
* ubcmtp(4) works because of a use-after-free. Many more drivers arempi2017-03-171-13/+6
| | | | | | | | | certainly doing the same. So revert r1.85 for the moment, we're too close from the release and these bugs have been there for years. Regression reported by tb@ on bugs@
* 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.
* Move per HC polling code to the stack.mpi2017-03-101-17/+36
| | | | | | | | | This code contains a use-after-free which be addressed in an upcoming diff. This fix xhci(4) polling mode. ok kettenis@
* Do not print uninitialized variable in DPRINTFN().mpi2017-03-061-2/+2
| | | | From Christian Ludwig.
* It is unsafe to dereference ``xfer'' after calling the callback as itmpi2017-03-061-9/+15
| | | | | | | might free it. Prevent a use-after-free in various aynchronous cases. Found while looking at another user-after-free pointed out by ehrhardt@.
* Let the stack perform DMA synchronization instead of doing it (partially)mpi2016-10-041-7/+21
| | | | | | | | | | | | | | | in HC drivers. Only ehci(4) was performing pre & post synchronization completly. Now pre-synchronization is done in usbd_transfer() and post-synchronization in usbd_transfer_complete(). This will allow us to remove the partial synchronization primitives from the pipe handlers. This is similar to what FreeBSD did in r158998, r164519 and r176203. From Marius Strobl. ok kettenis@
* Remove the restriction for the usbd_ref_* functions to work just in casemglocker2016-06-131-2/+2
| | | | | | | of dev->dying. With this we also can use them on device closing, not just detaching. ok mpi
* usbd_{endpoint,interface}_count() are no longer used and die.mpi2015-07-101-23/+1
|
* Set the length of isochronous transfers as the sum of the frames lengths.mpi2015-06-151-9/+10
| | | | | | | | | | | | This reduces differences between non-isoch and isoch transfers submissions, makes the generic DMA buffer overrun check work with isoch transfers and will allow some code simplifications in HC drivers. Since short-transfers were never checked for isoch transfers, we now need to pass the USBD_SHORT_XFER_OK flag to not change this behavior. This might be revisited later. ok ratchov@
* Remove some includes include-what-you-use claims don'tjsg2015-03-141-2/+1
| | | | | | | have any direct symbols used. Tested for indirect use by compiling amd64/i386/sparc64 kernels. ok tedu@ deraadt@
* KNF.uebayasi2015-02-121-2/+2
|
* Reduce the number of intermediate buffers by pre-allocating DMA buffersmpi2015-01-221-15/+17
| | | | | | | in the report functions instead of letting the stack do it magically for us. Reviewed and tested by David Higgs, thanks!
* There's no simple way so check for DMA buffer overrun with isochronousmpi2015-01-111-2/+2
| | | | | | transfers, so skip the check for such xfers for the moment. Issue reported by Ingo Feinerer and fix confirmed by Jan Stary.
* Always check for DMA buffer overrun, not just for some specific xfers.mpi2015-01-091-26/+8
|
* Add an asynchronous version of uhidev_get_report(), from David Higgsmpi2015-01-091-5/+7
| | | | | | | with some tweaks. Nothing use it for the moment, but upcoming upd(4) improvements need it.
* Make it clear that dma buffers are link to xfers, no functional change.mpi2014-11-011-8/+5
|
* Use understandable messages when the per-xfer poison value is incorrect.mpi2014-10-311-11/+8
| | | | Prodded by a comment from stsp@.
* Fix format signednessguenther2014-09-261-2/+2
| | | | ok blambert@ doug@
* Set and check for XFER_BUSY in the common methods instead of doing itmpi2014-08-101-2/+11
| | | | in every HC driver.
* add a size argument to free. will be used soon, but for now default to 0.tedu2014-07-121-3/+3
| | | | after discussions with beck deraadt kettenis.
* We already have three identical copies of the *hci_str() function,mpi2014-03-071-1/+19
| | | | | so merge them into usbd_str() to not introduce other copies with the upcoming HC drivers.
* Turn usbd_xfer_isread() into a public function so that we can usempi2014-03-061-11/+1
| | | | | it in various drivers, mainly HC, instead of always rerolling our own.
* Makes the "cleartoggle" function provided by HC drivers optionalmpi2014-03-061-4/+5
| | | | because upcoming xhci(4) driver won't use it.
* Clean-up usbd_abort_pipe() usage.pirofti2013-11-151-5/+3
| | | | | | | This function never fails. So change it's return type to void and adjust the copy-pasted callers that were checking the return. "If it compiles, ok" mpi@
* Polling is done per controller not per interface.pirofti2013-11-131-10/+3
| | | | | | | | | The controllers are linked through device->bus so the iface is redundant. So fixing usbd_dopoll() to take the device as argument and making usbd_interface2device_handle() private (for now) inside usbdi_util. Tested and okay mpi@
* Make usbd_free_xfer return void, since no callers use the return value.jeremy2013-11-061-3/+3
| | | | OK mpi@
* Begin conversion of USB stack to return int instead of usbd_status,jeremy2013-11-021-7/+7
| | | | | | | | | | starting with usbd_endpoint_count and usbd_interface_count. usbd_status should only be used to indicate the status of a USB transfer, it should not be used for generic error codes. Idea from and much hand-holding by mpi@ OK mpi@
* Pipe don't have states. Kill an useless & commented out chunk of code.mpi2013-10-311-8/+2
| | | | No functional change.
* usbd_pipe2device_handle() is not used, should not be used and die.mpi2013-10-311-7/+1
|
* If a transfer terminates with an I/O error status, do not modify thempi2013-10-141-10/+10
| | | | | | | | | | pipe to stop enquening the next transfer before the done() function has been called. This should fix the hangs seen when unplugging a USB keyboard attached to uhci(4). Problem reported by dcoppa@ and Peter Kane
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.