In D4020#92682, @adrian wrote:

This is a really big diff and looks like it includes more than "add wme support". What's going on?

Works fine for me.

Workaround RTL8188CUS stability problems by using BSS macid for mcast / bcast frames.

This part was removed, because device is still unstable with (or without) this workaround.

Rebase.

Obsolete.

In D4291#91096, @kevlo wrote:

In D4291#90993, @s3erios_gmail.com wrote:

In D4291#90697, @kevlo wrote:

The error handing is bogus. Is it really needded?

As for me, it works fine without this code. But:

• ieee80211_stop() will mark this interface as stopped when an error in urtwn_init() happens (for example, some time ago I have seen 'timeout waiting for checksum report' error). As a result, after an error - with this change - you can try to reinit the device with 'ifconfig wlan0 up'

I had seen this message once, but it appears I didn't fix it :(

In D4291#90697, @kevlo wrote:

The error handing is bogus. Is it really needded?

Fix race between ieee80211_tx_watchdog_stop() and ieee80211_tx_watchdog_refresh().

Fix locking

Remove unneded (sc->last_rom_addr == URTWN_EFUSE_MAX_LEN) checking in urtwn_efuse_read().

In D4034#86261, @adrian wrote:

dependencies are OK'ed. Commit them one at a time. :)

In D4034#85733, @adrian wrote:

go for it!

In D4069#85524, @adrian wrote:

Looks fine! Did you test it on anything?

• Call ieee80211_tx_watchdog_refresh() before calling ic_transmit() / ic_raw_xmit(); that adds a possibility to call it from the callee error handler.
• Update watchdog timer only when transmission occurs.
• Add few more checks.

Few places, where it can be used:
bwn(4):
static void
bwn_watchdog(void *arg)
{

struct bwn_softc *sc = arg;

In D3999#83480, @adrian wrote:

Please add the lock assertions and then yup, go ahead and commit it! THanks!

• Add URTWN_ASSERT_LOCKED(sc) where needed.
• Sort local variables.

In D3999#83473, @kevlo wrote:

It seems that vendor drivers (rtl8188eu and rtl8188cu/rtl8192cu)
mess with both R92C_RXFLTMAP* and R92C_RCR.
I'd like to know more about the difference between RCR and R92C_RXFLTMAP*
registers.

If you tested it and it works fine for you, please commit it, thanks.

Convert urtwn_txeof() to the common appearance.

If there is no possibility to use usbd_do_request*() without sleeping, then this will be a bit complicated (revert this part for now).

Rebase.

Add urtwn_set_mode()

In D3985#83018, @adrian wrote:

ok, so this stupid hack is because of something else - there's no locking around fetching and setting vap->iv_bss; and sometimes an invalid or NULL node shows up there. The hack (ni = ref(vap->iv_bss)) closes the window, but it's still there.

I'd rather we actually plan out and fix how the vap node lifecycle and refcounting happens, rather than what currently happens.

Rebase (to make it compile & work after rS288523 and rS288525).

Remove EDCA_VI_PARAM modification; vendor driver sets this value after common initialization procedure.

In D3968#82651, @adrian wrote:

Hi!

This is good. How about also refactoring out the "any bssid" rxfilter set/clear bit there into a separate function too? That way it's

urtwn_set_rx_bssid_all(sc, 1);
urtwn_set_gain(sc, xxX);

.. for scan, etc?

In D3845#79972, @kevlo wrote:

Not sure I like this. Part of the reason is we don't know much about
the internal workings of the chip. As for initializations of MAC/BB/RF,
you can see the vendor driver does set those registers.

In D3763#79519, @adrian wrote:

Hi,

So there are a lot of changes from int to something else. I think you should explain to people why the changes are useful as part of the description.

For example, people tend to just use 'int' for array iteration, and you've changed a handful of those over to be uint8_t. Why's that?

In D3758#79228, @adrian wrote:

Did you test this with powersaving enabled in wpi? I don't remember adding it, so I haven't tested it yet. I've only tested iwn.

1. The URTWN_RSSI macro in inappropriate here - since urtwn_get_rssi()/urtwn_r88e_get_rssi() returns negative value, in most cases this macro will cause overflow.
2. As I have said previously, 3rd byte is channel and 4th is always (or not?) zero. After adding two additional fields here, restored urtwn_r88e_get_rssi() call starts producing more realistic values (almost the same as from other NICs).

OK, this way is not correct too. I will fix this soon.

I think, that r88e_rx_cck structure is wrong (for example, sig_qual field contains current channel number + it is here for all frames, not only for CCK)

In D3820#78814, @adrian wrote:

Ok, so what's the difference between R88 and R92? Like, should the R88 chips be using R92 method, or is the R88 method we have broken?

In D3757#78349, @adrian wrote:

Hi,

Ok, so I'm going to put this on hold for now. I think wpi could benefit from what I did with iwn to defer sending frames on 5GHz until it sees a beacon frame - and that kind of wants a staging queue like this with a deferred transmit routine.

In D3640#78035, @adrian wrote:

I'm okay with hand-crafted ones for now, but we should think about how to push it into the net80211 taskqueue - likely with an actual deferred callback framework there.

Rebase.

Rebase.