Page MenuHomeFreeBSD

rtwn: Fix RTL8192EU cannot associate in STA mode
Needs ReviewPublic

Authored by cy on Thu, Nov 14, 2:43 AM.
Tags
None
Referenced Files
F102927196: D47562.id.diff
Mon, Nov 18, 8:30 PM
F102915761: D47562.diff
Mon, Nov 18, 5:18 PM
F102909329: D47562.id146415.diff
Mon, Nov 18, 3:15 PM
F102905888: D47562.id.diff
Mon, Nov 18, 2:07 PM
F102863843: D47562.diff
Mon, Nov 18, 3:54 AM
Subscribers

Details

Reviewers
adrian
bz
Group Reviewers
wireless
Summary

On some systems RTL8192EU will fail to associate in STA mode while
others it will work fine. On the systems RTL8192EU fails to associate
in STA mode, it works perfectly fine in AP mode. This points to a USB
timing issue when selecting a channel while in STA mode.

While here fix RTL8192EU power off and power on hang for the same reason.

PR: 247528
Reported by: Mc James <realmcjames@protonmail.ch>, many
Tested by: titus@edc.ro
Concept by: titus@edc.ro

Test Plan

Been running here since Jan 9, 2023.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

cy requested review of this revision.Thu, Nov 14, 2:43 AM

Can this be simplified to simply check if uc_delay_us is > 0? Otherwise from scrolling through uc_write_delay would be a bool or are we expecting more values?

There's /gotta/ be a way to do this without having the channel code try get the USB pointer.

Lemme noodle on it, I think we should be able to move uc_delay_us into the rtwn softc, and make uc_write_delay a softc function? instead of how it's currently done?

What's interesting is what's potentially causing the timing differences on XHCI versus EHCI? Like, are we missing some kind of flush/wait somewhere before issuing the next command(s) ?

There's /gotta/ be a way to do this without having the channel code try get the USB pointer.

Lemme noodle on it, I think we should be able to move uc_delay_us into the rtwn softc, and make uc_write_delay a softc function? instead of how it's currently done?

I can certainly do this. Same problem and fix for RTL8188EU. I can poke around at this tomorrow and maybe Monday.

What's interesting is what's potentially causing the timing differences on XHCI versus EHCI? Like, are we missing some kind of flush/wait somewhere before issuing the next command(s) ?

Probably. This affects RTL8188EU as well. Moving this into its own function would be the correct approach. I'll look at tomorrow and Monday.

I did a local version of this to see, and it doesn't /reliably/ associate, but it does associate.

Honestly I really do wonder what's different between EHCI and XHCI here, aiee.