Hi Laura, Justin, et el,
I've been playing with a handful of cheap USB wireless modules for support on the Raspberry Pi and other similar devices.
I've noticed that there's a bunch of overlap regarding usb IDs between the newer (and IMO preferred) rtl8xxxu and the vendor collection of drivers so you often get both drivers loaded. I've tended to fix this by just blacklisting the vendor upstream drivers.
The question is how best to deal with this in a generic way to ensure a good experience with these in Fedora?
Do we cross reference all the USB IDs and disable the non rtl8xxxu drivers once they have full coverage in rtl8xxxu? Do we actively patch out the IDs supported in rtl8xxxu from associated drivers?
Peter
On Mon, Oct 10, 2016 at 2:02 PM, Peter Robinson pbrobinson@gmail.com wrote:
Hi Laura, Justin, et el,
I've been playing with a handful of cheap USB wireless modules for support on the Raspberry Pi and other similar devices.
I've noticed that there's a bunch of overlap regarding usb IDs between the newer (and IMO preferred) rtl8xxxu and the vendor collection of drivers so you often get both drivers loaded. I've tended to fix this by just blacklisting the vendor upstream drivers.
Wait, that's a situation that exists upstream?
The question is how best to deal with this in a generic way to ensure a good experience with these in Fedora?
Do we cross reference all the USB IDs and disable the non rtl8xxxu drivers once they have full coverage in rtl8xxxu? Do we actively patch out the IDs supported in rtl8xxxu from associated drivers?
I'd suggest posing this question on the upstream wireless list, with the various driver maintainers CC'd. If it's an upstream problem then it really needs solving upstream.
josh
On Mon, Oct 10, 2016 at 7:14 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Mon, Oct 10, 2016 at 2:02 PM, Peter Robinson pbrobinson@gmail.com wrote:
Hi Laura, Justin, et el,
I've been playing with a handful of cheap USB wireless modules for support on the Raspberry Pi and other similar devices.
I've noticed that there's a bunch of overlap regarding usb IDs between the newer (and IMO preferred) rtl8xxxu and the vendor collection of drivers so you often get both drivers loaded. I've tended to fix this by just blacklisting the vendor upstream drivers.
Wait, that's a situation that exists upstream?
Yes, the first two commits to the new driver [1][2] sort of cover it as "it doesn't support all the functionality of the vendor driver" and mention that IDs should be moved over. I'm not sure if the dual loading is because missing patches to drop ID overlaps, still missing functionality (AP or ad-hoc at a guess) or just a general oversight.
[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=26... [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=03...
The question is how best to deal with this in a generic way to ensure a good experience with these in Fedora?
Do we cross reference all the USB IDs and disable the non rtl8xxxu drivers once they have full coverage in rtl8xxxu? Do we actively patch out the IDs supported in rtl8xxxu from associated drivers?
I'd suggest posing this question on the upstream wireless list, with the various driver maintainers CC'd. If it's an upstream problem then it really needs solving upstream.
Yes, I realise that, I've not done any analysis as to how much overlap there is, or functionality difference. I'd suspected it might be the case but only worked it out actually was last week. I thought I'd ask here first in case there was known reasons for the driver overlap that I'd missed.
Peter
On 10/10/2016 11:53 AM, Peter Robinson wrote:
On Mon, Oct 10, 2016 at 7:14 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Mon, Oct 10, 2016 at 2:02 PM, Peter Robinson pbrobinson@gmail.com wrote:
Hi Laura, Justin, et el,
I've been playing with a handful of cheap USB wireless modules for support on the Raspberry Pi and other similar devices.
I've noticed that there's a bunch of overlap regarding usb IDs between the newer (and IMO preferred) rtl8xxxu and the vendor collection of drivers so you often get both drivers loaded. I've tended to fix this by just blacklisting the vendor upstream drivers.
Wait, that's a situation that exists upstream?
Yes, the first two commits to the new driver [1][2] sort of cover it as "it doesn't support all the functionality of the vendor driver" and mention that IDs should be moved over. I'm not sure if the dual loading is because missing patches to drop ID overlaps, still missing functionality (AP or ad-hoc at a guess) or just a general oversight.
[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=26... [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=03...
The question is how best to deal with this in a generic way to ensure a good experience with these in Fedora?
Do we cross reference all the USB IDs and disable the non rtl8xxxu drivers once they have full coverage in rtl8xxxu? Do we actively patch out the IDs supported in rtl8xxxu from associated drivers?
I'd suggest posing this question on the upstream wireless list, with the various driver maintainers CC'd. If it's an upstream problem then it really needs solving upstream.
Yes, I realise that, I've not done any analysis as to how much overlap there is, or functionality difference. I'd suspected it might be the case but only worked it out actually was last week. I thought I'd ask here first in case there was known reasons for the driver overlap that I'd missed.
Peter
For my benefit, can you list the specific USB ids and configs that are causing conflicts so I can keep an eye out?
Thanks, Laura
Hi! On 10.10.2016 20:02, Peter Robinson wrote:
I've been playing with a handful of cheap USB wireless modules for support on the Raspberry Pi and other similar devices.
I've noticed that there's a bunch of overlap regarding usb IDs between the newer (and IMO preferred) rtl8xxxu and the vendor collection of drivers so you often get both drivers loaded. I've tended to fix this by just blacklisting the vendor upstream drivers.
FWIW: the rtl8723au driver is removed from mainline with 4.9 (https://git.kernel.org/torvalds/c/b49f6ab951 ). Maybe it might be feasible to simply disable it in our configs in advance of that change.
This is just meant as a data point, as I guess such a config adjustment would not solve the problem completely.
CU, knurd
kernel@lists.fedoraproject.org
-
Josh Boyer -
Laura Abbott -
Peter Robinson -
Thorsten Leemhuis