linux-raspi2: rtl8192cu vs 8192cu
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux-raspi2 (Ubuntu) |
Confirmed
|
Undecided
|
Paolo Pisati |
Bug Description
SRU justification:
Impact: as part of the RaspberryPI BSP we got an out of tree Realtek driver that predates the upstream rtlwifi driver:
commit 352ad803b031478
Author: popcornmix <email address hidden>
Date: Mon Sep 3 17:10:23 2012 +0100
Add non-mainline source for rtl8192cu wireless driver version v4.0.2_9000 as this is widely used. Disabled older rtlwifi dri
ver
8192cu needs old wireless extensions
The obsolete WIRELESS_EXT configuration is used
by the old Realtek code and is needed for AP support.
8192cu: CONFIG_AP_MODE hardcoded in autoconf.h
diff --git a/drivers/
index f9f9422..cfb2280 100644
--- a/drivers/
+++ b/drivers/
@@ -278,7 +278,8 @@ source "drivers/
source "drivers/
source "drivers/
source "drivers/
-source "drivers/
+#source "drivers/
+source "drivers/
source "drivers/
source "drivers/
source "drivers/
...
This driver not only predates Linux's rtlwifi driver, but it behaves differently too (the 'iw phy' commands doesn't work, AP is not working for some adapter, etc), it's stale (it's the same exact driver that was imported into the RaspberryPI BSP around Linux 3.2 and got no updates since then - https:/
I've tried to convince upstream to remove this driver and revert to rtlwifi, but my suggestion was met with resistance:
https:/
Since we successfully use rtlwifi in every other architecture / branches, i'm proposing to drop this out-of-tree driver and bring the raspi2 kernel closer to the other Ubuntu kernels.
If we ever feel the need for an out of tree driver for this chipset, the driver should probably be imported into master and propagated from there to all the branches.
Fix: Revert the Realtek driver, and add back RTLWIFI to the build
Test:
check for the presence of the 8192cu.ko module:
$ find /lib/modules/`uname -r` -name 8192cu.ko
if it's present you have the out-of-tree driver,
while if it's missing and you have the rtl819cu.ko, you're running the upstream driver:
$ find /lib/modules/`uname -r` -name rtl8192cu.ko
---
As part of the RaspberryPI BSP we got this commit:
https:/
-------
Add non-mainline source for rtl8192cu wireless driver version v4.0.2_…
…9000 as this is widely used. Disabled older rtlwifi driver
8192cu needs old wireless extensions
The obsolete WIRELESS_EXT configuration is used
by the old Realtek code and is needed for AP support.
8192cu: CONFIG_AP_MODE hardcoded in autoconf.h
-------
that disables the Realtek driver in drivers/
This result in a difference in the number or rtl8192 drivers shipped with generic:
drivers/
drivers/
drivers/
drivers/
drivers/
drivers/
drivers/
drivers/
drivers/
drivers/
drivers/
versus the only 8192 driver that we ship in linux-raspi2 due to the commit above:
drivers/
drivers/
Feature wise is not yet clear which of the two is preferable (and why), plus the raspi3 is shipping with a wifi chip and we should be careful not to break support for it.
Changed in linux-raspi2 (Ubuntu): | |
assignee: | nobody → Paolo Pisati (p-pisati) |
description: | updated |
fwiw, on my realtek 8912 based dongle AP mode works pretty much fine in 4.4 kernel on beaglebone... maybe the mainline/staging driver has improved enough between 4.0 and 4.4?
Is there a way we cna have both modules and hint which will be picked with priority? If so we could allow device builders to just blacklist the one they dont want etc.