Am 12.06.24 um 14:20 schrieb Martin Kaistra:
Am 12.06.24 um 03:47 schrieb Ping-Ke Shih:
Martin Kaistra <martin.kaistra@xxxxxxxxxxxxx> wrote:
Hi Ping-Ke, hi Bitterblue,
I have a problem with the rtl8xxxu driver and 8188f, but only on some boards.
More specifically, I can see that during the second channel switch (which
happens when I do "iw dev wlan0 scan"), the rtl8xxxu_read32(0e08) returns -110
(ETIMEDOUT) and after that no reads or writes work anymore until I unload and
reload the driver.
If this symptom is 100% reproducible, I would add many rtl8xxxu_read32(0xe08)
somewhere to bisect the cause resulting from writing IO or certain H2C commands.
Thanks to your suggestion, I found out that
1) the timeouts start occuring right after the first frame is sent (rtl8xxxu_tx)
2) the adress doesn't matter, rtl8xxxu_read8(0x100) also gets a timeout
After doing more debugging, I saw that the values that are written to the
txpower registers are different between vendor and mainline driver.
The efuse for the problematic boards has no txpower values set, but reads instead
00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
I guess, they haven't gone through the calibration stage yet..
The vendor driver seems to have a check for invalid values and uses some default
values instead. rtl8xxxu just uses 0xff, sets the power to max and then once a
frame is sent, the USB power supply is not enough and the chip goes into reset?!
When I either comment out the calls to .set_tx_power() or add some defaults in
case of 0xff in parse_efuse() the chip works and I don't see any timeout problems.
I will prepare a patch to fix at least rtl8188fu_parse_efuse() and then we can
see how to implement it for all supported chips.
