Two independent fixes found on a UGREEN a69c:5723 adapter
(chip_id=7, chip_mcu_id=1, product_id=0x8820, issue #118):
1) The firmware boots and answers every configuration request, but never
confirms MM_START_REQ, so the MAC never starts and wlan0 stays unusable
(the symptom reported in #79). The Windows loader (aicloadfw.sys) handles
product 0x8820 differently: it writes 0x40500010 = 0x2, masked-writes
0x40506024 (mask 0xff) = 0xdf, and uploads only the FMAC firmware without
the adid/patch/patch-table/patch-config layer. Mirror that behaviour,
gated on product_id == 0x8820 so that other D80 revisions (for example the
a69c:572f from #58) keep uploading the patch layer and stay unaffected.
The existing MCU1 cache fix (0x40100020 |= 0x1) is kept for both.
2) rwnx_cfg80211_connect() returned 0 when the state machine was already
CONNECTING/DISCONNECTING, without ever reporting a result. cfg80211 then
keeps wdev->conn allocated and rejects every later NL80211_CMD_CONNECT
with -EALREADY, so the driver's connect op is never called again and
NetworkManager loops on the password prompt ("associating -> disconnected"
every 5 s) with no driver activity at all. Report the failure instead:
reset the state and return -EBUSY.
Tested on Ubuntu 26.04 / 7.0.0-14-generic: 5 GHz association, DHCP, IPv6
SLAAC and internet traffic all work, and it survives reboot and USB re-plug.
Full logs and analysis: #118