| Age | Commit message (Collapse) | Author |
|---|
|
The mtw(4) driver works correctly on initial boot, but fails to initialize
the MT7601U WiFi adapter after a warm reboot.
Users must either physically unplug and replug the USB adapter, or perform a
full power cycle to restore functionality, if usb power is always powered
(only a replug works)
The root cause is that warm reboot does not power-cycle USB devices,
leaving the MT7601U in a stale state from the previous session.
The MCU retains its ready flag and the device ignores initialization
commands, resulting in timeout waiting for MCU to initialize errors.
At the OS Level, pinging 1.1.1.1 will work, but the speed will be very
slow. In addition in debug mode, we see thousand of error logs.
This patch addresses the issue by:
* Performing USB re-enumeration on attach to reset the device state
* Detecting when the MCU is already marked ready (stale from previous
session) and forcing a reset of the MCU before loading firmware
* Increasing the firmware load timeout from 3s to 10s to accommodate
slower initialization after reset
* Increasing MCU ready poll attempts from 100 to 300 with longer delays
to handle devices that take longer to become ready after reset
Note: The increase was random, lower value might work.
Test Plan:
Tested on MacBook Pro (late-2015) and a MacMini with MediaTek MT7601U
USB adapter across multiple warm reboot cycles.
With the mac-mini and a another desktop, the issue happens only if
connected via an always powered usb hub port in the monitor.
The laptop don't power cycle it power.
Differential Revision: https://reviews.freebsd.org/D54659
Reviewed by: adrian
|
|
Replace bzero with the equivalent memset(x,0,x) since the latter is
available in the kshim environment and we have a soft goal of migrating
to standard interfaces when there's a reason...
Sponsored by: Netflix
|
|
|
|
|
|
Differential Revision: https://reviews.freebsd.org/D54063
|
|
Add header values for xHCI debug capability. These values are defined in
section 7.6 of xHCI Specification 1.2b (April 2023).
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D53897
|
|
On inital import the name of HCCPARAMS1 was misnamed as HCSPARAMS0.
HCCPARAMS1 is defined in section 5.3.6 of xHCI Specification 1.2b (April
2023).
Reviewed by: adrian
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D53895
|
|
Reviewed By: aokblast
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D52994
|
|
Driver for Feature Integration Technology Inc. (aka Fintek)
F81232 USB to serial driver.
Reviewed by: thj,adrian,UB
Approved by: adrian
Differential Revision: https://reviews.freebsd.org/D53893
|
|
Realtek changed how it styled its name 25 or so years ago, but the old
style persisted in many places. These products use the new styling in
their datasheets.
Signed-off-by: ykla yklaxds@gmail.com
Sponsored by: Chinese FreeBSD Community
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1901
|
|
* constify mtw_write_region_1()'s data field
* convert to use ieee80211_crypto_get_*()
* .. note that rx/tx mic data routines are explicitly being called,
as this NIC is doing TKIP + MIC offload
Differential Revision: https://reviews.freebsd.org/D53704
Reviewed by: bz
|
|
PR: 290688
MFC After: 3 days
|
|
PR: 290421
MFC After: 3 days
|
|
- s/frequence/frequency/
- s/finsihed/finished/
MFC after: 5 days
|
|
|
|
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D52045
|
|
Migrate the following wifi drivers to use the seqno offload option.
Locally tested (STA mode) on:
* mtw
* uath
* upgt
* ural
* urtw
* uzyd
Differential Revision: https://reviews.freebsd.org/D50771
Okayed by: bz
|
|
xhci offers a debugging interface which uses a special usb 3 cable with the D+,
D- and VBUS pairs disconnected. This interface allows a target device to
configure its xhci controller as a debugging channel which can then be used to
provide a serial link between the target and a debug host.
This change extracts the udbc host mode driver from hrs@'s xhci debug
implementation.
Reviewed by: bcr (man page)
MFC after: Before 15-ALPHA3 builds
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D51299
|
|
* Enable A-MPDU TX by fixing the A-MPDU TX establish routine;
always assign sequence numbers from net80211 (for now); and
fix the descriptor programming.
* Add TODO items around CAM allocation for keys, MAC ID stuff which
we likely need to fix for working IBSS/AP behaviour, and whatever
other bits and pieces I noticed.
* Disable amsdu2ampdu, we can decap A-MSDU just fine in net80211,
doubly so if we somehow get A-MSDU inside an A-MPDU.
I've tested / verified that A-MPDU TX and A-MPDU RX is correctly
established and functioning by using rtwn in monitor mode.
I used an old r92su linux out of tree driver for comparison.
Differential Revision: https://reviews.freebsd.org/D50748
Okayed by: bz
|
|
Enable sequence number offload.
This should both enable the sequence number offloading and disable
the net80211 TX lock from being acquired/released/checked.
Differential Revision: https://reviews.freebsd.org/D50749
Okayed by: bz
|
|
Enable sequence number offload.
This should both enable the sequence number offloading and disable
the net80211 TX lock from being acquired/released/checked.
Differential Revision: https://reviews.freebsd.org/D50747
Okayed by: bz
|
|
|
|
This driver does not depend on netmap, and umb_input() works greatly
without netmap.
Remove the #ifdef DEV_NETMAP so that when "device netmap" is not
configured this driver can still correctly pass the inbound packets to
the net stack. Otherwise the input routine will be if_input_default()
which will silently drop all inbound packets.
PR: 263783
Reported by: Andre Albsmeier <mail@fbsd2.e4m.org>
Tested by: Andre Albsmeier <mail@fbsd2.e4m.org>
Differential Revision: https://reviews.freebsd.org/D52182
|
|
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
|
|
- s/tranfers/transfers/
MFC after: 3 days
|
|
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
|
|
Co-authored-by: Emmanuel Vadot <manu@FreeBSD.org>
Reviewed by: bapt, wulf
Relnotes: Yes
Sponsored by: Beckhoff Automation GmbH & Co. KG
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45659
|
|
Reviewed by: aokblast
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D51259
|
|
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
|
|
Reviewed by: imp, jhb
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D50913
|
|
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D50542
|
|
<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
|
|
Note: The commit in main was modified for the new macros in main.
stable merge will need to use the version originally in #1715
MFC After: 2 weeks
Pull Request: https://github.com/freebsd/freebsd-src/pull/1715
Closes: https://github.com/freebsd/freebsd-src/pull/1715
|
|
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
|
|
Fixes: 718cf2ccb995 (further adoption of SPDX)
MFC after: 3 days
Reviewed by: carlavilla, imp, mhorne
Approved by: carlavilla, mhorne (mentors)
Differential Revision: https://reviews.freebsd.org/D50374
|
|
dwc_otg_init() already takes care of creating the bus and setting up sc
to point to it.
Fixes: 518da7ace813e
MFC after: 1 week
|
|
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
|
