| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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!
|
|
|
|
| |
I've missed two more cases in the previous commit.
|
| |
|
|
|
|
|
|
| |
available device interfaces is called 'bNumInterfaces'.
ok phessler@, thfr@ (who provided the man page diff)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
on xhci(4) controllers by clearing the interface endpoints before opening
the pipes.
Tested by Mikolaj Kucharski for ugen(4) and gnezdo@ for uhidev(4), plus
myself for both.
ok mpi@
|
|
|
|
|
|
|
| |
an UR_CLEAR_FEATURE request on a specific endpoint address without the
need to have a pipe open to that endpoint.
From NetBSD, ok mpi@
|
|
|
|
|
|
|
|
| |
This includes ujoy_hid_is_collection() to work around limitations of
hid_is_collection() until this can be combined without fallout.
input, testing with 8bitdo controller, and ok brynet@
PS4 controller testing, fix for hid_is_collection, and ok mglocker@
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
usbd_clear_endpoint_stall(), which in turn will call
usbd_clear_endpoint_toggle(). It can be a common situation that when
this happens, there is still a transfer in the stalled queue being
in progress. The ehci(4) clear toggle function is currently doing a
panic() in the diagnostic code in this situation, which is a bit of
an overkill. The device still can be recovered by detaching/attaching
it. Therefore change the panic() in to a printf().
ok mpi@
|
|
|
|
|
|
|
| |
quirks.
Original diff from Sven M. Hallberg < pesco () khjk ! org >
Diff updated and tested by Timo Myyra
ok phessler@
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename klist_{insert,remove}() to klist_{insert,remove}_locked().
These functions assume that the caller has locked the klist. The current
state of locking remains intact because the kernel lock is still used
with all klists.
Add new functions klist_insert() and klist_remove() that lock the klist
internally. This allows some code simplification.
OK mpi@
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
| |
OK dlg@, bluhm@
No Opinion mpi@
Not against it claudio@
|
|
|
|
|
|
|
| |
athn(4) tested by stsp@, who points out that otus(4) and rsu(4) don't yet invoke
the code path to do their own key setting.
ok stsp@
|
|
|
|
|
|
| |
to DPRINTF's.
From Mikolaj Kucharski <mikolaj AT kucharski DOT name>
|
|
|
|
|
|
| |
all the keys are negotiated and installed.
ok stsp@
|
|
|
|
|
|
|
|
|
|
| |
devices whose INQUIRY command succeeds but with a residue equal to the
requested bytes. Subsequent i/o's (including the INQUIRY) which succeed
with a residue equal to the requested bytes will have residue set to 0.
Fixes (very?) old devices such as the memory stick Andrew Daugherity
pulled out of his drawer and with which he hoped to install 6.8.
Subsequent testing of diffs much appreciated!
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
difference is that is uses a different bRequest value for READ/WRITE.
Apart from that the flow control bits are in a different register
and resetting the data pipes uses different bits as well. We can
check if its an HXN by reading an HX-only register and checking for
a fail.
ok kettenis@
|
|
|
|
|
|
|
|
| |
async task(s).
Makes dhclient(8) much happier.
Suggestions and ok stsp@, jmatthew@
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Problem first reported against dhclient(8) by Artem Mazurov on bugs@
Bug was traced down into urtwn(4) by krw@ with a TP-Link TP-WA850RE AP.
Regardless, please configure your access points to use WPA2/AES only!
WPA1/TKIP is insecure and should die.
ok krw@
|
| |
|
|
|
|
| |
ok kn@
|
|
|
|
| |
ok tohe@, deraadt@
|
| |
|
|
|
|
| |
ok tobhe@, deraadt@
|
| |
|
| |
|
|
|
|
|
|
|
| |
movement smaller than threshold. Fixes an issue where the pointer
sometimes jumped a few pixels.
ok bluhm@
|
|
|
|
|
|
| |
already in revision 1.57 IMO.
From Mikolaj Kucharski <mikolaj AT kucharski DOT name>
|
| |
|
|
|
|
| |
From Raf Czlonka <rczlonka at gmail dot com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Stefan Hagen reports this is an audio device found on the
Lenovo ThinkPad Thunderbolt 3 Workstation Dock Gen 2.
Originally added as the id appeared in rtux64w10.INF from
thinkpad_usb-c_dock_gen2_drivers_v1.0.3.03241.exe as
%Lenovo-FFF.DeviceDesc% = RTL8153Bx64_S5WOL.ndi,USB\VID_17EF&PID_3083&REV_3101
but this appears to be wrong.
|
|
|
|
| |
Pointed by and ok jsg@
|
|
|
|
|
|
|
|
|
|
| |
Its value is conflicting with an effort to standardize TX flags fields of
the radiotap header from Mathy Vanhoef.
This flag used to indicate the presence of a specific hardware queue used
by WME but is unchecked.
ok sthen@, kn@
|
|
|
|
|
| |
found in lenovo version of realtek windows driver and linux
ok kevlo@
|
| |
|
|
|
|
|
| |
found in lenovo version of realtek windows driver and linux
ok kevlo@
|