summaryrefslogtreecommitdiffstats
path: root/sys/dev/usb (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Set the correct length before copying to userland.mpi2020-09-291-1/+2
| | | | | | | Prevent copying a partial and corrupted descriptor or leaking kernel memory. ok kn@, deraadt@
* Add TP-LINK UE300 device.kevlo2020-09-291-2/+3
| | | | | | Tested by Joel Carnat. ok deraadt@
* Since dlg@'s 2009 scsi midlayer refactoring the 'struct scsi_generic *cmd'krw2020-09-221-5/+5
| | | | | | | | | | | | member of 'struct scsi_xfer' has always been pointed at the 'struct scsi_generic cmdstore' member of the same instance. So nuke 'cmdstore' and remove the '*' from cmd. Take the address of cmd as required by the various casts. No intentional functional change. luna88k test by aoyama@, sparc64 test by jmatthew@ Identification of 2009's last *cmd use and ok jmatthew@
* umstc_intr is not in process context when adjusting wscons brightness. When brightnessderaadt2020-09-141-4/+31
| | | | | | is pushed to 0, the backlight is disabled by some backend code which happens to sleep. Solve this by bouncing to process context via a task. ok kettenis
* Correctly set y_sensors for Geyser2 touchpads.tobhe2020-09-111-7/+7
| | | | | Feedback and ok patrick@ ok kn@
* Rename SID_INQUIRY_HDR (a.k.a. 5) to more explicit SID_SCSI2_HDRLEN and use itkrw2020-09-051-5/+5
| | | | | | | | to replace various uses of '5' when calculating the amount of data in the INQUIRY response. Matches up more naturally with SID_SCSI2_ALEN. Also use to fix SCSIDEBUG display of INQUIRY responses to show correct count of bytes received/available.
* Don't rely on wTotalLength for usbd_get_cdesc() malloc/free but on themglocker2020-09-022-16/+21
| | | | | | | | actual length which has been allocated. We saw cases where the wTotalLength value is changing on a second read, e.g. when a USB device was waked up from sleep mode. ok mpi@
* Backout clear endpoint stall on open(2). It seems to break an illuminatedpatrick2020-08-311-3/+1
| | | | | | | Logitech keyboard for unknown reasons. Reported by denis@ ok djm@
* Fix a potential panic during free(9) which can be caused by an USBmglocker2020-08-271-4/+4
| | | | | | | | | | | device which returns a spurious value for wTotalLength on a configuration descriptor request. Therefore don't relay on wTotalLength for free(9) but on the length variable which was used for the malloc(9) before. The issue was reported by Mikolaj Kucharski <mikolaj (at) kucharski (dot) name> on bugs@. Discussed and ok deraadt@
* usbd_get_cdesc() returns usb_config_descriptor_t *. Therefore returnmglocker2020-08-271-3/+3
| | | | | | 'NULL' instead of '0'. ok deraadt@
* Clear endpoint stall on open(2) of /dev/uhidX to synchronize toggle bitpatrick2020-08-271-2/+4
| | | | | | | | | | | | | as needed on xhci(4) machines. On non-xhci(4) we save and restore the toggle bit on close/open of a pipe. With xhci(4) this does not seem to be possible, at least I haven't yet found it. This means that on those machines with xhci(4), after a pipe close/open, the device will use the previous state, while xhci(4)'s state is reset to default. By issuing a clear endpoint stall we reset the device's toggle bit. Now every time a /dev/uhid is (re-)opened the state should be synchronized. Discussed with damien@, mpi@ and Pedro Marteletto ok markus@
* Remove needless uses of SDEV_ONLYBIG. It was always set when SDEV_UMASS was set,krw2020-08-262-7/+7
| | | | | | | | and was always checked in concert with SDEV_ATAPI. Just rely on SDEV_ATAPI and SDEV_UMASS in all but the one place sd(4) where SDEV_ONLYBIG is set independently of SDEV_ATAPI/_UMASS. ok jmatthew@
* usbd_set_idle() use requires prototype from usbdi_util.hderaadt2020-08-251-1/+2
|
* uhidev(4) does apply the SET_IDLE request to all its child driversmglocker2020-08-237-9/+22
| | | | | | | | | | | | | | today. This doesn't seem to be right, since SET_IDLE limits the reporting frequency for interrupt IN endpoints, normally only required on keyboard and mouse-like input devices. We noticed recently that other device types, like e.g. the Cyrus soundKey uaudio(4), will stall after the SET_IDLE request has been issued. Therefore we move the SET_IDLE request only to the uhidev(4) child drivers which seem to require this request. Those we have identified to be; ukbd(4), ums(4), umstc(4), umt(4), utpms(4), and uwacom(4). Suggested and ok mpi@
* ubcmtp(4) doesn't attach to uhidev(4) but to uhub(4).mglocker2020-08-211-3/+1
| | | | ok jcs@
* Fix typo in commentgnezdo2020-08-171-2/+2
| | | | From Paul de Weerd
* Remove duplicate comment.mglocker2020-08-061-5/+1
| | | | ok mpi@
* Pack multiple packets into one xfer as possible. Given this is a 5x-7xkevlo2020-08-042-164/+221
| | | | | | | | | | TX improvement. It's all Jonathon's code so assert his copyright. Submitted by Jonathon Fletcher. Tested by jcs@, Mikolaj Kucharski, Jonathon Fletcher and myself. ok jmatthew@
* syncderaadt2020-08-032-4/+21
|
* Gear Head keyboard IDs, from Tom Murphyderaadt2020-08-031-1/+6
|
* 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@
* Nuke all occurrences of usbd_abort_pipe() if it gets called rightmglocker2020-07-3150-200/+67
| | | | | | | | | | before usbd_close_pipe(), since usbd_close_pipe() already takes care about aborting non-empty pipes. As investigated by gerhard@ usbdi.c rev. 1.57 did add usbd_abort_pipe() to usbd_close_pipe(), but the drivers didn't get cleaned up afterwards. ok gerhard@
* Don't turn on SDEV_DB* flags via UDMASS_UPPER. If you want SCSI debug output,krw2020-07-291-3/+1
| | | | | ask for it the normal way. Less surprising and more effective, since you have to specify SCSIDEBUG/_BUS/_TARGET/_LUN separately anyway.
* 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@
* Nuke unused struct scsi_link members of adapter softc's where thekrw2020-07-221-2/+1
| | | | driver successfully compiles on one or more of amd64, i386, hppa.
* regenjsg2020-07-222-4/+9
|
* add Intel AX200 Bluetoothjsg2020-07-221-1/+2
|
* deprecate interface input handler lists, just use one input function.dlg2020-07-221-12/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | the interface input handler lists were originally set up to help us during the intial mpsafe network stack work. at the time not all the virtual ethernet interfaces (vlan, svlan, bridge, trunk, etc) were mpsafe, so we wanted a way to avoid them by default, and only take the kernel lock hit when they were specifically enabled on the interface. since then, they have been fixed up to be mpsafe. i could leave the list in place, but it has some semantic problems. because virtual interfaces filter packets based on the order they were attached to the parent interface, you can get packets taken away in surprising ways, especially when you reboot and netstart does something different to what you did by hand. by hardcoding the order that things like vlan and bridge get to look at packets, we can document the behaviour and get consistency. it also means we can get rid of a use of SRPs which were difficult to replace with SMRs. the interface input handler list is an SRPL, which we would like to deprecate. it turns out that you can sleep during stack processing, which you're not supposed to do with SRPs or SMRs, but SRPs are a lot more forgiving and it worked. lastly, it turns out that this code is faster than the input list handling, so lots of winning all around. special thanks to hrvoje popovski and aaron bieber for testing. this has been in snaps as part of a larger diff for over a week.
* Move remaining scsi bus initialization info from "prototype scsi link"krw2020-07-201-7/+6
| | | | | | | fields to struct scsibus_attach_args. Nuke the struct scsi_link * (saa_sc_link) in scaibus_attach_args. Explicitly initialize each field in scsibus_attach_args variables.
* Move the adapter related items (luns, adapter, adapter_target,krw2020-07-191-6/+6
| | | | | | | adapter_buswidth, adapter_softc) from struct scsi_link to struct scsibus_attach_args. Additional compile tests by jmatthew@ (sparc64) and aoyam@ (luna88k).
* Access adapter softc via link->bus->sb_adapter_softc.krw2020-07-161-3/+3
| | | | | | | | In sparc64 autoconf access 'luns' via sb_luns and 'adapter_buswidth' via sb_adapter_buswidth. Removes last post-config uses of the copies of bus related information in scsi_link.
* When athn(4) is deciding how to decrypt an incoming frame, look into thestsp2020-07-131-2/+2
| | | | | | | | | ieee80211_node data structure to find the WPA group cipher which was negotiated with the peer, rather than checking the wireless interface's configuration data. Found while investigating a problem where WPA2+TKIP wasn't working with athn. Problem reported by Tim Chase.
* Build 'flags' in intermediate variable and shuffle sc_linkkrw2020-07-111-16/+17
| | | | initialization closer to config_found() invocation.
* Expunge some Captain Obvious comments, tweak whitespace a bit, move a debugkrw2020-07-111-2/+1
| | | | statement. All to make upcoming diff(s) smaller and easier to read.
* Change users of IFQ_SET_MAXLEN() and IFQ_IS_EMPTY() to use the "new" API.patrick2020-07-1018-50/+50
| | | | ok dlg@ tobhe@
* Change users of IFQ_DEQUEUE(), IFQ_ENQUEUE() and IFQ_LEN() to use thepatrick2020-07-1011-22/+22
| | | | | | "new" API. ok dlg@ tobhe@
* match on D-Link DWA-121 rev B1jsg2020-07-061-1/+2
| | | | from Miguel Landaeta
* regenjsg2020-07-062-4/+9
|
* add D-Link DWA-121 rev B1jsg2020-07-061-1/+2
| | | | from Miguel Landaeta
* uvideo_querycap(): Set the 'device_caps' field of struct v4l2_capability like done in utvfu(4)landry2020-07-051-2/+3
| | | | | | | | | | | | | | | | | | Fixes webcam detection in firefox 78, where code was added to check for V4L2_CAP_VIDEO_CAPTURE capability on 'device_caps', whereas we only set it in the 'capabilities' field. According to https://www.kernel.org/doc/html/v4.14/media/uapi/v4l/vidioc-querycap.html#description those distinct fields are here for drivers that provide several devices, but firefox decided to check for 'device_caps' field instead of 'capability' (cf https://hg.mozilla.org/integration/autoland/rev/33facf191f23) - so fill the field for compatibility reasons, while https://bugzilla.mozilla.org/show_bug.cgi?id=1650572 discusses with upstream what's the right way. ok mglocker@
* Fix mbuf leak in urtwn(4) with frames that are CCMP-crypted in hardware.stsp2020-07-051-1/+2
| | | | | Problem reported and fix tested by Bastian Wessling on bugs@ ok jmatthew@
* 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@
* Nuke trailing whitespace.krw2020-06-271-2/+2
|
* No need to bzero()/memset() 'struct scsibus_attach_args' variableskrw2020-06-271-2/+1
| | | | immediately before initializing the only field in the struct.
* kernel: use gettime(9)/getuptime(9) in lieu of time_second(9)/time_uptime(9)cheloha2020-06-241-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | time_second(9) and time_uptime(9) are widely used in the kernel to quickly get the system UTC or system uptime as a time_t. However, time_t is 64-bit everywhere, so it is not generally safe to use them on 32-bit platforms: you have a split-read problem if your hardware cannot perform atomic 64-bit reads. This patch replaces time_second(9) with gettime(9), a safer successor interface, throughout the kernel. Similarly, time_uptime(9) is replaced with getuptime(9). There is a performance cost on 32-bit platforms in exchange for eliminating the split-read problem: instead of two register reads you now have a lockless read loop to pull the values from the timehands. This is really not *too* bad in the grand scheme of things, but compared to what we were doing before it is several times slower. There is no performance cost on 64-bit (__LP64__) platforms. With input from visa@, dlg@, and tedu@. Several bugs squashed by visa@. ok kettenis@
* 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@
* Apply sc->sc_xfer_flags to control transfers as well. These are usedpatrick2020-06-241-5/+5
| | | | | | | | | | so that in polled-mode the USB transfers are marked synchronous. In case that sending commands to the USB mass storage fails, the control transfers are used to reset the device. Without the synchronous flag, the STOP command sent by sd(4) on powerdown would wait for completion indefinitely, possibly hanging the machine. ok gerhard@
* Blacklist Ericsson F5521gw broadband modem.tobhe2020-06-221-1/+9
| | | | ok sthen@
* regentobhe2020-06-222-4/+16
|
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.