Status: source-level investigation only; no new device measurements. Every source below is linked at a pinned commit.
There is a concrete reset candidate beyond TX_CLR: the vendor-derived
MT76x2U source has separate UDMA TX and IFDMA/FCE reset controls. Its
RTMPSwReset() uses CFG 0x9014[6] and CFG 0x0064[22:21], respectively.
Neither appears in the supplied list of failed experiments. Whether this
sequence clears this adapter's hard wedge remains untested. It is premature
to conclude that the silicon requires re-enumeration.
The handover reports EP0 CFG/MAC read/write round-trips still working,
MT_ASIC_VERSION=0x76120044, and bulk OUT timing out at the first ROM-patch
chunk on EP8. Kernel-driver binding also fails.
CFG 0x9018 |
Reported behavior |
|---|---|
0x00c00020 |
Soft wedge, TX_BUSY clear; bit19 TX_CLR set, 20 ms, clear recovered 3/3 trials. |
0x80c00020 |
Hard wedge, TX_BUSY set; repeated TX_CLR, MAC/PBF/WLAN resets, USB port reset, halt clearing, authorization toggle and xHCI rebind failed; physical replug recovered. |
The earlier undrained-RX report in mt7612u.md describes vendor requests
timing out too. Do not conflate that failure with this EP0-responsive state.
Physical replug changes power as well as enumeration; its success does not
prove that logical re-enumeration alone is sufficient.
Source: RTMPSwReset(), vendor-derived MT76x2U tree. The tree identifies itself as JEDI.MP2.mt76x2u.wifi.v3.2.1 and lists MT7612U and MT7662U among its targets. This is a pinned public mirror, not an authenticated copy of an untouched MediaTek release.
Use checked read-modify-write operations. In this table, pulse means set the mask, wait 15 ms, read again, clear the mask, wait 15 ms.
| Order | Space / offset | Operation | Source's purpose |
|---|---|---|---|
| 1 | CFG 0x9018 |
Clear 0x00c00000 |
Disable UDMA TX and RX |
| 2 | CFG 0x9080 |
Pulse 0x03f00000 |
Drop OUT EP4–EP9 data |
| 3 | CFG 0x9014 |
Pulse 0x00000040 |
Reset UDMA TX |
| 4 | CFG 0x0064 |
Pulse 0x00600000 |
Reset IFDMA/FCE |
| 5 | MAC 0x0400 |
Pulse 0x0000000c |
Reset MAC/PBF |
| 6 | CFG 0x9014 |
Pulse 0x00000020 |
Reset UDMA RX |
| 7 | CFG 0x9018 |
Set 0x00c00000; wait 15 ms |
Enable UDMA TX and RX |
The function's surrounding contract calls for cancelling bulk OUT URBs,
disabling MAC TX/RX (MAC 0x1004 = 0), and polling MAC TX idle
(MAC 0x1200 & 1 == 0) first. Those actions, firmware reload and final MAC
enable are commented out in this helper. Its contract says reload firmware
without asserting WLAN reset at CFG 0x0064[19].
There is an actual call at the start of rt28xx_init(), before
top-level initialization and mcu_sys_init(). Thus the helper is used during
bring-up; it is not evidence of a tested recovery from SIGKILL with TX_BUSY
stuck. Its active reset operations use EP0 register access and delays, with
no USB reset, configuration change or re-enumeration request.
For a userspace experiment, stop new submissions and cancel/reap outstanding transfers before touching the DMA. Bound and record the MAC-idle poll; do not turn it into an infinite wait on the fault being investigated. Leave MAC RX disabled until a live drain exists. Firmware/FCE/channel state must be reinitialized after the sequence; resuming old queued frames is not a valid success test. These are integration requirements, not measurements.
The vendor's CFG accessors agree with the pinned mt76 register accessors. All offsets above fit in 16 bits.
| Operation | bmRequestType | bRequest | wValue | wIndex | Data |
|---|---|---|---|---|---|
| Read CFG | 0xc0 |
0x47 |
0 |
offset | Read 4 bytes, little-endian |
| Write CFG | 0x40 |
0x46 |
0 |
offset | Write 4-byte little-endian value |
| Read MAC | 0xc0 |
0x07 |
0 |
offset | Read 4 bytes, little-endian |
| Write MAC | 0x40 |
0x06 |
0 |
offset | Write 4-byte little-endian value |
In this backend, use CFG_ADDR(offset) with the checked register accessors
for CFG space; pass a plain offset for MAC space. Require exactly four bytes
for each read/write and stop on a failed transaction. Never perform an RMW
from a fallback 0xffffffff read. 0x40 in the vendor's address-space
notation is not itself the register-request opcode.
No EEPROM/eFuse write or unknown vendor opcode is needed for this sequence.
The following are established controls, but none is independently documented as a hard USB-DMA recovery command.
| Control | Exact request or write | Meaning / relevance |
|---|---|---|
| Firmware vendor reset | EP0 (type=0x40, request=0x01, value=0x0001, index=0, length=0) |
mt76x02u_mcu_fw_reset(). Already called by local fw_reset() before the failing patch upload. |
| WMT reset | EP0 (type=0x20, request=0x01, value=0x0012, index=0, length=8), payload 6f fc 05 01 07 01 00 04 |
mt76x2u_mcu_reset_wmt(). Class, not vendor request. Normally follows patch upload/enable, with 20 ms settling; the reported failure occurs before that point. No proof it works as a pre-upload DMA reset. |
| WRITE_FCE | Request 0x42; two zero-data OUT requests encode the low/high 16-bit halves in wValue, at wIndex=offset and offset+2 |
mt76u_single_wr(). Writes FCE upload address/length; not a special reset command. Do not confuse this wire format with the four-byte CFG/MAC writes above. |
The normal MAC-space FCE setup is 0x0800=1 (PSE), 0x09a0=0x400230
(descriptor base), 0x09a4=1 (count), 0x09c4=0x44 (PDMA configuration),
and 0x0a6c=3 (skip FS). These are the mt76 upload preamble,
already present in local fce_setup(). Rewriting them is initialization,
not the dedicated CFG 0x0064[22:21] reset above.
MT_TX_CPU_FROM_FCE_CPU_DESC_IDX is MAC 0x09a8. The
upload code increments it after a successful bulk transfer.
Neither inspected loader establishes that zeroing or advancing it can repair
a NAKing endpoint. A stalled downstream descriptor is plausible, but the
observations do not isolate it; overwriting the index could instead lose the
relationship between submitted data and descriptors. Prefer the sourced
IFDMA/FCE reset over inventing an index value.
The vendor USB layout calls TX_BUSY and EP_OUT_VALID debug
status. EP_OUT_VALID describes endpoint data validity, not whether the USB
configuration exposes an endpoint. Zero during healthy idle is consequently
not surprising; zero with TX_BUSY set does not identify where the engine is
waiting. The same header names bit20 WL_LPK_EN for MT76xx while retaining
the older TXOP-countdown comment. The older rt2x00 header
describes TXOP_HALT as pausing the countdown when the TX buffer fills.
Neither supplies evidence that bit20 aborts or resets an active UDMA
transaction. Do not infer a recovery write from that generic mt76 name.
The vendor's mt76x2_polling_txq_empty() provides more specific observations to record before and after each reset stage:
| Space / offset | Idle/empty condition |
|---|---|
CFG 0x2240, 0x2250, 0x2260, 0x2270, 0x2280, 0x2290 |
Bit17 set for each OUT endpoint EP4–EP9 |
CFG 0x9100 |
(value & 0x07f00000) == 0, UDMA TX state idle |
MAC 0x0a30 |
(value & 0x000000ff) == 0, FCE TX1 empty |
MAC 0x0a34 |
(value & 0x0000ff00) == 0, FCE TX2 empty |
Capture these plus CFG 0x9018, 0x9014, 0x9080, 0x0064 and MAC
0x0400, 0x09a8. An idle status alone is insufficient: the subsequent
bounded bulk transfer and firmware/MCU exchange must also succeed.
libusb_set_configuration(handle, current_configuration) requests a reset
of USB configuration state: alternate settings, endpoint halts and toggles.
Cancel/reap transfers, keep automatic kernel reattachment disabled, and
release claimed interfaces first; reclaim afterward. Discover the actual
configuration value rather than assuming 1. Use the library API so the host
stack tracks the change. The setup tuple is (0x00, 0x09, configuration, 0, 0).
libusb device-handling documentation
libusb_set_interface_alt_setting(handle, interface, advertised_alt) maps to
(0x01, 0x0b, alt, interface, 0) with the interface claimed and its transfers
quiesced. Do not invent alt 1. Linux allows a single-alt device to stall this
request and then performs a host-side fallback, so API success alone need not
mean a device-side reset occurred. Linux usb_set_interface()
Neither API promises to reset MediaTek's internal UDMA/FCE state. Moreover,
Linux's usb_reset_and_verify_device() already sends
SET_CONFIGURATION while restoring an existing configuration after a successful
port reset. If the reported libusb_reset_device() succeeded along that path,
this request has effectively already been exercised. A separate request is
still an order-dependent experiment, not a stronger reset or an established
solution. Confirm its presence in a USB trace if that distinction matters.
Linux mt7601u firmware setup disables FCE (MAC 0x0800=0)
before its vendor reset, then reinitializes FCE and pulses TX_CLR. Its USB DMA
register is normal 0x0238, not MT7612U CFG 0x9018. This supplies a
related-chip ordering precedent, not evidence that its unrelated magic
initialization values are safe or necessary on MT7662.
Linux rt2x00 defines TX_CLEAR bit19 at normal 0x02a0. Neither
rt2800usb.c nor rt2800lib.c in v6.12 uses that
field. It adds no stronger hard-wedge recovery sequence than the dedicated
MT76x2U resets identified above.
The next discriminating experiment is the complete vendor sequence, with a known hard-wedged starting state, no open-time USB reset hidden in the test, and no power or enumeration transition. Record stage-by-stage registers and control return lengths, then verify firmware upload, MCU reply, and ordinary TX/RX against a live witness. Repeat on independently reproduced hard wedges and include an unchanged recovery attempt as the failing control. If the full sequence works, isolate its stages in later trials; do not attribute success to bit6 alone when multiple resets were applied.
Until that measurement exists, physical replug is the only reported working hard-wedge recovery; it is not a proven silicon requirement. The sources show separate MAC/PBF, UDMA and IFDMA/FCE reset controls, which explains why the previously attempted reset names do not cover every block. They do not publish enough MT7662 USB-core internals to prove an unrecoverable latch, specific deadlock, or mandatory power-on-reset condition. No driver change, hardware test, or recovery claim is made by this report.