oops, remove duplicate code

ok, this diff now fixes both of the incorrect transfer / EP configuration issues, and everything seems fine now on the RTL NICs I've tested.

add local wme2qid fix to ensure endpoints are uniquely used.

ok, i found the rest of the issue - in the EP setup, the EP array has all four endpoints to be configured, but then the init code manually walks the TX bulk endpoints and assigns them to the four endpoints.
In the case of the RTL8811AU it supports 4 TX bulk endpoints, but BK/BE are mapped to the same physical USB endpoint.
So, if I did parallel traffic between VO, VI and one of BK/BE, it was fine. If I did parallel traffic with BK and BE, traffic stalls.
If I then mapped BK and BE to different endpoints? It works fine.
But I can't DO that because there are other places in usb_tx_ep.c that setup some TX queue mapping bits in the hardware that I don't quite understand, and they all definitely only handle 1, 2 or 3 endpoints.
Also - the traffic stalls come back on the RTL8192EU because it has three TX bulk endpoints, so there's remapping still going on there.

update with historical reference from emaste, be clearer that
i have the NIC in question.

update commit message, from emaste

OK, if you have a device that has this ID we should clearly add it back. Perhaps we should add AR5523_2_ALT or something like that for 0x882a.

ok but i have a device with this product id! :) Maybe we need both?

And the Linux 0x0828 arrived via

commit b7d572e1871df06a96a1c9591c71c5494ff6b624
Author: Pontus Fuchs <pontus.fuchs@gmail.com>
Date:   Tue Oct 23 20:33:57 2012 +0200

Huh, this arrived in:

commit 02ac6454880b59bbc5f3f74dffaffa90b30adc8b
Author: Andrew Thompson <thompsa@FreeBSD.org>
Date:   Mon Feb 23 18:31:00 2009 +0000

update commit message

update commit message

FYI if Phab doesn't add the commit automatically (either because of a typo or misformatted commit message or because Phab is just broken) you can add it later via Edit Related Objects > Edit Commits and then paste the commit hash.

In D47500#1086528, @adrian wrote:

landed

I don't know what your nice 8 core laptop is but again I am also not sure why it matters. Please write a proper commit message.

Can you please write a normal descriptive commit message.

url

url

landed

(note - i saw I was missing a BIP capability bit, so I added that to the commit before I pushed it.)

In D47645#1086332, @emaste wrote:

The commit message sounds like this is a NFC but IEEE80211_FC0_VERSION_MASK and `IEEE80211_FC0_TYPE_MASK are now being checked where they were not before? I think this should be clarified in the commit message.

The commit message sounds like this is a NFC but IEEE80211_FC0_VERSION_MASK and `IEEE80211_FC0_TYPE_MASK are now being checked where they were not before? I think this should be clarified in the commit message.

ok, please re-review this!

address spacing comment from bz@

In D47522#1084776, @adrian wrote:

oh it's THIS bug, ha! ok, lemme go re-review D38854 and see if we can figure out how to get it in cleanly.

oh it's THIS bug, ha! ok, lemme go re-review D38854 and see if we can figure out how to get it in cleanly.

https://reviews.freebsd.org/D38854 and https://reviews.freebsd.org/D47562.

In D47522#1084687, @adrian wrote:

hm, looks like it may be a USB controller problem, hmph. Stay tuned.

use usbd_errstr()

Add a device_printf() to log when USB transfer errors happen, so it's easier to figure out what happened

updates from emaste/bz

hm, looks like it may be a USB controller problem, hmph. Stay tuned.

note - I've tested this on a variety of other rtwn NICs now - RTL8821AU, RTL8188EU, RTL8192EU - they worked fine. But RTL8192CU isn't working; TX seems broken. I don't think it's this patch, but I'm going to test on older laptops and also earlier freebsd version snapshots.

Thank you!