Band switching code needs to know what channel we switch to.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

PHY may need to be re-initialized during runtime (e.g. on band switch).
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is tiny optimization and grouping band/channel ops.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There aren't devices with multiple 802.11 cores supported by b43.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn 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: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Broadcom's wl 6.30.223.141 has some optimizations for radios 0x205[67].
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn 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: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn 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: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

PHYs other than A may also work in 5 GHz mode.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This cleans code a bit and allows adding support for more devices.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These are extra configs specific to the SSB. Lack of this dependency and
CONFIG_B43=y
CONFIG_B43_BUSES_BCMA=y
CONFIG_SSB=m
would result in:
> drivers/built-in.o: In function `b43_sdio_remove':
> sdio.c:(.text+0x14657f): undefined reference to `ssb_bus_unregister'
> drivers/built-in.o: In function `b43_sdio_probe':
> sdio.c:(.text+0x14672f): undefined reference to `ssb_bus_sdiobus_register'
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We always operate on one core and simple band switch doesn't require
full core reset. Simply reset the PHY.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use separated function for taking PHY out of reset and implement reset
for BCMA.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There are two groups of init values. The first one has to be uploaded
once per wireless core reset but the second one on every band switch.
To implement band switching in an optimal way allow uploading band
init values only (by using a separated function).
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This adds choice submenu "Supported bus types" as two simple bool
configs would allow user to compile b43 without any bus support
(prety useless).
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Users of new (BCMA based) wireless chipsets may not want to enable SSB.
This is hopefully the last code patch for dropping SSB dependency.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Setting it to true during init doesn't seem to be any workaround while
it can cause problems (not enabling radio due to belief it's enabled).
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This removes dealing with pointers directly and allows tracking radio
state with radio_on variable.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is the first step to remove leftover code.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some ancient Broadcom devices had one core per band, e.g.:
ssb: Found chip with id 0x4306, rev 0x02 and package 0x00
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x02, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x04, vendor 0x4243)
ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x01, vendor 0x4243)
ssb: Core 3 found: V90 (cc 0x807, rev 0x01, vendor 0x4243)
ssb: Core 4 found: PCI (cc 0x804, rev 0x07, vendor 0x4243)
ssb: Core 5 found: IEEE 802.11 (cc 0x812, rev 0x04, vendor 0x4243)

This hardware model was dropped for newer devices handled by b43.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We've implemented table calculation, but forgot to enable writing it in
power setup function.
By the way document table layout.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Logic in specs and our code was wrong. Init and calibration values for
newer cards depend on radio revision, not PHY revision.
To make code clearer, change tables names to include "radio" or "phy".
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

They were extracted from MMIO dumps of 14e4:4353 and wl 6.30.223.141.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Mostly just add place for future code
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Bit 0x200 has been noticed in the following log:
 radio_read(0x02ca) -> 0x0000
radio_write(0x00ca) <- 0x0080
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

New Broadcom drivers don't upload it anymore. It was probably a copy & paste
mistake in early N-PHY rev 3+ days.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Register B43_MMIO_PSM_PHY_HDR is 16 bit one, so accessing it with 32b
functions isn't safe. On my machine it causes delayed (!) CPU exception:

Disabling lock debugging due to kernel taint
mce: [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 4: b200000000070f0f
mce: [Hardware Error]: TSC 164083803dc
mce: [Hardware Error]: PROCESSOR 2:20fc2 TIME 1396650505 SOCKET 0 APIC 0 microcode 0
mce: [Hardware Error]: Run the above through 'mcelog --ascii'
mce: [Hardware Error]: Machine check: Processor context corrupt
Kernel panic - not syncing: Fatal machine check on current CPU
Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> [2.6.35+]
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Instead of an explicit cast, use the min_t macro.
Signed-off-by: NSilvan Jegen <s.jegen@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NZhao, Gang <gamerh2o@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>