By the way add few chipsets that were tracked with "wl" dumps.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Seems to be required by some hardware, wl does it every time.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This could be a bit confusing to see warning about lacking support for
5 GHz band if your device supports 2.4 GHz only.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Support for N-PHY rev 8 with 0x2057 rev 5 is almost ready, but we still
need to figure out how to handle rev 9 first.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Initialization of N-PHY radio revs 5 and 7 requires writing to 0x1.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Type of radio has a major meaning for the driver. There is quite some
code that does initialization/calibration depending on the radio rev.
Knowing radio params is quite important to provide help to users, so
print it even with debugging disabled.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This changes
b43-phy0: Found Radio: Manuf 0x17F, Version 0x7769, Revision 4
to the
b43-phy0: Found Radio: Manuf 0x17F, Version 0x2069, Revision 4
which matches what closed source driver reports:
$ wl revinfo
radiorev 0x42069000
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This allows adding more revisions support, spotting lacking tables and
unifies naming schema.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This adds some cores with 0x2057 radio which will be supported soon as
well as core 40 that I missed in the earlier firmware patch.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It doesn't include any device (radio revision) specific code yet, so it
isn't really usable. As the commit says, it's just some generic code.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
LCNXN is simply a continuation of N, e.g. code handling LCNXN revs 0 and
1 is mostly the same as for N-PHY revs 7+.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Clean ucode selection, fix choice of firmware for LCN, drop some goto-s,
add new devices.
Tested on 14e4:4312, 14e4:4315, 14e4:4328, 14e4:432b, 14e4:4353.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add support for external PA and clean code a bit.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This allows new devices users to save some space.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Old devices (A-PHY or B-PHY) are supposed to be supported by b43legacy.
We keep phy_a.c as it's needed for G-PHY which shares some design.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Band switching code needs to know what channel we switch to.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
PHY may need to be re-initialized during runtime (e.g. on band switch).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is tiny optimization and grouping band/channel ops.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There aren't devices with multiple 802.11 cores supported by b43.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It was never used, b43_switch_channel is always called with hw_value
(from mac80211) or whatever get_default_chan returns.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Support for firmware rev 508+ was added years ago, but we never noticed
it reports channel in a different way for G-PHY devices. Instead of
offset from 2400 MHz it simply passes channel id (AKA hw_value).
So far it was (most probably) affecting monitor mode users only, but
the following recent commit made it noticeable for quite everybody:
commit 3afc2167f6
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date: Tue Mar 4 16:50:13 2014 +0200
cfg80211/mac80211: ignore signal if the frame was heard on wrong channel
Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Cc: stable@vger.kernel.org
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This fixes regression introduced by adding some G-PHY devices to the
list of dual band devices. There is simply no support for 5 GHz on
G-PHY devices in b43. It results in:
WARNING: CPU: 0 PID: 79 at drivers/net/wireless/b43/phy_g.c:75 b43_gphy_channel_switch+0x125/0x130 [b43]()
b43-phy1 ERROR: PHY init: Channel switch to default failed
Regression was introduced by the following commit:
commit 773cfc508f
Author: Rafał Miłecki <zajec5@gmail.com>
Date: Mon May 19 23:18:55 2014 +0200
b43: add more devices to the bands database
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Broadcom's wl 6.30.223.141 has some optimizations for radios 0x205[67].
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
PHY has to be often re-initialized (e.g. during band switching after PHY
reset), however some operations have to be performed only once (only
power reset affects them).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Broadcom hardware uses a bit tricky hw_value-s for 5 GHz channels,
values 184-228 are used for 4920-5140 MHz center frequencies. Normally
you expect channels 7-16 (e.g. 5060 MHz is channel 12, not 212). We never
meant to register hw_value 228 with freq 6140 MHz (5000 + 228 * 5).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
