AC-PHY hardware includes new control 0x3 bits that need to be set to the
0x1 by default.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
b43 has a FIXME about locking in the mac80211 set-beacon-int callback for a long time.
As it turns out there actually is a tiny race window that could result in
a use-after-free bug of the 'current_beacon' memory.
Nobody ever reported this, so it probably never happened.
Fix this by adding a spin lock that protects the current_beacon access.
We must not be in atomic context while accessing hardware (due to SDIO),
so the beacon update bottom half has to clone the skb and release the lock
before writing it to hardware.
Let's all hope that this stops the troll who is trying to submit incorrect
fixes for this issue repeatedly.
And let's hope that I'm not a troll, too, who just hides even more evil code
in an even more complex attempt to fix the issue.
Signed-off-by: Michael Buesch <m@bues.ch>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
It works pretty much the same way as in N-PHY.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Broadcom hardware supports auto-adjustment of TX power depending on the
currently used rate. So far all calculations were handled without any
helpers (API) using big arrays and magic offsets.
It seems Broadcom recently decided to clean this up by developing PPR.
Their wlc_ppr.h can be found in open parts of the SDK.
As we plan to implement support for rate-based TX power it makes sense
to also implement our version of PPR as well.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Access to PHY and radio registers is indirect on Broadcom hardware and
it seems that addressing on some MIPS SoCs may require flushing. So far
this problem was noticed on 0x4716 SoC only (marketing names: BCM4717,
BCM4718).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is the first step to remove leftover code.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The asyncronous firmware load uses a completion struct to hold firmware
processing until the user-space routines are up and running. There is.
however, a problem in that the waiter is nevered canceled during teardown.
As a result, unloading the driver when firmware is not available causes an oops.
To be able to access the completion structure at teardown, it had to be moved
into the b43_wldev structure.
This patch also fixes a typo in a comment.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Instead of defining the magic values in the code use constants.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Drivers that don't use chanctxes cannot perform VHT association because
they still use a "backward compatibility" pair of {ieee80211_channel,
nl80211_channel_type} in ieee80211_conf and ieee80211_local.
Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
[fix kernel-doc]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Recent versions of udev cause synchronous firmware loading from the
probe routine to fail because the request to user space would time
out. The original fix for b43 (commit 6b6fa58) moved the firmware
load from the probe routine to a work queue, but it still used synchronous
firmware loading. This method is OK when b43 is built as a module;
however, it fails when the driver is compiled into the kernel.
This version changes the code to load the initial firmware file
using request_firmware_nowait(). A completion event is used to
hold the work queue until that file is available. This driver
reads several firmware files - the remainder can be read synchronously.
On some test systems, the async read fails; however, a following synch
read works, thus the async failure falls through to the sync try.
Reported-and-Tested by: Felix Janda <felix.janda@posteo.de>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> (V3.4+)
Signed-off-by: John W. Linville <linville@tuxdriver.com>
First of all, use PHY names instead of magic numbers. It should make
configuring kernel easier in case of not enabled PHY type support.
Secondly, always print info about PHY. This is really basic info about
hardware and quite important for the support level.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are more than 3 registers on new hardware. Host flags handling has
to be rewritten, as we can't use u128 type to handle all 5 regs.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
b43 with open firmware crashes mac80211 because
it changes the number of queues at runtime which,
while it was never really supported, now crashes
mac80211 due to the new hardware queue logic.
Fix this by detecting open vs. proprietary fw
earlier and registering with mac80211 with the
right number of queues.
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Cc: stable@vger.kernel.org (depends on commit a6f38ac3)
Signed-off-by: John W. Linville <linville@tuxdriver.com>
this patch fixes kernel Oops on "rmmod b43" if firmware was not loaded:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000088
IP: [<ffffffff8104e988>] drain_workqueue+0x25/0x142
PGD 153ac6067 PUD 153b82067 PMD 0
Oops: 0000 [#1] SMP
Signed-off-by: Oleksij Rempel <bug-track@fisher-privat.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Recent changes in udev are causing problems for drivers that load firmware
from the probe routine. As b43 has such a structure, it must be changed.
As this driver loads more than 1 firmware file, changing to the asynchronous routine
request_firmware_nowait() would be complicated. In this implementation, the probe
routine starts a queue that calls the firmware loading routines.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Following Rafal request, we verified that on "modern" CPUs using one
or more workers is equivalent. Here is patch V3 that addresses the
packet loss bug in the dma engine using only one worker.
-------
This patch addresses a bug in the dma worker code that keeps draining
packets even when the hardware queues are full. In such cases packets
can not be passed down to the device and are erroneusly dropped by the
code.
This problem was already discussed here
http://www.mail-archive.com/b43-dev@lists.infradead.org/msg01413.html
and acknowledged by Michael.
Number of hardware queues is now defined in b43.h (B43_QOS_QUEUE_NUM).
Acknowledgements to Riccardo Paolillo <riccardo.paolillo@gmail.com> and
Michele Orru <michele.orru@hotmail.it>
Signed-off-by: Francesco Gringoli <francesco.gringoli@ing.unibs.it>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The biggest change is reversing order of reading 32-bit table value.
MMIO dumps has shown it's done that way for LCN-PHY.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We have module param called use_pio which is much easier to use.
Cc: Larry Finger <larry.finger@lwfinger.net>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This removes the "FWxx" ID strings from the b43 and b43legacy
drivers. They were once used to match a specific driver revision
to a set of firmware files. However, this is hardly useful today.
Additionally, the IDs are not updated and maintained properly, so
they might mislead users.
Signed-off-by: Michael Buesch <m@bues.ch>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some hardware with 64-bit DMA uses lower address word for setting
routing (translation) bit. Add workaround for such boards.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Analyze of MMIO dumps from BCM43224, BCM43225, BCM4313 and BCM4331 has
shown that wl disables parity check for all that cards. This is required
for receiving any packets from the hardware.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It does nothing useful yet, so it is matched as BROKEN.
For now this is just an option for b43, in future we may want to make
b43 support SSB or BCMA (note: or, not xor).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Recent trivial fix corrected 'occured', but left 'reqest'.
codespell needs another dictionary entry.
cc: Lucas De Marchi <lucas.demarchi@profusion.mobi>
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
We free name "dev" for something generic (like dev abstraction layer).
Additionaly code is cleaner now, especially magic dev->dev-dev chains.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As discussed we do not know band width at core reset time and it is not a good
idea to reset whole just to change band. So just set unconditionally 20 MHz
band width as default during core reset.
As for defines PHY clock changed to band width in specs and it makes much more
sens to call defines by band width which is self-explainable. Updated specs do
not mention 0 value, but comparing to old ones you can notice lineral relation
between PHY clock speed and band width. So it makes sense for 0x0 value to be
10 MHz band width.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
