diff mbox series

[v7,12/12] wifi: rtlwifi: Enable the new rtl8192du driver

Message ID 5f2da7ee-876a-42fc-8fec-ec5386fa8c26@gmail.com (mailing list archive)
State Accepted
Delegated to: Ping-Ke Shih
Headers show
Series wifi: rtlwifi: Add new rtl8192du driver | expand

Commit Message

Bitterblue Smith May 23, 2024, 2:49 p.m. UTC
The RTL8192DU is an older Wifi 4 dual band chip. It comes in two
flavours: single MAC single PHY (like most Realtek Wifi 4 USB devices),
and dual MAC dual PHY.

The single MAC single PHY version is 2T2R and can work either in the
2.4 GHz band or the 5 GHz band.

The dual MAC dual PHY version has two USB interfaces and appears to the
system as two separate 1T1R Wifi devices, one working in the 2.4 GHz
band, the other in the 5 GHz band.

This was tested only with a single MAC single PHY device, mostly in
station mode. The speeds in the 2.4 GHz band with 20 MHz channel width
are similar to the out-of-tree driver: 85/51 megabits/second.

Stefan Lippers-Hollmann tested the speed in the 5 GHz band with 40 MHz
channel width: 173/99 megabits/second.

It was also tested briefly in AP mode. It's emitting beacons and my
phone can connect to it.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
---
v7:
 - No change.

v6:
 - No change.

v5:
 - Call it 802.11n instead of 802.11an in Kconfig.

v4:
 - No change.

v3:
 - No change.

v2:
 - Patch is new in v2, split from patch 3/3 in v1.
---
 drivers/net/wireless/realtek/rtlwifi/Kconfig        | 12 ++++++++++++
 drivers/net/wireless/realtek/rtlwifi/Makefile       |  1 +
 .../net/wireless/realtek/rtlwifi/rtl8192du/Makefile | 13 +++++++++++++
 3 files changed, 26 insertions(+)
 create mode 100644 drivers/net/wireless/realtek/rtlwifi/rtl8192du/Makefile

Comments

Ping-Ke Shih May 27, 2024, 7:47 a.m. UTC | #1
Hi Stefan,

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> The RTL8192DU is an older Wifi 4 dual band chip. It comes in two
> flavours: single MAC single PHY (like most Realtek Wifi 4 USB devices),
> and dual MAC dual PHY.
> 
> The single MAC single PHY version is 2T2R and can work either in the
> 2.4 GHz band or the 5 GHz band.
> 
> The dual MAC dual PHY version has two USB interfaces and appears to the
> system as two separate 1T1R Wifi devices, one working in the 2.4 GHz
> band, the other in the 5 GHz band.
> 
> This was tested only with a single MAC single PHY device, mostly in
> station mode. The speeds in the 2.4 GHz band with 20 MHz channel width
> are similar to the out-of-tree driver: 85/51 megabits/second.
> 
> Stefan Lippers-Hollmann tested the speed in the 5 GHz band with 40 MHz
> channel width: 173/99 megabits/second.

Could you please confirm this description is still correct in v7?
If so, your Tested-by tag is welcome.
Stefan Lippers-Hollmann May 27, 2024, 9:25 a.m. UTC | #2
Hi

On 2024-05-27, Ping-Ke Shih wrote:
> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> > The RTL8192DU is an older Wifi 4 dual band chip. It comes in two
> > flavours: single MAC single PHY (like most Realtek Wifi 4 USB devices),
> > and dual MAC dual PHY.
[...]
> > Stefan Lippers-Hollmann tested the speed in the 5 GHz band with 40 MHz
> > channel width: 173/99 megabits/second.
>
> Could you please confirm this description is still correct in v7?
> If so, your Tested-by tag is welcome.

I held back with a formal Tested-by for this, as rtlwifi needs
some fixing after the chanctx changes
(0a44dfc070749514b804ccac0b1fd38718f7daa1, "wifi: mac80211:
simplify non-chanctx drivers") went in (for v6.9 and up).

So, yes, rtl8192du v7 itself works fine (as did v6 and previous), but
the chanctx changes do cause a performance regression, resulting in
lower (and very inconsistent) throughput and larger packet loss,
due to the rate control being confused. As Bitterblue found out,
rtlwifi relies on the previous behaviour imposed by

ieee80211_hw_config(local, ~0);

As a consequence of the change to

ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_LISTEN_INTERVAL |
				   IEEE80211_CONF_CHANGE_MONITOR |
				   IEEE80211_CONF_CHANGE_PS |
				   IEEE80211_CONF_CHANGE_RETRY_LIMITS |
				   IEEE80211_CONF_CHANGE_IDLE);

mac80211 effectively sets a retry limit of 0x4, while rtlwifi
expects a retry limit of 0x30 (in STA mode or 0x7 in AP mode),
causing rtlwifi not to settle on a good fallback rate (and thereby
losing packets).

Disclaimer: the above issue and its explanation has been discovered
by Bitterblue, I just did the git bisecting (rtl8192du on top of
v6.8..v6.9) and performance testing to pinpoint the commit causing
the regression.

rtl8192du on top of v6.9+ (with the chanctx changes):
$ iperf3 -c <remote_ipv6>
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   384 KBytes  3.14 Mbits/sec
[  5]   1.00-2.00   sec   512 KBytes  4.19 Mbits/sec
[  5]   2.00-3.00   sec  1.00 MBytes  8.39 Mbits/sec
[  5]   3.00-4.00   sec   640 KBytes  5.24 Mbits/sec
[  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec
[  5]   6.00-7.00   sec   256 KBytes  2.10 Mbits/sec
[  5]   7.00-8.00   sec   640 KBytes  5.25 Mbits/sec
[  5]   8.00-9.00   sec   512 KBytes  4.19 Mbits/sec
[  5]   9.00-10.00  sec   256 KBytes  2.10 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  4.12 MBytes  3.46 Mbits/sec                  receiver

$ iperf3 -c <remote_ipv6> --reverse
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  12.9 MBytes   108 Mbits/sec    0    629 KBytes
[  5]   1.00-2.00   sec  9.75 MBytes  81.8 Mbits/sec    0   1.13 MBytes
[  5]   2.00-3.00   sec  11.0 MBytes  92.3 Mbits/sec    0   1.63 MBytes
[  5]   3.00-4.00   sec  1.38 MBytes  11.5 Mbits/sec    1   1.67 MBytes
[  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    1   1.39 KBytes
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    1   1.39 KBytes
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    0   1.39 KBytes
[  5]   7.00-8.00   sec  9.88 MBytes  82.8 Mbits/sec    0   2.12 MBytes
[  5]   8.00-9.00   sec  6.88 MBytes  57.7 Mbits/sec    3   2.32 MBytes
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec    0   2.32 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  51.8 MBytes  43.4 Mbits/sec    6             sender

$ iperf3 -c <remote_ipv6> --bidir
[ ID][Role] Interval           Transfer     Bitrate         Retr  Cwnd
[  5][RX-S]   0.00-1.00   sec  0.00 Bytes  0.00 bits/sec
[  8][TX-S]   0.00-1.00   sec  1.38 MBytes  11.5 Mbits/sec    0   90.6 KBytes
[  5][RX-S]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec
[  8][TX-S]   1.00-2.00   sec  4.12 MBytes  34.6 Mbits/sec    4   1.39 KBytes
[  5][RX-S]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec
[  8][TX-S]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    1   1.39 KBytes
[  5][RX-S]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec
[  8][TX-S]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    1   1.39 KBytes
[  5][RX-S]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec
[  8][TX-S]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   1.39 KBytes
[  5][RX-S]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec
[  8][TX-S]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    2    106 KBytes
[  5][RX-S]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec
[  8][TX-S]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    0    106 KBytes
[  5][RX-S]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec
[  8][TX-S]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0    106 KBytes
[  5][RX-S]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec
[  8][TX-S]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0    106 KBytes
[  5][RX-S]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec
[  8][TX-S]   9.00-10.00  sec  1.25 MBytes  10.5 Mbits/sec    2    119 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][RX-S]   0.00-10.01  sec  0.00 Bytes  0.00 bits/sec                  receiver
[  8][TX-S]   0.00-10.01  sec  6.75 MBytes  5.66 Mbits/sec   10             sender

Again, rtl8192du v7 itself is 'fine' and could (can) achieve 180/100
MBit/s before the chanctx changes, so merging v7 might be okay - but
there needs to be a fix for rtlwifi as a whole (and maybe even other
drivers) for v6.9+ and the chanctx changes that came with it (not
every chipset supported by rtlwifi might be affected equally badly,
e.g. rtl8192cu might not noticeably be, according to Bitterblue's
testing).

So with the (performance/ packet loss) caveat above:

Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>

I am running rtl8192du v7 on top of v6.9.2 now (and tested it on top
of wireless-next as of last Friday (2024-05-24)), with the performance
figures above.

Regards
	Stefan Lippers-Hollmann

--
This is the result of my git bisecting:

$ git bisect good
0a44dfc070749514b804ccac0b1fd38718f7daa1 is the first bad commit
commit 0a44dfc070749514b804ccac0b1fd38718f7daa1
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Jan 29 19:34:38 2024 +0100

    wifi: mac80211: simplify non-chanctx drivers

    There are still surprisingly many non-chanctx drivers, but in
    mac80211 that code is a bit awkward. Simplify this by having
    those drivers assign 'emulated' ops, so that the mac80211 code
    can be more unified between non-chanctx/chanctx drivers. This
    cuts the number of places caring about it by about 15, which
    are scattered across - now they're fewer and no longer in the
    channel context handling.

    Link: https://msgid.link/20240129194108.6d0ead50f5cf.I60d093b2fc81ca1853925a4d0ac3a2337d5baa5b@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>

 drivers/net/wireless/admtek/adm8211.c                          |   4 +
 drivers/net/wireless/ath/ar5523/ar5523.c                       |   4 +
 drivers/net/wireless/ath/ath5k/mac80211-ops.c                  |   4 +
 drivers/net/wireless/ath/ath9k/htc_drv_main.c                  |   4 +
 drivers/net/wireless/ath/ath9k/main.c                          |   4 +
 drivers/net/wireless/ath/carl9170/main.c                       |   4 +
 drivers/net/wireless/ath/wcn36xx/main.c                        |   4 +
 drivers/net/wireless/atmel/at76c50x-usb.c                      |   4 +
 drivers/net/wireless/broadcom/b43/main.c                       |   4 +
 drivers/net/wireless/broadcom/b43legacy/main.c                 |   4 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/mac80211_if.c |   4 +
 drivers/net/wireless/intel/iwlegacy/3945-mac.c                 |   4 +
 drivers/net/wireless/intel/iwlegacy/4965-mac.c                 |   4 +
 drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c              |   4 +
 drivers/net/wireless/intersil/p54/main.c                       |   4 +
 drivers/net/wireless/marvell/libertas_tf/main.c                |   4 +
 drivers/net/wireless/marvell/mwl8k.c                           |   4 +
 drivers/net/wireless/mediatek/mt76/mt7603/main.c               |   4 +
 drivers/net/wireless/mediatek/mt76/mt76x0/pci.c                |   4 +
 drivers/net/wireless/mediatek/mt76/mt76x0/usb.c                |   4 +
 drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c           |   4 +
 drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c           |   4 +
 drivers/net/wireless/mediatek/mt76/mt792x_core.c               |   7 +-
 drivers/net/wireless/mediatek/mt76/mt7996/main.c               |   4 +
 drivers/net/wireless/mediatek/mt7601u/main.c                   |   4 +
 drivers/net/wireless/purelifi/plfxlc/mac.c                     |   4 +
 drivers/net/wireless/ralink/rt2x00/rt2400pci.c                 |   4 +
 drivers/net/wireless/ralink/rt2x00/rt2500pci.c                 |   4 +
 drivers/net/wireless/ralink/rt2x00/rt2500usb.c                 |   4 +
 drivers/net/wireless/ralink/rt2x00/rt2800pci.c                 |   4 +
 drivers/net/wireless/ralink/rt2x00/rt2800soc.c                 |   4 +
 drivers/net/wireless/ralink/rt2x00/rt2800usb.c                 |   4 +
 drivers/net/wireless/ralink/rt2x00/rt61pci.c                   |   4 +
 drivers/net/wireless/ralink/rt2x00/rt73usb.c                   |   4 +
 drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c             |   4 +
 drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c             |   4 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c          |   4 +
 drivers/net/wireless/realtek/rtlwifi/core.c                    |   4 +
 drivers/net/wireless/realtek/rtw88/mac80211.c                  |   4 +
 drivers/net/wireless/realtek/rtw89/core.c                      |   7 +-
 drivers/net/wireless/rsi/rsi_91x_mac80211.c                    |   4 +
 drivers/net/wireless/st/cw1200/main.c                          |   4 +
 drivers/net/wireless/ti/wl1251/main.c                          |   4 +
 drivers/net/wireless/virtual/mac80211_hwsim.c                  |   4 +
 drivers/net/wireless/zydas/zd1211rw/zd_mac.c                   |   4 +
 drivers/staging/vt6655/device_main.c                           |   4 +
 drivers/staging/vt6656/main_usb.c                              |   4 +
 include/net/mac80211.h                                         |  13 ++
 net/mac80211/cfg.c                                             |  42 +++----
 net/mac80211/chan.c                                            | 111 +++--------------
 net/mac80211/ieee80211_i.h                                     |   9 +-
 net/mac80211/iface.c                                           |   6 +-
 net/mac80211/main.c                                            | 205 +++++++++++++++++++++++++------
 net/mac80211/mlme.c                                            |   3 +-
 net/mac80211/offchannel.c                                      |  21 ++--
 net/mac80211/scan.c                                            |  18 +--
 net/mac80211/tx.c                                              |   2 -
 net/mac80211/util.c                                            |  27 ++--
 58 files changed, 444 insertions(+), 207 deletions(-)

$ git bisect log
git bisect start
# Status: warte auf guten und schlechten Commit
# bad: [a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6] Linux 6.9
git bisect bad a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6
# Status: warte auf gute(n) Commit(s), schlechter Commit bekannt
# good: [e8f897f4afef0031fe618a8e94127a0934896aba] Linux 6.8
git bisect good e8f897f4afef0031fe618a8e94127a0934896aba
# bad: [480e035fc4c714fb5536e64ab9db04fedc89e910] Merge tag 'drm-next-2024-03-13' of https://gitlab.freedesktop.org/drm/kernel
git bisect bad 480e035fc4c714fb5536e64ab9db04fedc89e910
# bad: [9187210eee7d87eea37b45ea93454a88681894a4] Merge tag 'net-next-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
git bisect bad 9187210eee7d87eea37b45ea93454a88681894a4
# bad: [9187210eee7d87eea37b45ea93454a88681894a4] Merge tag 'net-next-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
git bisect bad 9187210eee7d87eea37b45ea93454a88681894a4
# good: [a01c9fe32378636ae65bec8047b5de3fdb2ba5c8] Merge tag 'nfsd-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux
git bisect good a01c9fe32378636ae65bec8047b5de3fdb2ba5c8
# bad: [ca61ba3885274a684c83d8a538eb77b30e38ee92] Merge branch 'rework-genet-mdioclocking'
git bisect bad ca61ba3885274a684c83d8a538eb77b30e38ee92
# good: [f42822f22b1c5f72c7e3497d9683f379ab0c5fe4] bnxt_en: Use firmware provided maximum filter counts.
git bisect good f42822f22b1c5f72c7e3497d9683f379ab0c5fe4
# bad: [e10cd2ddd89e8b3e61b49247067e79f7debec2f1] wifi: rtw89: load BB parameters to PHY-1
git bisect bad e10cd2ddd89e8b3e61b49247067e79f7debec2f1
# good: [2594e4d9e1a2d79bf7bb262974abaf5ef153e371] wifi: iwlwifi: prepare for reading SAR tables from UEFI
git bisect good 2594e4d9e1a2d79bf7bb262974abaf5ef153e371
# bad: [719036ae06d4bfdb65139e3947a8404dec298bc5] wifi: cfg80211: move puncturing validation code
git bisect bad 719036ae06d4bfdb65139e3947a8404dec298bc5
# good: [1209f487d452ff7e822dec30661fd6b5163fb8cf] wifi: rtl8xxxu: Add TP-Link TL-WN823N V2
git bisect good 1209f487d452ff7e822dec30661fd6b5163fb8cf
# good: [4dbd964f33aab6f99891b9610ad4b36cc215be0d] wifi: rtw89: 8922a: add chip_ops::rfk_hw_init
git bisect good 4dbd964f33aab6f99891b9610ad4b36cc215be0d
# good: [2fd53eb04c492eb9a2b06f994b36e5cf34ba7541] wifi: mac80211: remove unused MAX_MSG_LEN define
git bisect good 2fd53eb04c492eb9a2b06f994b36e5cf34ba7541
# bad: [0a44dfc070749514b804ccac0b1fd38718f7daa1] wifi: mac80211: simplify non-chanctx drivers
git bisect bad 0a44dfc070749514b804ccac0b1fd38718f7daa1
# good: [61f0261131c8dc2beeb6b34781a54788221081e9] wifi: mac80211: clean up band switch in duration
git bisect good 61f0261131c8dc2beeb6b34781a54788221081e9
# good: [2d9698dd32d086e47b8bff3df4322cc017c17b55] wifi: mac80211: clean up HE 6 GHz and EHT chandef parsing
git bisect good 2d9698dd32d086e47b8bff3df4322cc017c17b55
# first bad commit: [0a44dfc070749514b804ccac0b1fd38718f7daa1] wifi: mac80211: simplify non-chanctx drivers
Bitterblue Smith May 27, 2024, 11:06 p.m. UTC | #3
On 27/05/2024 12:25, Stefan Lippers-Hollmann wrote:
> Hi
> 
> On 2024-05-27, Ping-Ke Shih wrote:
>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>>> The RTL8192DU is an older Wifi 4 dual band chip. It comes in two
>>> flavours: single MAC single PHY (like most Realtek Wifi 4 USB devices),
>>> and dual MAC dual PHY.
> [...]
>>> Stefan Lippers-Hollmann tested the speed in the 5 GHz band with 40 MHz
>>> channel width: 173/99 megabits/second.
>>
>> Could you please confirm this description is still correct in v7?
>> If so, your Tested-by tag is welcome.
> 
> I held back with a formal Tested-by for this, as rtlwifi needs
> some fixing after the chanctx changes
> (0a44dfc070749514b804ccac0b1fd38718f7daa1, "wifi: mac80211:
> simplify non-chanctx drivers") went in (for v6.9 and up).
> 
> So, yes, rtl8192du v7 itself works fine (as did v6 and previous), but
> the chanctx changes do cause a performance regression, resulting in
> lower (and very inconsistent) throughput and larger packet loss,
> due to the rate control being confused. As Bitterblue found out,
> rtlwifi relies on the previous behaviour imposed by
> 
> ieee80211_hw_config(local, ~0);
> 
> As a consequence of the change to
> 
> ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_LISTEN_INTERVAL |
> 				   IEEE80211_CONF_CHANGE_MONITOR |
> 				   IEEE80211_CONF_CHANGE_PS |
> 				   IEEE80211_CONF_CHANGE_RETRY_LIMITS |
> 				   IEEE80211_CONF_CHANGE_IDLE);
> 
> mac80211 effectively sets a retry limit of 0x4, while rtlwifi
> expects a retry limit of 0x30 (in STA mode or 0x7 in AP mode),
> causing rtlwifi not to settle on a good fallback rate (and thereby
> losing packets).
> 
> Disclaimer: the above issue and its explanation has been discovered
> by Bitterblue, I just did the git bisecting (rtl8192du on top of
> v6.8..v6.9) and performance testing to pinpoint the commit causing
> the regression.
> 
> rtl8192du on top of v6.9+ (with the chanctx changes):
> $ iperf3 -c <remote_ipv6>
> [ ID] Interval           Transfer     Bitrate
> [  5]   0.00-1.00   sec   384 KBytes  3.14 Mbits/sec
> [  5]   1.00-2.00   sec   512 KBytes  4.19 Mbits/sec
> [  5]   2.00-3.00   sec  1.00 MBytes  8.39 Mbits/sec
> [  5]   3.00-4.00   sec   640 KBytes  5.24 Mbits/sec
> [  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec
> [  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec
> [  5]   6.00-7.00   sec   256 KBytes  2.10 Mbits/sec
> [  5]   7.00-8.00   sec   640 KBytes  5.25 Mbits/sec
> [  5]   8.00-9.00   sec   512 KBytes  4.19 Mbits/sec
> [  5]   9.00-10.00  sec   256 KBytes  2.10 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bitrate
> [  5]   0.00-10.00  sec  4.12 MBytes  3.46 Mbits/sec                  receiver
> 
> $ iperf3 -c <remote_ipv6> --reverse
> [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
> [  5]   0.00-1.00   sec  12.9 MBytes   108 Mbits/sec    0    629 KBytes
> [  5]   1.00-2.00   sec  9.75 MBytes  81.8 Mbits/sec    0   1.13 MBytes
> [  5]   2.00-3.00   sec  11.0 MBytes  92.3 Mbits/sec    0   1.63 MBytes
> [  5]   3.00-4.00   sec  1.38 MBytes  11.5 Mbits/sec    1   1.67 MBytes
> [  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    1   1.39 KBytes
> [  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    1   1.39 KBytes
> [  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    0   1.39 KBytes
> [  5]   7.00-8.00   sec  9.88 MBytes  82.8 Mbits/sec    0   2.12 MBytes
> [  5]   8.00-9.00   sec  6.88 MBytes  57.7 Mbits/sec    3   2.32 MBytes
> [  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec    0   2.32 MBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bitrate         Retr
> [  5]   0.00-10.00  sec  51.8 MBytes  43.4 Mbits/sec    6             sender
> 
> $ iperf3 -c <remote_ipv6> --bidir
> [ ID][Role] Interval           Transfer     Bitrate         Retr  Cwnd
> [  5][RX-S]   0.00-1.00   sec  0.00 Bytes  0.00 bits/sec
> [  8][TX-S]   0.00-1.00   sec  1.38 MBytes  11.5 Mbits/sec    0   90.6 KBytes
> [  5][RX-S]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec
> [  8][TX-S]   1.00-2.00   sec  4.12 MBytes  34.6 Mbits/sec    4   1.39 KBytes
> [  5][RX-S]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec
> [  8][TX-S]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    1   1.39 KBytes
> [  5][RX-S]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec
> [  8][TX-S]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    1   1.39 KBytes
> [  5][RX-S]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec
> [  8][TX-S]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   1.39 KBytes
> [  5][RX-S]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec
> [  8][TX-S]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    2    106 KBytes
> [  5][RX-S]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec
> [  8][TX-S]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    0    106 KBytes
> [  5][RX-S]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec
> [  8][TX-S]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0    106 KBytes
> [  5][RX-S]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec
> [  8][TX-S]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0    106 KBytes
> [  5][RX-S]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec
> [  8][TX-S]   9.00-10.00  sec  1.25 MBytes  10.5 Mbits/sec    2    119 KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID][Role] Interval           Transfer     Bitrate         Retr
> [  5][RX-S]   0.00-10.01  sec  0.00 Bytes  0.00 bits/sec                  receiver
> [  8][TX-S]   0.00-10.01  sec  6.75 MBytes  5.66 Mbits/sec   10             sender
> 
> Again, rtl8192du v7 itself is 'fine' and could (can) achieve 180/100
> MBit/s before the chanctx changes, so merging v7 might be okay - but
> there needs to be a fix for rtlwifi as a whole (and maybe even other
> drivers) for v6.9+ and the chanctx changes that came with it (not
> every chipset supported by rtlwifi might be affected equally badly,
> e.g. rtl8192cu might not noticeably be, according to Bitterblue's
> testing).
> 
> So with the (performance/ packet loss) caveat above:
> 
> Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
> 
> I am running rtl8192du v7 on top of v6.9.2 now (and tested it on top
> of wireless-next as of last Friday (2024-05-24)), with the performance
> figures above.
> 
> Regards
> 	Stefan Lippers-Hollmann
> 
> --
> This is the result of my git bisecting:
> 
> $ git bisect good
> 0a44dfc070749514b804ccac0b1fd38718f7daa1 is the first bad commit
> commit 0a44dfc070749514b804ccac0b1fd38718f7daa1
> Author: Johannes Berg <johannes.berg@intel.com>
> Date:   Mon Jan 29 19:34:38 2024 +0100
> 
>     wifi: mac80211: simplify non-chanctx drivers
> 
>     There are still surprisingly many non-chanctx drivers, but in
>     mac80211 that code is a bit awkward. Simplify this by having
>     those drivers assign 'emulated' ops, so that the mac80211 code
>     can be more unified between non-chanctx/chanctx drivers. This
>     cuts the number of places caring about it by about 15, which
>     are scattered across - now they're fewer and no longer in the
>     channel context handling.
> 
>     Link: https://msgid.link/20240129194108.6d0ead50f5cf.I60d093b2fc81ca1853925a4d0ac3a2337d5baa5b@changeid
>     Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> 
>  drivers/net/wireless/admtek/adm8211.c                          |   4 +
>  drivers/net/wireless/ath/ar5523/ar5523.c                       |   4 +
>  drivers/net/wireless/ath/ath5k/mac80211-ops.c                  |   4 +
>  drivers/net/wireless/ath/ath9k/htc_drv_main.c                  |   4 +
>  drivers/net/wireless/ath/ath9k/main.c                          |   4 +
>  drivers/net/wireless/ath/carl9170/main.c                       |   4 +
>  drivers/net/wireless/ath/wcn36xx/main.c                        |   4 +
>  drivers/net/wireless/atmel/at76c50x-usb.c                      |   4 +
>  drivers/net/wireless/broadcom/b43/main.c                       |   4 +
>  drivers/net/wireless/broadcom/b43legacy/main.c                 |   4 +
>  drivers/net/wireless/broadcom/brcm80211/brcmsmac/mac80211_if.c |   4 +
>  drivers/net/wireless/intel/iwlegacy/3945-mac.c                 |   4 +
>  drivers/net/wireless/intel/iwlegacy/4965-mac.c                 |   4 +
>  drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c              |   4 +
>  drivers/net/wireless/intersil/p54/main.c                       |   4 +
>  drivers/net/wireless/marvell/libertas_tf/main.c                |   4 +
>  drivers/net/wireless/marvell/mwl8k.c                           |   4 +
>  drivers/net/wireless/mediatek/mt76/mt7603/main.c               |   4 +
>  drivers/net/wireless/mediatek/mt76/mt76x0/pci.c                |   4 +
>  drivers/net/wireless/mediatek/mt76/mt76x0/usb.c                |   4 +
>  drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c           |   4 +
>  drivers/net/wireless/mediatek/mt76/mt76x2/usb_main.c           |   4 +
>  drivers/net/wireless/mediatek/mt76/mt792x_core.c               |   7 +-
>  drivers/net/wireless/mediatek/mt76/mt7996/main.c               |   4 +
>  drivers/net/wireless/mediatek/mt7601u/main.c                   |   4 +
>  drivers/net/wireless/purelifi/plfxlc/mac.c                     |   4 +
>  drivers/net/wireless/ralink/rt2x00/rt2400pci.c                 |   4 +
>  drivers/net/wireless/ralink/rt2x00/rt2500pci.c                 |   4 +
>  drivers/net/wireless/ralink/rt2x00/rt2500usb.c                 |   4 +
>  drivers/net/wireless/ralink/rt2x00/rt2800pci.c                 |   4 +
>  drivers/net/wireless/ralink/rt2x00/rt2800soc.c                 |   4 +
>  drivers/net/wireless/ralink/rt2x00/rt2800usb.c                 |   4 +
>  drivers/net/wireless/ralink/rt2x00/rt61pci.c                   |   4 +
>  drivers/net/wireless/ralink/rt2x00/rt73usb.c                   |   4 +
>  drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c             |   4 +
>  drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c             |   4 +
>  drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c          |   4 +
>  drivers/net/wireless/realtek/rtlwifi/core.c                    |   4 +
>  drivers/net/wireless/realtek/rtw88/mac80211.c                  |   4 +
>  drivers/net/wireless/realtek/rtw89/core.c                      |   7 +-
>  drivers/net/wireless/rsi/rsi_91x_mac80211.c                    |   4 +
>  drivers/net/wireless/st/cw1200/main.c                          |   4 +
>  drivers/net/wireless/ti/wl1251/main.c                          |   4 +
>  drivers/net/wireless/virtual/mac80211_hwsim.c                  |   4 +
>  drivers/net/wireless/zydas/zd1211rw/zd_mac.c                   |   4 +
>  drivers/staging/vt6655/device_main.c                           |   4 +
>  drivers/staging/vt6656/main_usb.c                              |   4 +
>  include/net/mac80211.h                                         |  13 ++
>  net/mac80211/cfg.c                                             |  42 +++----
>  net/mac80211/chan.c                                            | 111 +++--------------
>  net/mac80211/ieee80211_i.h                                     |   9 +-
>  net/mac80211/iface.c                                           |   6 +-
>  net/mac80211/main.c                                            | 205 +++++++++++++++++++++++++------
>  net/mac80211/mlme.c                                            |   3 +-
>  net/mac80211/offchannel.c                                      |  21 ++--
>  net/mac80211/scan.c                                            |  18 +--
>  net/mac80211/tx.c                                              |   2 -
>  net/mac80211/util.c                                            |  27 ++--
>  58 files changed, 444 insertions(+), 207 deletions(-)
> 
> $ git bisect log
> git bisect start
> # Status: warte auf guten und schlechten Commit
> # bad: [a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6] Linux 6.9
> git bisect bad a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6
> # Status: warte auf gute(n) Commit(s), schlechter Commit bekannt
> # good: [e8f897f4afef0031fe618a8e94127a0934896aba] Linux 6.8
> git bisect good e8f897f4afef0031fe618a8e94127a0934896aba
> # bad: [480e035fc4c714fb5536e64ab9db04fedc89e910] Merge tag 'drm-next-2024-03-13' of https://gitlab.freedesktop.org/drm/kernel
> git bisect bad 480e035fc4c714fb5536e64ab9db04fedc89e910
> # bad: [9187210eee7d87eea37b45ea93454a88681894a4] Merge tag 'net-next-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
> git bisect bad 9187210eee7d87eea37b45ea93454a88681894a4
> # bad: [9187210eee7d87eea37b45ea93454a88681894a4] Merge tag 'net-next-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
> git bisect bad 9187210eee7d87eea37b45ea93454a88681894a4
> # good: [a01c9fe32378636ae65bec8047b5de3fdb2ba5c8] Merge tag 'nfsd-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux
> git bisect good a01c9fe32378636ae65bec8047b5de3fdb2ba5c8
> # bad: [ca61ba3885274a684c83d8a538eb77b30e38ee92] Merge branch 'rework-genet-mdioclocking'
> git bisect bad ca61ba3885274a684c83d8a538eb77b30e38ee92
> # good: [f42822f22b1c5f72c7e3497d9683f379ab0c5fe4] bnxt_en: Use firmware provided maximum filter counts.
> git bisect good f42822f22b1c5f72c7e3497d9683f379ab0c5fe4
> # bad: [e10cd2ddd89e8b3e61b49247067e79f7debec2f1] wifi: rtw89: load BB parameters to PHY-1
> git bisect bad e10cd2ddd89e8b3e61b49247067e79f7debec2f1
> # good: [2594e4d9e1a2d79bf7bb262974abaf5ef153e371] wifi: iwlwifi: prepare for reading SAR tables from UEFI
> git bisect good 2594e4d9e1a2d79bf7bb262974abaf5ef153e371
> # bad: [719036ae06d4bfdb65139e3947a8404dec298bc5] wifi: cfg80211: move puncturing validation code
> git bisect bad 719036ae06d4bfdb65139e3947a8404dec298bc5
> # good: [1209f487d452ff7e822dec30661fd6b5163fb8cf] wifi: rtl8xxxu: Add TP-Link TL-WN823N V2
> git bisect good 1209f487d452ff7e822dec30661fd6b5163fb8cf
> # good: [4dbd964f33aab6f99891b9610ad4b36cc215be0d] wifi: rtw89: 8922a: add chip_ops::rfk_hw_init
> git bisect good 4dbd964f33aab6f99891b9610ad4b36cc215be0d
> # good: [2fd53eb04c492eb9a2b06f994b36e5cf34ba7541] wifi: mac80211: remove unused MAX_MSG_LEN define
> git bisect good 2fd53eb04c492eb9a2b06f994b36e5cf34ba7541
> # bad: [0a44dfc070749514b804ccac0b1fd38718f7daa1] wifi: mac80211: simplify non-chanctx drivers
> git bisect bad 0a44dfc070749514b804ccac0b1fd38718f7daa1
> # good: [61f0261131c8dc2beeb6b34781a54788221081e9] wifi: mac80211: clean up band switch in duration
> git bisect good 61f0261131c8dc2beeb6b34781a54788221081e9
> # good: [2d9698dd32d086e47b8bff3df4322cc017c17b55] wifi: mac80211: clean up HE 6 GHz and EHT chandef parsing
> git bisect good 2d9698dd32d086e47b8bff3df4322cc017c17b55
> # first bad commit: [0a44dfc070749514b804ccac0b1fd38718f7daa1] wifi: mac80211: simplify non-chanctx drivers

That's all correct.

Johannes suggested that we should set hw->wiphy->retry_{long,short}
before ieee80211_register_hw(). So that would go in
_rtl_init_mac80211(). That has the added benefit of making the
true retry limits visible to userspace ("iw phy").

The problem is that setting hw->wiphy->retry_{long,short} is
not enough. rtlwifi still gets the default retry limits of 4
and 7, because ieee80211_register_hw() doesn't set
hw->conf.long_frame_max_tx_count (and hw->conf.short_frame_max_tx_count).
Johannes suggested moving this code from ieee80211_alloc_hw_nm()
to ieee80211_register_hw():

	local->hw.conf.long_frame_max_tx_count = wiphy->retry_long;
	local->hw.conf.short_frame_max_tx_count = wiphy->retry_short;

I didn't do this yet partly because I don't want to compile
the entire kernel, and partly because I'm not sure how to handle
the different retry limits for AP/IBSS mode and station mode.

Can we change hw->wiphy->retry_{long,short} any time, not just
before ieee80211_register_hw()? If yes, what is even the point
of hw->conf.{short,long}_frame_max_tx_count ? It would be simpler
if we can ignore them and use hw->wiphy->retry_{long,short}
directly.

What do y'all think?
Ping-Ke Shih May 28, 2024, 2:02 a.m. UTC | #4
Stefan Lippers-Hollmann <s.l-h@gmx.de> wrote:
> 
> Again, rtl8192du v7 itself is 'fine' and could (can) achieve 180/100
> MBit/s before the chanctx changes, so merging v7 might be okay - but
> there needs to be a fix for rtlwifi as a whole (and maybe even other
> drivers) for v6.9+ and the chanctx changes that came with it (not
> every chipset supported by rtlwifi might be affected equally badly,
> e.g. rtl8192cu might not noticeably be, according to Bitterblue's
> testing).
> 
> So with the (performance/ packet loss) caveat above:
> 
> Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>

Thanks for your test and additional information. I will merge v7.
Ping-Ke Shih May 28, 2024, 2:39 a.m. UTC | #5
Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> Johannes suggested that we should set hw->wiphy->retry_{long,short}
> before ieee80211_register_hw(). So that would go in
> _rtl_init_mac80211(). That has the added benefit of making the
> true retry limits visible to userspace ("iw phy").
> 
> The problem is that setting hw->wiphy->retry_{long,short} is
> not enough. rtlwifi still gets the default retry limits of 4
> and 7, because ieee80211_register_hw() doesn't set
> hw->conf.long_frame_max_tx_count (and hw->conf.short_frame_max_tx_count).
> Johannes suggested moving this code from ieee80211_alloc_hw_nm()
> to ieee80211_register_hw():
> 
>         local->hw.conf.long_frame_max_tx_count = wiphy->retry_long;
>         local->hw.conf.short_frame_max_tx_count = wiphy->retry_short;
> 
> I didn't do this yet partly because I don't want to compile
> the entire kernel, and partly because I'm not sure how to handle
> the different retry limits for AP/IBSS mode and station mode.
> 
> Can we change hw->wiphy->retry_{long,short} any time, not just
> before ieee80211_register_hw()? If yes, what is even the point
> of hw->conf.{short,long}_frame_max_tx_count ? It would be simpler
> if we can ignore them and use hw->wiphy->retry_{long,short}
> directly.
> 
> What do y'all think?

Logically I think you can change hw->wiphy->retry_{long,short} any time,
because cfg80211/mac80211 seemingly just bypass the values to driver. 

One thing is that should we honor the values set by user space?
But we can't know if user space has set the value, right?

If user space has not set, driver wants to control this value by itself
according to AP/IBSS/station modes.
If user space has set, driver fully follows the value from user space.
Is above the behavior you want?
Johannes Berg May 28, 2024, 6:59 a.m. UTC | #6
On Tue, 2024-05-28 at 02:39 +0000, Ping-Ke Shih wrote:
> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> > Johannes suggested that we should set hw->wiphy->retry_{long,short}
> > before ieee80211_register_hw(). So that would go in
> > _rtl_init_mac80211(). That has the added benefit of making the
> > true retry limits visible to userspace ("iw phy").
> > 
> > The problem is that setting hw->wiphy->retry_{long,short} is
> > not enough. rtlwifi still gets the default retry limits of 4
> > and 7, because ieee80211_register_hw() doesn't set
> > hw->conf.long_frame_max_tx_count (and hw->conf.short_frame_max_tx_count).
> > Johannes suggested moving this code from ieee80211_alloc_hw_nm()
> > to ieee80211_register_hw():
> > 
> >         local->hw.conf.long_frame_max_tx_count = wiphy->retry_long;
> >         local->hw.conf.short_frame_max_tx_count = wiphy->retry_short;

Right, so I suggested that because then driver changes between alloc and
register can take effect rather than being overwritten, and these are
the retry limits that are actually visible to userspace.

> > I didn't do this yet partly because I don't want to compile
> > the entire kernel, and partly because I'm not sure how to handle
> > the different retry limits for AP/IBSS mode and station mode.
> > 
> > Can we change hw->wiphy->retry_{long,short} any time, not just
> > before ieee80211_register_hw()? If yes, what is even the point
> > of hw->conf.{short,long}_frame_max_tx_count ? It would be simpler
> > if we can ignore them and use hw->wiphy->retry_{long,short}
> > directly.
> > 
> > What do y'all think?
> 
> Logically I think you can change hw->wiphy->retry_{long,short} any time,
> because cfg80211/mac80211 seemingly just bypass the values to driver. 

Not quite, I think there's some additional layer of thing in mac80211?

> But we can't know if user space has set the value, right?

You can't check from the value, but that's why I said to change the
defaults before registering etc.

> One thing is that should we honor the values set by user space?
> 
> If user space has not set, driver wants to control this value by itself
> according to AP/IBSS/station modes.
> If user space has set, driver fully follows the value from user space.
> Is above the behavior you want?

Honestly, is it? I think most drivers these days probably ignore the
values from userspace for lesser reasons (e.g. iwlwifi always has a
firmware-internal limit of 16 IIRC.)

This API also comes from the dawn of wireless in Linux, and was just
ported from wireless extensions to nl80211. So I wouldn't feel too bad
about simply ignoring it either.

johannes
Ping-Ke Shih May 28, 2024, 8:41 a.m. UTC | #7
Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2024-05-28 at 02:39 +0000, Ping-Ke Shih wrote:
> > One thing is that should we honor the values set by user space?
> >
> > If user space has not set, driver wants to control this value by itself
> > according to AP/IBSS/station modes.
> > If user space has set, driver fully follows the value from user space.
> > Is above the behavior you want?
> 
> Honestly, is it? I think most drivers these days probably ignore the
> values from userspace for lesser reasons (e.g. iwlwifi always has a
> firmware-internal limit of 16 IIRC.)
> 
> This API also comes from the dawn of wireless in Linux, and was just
> ported from wireless extensions to nl80211. So I wouldn't feel too bad
> about simply ignoring it either.

Agree. My thought was limited to have the same behavior as rtlwifi was.
Ignoring handle of IEEE80211_CONF_CHANGE_RETRY_LIMITS would be simpler.

Ping-Ke
diff mbox series

Patch

diff --git a/drivers/net/wireless/realtek/rtlwifi/Kconfig b/drivers/net/wireless/realtek/rtlwifi/Kconfig
index cfe63f7b28d9..1e66c1bf7c8b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/Kconfig
+++ b/drivers/net/wireless/realtek/rtlwifi/Kconfig
@@ -119,6 +119,18 @@  config RTL8192CU
 
 	If you choose to build it as a module, it will be called rtl8192cu
 
+config RTL8192DU
+	tristate "Realtek RTL8192DU USB Wireless Network Adapter"
+	depends on USB
+	select RTLWIFI
+	select RTLWIFI_USB
+	select RTL8192D_COMMON
+	help
+	This is the driver for Realtek RTL8192DU 802.11n USB
+	wireless network adapters.
+
+	If you choose to build it as a module, it will be called rtl8192du
+
 config RTLWIFI
 	tristate
 	select FW_LOADER
diff --git a/drivers/net/wireless/realtek/rtlwifi/Makefile b/drivers/net/wireless/realtek/rtlwifi/Makefile
index 423981b148df..9cf32277c7f1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/Makefile
+++ b/drivers/net/wireless/realtek/rtlwifi/Makefile
@@ -25,6 +25,7 @@  obj-$(CONFIG_RTL8192CU)		+= rtl8192cu/
 obj-$(CONFIG_RTL8192SE)		+= rtl8192se/
 obj-$(CONFIG_RTL8192D_COMMON)	+= rtl8192d/
 obj-$(CONFIG_RTL8192DE)		+= rtl8192de/
+obj-$(CONFIG_RTL8192DU)		+= rtl8192du/
 obj-$(CONFIG_RTL8723AE)		+= rtl8723ae/
 obj-$(CONFIG_RTL8723BE)		+= rtl8723be/
 obj-$(CONFIG_RTL8188EE)		+= rtl8188ee/
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192du/Makefile b/drivers/net/wireless/realtek/rtlwifi/rtl8192du/Makefile
new file mode 100644
index 000000000000..569bfd3d5030
--- /dev/null
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192du/Makefile
@@ -0,0 +1,13 @@ 
+# SPDX-License-Identifier: GPL-2.0
+rtl8192du-objs :=		\
+		dm.o		\
+		fw.o		\
+		hw.o		\
+		led.o		\
+		phy.o		\
+		rf.o		\
+		sw.o		\
+		table.o		\
+		trx.o
+
+obj-$(CONFIG_RTL8192DU) += rtl8192du.o