RTL8192CU: re-enable the upstream rtl8192cu driver

[clivem]

This is a RFC rather than a PR. Please read the commit comments.

The patch results in both the vendor 8192cu driver and upstream rtl8192cu driver being built.

Can the guys who want the hostapd, wi-fi repeater functionality, and a driver using upstream cfg80211/nl80211, please test with rtl8192cu driver..... @fran6co @MrEngman

Commit comments below.........

Continue building the Realtek vendor (8192cu) driver.

Vendor driver now using CONFIG_RTL8192CU_VENDOR.

Add CONFIG_RTL_CARDS=m and CONFIG_RTL8192CU_VENDOR=m to the
default RPi kernel configs.

Suggest adding /etc/modprobe.d/blacklist-rtl8192cu.conf, containing
text "blacklist rtl8192cu" on the distribution, to blacklist rtl8192cu
so 8192cu remains the default driver for RTL8188CUS and RTL8192CU
based dongles.

Initial testing with rtl8192cu driver of single channel 20MHz 8188's
and dual channel 40MHz 8192's suggest that several issues from the
past are no longer issues, including the death spiral, (whereby sync
speed gets reduced but never increased), and throughput is much better.

Suggest that vendor driver should be left using the built-in cfg80211
and people wishing to use recent version of hostapd, (rather than the
Realtek version that was shipped with the out-of-tree vendor driver),
should switch to using rtl8192cu driver and blacklist 8192cu driver.

[popcornmix]

Ping @XECDesign

Can we create a file /etc/modprobe.d/blacklist-rtl8192cu.conf containing blacklist rtl8192cu
to stop the upstream driver from being used when doing an apt-get dist-upgrade or with a new image. Currently that will have no effect, as rtl8192cu is not built.

After a while we'll start building the upstream driver (which will be disabled by default), but users will have the choice to change the blacklist to blacklist 8192cu to switch to the upstream driver. Eventually if testing of the upstream is positive for the majority of testers, we may be able to drop the out-of-tree driver.

[popcornmix]

More discussion about this is here: #1489

[clivem]

With the upstream (rtl8192cu) driver, I've been continually streaming DSD (ie. 64x 44k1 CD) to 2x 8192cu dongled Pi's for ~10 hours, connected to the same AP. All looks good. Still playing music without any stuttering.

[clivem]

@popcornmix I was tempted to add, CONFIG_RTL8XXXU=m, and CONFIG_RTL8XXXU_UNTESTED=y to the patch and suggest also adding a blacklist-rtl8xxxu.conf.

With CONFIG_RTL8XXXU_UNTESTED, the USB ID's for the 8188CUS's and 8192CU's are added to the rtl8xxxu driver, which offers a third driver option for the 8188CUS and 8192CU. I think the Jes Sorensen (of RedHat) rtl8xxxu driver is going to shake-out as the way forward for these 8188/8192 dongles. It is being actively developed..... but still lacks dual channel 40MHz support IIRC, so throughput is limited at the moment for people with 40MHz capable hardware.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/net/wireless/realtek/rtl8xxxu

In any case you should probably add CONFIG_RTL8XXXU=m (without the UNTESTED option) to the default RPi builds, so that support is added for people with RTL8723AU chipset dongles. Not that I have tested that myself, but I know a man who has, successfully. ;)

[MrEngman]

@clivem Just tried the rtl8192cu driver again and the same issue still exists as I mentioned in #1488 or #1489 with the wifi LED being permanently on. Previously I used an Edimax EW-7811Un, but this time tried with a Micronet SP907NS which uses the 8188cus chipset and the LED is again permanently on. Not something I like so I think I'll be sticking with the 8192cu driver for the moment ;)

Tried the 8192cu driver with just the #1488 patch and then with both #1488 and #1489 patches and had no problems with either configuration but I don't use Network Manager. Tried the EW-7811Un with just #1488 and both the EW-7811Un and SP907NS using #1488 and #1489.

I usually use raspbian jessie lite and connect via SSH from a W7 laptop.

Which image were you having problems with Network Manager? Just curious but would like to try it if possible to see what happens.

[clivem]

with the wifi LED being permanently on

That's a "feature" of the upstream rtl8192cu driver. The LED doesn't flash due to traffic, as it does with vendor 8192cu driver, it's just lit permanently.

Which image were you having problems with Network Manager?

I use Fedora as a base. I don't even know if Raspbian/Debian uses NetworkManager, but several other distros do.

Right now, from my POV, #1489 patch needs to be reverted. #1488, 9 patch series, which I don't think @popcornmix applied yet, is OK. That's mostly compiler warnings dealt with. Innocuous, no big deal... It's the deliberate change to system cfg80211/n180211, from #1489, that's causing the "8192cu driver incompatible with being MANAGED by NetworkManager" issue for me.

[fran6co]

I think the issue with NetworkManager is fixed by #1488 as it fixes pvaret/rtl8192cu-fixes#23 with 0a71af8

[clivem]

I think the issue with NetworkManager is fixed

Well, you think wrong! ;)

As I indicated to @popcornmix in my comment, #1488 (comment), I was already applying that patch set before I encountered #1489

[fran6co]

did you try both PRs together?

[clivem]

did you try both PRs together?

Yes. I hope to have time next week to get to the bottom of what the issue is. But in one conversation I have had already about this, it was "suggested" that the external cfg80211 that you enabled with that #1489 patch, isn't fully implemented in the Realtek code you enabled.

[MrEngman]

One thing I found strange. With the 8192cu driver lsmod shows

Module                  Size  Used by
8192cu                569295  0
cfg80211              427855  1 8192cu
sg                     18319  0
rfkill                 16037  2 cfg80211
snd_bcm2835            20511  0
snd_pcm                75698  1 snd_bcm2835
snd_timer              19160  1 snd_pcm
bcm2835_gpiomem         3040  0
bcm2835_wdt             3225  0
snd                    51844  3 snd_bcm2835,snd_timer,snd_pcm
uio_pdrv_genirq         3164  0
uio                     8000  1 uio_pdrv_genirq
ipv6                  347530  26

But with the rtl8192cu driver lsmod shows

Module                  Size  Used by
sha256_generic          9327  1
hmac                    2959  1
drbg                   13648  1
ctr                     3757  1
ccm                     8240  1
arc4                    1958  2
rtl8192cu              88577  0
rtl_usb                12828  1 rtl8192cu
rtl8192c_common        58401  1 rtl8192cu
rtlwifi                85402  3 rtl_usb,rtl8192c_common,rtl8192cu
mac80211              532034  3 rtl_usb,rtlwifi,rtl8192cu
cfg80211              427855  2 mac80211,rtlwifi
sg                     18319  0
rfkill                 16037  2 cfg80211
snd_bcm2835            20511  0
snd_pcm                75698  1 snd_bcm2835
snd_timer              19160  1 snd_pcm
snd                    51844  3 snd_bcm2835,snd_timer,snd_pcm
bcm2835_gpiomem         3040  0
bcm2835_wdt             3225  0
uio_pdrv_genirq         3164  0
uio                     8000  1 uio_pdrv_genirq
ipv6                  347530  26

whatever those differences may indicate.

[clivem]

whatever those differences may indicate.

That just indicates what we already know. That the vendor driver has 500k's worth of "private" static crap (ie. their own versions of kernel functionality) compiled in, rather than using kernel system modules. ;)

[fran6co]

@clivem The support is complete from what I could see and I didn't have any problem so far. I'm downloading an image with NetworkManager by default to check it out. I agree that if this patch is breaking the wifi it should be reverted back until a fix is submitted.

[clivem]

@fran6co If you have time to look at this before me.... I suspect what is important is who is creating the actual wlan0 network interface and when it is created. ie. it needs to be created when the driver module loads and before NetworkManager starts.

[fran6co]

@clivem the interface is created, when I run ip link the interface is there even when I don't setup anything in the /etc/network/interfaces. I think the problem is that NetworkManager doesn't recognise it for some reason. I'll know more about it when I get Fedora in some Pi to test it out.

[clivem]

Hmmmm. The interface wasn't being created by default. I could force it to be created by running a standalone wpa_supplicant with "-iwlan0", then it magically appears after that is started, but that isn't really a solution. But it might give you a clue.....

[fran6co]

That means that NetworkManager is filtering it out for some reason that's why I was pointing to the other fix. Maybe there is some other missing attribute that NetworkManager needs.

[clivem]

I'm really nervous about any "big" changes, other than to fix compiler warnings to that Realtek vendor code. It's old, crusty, unmaintained and wouldn't surprise me if there are other as yet other unforeseen consequences from such a change. ;)

[clivem]

That means that NetworkManager is filtering it out for some reason that's why I was pointing to the other fix. Maybe there is some other missing attribute that NetworkManager needs.

Hmmm. I think if the interface was created by the driver as it used to be, NetworkManager would see it and MANAGE it. But I'm guessing. I really haven't had time to look at this and probably won't until the middle of next week.

[fran6co]

Interface is there as demonstrated by you running the wpa_supplicant, the
problem is that NetworkManager is not seeing it. I'll work on it this
weekend.
On sáb, 11 de jun de 2016 at 16:09 Clive Messer [email protected]
wrote:

That means that NetworkManager is filtering it out for some reason that's
why I was pointing to the other fix. Maybe there is some other missing
attribute that NetworkManager needs.

Hmmm. I think if the interface was created by the driver as it used to be,
NetworkManager would see it and MANAGE it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1525 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAsUSFBf9snTBRhg4mY5WnwVRfKUkx8uks5qKwfrgaJpZM4Izh05
.

[clivem]

@fran6co Back to topic, does upstream rtl8192cu driver work for whatever you need it to, your use case.... hostapd, or whatever else you are using for your wi-fi repeater?

[fran6co]

No, I need in addition to the cfg80211 the concurrent feature of the
Realtek driver that lets me use a single dongle as a client and as a router
at the same time.
On sáb, 11 de jun de 2016 at 16:57 Clive Messer [email protected]
wrote:

@fran6co https://github.com/fran6co Back to topic, does rtl8192cu
driver work for whatever you need it to, you use case.... hostapd, or
whatever else you are using for your wi-fi repeater?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1525 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAsUSK_IQBZYoVyEYU2lm3Po2xECYe2Qks5qKxM4gaJpZM4Izh05
.

[clivem]

I need in addition to the cfg80211 the concurrent feature of the Realtek driver

That's a shame. It would have nice to be able to think, going into the future, we could "drop" the "vendor" driver.

[fran6co]

Yeah, it would be nice to kill the realtek driver. Wish I knew a bit more about driver programming to actually help out with it.

[fran6co]

Fixed NetworkManager issue in #1488

[clivem]

Note to self..... I'm not sure that moving the general population to the upstream rtl8192cu driver is a realistic proposition. Further testing has "forced" the reproduction of the death spiral issue, which can be hastened by placing the dongled Pi very close (less than 1m) from the AP. SGI also still an issue. The "require advanced functionality" guys, not been able to use the single wifi interface as both client and server, for repeater with upstream driver........ I seriously doubt Larry Wall is going to be interested in adding any new functionality to this driver. ;) When not using PRO (ie. Cisco, Mikrotik) AP gear, instead using the usual crap router/AP (BT Home Hub, Technicolor, Sagem) that is provided by most ISP's when you take a broadband connection, having a single client connected with upstream rtl8192cu driver, seems to sabotage the throughput of anything else connected to that AP. (Possibly related to SGI compatibility. ISTR, that it is a 10% performance hit on 'n' without SGI.)

[popcornmix]

Yes, I'm not confident the upstream driver is good enough.
Building and blacklisting it should be safe though and will allow people who want to try it to try it.
Maybe it will get there...

[clivem]

Building and blacklisting it should be safe though and will allow people who want to try it to try it.

Yep, agreed. Should definitely do that. I guess I'm just saying that what for me started out to be the most positive testing experience I've ever had with rtl8912cu on Fri/Sat, has descended back to the uncomfortable place I was in a year ago, having placed an order for several hundred generic OEM'd RTL8188CUS dongles, and I don't think it is realistic to think that the "crusty vendor driver" is ever going to be retired, in favour of the upstream rtl8192cu. I doubt upstream rtl8192cu it is ever going to see anything more than the odd one line change, to keep it "working".

Maybe it will get there...

I think our best hope is that rtl8xxxu driver, which is being actively developed by the RedHat guy. On the basis that it isn't even turned-on in the current builds..... More and more, my thinking is to add a blacklist-rtl8xxxu.conf for that to the distro as well, and at the point you start building upstream rtl8192cu, also build rtl8xxxu with CONFIG_RTL8XXXU=m, and CONFIG_RTL8XXXU_UNTESTED=y.

[fran6co]

I think the realtek crusty vendor driver can be refactored and polished a lot, realtek uses the same code base for all its drivers so there are a lot of fixes a new features that can be pulled from there. That's why I was advocating #1468 (comment) and pvaret/rtl8192cu-fixes#89 for creating an out of tree module for this and get patches and fixes from all the people that use this driver. You can still bundle it using git submodule feature so you don't have to change anything in the way you build Raspberry's kernel (maybe add a --recursive to the git command that downloads the code)

[dlech]

I would like to be able to share this code with ev3dev. We distribute Debian for LEGO MINDSTORMS EV3. The EV3 has limited resources (300MHz armel, 64MB RAM), so using DKMS is really not an option, it takes way too long to compile on the device. We also support a BeagleBone based device, so I would like to patch this into the BeagleBone kernel as well.

In the past, we distributed this driver as a separate debian package that was released alongside the kernel package. The downside to this is that people who want to compile their own kernel then also have to figure out how to compile the extra package against their own kernel, otherwise they lose wifi. So, we started building it in-tree like what is done here for the RPi kernel.

Using submodules is annoying, but we already do it for some other drivers we share between EV3, Raspberry Pi and BeagleBone. I am willing to put up with submodules, but I think there would be many people in RPi land that would be opposed to the idea. There is also git subtree, but it has shortcomings as well. It's unfortunate there is not a simpler way to share this code.

[clivem]

OK, taking a step back, at the point someone is going to take ownership, or maintainership, or call it whatever you will of the vendor driver, we need to deal with the trust thing first, not the mechanism by which multiple parties are all going to build from the same code base. I trust @popcornmix not to pull changes from fools who have even less of a clue about what they are doing than I do, and that the 8192cu driver will continue working for my use case on Pi as it has done for the last 2 years. The problem with shared code bases is that different people have different priorities...... What one person considers an essential change, might not be considered to be so by all the parties, eg. when it results in breaking something that used to work. It's why forks happen......
I doubt the Pi people will want to give-up veto over any code, they have made the decision to include and distribute in the downstream kernel and have therefore taken responsibility for, without being certain that it isn't going to come back and bite them in the backside. Which was why I was suggesting that it might be better to hack on the vendor driver, call it something else, and leave the Realtek vendor code already in the Pi kernel alone, unless it is an essential fix, or some interface in the kernel changes and the vendor code has to be "tweaked" to even get it to compile.....

[fran6co]

Thanks for the feedback @dlech. I think there are other IoT devices that could benefit from this even if they are not using it at the moment.
Regardless of that the only dkms that I could find is for Arch https://aur.archlinux.org/packages/8192cu-dkms I guess it's not being used that much in general but I have seen a lot of people installing it manually with dkms because they had problems with the upstream driver so I think the interest is there.
The Raspberry community is a big user of this crappy driver as you said, enabling others to use it as well could benefit more users than the other way around.

[fran6co]

@clivem you wouldn't need to sacrifice the stability if raspberry created the repository, it would have to go through a PR and being accepted by the current kernel maintainers. I think the cfg80211 change it wasn't just a nice thing to have or essential for a minority of people, being able to use modern tools to manage the wifi makes it easier for the community in general to give support and have the driver working for a bit longer.

[clivem]

I so much want to tell you a story, but I can't because of a NDA......

I personally think your time would be better spent trying to help add functionality to the rtl8xxxu driver, at the point you want to work on wifi driver code. This Realtek driver is a legacy thing. Use it while it carries on working, but don't waste precious resources on it. The community should make sure they have their own, Open Source driver that supports all the functionality they need, by the time the rest of the nails have been driven into its coffin!

[fran6co]

Yeah, I totally agree with you. I wish it were a lot easier to fix all the issues with the Open Source driver instead of hacking this crappy driver.

[clivem]

Well, if I were you and that concurrent behaviour was important to me, I'd try talking to Jes Sorensen about it and whether he has any plans to implement it in the rt8xxxu driver. If he does, great. If not, there's a project for you!

[fran6co]

Thanks, I didn't think about it. I'll drop him a line

[howardqiao]

BTW,I've tested the rtl8723bu driver based on rpi-4.6.y branch,(CONFIG_RTL8XXXU=m, and CONFIG_RTL8XXXU_UNTESTED=y) the kernel can recognize the device ,but can't find any SSID,there is no any signal.Instead ,this driver (https://www.github.com/lwfinger/8723bu) is the right driver, with the driver i can sucessfully enable rtl8723bu and connet to any SSID,rtl8723bu is a single chip solution of WIfi & Bluetooth 4.0,it's a good product for old PIs, Linux kernel 4.6 has added the driver.I'll try 8129cu later.

[clivem]

@popcornmix Is there a reason why rpi-4.7.y rtl8192cu vendor driver doesn't include any of the 3x @fran6co rpi-4.4.y commits? It's really frustrating trying to figure these things out, when trees have been rebased and squashed, and revision history is lost.......

[popcornmix]

#1488 applied (with trivial fix) and builds okay. #1489 applies but doesn't build. Looks like IEEE80211_BAND_2GHZ/IEEE80211_BAND_5GHZ no longer exist.

[fran6co]

The IEEE80211_BAND_2GHZ/IEEE80211_BAND_5GHZ seems easy to fix, they should be replaced by NL80211_BAND_2GHZ/NL80211_BAND_5GHZ. I don't have a Pi at hand to actually test it in the near future.

[fran6co]

I have the patch ready but I can't test it:

diff --git a/drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c b/drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c
index 682cb00..68ea301 100644
--- a/drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c
+++ b/drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c
@@ -49,6 +49,17 @@ static const u32 rtw_cipher_suites[] = {
 #endif //CONFIG_IEEE80211W
 };

+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 7, 0)
+enum ieee80211_band {
+        IEEE80211_BAND_2GHZ = NL80211_BAND_2GHZ,
+        IEEE80211_BAND_5GHZ = NL80211_BAND_5GHZ,
+        IEEE80211_BAND_60GHZ = NL80211_BAND_60GHZ,
+
+        /* keep last */
+        IEEE80211_NUM_BANDS
+};
+#endif
+
 #define RATETAB_ENT(_rate, _rateid, _flags) \
        {                                   \
            .bitrate        = (_rate),                  \

[popcornmix]

@fran6co there seem to be additional issues:

drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c: In function 'rtw_spt_band_free':
drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c:240:20: warning: comparison between 'enum nl80211_band' and 'enum ieee80211_band' [-Wenum-compare]
  if(spt_band->band == IEEE80211_BAND_2GHZ)
                    ^
drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c:246:25: warning: comparison between 'enum nl80211_band' and 'enum ieee80211_band' [-Wenum-compare]
  else if(spt_band->band == IEEE80211_BAND_5GHZ)
                         ^
drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c: In function 'rtw_cfg80211_indicate_scan_done':
drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c:1829:4: error: incompatible type for argument 2 of 'cfg80211_scan_done'
    cfg80211_scan_done(pwdev_priv->scan_request, aborted);
    ^
In file included from drivers/net/wireless/realtek/rtl8192cu/include/osdep_service.h:793:0,
                 from drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c:23:
./include/net/cfg80211.h:4104:6: note: expected 'struct cfg80211_scan_info *' but argument is of type 'bool'
 void cfg80211_scan_done(struct cfg80211_scan_request *request,
      ^
scripts/Makefile.build:289: recipe for target 'drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.o' failed

[fran6co]

Uhm.. It's going to need break backward compatibility then. I'll make the patch.

[fran6co]

Discarding the other patch.

diff --git a/drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c b/drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c
index 682cb00..1d37ca2 100644
--- a/drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c
+++ b/drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c
@@ -57,7 +57,7 @@ static const u32 rtw_cipher_suites[] = {
        }

 #define CHAN2G(_channel, _freq, _flags) {              \
-       .band           = IEEE80211_BAND_2GHZ,      \
+       .band           = NL80211_BAND_2GHZ,        \
        .center_freq        = (_freq),              \
        .hw_value           = (_channel),           \
        .flags          = (_flags),             \
@@ -66,7 +66,7 @@ static const u32 rtw_cipher_suites[] = {
 }

 #define CHAN5G(_channel, _flags) {                 \
-       .band           = IEEE80211_BAND_5GHZ,      \
+       .band           = NL80211_BAND_5GHZ,        \
        .center_freq        = 5000 + (5 * (_channel)),      \
        .hw_value           = (_channel),           \
        .flags          = (_flags),             \
@@ -166,18 +166,18 @@ void rtw_5g_rates_init(struct ieee80211_rate *rates)
 }

 struct ieee80211_supported_band *rtw_spt_band_alloc(
-       enum ieee80211_band band
+       enum nl80211_band  band
        )
 {
        struct ieee80211_supported_band *spt_band = NULL;
        int n_channels, n_bitrates;

-       if(band == IEEE80211_BAND_2GHZ)
+       if(band == NL80211_BAND_2GHZ)
        {
            n_channels = RTW_2G_CHANNELS_NUM;
            n_bitrates = RTW_G_RATES_NUM;
        }
-       else if(band == IEEE80211_BAND_5GHZ)
+       else if(band == NL80211_BAND_5GHZ)
        {
            n_channels = RTW_5G_CHANNELS_NUM;
            n_bitrates = RTW_A_RATES_NUM;
@@ -201,12 +201,12 @@ struct ieee80211_supported_band *rtw_spt_band_alloc(
        spt_band->n_channels = n_channels;
        spt_band->n_bitrates = n_bitrates;

-       if(band == IEEE80211_BAND_2GHZ)
+       if(band == NL80211_BAND_2GHZ)
        {
            rtw_2g_channels_init(spt_band->channels);
            rtw_2g_rates_init(spt_band->bitrates);
        }
-       else if(band == IEEE80211_BAND_5GHZ)
+       else if(band == NL80211_BAND_5GHZ)
        {
            rtw_5g_channels_init(spt_band->channels);
            rtw_5g_rates_init(spt_band->bitrates);
@@ -226,13 +226,13 @@ void rtw_spt_band_free(struct ieee80211_supported_band *spt_band)
        if(!spt_band)
            return;

-       if(spt_band->band == IEEE80211_BAND_2GHZ)
+       if(spt_band->band == NL80211_BAND_2GHZ)
        {
            size = sizeof(struct ieee80211_supported_band)
                + sizeof(struct ieee80211_channel)*RTW_2G_CHANNELS_NUM
                + sizeof(struct ieee80211_rate)*RTW_G_RATES_NUM;
        }
-       else if(spt_band->band == IEEE80211_BAND_5GHZ)
+       else if(spt_band->band == NL80211_BAND_5GHZ)
        {
            size = sizeof(struct ieee80211_supported_band)
                + sizeof(struct ieee80211_channel)*RTW_5G_CHANNELS_NUM
@@ -301,12 +301,12 @@ static int rtw_ieee80211_channel_to_frequency(int chan, int band)
        /* see 802.11 17.3.8.3.2 and Annex J
        * there are overlapping channel numbers in 5GHz and 2GHz bands */

-       if (band == IEEE80211_BAND_5GHZ) {
+       if (band == NL80211_BAND_5GHZ) {
        if (chan >= 182 && chan <= 196)
                return 4000 + chan * 5;
              else
                     return 5000 + chan * 5;
-       } else { /* IEEE80211_BAND_2GHZ */
+       } else { /* NL80211_BAND_2GHZ */
            if (chan == 14)
                return 2484;
              else if (chan < 14)
@@ -391,9 +391,9 @@ static int rtw_cfg80211_inform_bss(_adapter *padapter, struct wlan_network *pnet
                        DBG_871X("%s, got sr, but ssid mismatch, to remove this bss\n", __func__);

                        if (pselect_network->Configuration.DSConfig <= RTW_CH_MAX_2G_CHANNEL)
-                           freq = rtw_ieee80211_channel_to_frequency(pselect_network->Configuration.DSConfig, IEEE80211_BAND_2GHZ);
+                           freq = rtw_ieee80211_channel_to_frequency(pselect_network->Configuration.DSConfig, NL80211_BAND_2GHZ);
                        else
-                           freq = rtw_ieee80211_channel_to_frequency(pselect_network->Configuration.DSConfig, IEEE80211_BAND_5GHZ);
+                           freq = rtw_ieee80211_channel_to_frequency(pselect_network->Configuration.DSConfig, NL80211_BAND_5GHZ);

                        notify_channel = ieee80211_get_channel(wiphy, freq);
                        pselect_bss = cfg80211_get_bss(wiphy, NULL/*notify_channel*/,
@@ -424,9 +424,9 @@ static int rtw_cfg80211_inform_bss(_adapter *padapter, struct wlan_network *pnet

        channel = pnetwork->network.Configuration.DSConfig;
        if (channel <= RTW_CH_MAX_2G_CHANNEL)
-           freq = rtw_ieee80211_channel_to_frequency(channel, IEEE80211_BAND_2GHZ);
+           freq = rtw_ieee80211_channel_to_frequency(channel, NL80211_BAND_2GHZ);
        else
-           freq = rtw_ieee80211_channel_to_frequency(channel, IEEE80211_BAND_5GHZ);
+           freq = rtw_ieee80211_channel_to_frequency(channel, NL80211_BAND_5GHZ);

        notify_channel = ieee80211_get_channel(wiphy, freq);

@@ -572,9 +572,9 @@ int rtw_cfg80211_check_bss(_adapter *padapter)
            return _FALSE;

        if (pnetwork->Configuration.DSConfig <= RTW_CH_MAX_2G_CHANNEL)
-           freq = rtw_ieee80211_channel_to_frequency(pnetwork->Configuration.DSConfig, IEEE80211_BAND_2GHZ);
+           freq = rtw_ieee80211_channel_to_frequency(pnetwork->Configuration.DSConfig, NL80211_BAND_2GHZ);
        else
-           freq = rtw_ieee80211_channel_to_frequency(pnetwork->Configuration.DSConfig, IEEE80211_BAND_5GHZ);
+           freq = rtw_ieee80211_channel_to_frequency(pnetwork->Configuration.DSConfig, NL80211_BAND_5GHZ);

        notify_channel = ieee80211_get_channel(padapter->rtw_wdev->wiphy, freq);
        bss = cfg80211_get_bss(padapter->rtw_wdev->wiphy, notify_channel,
@@ -633,9 +633,9 @@ void rtw_cfg80211_indicate_connect(_adapter *padapter)
            u16 channel = cur_network->network.Configuration.DSConfig;

            if (channel <= RTW_CH_MAX_2G_CHANNEL)
-               freq = rtw_ieee80211_channel_to_frequency(channel, IEEE80211_BAND_2GHZ);
+               freq = rtw_ieee80211_channel_to_frequency(channel, NL80211_BAND_2GHZ);
            else
-               freq = rtw_ieee80211_channel_to_frequency(channel, IEEE80211_BAND_5GHZ);
+               freq = rtw_ieee80211_channel_to_frequency(channel, NL80211_BAND_5GHZ);

            notify_channel = ieee80211_get_channel(wiphy, freq);
            #endif
@@ -3125,9 +3125,9 @@ void rtw_cfg80211_indicate_sta_assoc(_adapter *padapter, u8 *pmgmt_frame, uint f
 #else /* defined(RTW_USE_CFG80211_STA_EVENT) */
        channel = pmlmeext->cur_channel;
        if (channel <= RTW_CH_MAX_2G_CHANNEL)
-           freq = rtw_ieee80211_channel_to_frequency(channel, IEEE80211_BAND_2GHZ);
+           freq = rtw_ieee80211_channel_to_frequency(channel, NL80211_BAND_2GHZ);
        else
-           freq = rtw_ieee80211_channel_to_frequency(channel, IEEE80211_BAND_5GHZ);
+           freq = rtw_ieee80211_channel_to_frequency(channel, NL80211_BAND_5GHZ);

        #ifdef COMPAT_KERNEL_RELEASE
        rtw_cfg80211_rx_mgmt(padapter, freq, 0, pmgmt_frame, frame_len, GFP_ATOMIC);
@@ -3170,9 +3170,9 @@ void rtw_cfg80211_indicate_sta_disassoc(_adapter *padapter, unsigned char *da, u
 #else /* defined(RTW_USE_CFG80211_STA_EVENT) */
        channel = pmlmeext->cur_channel;
        if (channel <= RTW_CH_MAX_2G_CHANNEL)
-           freq = rtw_ieee80211_channel_to_frequency(channel, IEEE80211_BAND_2GHZ);
+           freq = rtw_ieee80211_channel_to_frequency(channel, NL80211_BAND_2GHZ);
        else
-           freq = rtw_ieee80211_channel_to_frequency(channel, IEEE80211_BAND_5GHZ);
+           freq = rtw_ieee80211_channel_to_frequency(channel, NL80211_BAND_5GHZ);

        pmgmt_frame = mgmt_buf;
        pwlanhdr = (struct rtw_ieee80211_hdr *)pmgmt_frame;
@@ -3999,9 +3999,9 @@ void rtw_cfg80211_rx_action_p2p(_adapter *padapter, u8 *pmgmt_frame, uint frame_

 indicate:
        if (channel <= RTW_CH_MAX_2G_CHANNEL)
-           freq = rtw_ieee80211_channel_to_frequency(channel, IEEE80211_BAND_2GHZ);
+           freq = rtw_ieee80211_channel_to_frequency(channel, NL80211_BAND_2GHZ);
        else
-           freq = rtw_ieee80211_channel_to_frequency(channel, IEEE80211_BAND_5GHZ);
+           freq = rtw_ieee80211_channel_to_frequency(channel, NL80211_BAND_5GHZ);

 #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,37)) || defined(COMPAT_KERNEL_RELEASE)
        rtw_cfg80211_rx_mgmt(padapter, freq, 0, pmgmt_frame, frame_len, GFP_ATOMIC);
@@ -4039,9 +4039,9 @@ void rtw_cfg80211_rx_p2p_action_public(_adapter *padapter, u8 *pmgmt_frame, uint

 indicate:
        if (channel <= RTW_CH_MAX_2G_CHANNEL)
-           freq = rtw_ieee80211_channel_to_frequency(channel, IEEE80211_BAND_2GHZ);
+           freq = rtw_ieee80211_channel_to_frequency(channel, NL80211_BAND_2GHZ);
        else
-           freq = rtw_ieee80211_channel_to_frequency(channel, IEEE80211_BAND_5GHZ);
+           freq = rtw_ieee80211_channel_to_frequency(channel, NL80211_BAND_5GHZ);

 #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,37)) || defined(COMPAT_KERNEL_RELEASE)
        rtw_cfg80211_rx_mgmt(padapter, freq, 0, pmgmt_frame, frame_len, GFP_ATOMIC);
@@ -4069,9 +4069,9 @@ void rtw_cfg80211_rx_action(_adapter *adapter, u8 *frame, uint frame_len, const
            DBG_871X("RTW_Rx:category(%u), action(%u)\n", category, action);

        if (channel <= RTW_CH_MAX_2G_CHANNEL)
-           freq = rtw_ieee80211_channel_to_frequency(channel, IEEE80211_BAND_2GHZ);
+           freq = rtw_ieee80211_channel_to_frequency(channel, NL80211_BAND_2GHZ);
        else
-           freq = rtw_ieee80211_channel_to_frequency(channel, IEEE80211_BAND_5GHZ);
+           freq = rtw_ieee80211_channel_to_frequency(channel, NL80211_BAND_5GHZ);

 #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,37)) || defined(COMPAT_KERNEL_RELEASE)
        rtw_cfg80211_rx_mgmt(adapter, freq, 0, frame, frame_len, GFP_ATOMIC);
@@ -5258,7 +5258,7 @@ static struct cfg80211_ops rtw_cfg80211_ops = {
 #endif
 };

-static void rtw_cfg80211_init_ht_capab(struct ieee80211_sta_ht_cap *ht_cap, enum ieee80211_band band, u8 rf_type)
+static void rtw_cfg80211_init_ht_capab(struct ieee80211_sta_ht_cap *ht_cap, enum nl80211_band  band, u8 rf_type)
 {

 #define MAX_BIT_RATE_40MHZ_MCS15       300     /* Mbps */
@@ -5282,7 +5282,7 @@ static void rtw_cfg80211_init_ht_capab(struct ieee80211_sta_ht_cap *ht_cap, enum
        ht_cap->mcs.tx_params = IEEE80211_HT_MCS_TX_DEFINED;

        /*
-        *hw->wiphy->bands[IEEE80211_BAND_2GHZ]
+        *hw->wiphy->bands[NL80211_BAND_2GHZ]
         *base on ant_num
         *rx_mask: RX mask
         *if rx_ant =1 rx_mask[0]=0xff;==>MCS0-MCS7
@@ -5327,16 +5327,16 @@ void rtw_cfg80211_init_wiphy(_adapter *padapter)

        /* if (padapter->registrypriv.wireless_mode & WIRELESS_11G) */
        {
-           bands = wiphy->bands[IEEE80211_BAND_2GHZ];
+           bands = wiphy->bands[NL80211_BAND_2GHZ];
            if(bands)
-               rtw_cfg80211_init_ht_capab(&bands->ht_cap, IEEE80211_BAND_2GHZ, rf_type);
+               rtw_cfg80211_init_ht_capab(&bands->ht_cap, NL80211_BAND_2GHZ, rf_type);
        }

        /* if (padapter->registrypriv.wireless_mode & WIRELESS_11A) */
        {
-           bands = wiphy->bands[IEEE80211_BAND_5GHZ];
+           bands = wiphy->bands[NL80211_BAND_5GHZ];
            if(bands)
-               rtw_cfg80211_init_ht_capab(&bands->ht_cap, IEEE80211_BAND_5GHZ, rf_type);
+               rtw_cfg80211_init_ht_capab(&bands->ht_cap, NL80211_BAND_5GHZ, rf_type);
        }
 }

@@ -5407,9 +5407,9 @@ static void rtw_cfg80211_preinit_wiphy(_adapter *padapter, struct wiphy *wiphy)
        wiphy->n_cipher_suites = ARRAY_SIZE(rtw_cipher_suites);

        /* if (padapter->registrypriv.wireless_mode & WIRELESS_11G) */
-           wiphy->bands[IEEE80211_BAND_2GHZ] = rtw_spt_band_alloc(IEEE80211_BAND_2GHZ);
+           wiphy->bands[NL80211_BAND_2GHZ] = rtw_spt_band_alloc(NL80211_BAND_2GHZ);
        /* if (padapter->registrypriv.wireless_mode & WIRELESS_11A) */
-           wiphy->bands[IEEE80211_BAND_5GHZ] = rtw_spt_band_alloc(IEEE80211_BAND_5GHZ);
+           wiphy->bands[NL80211_BAND_5GHZ] = rtw_spt_band_alloc(NL80211_BAND_5GHZ);

 #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,38) && LINUX_VERSION_CODE < KERNEL_VERSION(3,0,0))
        wiphy->flags |= WIPHY_FLAG_SUPPORTS_SEPARATE_DEFAULT_KEYS;
@@ -5515,8 +5515,8 @@ void rtw_wdev_free(struct wireless_dev *wdev)

        pwdev_priv = wdev_to_priv(wdev);

-       rtw_spt_band_free(wdev->wiphy->bands[IEEE80211_BAND_2GHZ]);
-       rtw_spt_band_free(wdev->wiphy->bands[IEEE80211_BAND_5GHZ]);
+       rtw_spt_band_free(wdev->wiphy->bands[NL80211_BAND_2GHZ]);
+       rtw_spt_band_free(wdev->wiphy->bands[NL80211_BAND_5GHZ]);

        wiphy_free(wdev->wiphy);

[popcornmix]

It's hard to apply that as github loses the tabs....

[fran6co]

I'll create a PR.

[popcornmix]

Cool

[clivem]

@popcornmix Do you know if there was any progess with adding the blacklist files to Raspbian. I have just been contacted by a user who says that his dongle does not work with VENDOR 8192cu driver and he needs to blacklist it and use upstream rtl8192cu. It sure would help if the RPi kernel builds had both modules pre-built, with the upstream module blacklisted by the OS by default.

[popcornmix]

Ping @XECDesign
Does raspbian now add the /etc/modprobe.d/blacklist-rtl8xxxu.conf containing blacklist rtl8xxxu so we can start building that module without breaking things?

[clivem]

Yes, that as well if you also want to build rtl8xxxx, but more importantly, /etc/modprobe.d/blacklist-rtl8192cu.conf, containing blacklist rtl8192cu if you are going to have both 8192cu and rtl8192cu drivers available to the OS.