Parse out and display xhci controller extended capabilities. This gives
us a mechanism to pick these up when the controller attaches. The print
helps users and developer know the availability of features in the wild.
This change will let developers know from dmesg that a controller
supports USB debugging.
Reviewed by: aokblast
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D51255
No functional change.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: aokblast, imp
Differential Revision: https://reviews.freebsd.org/D52147
With factoring out of supporting code from ugen(4) driver.
The ioctl is used in FIDO/U2F security key drivers to get
USB product and manufacturer strings.
PR: 264843
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D51609
instead of renaming uhid(4) to hidraw to make easier import of coming
u2f(4) driver which has similar option.
Differential Revision: https://reviews.freebsd.org/D51608
It disables interrupt emulation on poll-driven buses like USB and
forces aquiring of only one USB frame per read(2) operation.
This avoids an FIDO/U2F issue where IN endpoint data received from
the device right before the file handle is closed, gets lost.
PR: 263995
Reviewed by: aokblast
Differential revision: https://reviews.freebsd.org/D51605
The CDC-NCM (USB Communications Device Class – Network Control Model)
protocol allows multiple Ethernet frames to be encapsulated into a single
USB transfer.
On iOS, CDC-NCM is currently implemented for RX only and uses a fixed number
of entries (16). To maintain compatibility with older iOS versions, we attempt
to enable NCM on the USB device first; if this fails, we fall back to the
original behavior.
Approved by: lwhsu (mentor), markj (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Since gpiobus_attach_bus can attach the gpiobus child along with its
children in the same bus pass, the parent controller's reference to
gpiobus might not be set by the time the children need it. Instead,
drivers should use gpiobus_add_bus and explicitly call
bus_attach_children.
Reviewed by: mmel, imp (older version)
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D51578
The CH343 devices support any baud rate up to 6 Mbps.
PR: 272803
Reviewed by: imp
Tested by: joerg, Tomasz "CeDeROM" CEDRO <tomek_AT_cedro_DOT_info>
Differential Revision: https://reviews.freebsd.org/D46290
<sys/proc.h> doesn't need <sys/runq.h>. Remove this include and add it
back for kernel files that relied on the pollution.
Reviewed by: kib
MFC after: 1 month
Event: Kitchener-Waterloo Hackathon 202506
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45387
usb_msc_auto_quirk() potentially crashes usb devices with a hidden
storage (see bug 287333). These devices may still operate normally if
usb_msc_auto_quirk() would not be called all and the hidden storage is
ignored. This patch makes sure, that usb_msc_auto_quirk() is not called
when the UQ_MSC_IGNORE quirk is set for a device. It shouldn't be called
anyway if the hidden storage supposed to be ignored. This gives users a
chance to get their devices working by using
'usbconfig add_dev_quirk_vplh <vid> <pid> <lo_rev> <hi_rev> UQ_MSC_IGNORE'.
Reviewed by: imp
MFC After: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/1716
Closes: https://github.com/freebsd/freebsd-src/pull/1716
Switch to using sys/stdarg.h for va_list type and va_* builtins.
Make an attempt to insert the include in a sensible place. Where
style(9) was followed this is easy, where it was ignored, aim for the
first block of sys/*.h headers and don't get too fussy or try to fix
other style bugs.
Reviewed by: imp
Exp-run by: antoine (PR 286274)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1595
When processing messages produced by the USB device, umb_decap() trusts
ptroff and later dlen and doff with pointer arithmetic, without
sufficient sanity checks. The resulting pointer address may be outside
of the valid boundary, causing the wrong memory to be copied or a page
fault.
This fix from Gerhard Roth was obtained after coordination upstream with
OpenBSD. It converts the variables to 64-bit integers, which should
mitigate the risk of overflows.
PR: 284920
Reported by: Robert Morris <rtm@lcs.mit.edu>
Approved by: philip (mentor)
Sponsored by: The FreeBSD Foundation
umb_getinfobuf() is called with offs and size taken from messages sent
by the USB device. The sanity check is not sufficient, due to a possible
integer wrap. This can allow a broken or malicious USB device, or
possibly the network operator, to cause a buffer overflow.
This fix from Gerhard Roth was obtained after coordination upstream with
OpenBSD. It converts the variables to 64-bit integers, which should
mitigate the risk of overflows.
PR: 284906
Reported by: Robert Morris <rtm@lcs.mit.edu>
Approved by: philip (mentor)
Sponsored by: The FreeBSD Foundation
len comes from ipv4elem.prefixlen in a MBIM_CID_IP_CONFIGURATION message
from the USB device, and should not be trusted, as it could be any
uint32_t value. Without this extra check, a potential buffer overflow
could subsequently occur in umb_in_len2mask().
Fix from Gerhard Roth, after coordination upstream with OpenBSD.
PR: 284904
Reported by: Robert Morris <rtm@lcs.mit.edu>
Approved by: philip (mentor)
Sponsored by: The FreeBSD Foundation
Now that we have a safe way to detect the vast majority of problems
with SYNCHRONIEZ CACHE, and since I have devices from many of these
vendors that work just fine (one of which will hang if you send it a
SYNCHROMIZE CACHE), I think these should all be reverted. The details
of when they were added are sketchy, the age of the devices in
question means these vendors have many generations of products after
and the general over-quirking of SYNCHRONIZE CACHE all point to just
removing them and adding back specific quirks should any need arise
after trying other means to debug.
The APPLE quirk was added because the autoquirk code would hang an ipod
with RockBox with a reset loop in the firmware. Since it was quirked, it
disabled the autoprobe and started working. Now that we've disabled the
autoprobe, we can remove it for sure.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D49478
There are significant problems with the current autoquirk code. This
results in quite a bit of bogus over-quirking.
Most commands don't do the proper "sense" dance to get the scsi sense
codes to see if the failures are interesting or not. A number of
'sleeps' are used to try to get around this, but they are racy. Rather
than fix these, use better hueristics just introduced to catch
SYNCHRONIZE CACHE problems, etc.
The test for getting max lun number was bogus. It would set this quirk
both on errors and when 0 was returned. It appears to be an attempt to
filter our REPORT LUNS error messages that are actually benign (we
ignore the errors properly). These errors are also only filtered
sometimes, so the test is unreliable. In addition, it's doing exactly
the same test that the umass driver is doing and recovering in the
same way. There's no value add here.
The TEST UNIT READY almost always fails because the drive is becoming
ready. The SENSE is usually UNIT ATTENTION 28/0 "Drive went from
not ready to ready" which is a normal condition.
The crazy looping to get INQUIRY data is odd. It shouldn't be needed
and rarely actually fails (I've not seen any, despite using this code
on some really sketchy drives). It should set a NO_INQUIRY quirk if it
fails, but instead sets a whole bunch of other, mostly unrelated
quirks if it fails.
The INQUIRY code also doesn't recognie RBC devices as well as DIRECT
devices. This means it fails on some older generations of cameras that
could actually benefit from this code.
The SYNCHRONIZE CACHE test is flawed. It will do the same failed test
over and over again in the event the command succeeds. There are
better ways to detect probelms.
The START STOP test is useless. It doesn't really help on any of the
devices I've tested on. It appears to be another result of the failure
to properly obtain the SENSE code and do appropriate things with it.
The PREVENT ALLOW test is useless. It is overwhelmingly used to
prevent an error message later. However, after it was added the error
message was changed to be informative and not scary. We properly
probe this at runtime on all the devices I tested on.
At the end of the tests, we try to clear the SENSE errors, but
do so imperfectly. Only one is cleared and we use INQUIRY rather
than the better TEST UNIT READY.
Attempted re-write to fix this caused additional problems as the reset
code was not at all robust (the same sequnce in umass / CAM worked when
we disabled this code).
In addition, the over-quirking and hair-triggered declaration that
SYNCHRONIE CACHE is bad would mean that some working drives that have
cache wouldn't flush the cache when WCE=1, leading to
corruption. Thankfully, nearly all (but not all) the USB sticks I have
default to WCE=0. One, however, did default to WCE=1 and some allow
setting it (despite the fact this is a bad idea on removeable
devices). However, for real disks attached via USB could be tripped up
over this.
When we do reset, some small subset of drives are now failing to
probe. There are reports on the FreeBSD forums that at least one ebook
reader no longer works. A different ebook reads is affected as well
(one of my long-time friends has htis). in my collection, one USB memory
stick, one SD card reader and one USB to generic PATA adapter no longer
work. All of them are pretty obscure (you could literally say they were
found in my junk drawer), but are troubling. These problems appear to
disappear if we stop doing the auto-quirk code.
For all these reasons, I'm turning this off and will likely remove
it entirely in the future once the alternative SYNC CACHE code
has provent itself.
Differential Revision: https://reviews.freebsd.org/D49477
Sponsored by: Netflix
When completing a request for UFI, don't fail the request on
non-zero asc/ascq values if we've done a request sense.
This idea is from umass.c 1.100 by mycroft. He used it to help
elminate the INQUIRY_SHORT quirk that we still have. However, it will
make little difference because we treat both return values the same
for CBI. And it appears we have (maybe bogusly) some devices that
specify this quirk that aren't CBI.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D49475
Call umass_std_transform instead of following the sc_transform member to
get the standard transforms now that has moved to
umass_std_transform. Pass NULL as the CCB so that we don't stomp on the
status that was just set (and allow that in std_transform).
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D49474
Elsewhere, if we fail a command, we use SCSI code ILLEGAL REQUEST/24/00,
but here we were using the CAM code for illegal request.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D49473
Only doing a short inquiry and converting TUR to START STOP UNIT are the
same everywhere, so move those quirks to umass_std_transform.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D49472
Move the length checks, and byte copying into umass_std_transform. The
copies are typically small and this simplifies the code a lot. Move
zeroing the buffer now to only when we change TEST UNIT READY to START
STOP.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D49471
Now that nothing returns (2) to fake the success of the command,
eliminate that magic number by eliminating the case.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D49469
Just go ahead and fail SYNCHRONIZE_CACHE commands for UFI. This standard
doesn't have a cache to flush, and the upper layers (aka da) will notice sync
cache failed and won't send it again.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D49468
Generally, lying to the periph drivers about commands working is a bad
idea. They cannot get a global insight into the actual capacities of
the device when commands just work. There's good reason to intercept
bad commands at times, and to prevent the device from being exposed to
commands that, for example, hand the device. However, upper layer
periph drivers is the better place to cope with devices that don't
support the commands since it can make other inferences about the
device when it has wider knowledge.
But this represents a change in philosphy, so document that as
well. This shift happened for some commands a while ago. Many of the
quirks existed only to avoid whining errors on boot that were benign
and were a big burden. So da and cd slowly stopped the whining. Except
in cases where the command hangs the drive, we should limit new quirks
and avoid overly broad quirks (things work, but are less performant or
reliable, again mostly to avoid harmless errors that are no longer
printed).
Other sims will likely need some help with this.
Differential Revision: https://reviews.freebsd.org/D49467
Sponsored by: Netflix
When we know the umass device doesn't support synchronize cache
(either probed or hard quirk), fail the command w/o sending it to the
device. The da driver is the only driver that sends this command, and
since this filter was written has grown the ability to catch the
failure and never send the command again.
In an ideal world, we'd let the da driver work this out. However,
there's a lot of devices that hang when this command is sent in a way
that's impossible to detect other than a black list. There's also a
number that require a hard USB endpoint reset to recover, which the
autoquirk code takes care of. So umass has to act as a filter.
By failing this command, we're able to avoid upper level BIO_FLUSH
commands by tagging the underlying disk as not supporting that.
Differential Revision: https://reviews.freebsd.org/D49466
Sponsored by: Netflix
Move illegal opcode completion of ccb to its own function. da can cope
with a number of different failures now (it didn't used to), so we
should return the unnsupported commands as illegal rather than faking
completion. This will allow da to, in the future, do more intelligent
things in response to these quirks. Other SIMs will need to do this
too.
Differential Revision: https://reviews.freebsd.org/D49465
Sponsored by: Netflix
to Linux hidraw compatibility API.
Respective Linux commit f43d3870cafa made by Dean Camera message is:
Currently the hidraw module can only read and write feature HID reports on
demand, via dedicated ioctls. Input reports are read from the device through
the read() interface, while output reports are written through the write
interface().
This is insufficient; it is desirable in many situations to be able to read and
write input and output reports through the control interface to cover
additional scenarios:
- Reading an input report by its report ID, to get initial state
- Writing an input report, to set initial input state in the device
- Reading an output report by its report ID, to obtain current state
- Writing an output report by its report ID, out of band
This patch adds these missing ioctl requests to read and write the remaining
HID report types. Note that not all HID backends will neccesarily support this
(e.g. while the USB link layer supports setting Input reports, others may not).
FreeBSD native uhid(4) compatible API already has similar ioctls.
MFC after: 3 days
uether_rxmbuf() assumes the uether_newbuf() model where the caller has
just set m_len to the entire size of the mbuf, and passed the final
size into uether_rxmbuf() for finalization.
In if_ure we're creating our own mbuf chains, and the accounting is all
already accurate. uether_rxmbuf's logic won't work at all for a chain,
so let's add an assertion to that effect (but I think the other callers
were all OK).
This fixes a panic on my Windows DevKit when undergoing any kind of
network stress that surfaces after the bogus mbuf is injected into the
network stack (usually observed in `m_dup`).
markj and I had spent some time investigating it and decided there's
some kind of buffer underrun happening; the rx packet descriptor reports
a length longer than what's actually available. We discard the rest of
the transfer, but then we end up fetching it in a subsequent transfer
and end up casting packet data to a `struct ure_rxpkt` incorrectly. It
would be better to fix the underlying root cause, but this is a
reasonable mitigation in the interim.
Reviewed by: markj
Fixes: 7d5522e16a ("A major update to the ure driver.")
Differential Revision: https://reviews.freebsd.org/D43465
Explicitly set the software ciphers; add support for GCMP-128.
Locally tested:
* AR5523 11abg NIC, 2/5GHz STA operation, GCMP forced
in wpa_supplicant.conf
Differential Revision: https://reviews.freebsd.org/D49370
Reviewed by: bz
Only set the GETMAXLUN quirk when it causes an error, but don't set it
when it returns 0. Since we reset the device when we set any quirk, only
set this quirk when it generates an error so umass will avoid it. When
the command works, there's no reason for umass to avoid it at all.
MFC After: 1 week
Sponsored by: Netflix
I have several of these. They all work without these quirks (either the
auto quirk mechanism does the right thing, or a likely
soon-to-be-removed vendor catch-all does the right thing, or no probing
at all does the right hting).
Both PREVENT ALLOW and SYNCHRONIZE CACHE are (a) unimplemented but (b)
return the proper asc/ascq code so da just does the right thing, quirk
or no. This was a left-over from the days where you'd get scary error
messages, but we'd work just fine. Now that the scary error messages are
gone (and only a calm one under bootverbose), this can be deleted.
Sponsored by: Netflix
We only try to do a GETMAXLUN query of BBB devices. If we're forcing the
device to be CBI, then it's not BBB. Delete the quirks from there. Also,
UFI devices are all CBI as well, so remove the quirk from there as well.
Confirmed this isn't needed with three different floppy disk drives I
have.
Sponsored by: Netflix
The USB bus performs additional teardown steps in between detaching
child devices and deleting child devices.
Reported by: phk, thj
Tested by: phk
Fixes: e9d3857040 ("Use bus_detach_children instead of bus_generic_detach")
A REQUEST SENSE CDB was just copied into the cmd buffer, so testing for
INQUIRY will always fail. Remove the dead code.
This code was added, apparently by mistake in 2003. 8541fbec79
merged changes from NetBSD's umass_scsipi.c 1.8 to address some BBB
bulk-in clear problems. NetBSD had fixed a problem in the
FORCE_SHORT_INQUIRY quirk code they had ported from FreeBSD that FreeBSD
also needed. That merge also included the dead code, which was not in
NetBSD.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D49311
Previously, a two-finger horizontal scroll would result in a forwards/backwards
keyboard event being performed. This patch changes that functionality to be
specified via two new sysctls: horizontal_swipe_finger_count and
scroll_finger_count. The former specifies how many fingers are used to perform
the aforementioned forwards/backwards keyboard event, while the latter specifies
how many fingers are used to perform horizontal scrolling. 0 disables each of
them.
The threshold for scrolling has been coupled into a single tunable:
scr_threshold. This tunable is used for both scrolling and the horizontal swipe.
t_factor and t_invert tunables have been created in the same manner as their
z-axis counterparts.
Horizontal scrolling is disabled by default, as it requires the sysctl
hw.usb.wsp.t_factor to 3 (wsp mode). Horizontal swiping is enabled by default
with a three-finger tap.
Also rewrite much of, and improve, documentation.
Signed-off-by: Joshua Rogers <Joshua@Joshua.Hu>
