8188eu and 8192cus coexisting

[procount]

Hi @lwfinger, not an issue as such, but more of a request for advice.
I am trying to add cfg80211 versions of rtl8192cus and rlt8188eu wifi drivers to my fork of NOOBS, so that means building them into the 4.1.y kernel with buildroot, not as modules.
I backported the 8192cus driver from 4.8.y into buildroot and that seems to work ok.
But when I try to add the 8188eu driver from staging, buildroot fails with multiple definitions of the same labels in built-in.o - I assume because the 8192c and 8188eu are very similar and have a lot of the same names. I even tried bumping the kernel to 4.8, but the same name clashes arose.
Do you have any suggestions how I can overcome this problem and get both of them integrated? Would your standalone drivers here solve my problem?

[lwfinger]

Realtek tends to derive all of their USB drivers from the same database, which leads to namespace conflicts of exactly the form you mention when having them built into the kernel, even though they are OK when built as modules.

The only solution is to rename the offending symbols in one of those drivers. The standalone drivers (which are from Realtek) will not solve the problem.

Where does your code for the 8192cu come from? I just built an "all yes" configuration for the mainline kernel with no problems. At least, sed will be your friend when it comes to renaming the symbols that need to be changed..

[procount]

Currently I'm just using the driver code from the rpi-linux github account.
4.1.y of the 8192cu does not include a cfg80211 interface, so I was modifying NOOBS to use the old legacy interface. But then I noticed that someone modified it in the 4.8.y branch to include this interface, so I used that one instead and saved myself a whole heap of pain. It seems to work ok.
It was only when I started adding the 4.1.y staging version of the 8188EU driver I hit this problem.
But I see NOOBS has just been bumped to 4.4.y, so I think I will try the drivers from that kernel version and rename the appropriate symbols as you mentioned.
Thanks for confirming the issue and your advice.

[procount]

So before I sharpened my SED skills, I removed the 8192cu driver and added the 8188eu driver from 4.4.y kernel version just to check it worked. It built without any symbol clashes and the 8188eu driver was loaded as wlan0. BUT, NOOBS (which uses the cfg80211 interface from wpa_supplicant, controlled via DBUS, and using the nl80211 interface) claimed there was no wireless interface. This suggests to me that the driver is not cfg80211 compliant, or the correct compile option is not set to enable it. Within buildroot kernel options, both CONFIG_CFG80211 and CONFIG_CFG80211_WEXT were set.

Is there anything else I need to set, to enable the cfg80211 interface?

[lwfinger]

The in-kernel version of that driver does not use cfg80211. You will need to implement the v4.1.8_9499
branch of this repo to get that capability.

[procount]

Thanks. I'll give it a go.

[procount]

After successfully renaming the functions and integrating this 8188eu driver on the v4.1.8_9499 branch into Buildroot as a builtin driver with cfg80211 for kernel 4.1.y, I am now trying to upgrade the kernel to 4.14.15.

Is this driver still appropriate for that kernel version?
I tried building it, but I got the following errors:

In file included from drivers/net/wireless/realtek/rtl8188eu/core/rtw_cmd.c:23:0:
drivers/net/wireless/realtek/rtl8188eu/include/osdep_service.h: In function ‘thread_enter’:
drivers/net/wireless/realtek/rtl8188eu/include/osdep_service.h:576:2: error: implicit declaration of function ‘allow_signal’ [-Werror=implicit-function-declaration]
  allow_signal(SIGTERM);
  ^
drivers/net/wireless/realtek/rtl8188eu/include/osdep_service.h: In function ‘flush_signals_thread’:
drivers/net/wireless/realtek/rtl8188eu/include/osdep_service.h:581:2: error: implicit declaration of function ‘signal_pending’ [-Werror=implicit-function-declaration]
  if (signal_pending (current))
  ^
drivers/net/wireless/realtek/rtl8188eu/include/osdep_service.h:583:3: error: implicit declaration of function ‘flush_signals’ [-Werror=implicit-function-declaration]
   flush_signals(current);
   ^
cc1: some warnings being treated as errors

I'm guessing the implicit-function-declaration flag is something new to this kernel version - maybe I can fix the driver with some forward function declarations (?). But I just wanted to make sure that this driver is still the most appropriate for cfg80211 functionality before I went further. TIA.

[lwfinger]

The kernel APIs change from time to time. An out-of-kernel driver such as this needs to be able to test the kernel version and change the code appropriately. That is why you will see conditional statements such as "#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 15, 0)" sprinkled throughout the code. Unfortunately, some distros (most notably Ubuntu) backport such changes to older kernel versions. Once they do this, a simple test of the kernel version is not sufficient. Unfortunately, for you, I do not try to keep my repos in a state where they will build on distros that subscribe to these practices. You will need to determine the necessary modifications, and make them yourself. Sorry, but that has been my policy ever since Ubuntu started this madness.

FYI, this repo builds perfectly on unadultered kernels through the current 4.16.0-rc3.

This driver is the best one that I have.

[procount]

Thanks for the background info.
I'm not building for Ubuntu. I'm building from rpi-linux kernel repo and it worked fine in 4.1.y. Hopefully it's just a few compiler options somewhere I have to tweak. I will persevere then.

[procount]

EDIT: Doh! I think I need to pull down the latest commit and rename the functions again 😉

[lwfinger]

That was what I was about to suggest. Of course, stale repos probably will not build with the latest kernels!

[procount]

Yeah, when I remembered you said it built perfectly on 4.16, I had a lightbulb moment and then saw I was slowly re-implementing all the commits you had already done! (Well, at least it confirmed I was doing the changes in the right way). I don't fancy going through SED again, even though I automated most of it, so I'll try and merge your latest changes into my old version. Thanks for your advice.

[procount]

I think include/osdep_service.h is missing the following section on branch v4.1.8_9499

#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0)
    #include <linux/sched/signal.h>
#endif

That gets everything compiled up until:

drivers/net/wireless/realtek/rtl8188eu/os_dep/ioctl_cfg80211.c: In function ‘rtw_cfg80211_indicate_connect’:
drivers/net/wireless/realtek/rtl8188eu/os_dep/ioctl_cfg80211.c:696:4: warning: passing argument 2 of ‘cfg80211_roamed’ from incompatible pointer type [enabled by default]
    , GFP_ATOMIC);
    ^

[lwfinger]

I have not been maintaining that branch. If you can fix it great, otherwise, it will be a few days until I can get to it.

[procount]

Ah. Ok. Well, if I spot anything obvious like above, or can merge diffs from master, I may post a PR for you. But it may take me several days too!

[procount]

Looking at the previous issues, I found #232. Applying the v4.1.8_9499_fix.zip patch from there allowed the branch to compile. Next step: testing....

[procount]

When compiling, I got the following warning. Is this an issue?

drivers/net/wireless/realtek/rtl8188eu/os_dep/ioctl_cfg80211.c: In function ‘rtw_cfg80211_inform_bss’:
drivers/net/wireless/realtek/rtl8188eu/os_dep/ioctl_cfg80211.c:502:1: warning: the frame size of 1056 bytes is larger than 1024 bytes [-Wframe-larger-than=]

I got the following messages in dmesg:

[    2.077896] usbcore: registered new interface driver rtl8188eu
...
[    3.788118] usb 1-1.1: New USB device found, idVendor=0bda, idProduct=8179
[    3.788135] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    3.788142] usb 1-1.1: Product: 802.11n NIC
[    3.788148] usb 1-1.1: Manufacturer: Realtek
...
[    8.583539] R8188EU: Loaded firmware file rtlwifi/rtl8188eufw.bin
[    8.583561] R8188EU: Firmware Version 11, SubVersion 1, Signature 0x88e1
[    8.937781] ==> rtl8188e_iol_efuse_patch
[    9.513579] r8152 1-1.4.4:1.0 eth0: carrier on
[   13.287524] R8188EU: nolinked power save enter
[   16.178106] ==> rtl8188e_iol_efuse_patch
[   16.482472] R8188EU: nolinked power save leave
[   18.487393] R8188EU: nolinked power save enter
{repeats every 7 secs}

The nolinked power save seems to be a similar error to that mentioned in #204.

I can't test this with an Access Point til later, but so far it's looking quite promising.

[lwfinger]

The frame size warning comes from the statement "u8 buf[MAX_BSSINFO_LEN], *pbuf;", and is due to that large array on the stack. The fix is not difficult, but it is tricky. The line is changed to "u8 *buf, *pbuf" and someplace before buf is used, that amount of space is gotten with a kzalloc() call. The difficult part to remember is to kfree(buf) before the routine exits, otherwise you leak the memory. Unless you really want to fix it, you can ignore it. The x86 stack is large enough that it will not cause any problems.
.
Those power save messages are not errors. They are just aggressive informational messages showing that the AP is going into and out of power-save mode. Find the lines that issue those messages and change drv_always to drv_info.

[procount]

Thanks. I'll see what I can do & report back later.
BTW, I'm on Rpi ARM, not x86, so I have a little less memory to play with.

[procount]

Those 2 issues are now fixed.
But I still get an annoying message in dmesg every 7-8 secs. :

==> rtl8188e_iol_efuse_patch

I found it in hal/rtl8188e_hal_init.c rtl8188e_iol_efuse_patch(struct adapter *padapter)
printk("==> %s\n",__FUNCTION__);

Is this necessary, or can I just comment it out? Is it just a debug message?

[procount]

I've now been able to connect to an AP and it all seems to work.
The iol_fuse_patch message disappears once it is connected, so maybe I'll leave it.

[procount]

PR #244 created