aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/wireless/b43
Commit message (Collapse)AuthorAge
...
* | b43: PHY: drop is_40mhz (get width info from chandef)Rafał Miłecki2014-06-19
| | | | | | | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | b43: PHY: drop own channel_freq (get it from chandef when needed)Rafał Miłecki2014-06-19
| | | | | | | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | b43: store current channel using struct cfg80211_chan_defRafał Miłecki2014-06-19
| | | | | | | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | b43: b43_op_config: set channel info before switching bandRafał Miłecki2014-06-19
| | | | | | | | | | | | | | 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>
* | b43: PHY: don't force default channel during initRafał Miłecki2014-06-19
| | | | | | | | | | | | | | 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>
* | b43: b43_op_config: use IEEE80211_CONF_CHANGE_CHANNELRafał Miłecki2014-06-19
| | | | | | | | | | | | | | 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>
* | b43: b43_op_config: drop check for core changeRafał Miłecki2014-06-19
| | | | | | | | | | | | | | 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>
* | b43: drop B43_DEFAULT_CHANNELRafał Miłecki2014-06-19
|/ | | | | | | | 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>
* b43: N-PHY: optimize radio switching on/offRafał Miłecki2014-05-29
| | | | | | | 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>
* b43: N-PHY: optimize init by doing some ops just onceRafał Miłecki2014-05-29
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: PHY: allow init optimizations by tracking PHY stateRafał Miłecki2014-05-29
| | | | | | | | | 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>
* b43: N-PHY: add missing calib values for radio 0x2026 rev 11Rafał Miłecki2014-05-22
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: fix list of 5 GHz channels for 802.11n cardsRafał Miłecki2014-05-22
| | | | | | | | | | 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>
* b43: fix typo in define name for 2 GHz channels (s/CHAN4G/CHAN2G/)Rafał Miłecki2014-05-22
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: xmit: set 5 GHz bit depending on current bandRafał Miłecki2014-05-20
| | | | | | | PHYs other than A may also work in 5 GHz mode. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: add more devices to the bands databaseRafał Miłecki2014-05-20
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: move bands detection to a separated functionRafał Miłecki2014-05-20
| | | | | | | This cleans code a bit and allows adding support for more devices. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: make B43_PCMCIA and B43_SDIO depend on B43_SSBRafał Miłecki2014-05-19
| | | | | | | | | | | | | | | | 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: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: rework band switchingRafał Miłecki2014-05-19
| | | | | | | | We always operate on one core and simple band switch doesn't require full core reset. Simply reset the PHY. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: complete PHY resetRafał Miłecki2014-05-19
| | | | | | | | Use separated function for taking PHY out of reset and implement reset for BCMA. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: move PHY reset code into PHY specific fileRafał Miłecki2014-05-19
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: split upload of init values into 2 functionsRafał Miłecki2014-05-19
| | | | | | | | | | 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: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: drop SSB dependencyRafał Miłecki2014-05-13
| | | | | | | | | 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: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: adjust code to compile without SSBRafał Miłecki2014-05-13
| | | | | | | | 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: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: N-PHY: complete radio 0x2056 setupRafał Miłecki2014-04-30
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: don't pre-set radio_on variable to trueRafał Miłecki2014-04-30
| | | | | | | | 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: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: use b43_software_rfkill helperRafał Miłecki2014-04-30
| | | | | | | | This removes dealing with pointers directly and allows tracking radio state with radio_on variable. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: bcma: respect GMODE (band choice) during core resetRafał Miłecki2014-04-30
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: remove list of IEEE 802.11 devicesRafał Miłecki2014-04-22
| | | | | | | 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>
* b43: ssb: refuse to support more than IEEE 802.11 coreRafał Miłecki2014-04-22
| | | | | | | | | | | | | | | | 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: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: N-PHY: enable forgotten write of hw power adjust tableRafał Miłecki2014-04-22
| | | | | | | | | We've implemented table calculation, but forgot to enable writing it in power setup function. By the way document table layout. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: N-PHY: fix selection of init & calib valuesRafał Miłecki2014-04-22
| | | | | | | | | 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: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: N-PHY: add init & calib values for radio 0x2056 rev 11Rafał Miłecki2014-04-22
| | | | | | | They were extracted from MMIO dumps of 14e4:4353 and wl 6.30.223.141. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: N-PHY: prepare for rev 7+ RSSI calibrationRafał Miłecki2014-04-22
| | | | | | | Mostly just add place for future code Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: N-PHY: implement RF control INTC for revs 7+Rafał Miłecki2014-04-22
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: N-PHY: implement reading support for radio 0x2057Rafał Miłecki2014-04-22
| | | | | | | | | Bit 0x200 has been noticed in the following log: radio_read(0x02ca) -> 0x0000 radio_write(0x00ca) <- 0x0080 Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: N-PHY: random updates and typo fixes all aroundRafał Miłecki2014-04-22
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: N-PHY: rev3+: complete workaroundsRafał Miłecki2014-04-22
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: N-PHY: drop second noise variance tableRafał Miłecki2014-04-22
| | | | | | | | 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: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: G-PHY: fix random mistakes to match specsRafał Miłecki2014-04-22
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: Fix machine check error due to improper access of B43_MMIO_PSM_PHY_HDRRafał Miłecki2014-04-09
| | | | | | | | | | | | | | | | | | | 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: Rafał Miłecki <zajec5@gmail.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> [2.6.35+] Signed-off-by: John W. Linville <linville@tuxdriver.com>
* net: Replace min macro with min_tSilvan Jegen2014-03-03
| | | | | | | Instead of an explicit cast, use the min_t macro. Signed-off-by: Silvan Jegen <s.jegen@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: return true / false instead of numbers in functions which return bool valueZhao, Gang2014-02-24
| | | | | Signed-off-by: Zhao, Gang <gamerh2o@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: Kconfig: let config B43_BCMA_PIO depends on B43Zhao, Gang2014-02-24
| | | | | | | | | Logically, config B43_BCMA_PIO should depend on B43. This also solves the problem that sub options of b43 driver didn't indent correctly in make menuconfig's ncurses window. Signed-off-by: Zhao, Gang <gamerh2o@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: use kernel api to replace b43 specific helper functionZHAO Gang2014-02-13
| | | | | | | | Use ieee80211_channel_to_frequency() to replace b43_channel_to_freq_{2,5}ghz(), and remove unused b43_freq_to_channel_{2,5}ghz(). Signed-off-by: ZHAO Gang <gamerh2o@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: fix the wrong assignment of status.freq in b43_rx()ZHAO Gang2014-01-23
| | | | | | | | | | | | | | Use the right function to update frequency value. If rx skb is probe response or beacon, the wrong frequency value can cause problem that bss info can't be updated when it should be. Cc: <stable@vger.kernel.org> Fixes: 8318d78a44d4 ("cfg80211 API for channels/bitrates, mac80211 and driver conversion") Signed-off-by: ZHAO Gang <gamerh2o@gmail.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: Fix unload oops if firmware is not availableLarry Finger2014-01-13
| | | | | | | | | | | | | | | | 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>
* b43: Fix lockdep splatLarry Finger2014-01-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In https://bugzilla.kernel.org/show_bug.cgi?id=67561, a locking dependency is reported when b43 is used with hostapd, and rfkill is used to kill the radio output. The lockdep splat (in part) is as follows: ====================================================== [ INFO: possible circular locking dependency detected ] 3.12.0 #1 Not tainted ------------------------------------------------------- rfkill/10040 is trying to acquire lock: (rtnl_mutex){+.+.+.}, at: [<ffffffff8146f282>] rtnl_lock+0x12/0x20 but task is already holding lock: (rfkill_global_mutex){+.+.+.}, at: [<ffffffffa04832ca>] rfkill_fop_write+0x6a/0x170 [rfkill] --snip-- Chain exists of: rtnl_mutex --> misc_mtx --> rfkill_global_mutex The fix is to move the initialization of the hardware random number generator outside the code range covered by the rtnl_mutex. Reported-by: yury <urykhy@gmail.com> Tested-by: yury <urykhy@gmail.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Merge branch 'for-linus-dma-masks' of git://git.linaro.org/people/rmk/linux-armLinus Torvalds2013-11-13
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull DMA mask updates from Russell King: "This series cleans up the handling of DMA masks in a lot of drivers, fixing some bugs as we go. Some of the more serious errors include: - drivers which only set their coherent DMA mask if the attempt to set the streaming mask fails. - drivers which test for a NULL dma mask pointer, and then set the dma mask pointer to a location in their module .data section - which will cause problems if the module is reloaded. To counter these, I have introduced two helper functions: - dma_set_mask_and_coherent() takes care of setting both the streaming and coherent masks at the same time, with the correct error handling as specified by the API. - dma_coerce_mask_and_coherent() which resolves the problem of drivers forcefully setting DMA masks. This is more a marker for future work to further clean these locations up - the code which creates the devices really should be initialising these, but to fix that in one go along with this change could potentially be very disruptive. The last thing this series does is prise away some of Linux's addition to "DMA addresses are physical addresses and RAM always starts at zero". We have ARM LPAE systems where all system memory is above 4GB physical, hence having DMA masks interpreted by (eg) the block layers as describing physical addresses in the range 0..DMAMASK fails on these platforms. Santosh Shilimkar addresses this in this series; the patches were copied to the appropriate people multiple times but were ignored. Fixing this also gets rid of some ARM weirdness in the setup of the max*pfn variables, and brings ARM into line with every other Linux architecture as far as those go" * 'for-linus-dma-masks' of git://git.linaro.org/people/rmk/linux-arm: (52 commits) ARM: 7805/1: mm: change max*pfn to include the physical offset of memory ARM: 7797/1: mmc: Use dma_max_pfn(dev) helper for bounce_limit calculations ARM: 7796/1: scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations ARM: 7795/1: mm: dma-mapping: Add dma_max_pfn(dev) helper function ARM: 7794/1: block: Rename parameter dma_mask to max_addr for blk_queue_bounce_limit() ARM: DMA-API: better handing of DMA masks for coherent allocations ARM: 7857/1: dma: imx-sdma: setup dma mask DMA-API: firmware/google/gsmi.c: avoid direct access to DMA masks DMA-API: dcdbas: update DMA mask handing DMA-API: dma: edma.c: no need to explicitly initialize DMA masks DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks DMA-API: crypto: remove last references to 'static struct device *dev' DMA-API: crypto: fix ixp4xx crypto platform device support DMA-API: others: use dma_set_coherent_mask() DMA-API: staging: use dma_set_coherent_mask() DMA-API: usb: use new dma_coerce_mask_and_coherent() DMA-API: usb: use dma_set_coherent_mask() DMA-API: parport: parport_pc.c: use dma_coerce_mask_and_coherent() DMA-API: net: octeon: use dma_coerce_mask_and_coherent() DMA-API: net: nxp/lpc_eth: use dma_coerce_mask_and_coherent() ...
| * DMA-API: net: b43: replace dma_set_mask()+dma_set_coherent_mask() with new ↵Russell King2013-09-21
| | | | | | | | | | | | | | | | | | | | | | | | | | helper Replace the following sequence: dma_set_mask(dev, mask); dma_set_coherent_mask(dev, mask); with a call to the new helper dma_set_mask_and_coherent(). Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-09 01:14:08 -0400