Red Hat Bugzilla – Bug 1027651
Wireless driver for Broadcom BCM4352 802.11 Hybrid Wireless Controller 184.108.40.206
Last modified: 2014-03-19 09:42:02 EDT
Description of problem:
I own a G750JX and the model comes with a Broadcom BCM43b1 802.11 Hybrid Wireless Controller 220.127.116.11
The fedora linux kernel does not come with a wireless driver for this card, however some people have made one that works.
It can be found here:
For kernels >= 3.10 some adjustments need to be done (minor change in architecture). I can attach the updated version I use (manually compiled each kernel update).
Unfortunately, I'm not sure what needs to be done in order to push this module into the kernel but this module works (mostly) with minor hickups.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start Fedora
Please see description
Fedora doesn't use out-of-tree drivers. The best solution is to engage upstream in getting support for this device added to brcm80211.
Can you please give me some pointers on how to do that? Which person to contact, etc?
You could look at: http://wireless.kernel.org/en/users/Drivers/brcm80211
When you do please recheck the device number, because there exists no such thing as a bcm43b1 chip.
I appologise, I was looking at dmesg messages instead of lspci. The correct model is
03:00.0 Network controller: Broadcom Corporation BCM4352 802.11ac Wireless Network Adapter (rev 03)
Can you post lspci -nnvv of this?
I'll assume it's 0x14e4:4352, but would like to see more.
Currently the upstream code supports *80211 cores* 17, 23,24.
Arend: the page you reference, doens't show 4352. What would core id be for this?
I know you can get it with udevadm monitor, is this another tool for finding that core id?
Created attachment 822512 [details]
According to the lspci output it's actually:
03:00.0 Network controller : Broadcom Corporation BCM4352 802.11ac Wireless Network Adapter [14e4:43b1] (rev 03)
I can run udevadm monitor but I need parameters for it (i ran it by itself and no output).
Worked for me:
udevadm monitor --kernel --property
Created attachment 823595 [details]
Ok, I ran that command as root and the rmmod / modprobe to actually get something there. The output is attached.
Better, but one more piece I missed.
modprobe -r wl bcma brcmsmac
Setup the udev window as before
then do this instead
As noted in Comment 1 by the maintainers, we don't support out of tree drivers. The wl driver you are using being one of them. If we can get the ID of your core, perhaps it exists upstream in bcm80211 already. Saddly if not, ... I'd have to close this at that point.
Created attachment 823625 [details]
udevadm output #2
This is the requested output.
In case it's not upstream, can you at least point me in the right direction so that I may contact someone who is actually working on this and can help me?
Additionally, I found this:
Unfortunately I'm not familiar with the sumission workflow so I don't know when this patch (which supposedly adds support for my card) will get in the kernel.
The patch you mention appears to be in already, kernel version v3.9-12346-gd4988d4.
The udev output seems to show the bcma isn't happy with your chip, doesn't find a core it supports, as you say.
This device is an 802.11 ac device which I'm new to: this is newer high performance device and it makes sense that the drivers lag for this at this point. Let me check around.
Are you loading wl intentionally? (blacklisting b43 and or bcma/brcmsmac)
Can you post your kernel .config file? Should be in the /boot directory with the kernel.
Created attachment 824657 [details]
Kernel config file
So, every time the kernel updates I recompile the kernel driver I pointed in the initial link (make clean, make, make install, depmod -a, modprobe wl). After doing this, any subsequent bootups with this kernel have wireless out of the box.
I do not blacklist b43 or bcma/brcmsmac.
Apparently, the driver done by the guy @canonical is based on the official broadcom driver (which now supports my card but doesn't compile):
(In reply to Munteanu Victor Ion from comment #13)
> Additionally, I found this:
> Unfortunately I'm not familiar with the sumission workflow so I don't know
> when this patch (which supposedly adds support for my card) will get in the
This is in post 3.10 kernel already.
Then it's not working for my wifi (on 3.12.8-300.fc20.x86_64).
Probably not much help to you other than just peripheral info. It appears that drivers are just now starting to support 802.11ac rates you desire. The bug below is for an Intel chipset
I just checked this morning for you again after reading it, nothing new to this issue for you from BCM upstream, unfortunately. I'll keep looking, but until something shows up, not much I can do to help.
I know BCM is limited in resources to support open source, several chips we'd like to see support for already, but it's up to them to put resources on that effort. Wish I had better news.
Would you like to keep this open still?
Forgot something.. The bz above shows *some* support for this technology in 3.14 which may or may not help, but is another build to try that can conceivably support you, but I'm pretty dubious without more support from the chip driver.
In all your spare time, right? :)
I don't know how to reply to your message. From my point of view as a regular linux user it is frustrating to see that you have a WORKING DRIVER and you refuze to accept it and integrate it in the linux kernel.
You said that:
> I know BCM is limited in resources to support open source, several chips we'd > like to see support for already, but it's up to them to put resources on that > effort.
The thing is Broadcom did they part. If you go to this link:
and download the driver and compile it, it works (for kernel < 3.10) and for 3.10+ you need to do minor changes which I was able to do with some C knowledge and Google.
So, the there are two directions I can go. Wait like 1-2 years until more laptops come with this technology and support will be added at some point, or you can put me in contact with the person in charge of this specific module so that I may email him/her for information and I will brush off my C skills and integrate it myself, and then there's no excuse not to push it upstream.
(In reply to Munteanu Victor Ion from comment #21)
> Dear John,
> I don't know how to reply to your message. From my point of view as a
> regular linux user it is frustrating to see that you have a WORKING DRIVER
> and you refuze to accept it and integrate it in the linux kernel.
> You said that:
> > I know BCM is limited in resources to support open source, several chips we'd > like to see support for already, but it's up to them to put resources on that > effort.
> The thing is Broadcom did they part. If you go to this link:
I have to correct you here. This so-called hybrid driver that you indicate as working driver is only partially compiled and the majority is a binary blob. That is all the excuse one need to not push it upstream.
I appologise, I've looked over the sources and saw the blob. I've only fixed the compile errors, didn't bother to look at all the code.
I will try to see if I can contribute directly upstream. In the mean time I believe you can close this.
I certainly get your frustration: buying the latest and not having out of the box support. I'll continue to monitor this situation and support this as I can. Will close this for now, but if you decide to contribute please feel free to reopen this or a new issue. I certainly wish to know!
Arend, as always, thanks for the information and help! Owe you another one.