- 13 Dec, 2011 31 commits
-
-
Arend van Spriel authored
The dma.c source file now uses the register access functions provided by bcma. Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by:
Alwin Beukers <alwin@broadcom.com> Signed-off-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
Franky Lin <frankyl@broadcom.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Arend van Spriel authored
Using BCMA hides the specifics about the host interface. The driver is now using the DMA-API to do dma related calls. BCMA provides the device object to use in the DMA-API calls. Reviewed-by:
-
Arend van Spriel authored
The driver now uses the bcma register access functions to read and write the registers on the 802.11 core. The dma and phy code need to be modified next and access to the other cores. That will be done in coming patches. Reviewed-by:
-
Arend van Spriel authored
The core enumeration rom is already parsed by the bcma bus driver and there is no need to repeat the exercise. The ai_scan() function still exists but is targetted for removal as well. Reviewed-by:
-
Arend van Spriel authored
The ai_attach now takes a bcma_bus object as its parameter to obtain all required information needed for chip control. Reviewed-by:
-
Arend van Spriel authored
When moving to bcma usage there are two busses in play. The pci bus connecting the device to the host and the bcma bus connecting the cores in the device. To distinguish this the attribute pbus has been renamed to a more explicit name, ie. pcibus. Reviewed-by:
-
Arend van Spriel authored
The driver is probed through bcma which provides a device representing the core. This device is now passed in brcms_c_attach and brcms_b_attach functions. Reviewed-by:
-
Arend van Spriel authored
A new bus driver called "bcma" has been introduced into the kernel tree which considers the Broadcom AMBA chip interconnect as a bus. Each core in the chip is a bcma device. This commit changes brcms_mac80211.c into a bcma device driver. Reviewed-by:
-
Arend van Spriel authored
Instead of directly accessing the fields in struct si_pub the driver now uses inline access functions. This is in preparation of the bcma integration as a lot of information will be provided by bcma module. Reviewed-by:
Roland Vossen <rvossen@broadcom.com> Signed-off-by:
-
Arend van Spriel authored
The structure si_pub contained couple of fields that were only used internally in aiutils.c. These have been moved to the si_info structure. Reviewed-by:
-
Arend van Spriel authored
Several fields from the si_pub structure were not used or only set once but never checked. These fields have been removed. Reviewed-by:
-
Arend van Spriel authored
Just scratching an itch here, but it makes more sense to use the static keyword if you think about how the compiler treats inline functions. Reviewed-by:
-
Arend van Spriel authored
The BCMA header only had definitions for 32-bit register access. Used those as a template for the 16-bit flavour. Also changed them to inline functions to be on the safe side. As offset parameter is used twice there would be a problem when used like this: bcma_set32(core, offset++, val); Reviewed-by:
-
Franky Lin authored
bcm4325 and bcm4336 are not supported by brcmfmac. Remove the drive strength setting code specific for these chips. Reviewed-by:
-
Franky Lin authored
This patch adds support for bcm4330 chip which has a SDIO device id 0x4330. All basic functionalities of bcm4330 are supported by brcmfmac after this patch. Reviewed-by:
-
Franky Lin authored
Some shared structures in fullmac have a wrong combination of version number and declarations. This patch fixes it by upgrading them to the latest version. This allows brcmfmac to support new firmwares with new features. Reviewed-by:
-
Franky Lin authored
bus interface was stored in sdio card device. The device pointer is used as parameter of interface functions between common layer and bus layer to make the function declaration generic for different bus type. But the card device is a parent device layer for SDIO function devices. It doesn't contain all contexts needed by udev. This patch moves the shared structure to private driver data pointer of SDIO function 2 device which is more appopriate for net device and cfg80211 registration. Reviewed-by:
-
Rajkumar Manoharan authored
Regulatory updates set by CORE are ignored for custom regulatory cards. Let us notify the changes to the driver, as some drivers uses core hint to restore its orig_* reg domain setting. Cc: Paul Stewart <pstew@google.com> Signed-off-by:
Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Acked-by:
Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by:
-
Rajkumar Manoharan authored
Whenever the regulatory got updated by country IE for the world roaming cards, need to reconfigure the tx power immediately to increase the power level. Reviewed-by:
Sam Leffler <sleffler@google.com> Signed-off-by:
-
Luis R. Rodriguez authored
When we receive a country IE hint and we have a world roaming card we can optimize output power further by ensuring that we use the calibrated data for the country by using that country's own CTL data. That is -- when world roaming and when we process a country IE we no longer need to use the lowest output power of all CTLs instead we use an optimized CTL output power for that specific country. We accomplish this by copying the regulatory data prior on init and restoring it when cfg80211 tells us it gets a core hint. Core hints are only sent on init and when it wants to restore reguulatory settings. We take advantage of this fact and apply the cached regulatory data when we get a core hint. When we get a country IE hint though we process the regulatory data as if programmed for a specific country. Tested-by:
-
Luis R. Rodriguez authored
This has no functional change. The helper can be used later for other things like country IE changes and following the CTL for different countries. Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Helmut Schaa authored
Use ieee80211_is_data, ieee80211_is_mgmt and ieee80211_is_first_frag in the tx status path. This makes the code easier to read and allows us to remove two local variables: frag and type. Signed-off-by:
Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by:
-
Helmut Schaa authored
Signed-off-by:
-
Yogesh Ashok Powar authored
When a station leaves suddenly while ampdu traffic to that station is still running, there is a possibility that the ampdu pending queues are not freed due to a race condition leading to memory leaks. In '__sta_info_destroy' when we attempt to destroy the ampdu sessions in 'ieee80211_sta_tear_down_BA_sessions', the driver calls 'ieee80211_stop_tx_ba_cb_irqsafe' to delete the ampdu structures (tid_tx) and splice the pending queues and this job gets queued in sdata workqueue. However, the sta entry can get destroyed before the above work gets scheduled and hence the race. Purging the queues and freeing the tid_tx to avoid the leak. The better solution would be to fix the race, but that can be taken up in a separate patch. Signed-off-by:
Nishant Sarmukadam <nishants@marvell.com> Signed-off-by:
Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by:
-
Vasanthakumar Thiagarajan authored
It is quite possible to run into a race in bss timeout where the drivers see the bss entry just before notifying cfg80211 of a roaming event but it got timed out by the time rdev->event_work got scehduled from cfg80211_wq. This would result in the following WARN-ON() along with the failure to notify the user space of the roaming. The other situation which is happening with ath6kl that runs into issue is when the driver reports roam to same AP event where the AP bss entry already got expired. To fix this, move cfg80211_get_bss() from __cfg80211_roamed() to cfg80211_roamed(). [158645.538384] WARNING: at net/wireless/sme.c:586 __cfg80211_roamed+0xc2/0x1b1() [158645.538810] Call Trace: [158645.538838] [<c1033527>] warn_slowpath_common+0x65/0x7a [158645.538917] [<c14cfacf>] ? __cfg80211_roamed+0xc2/0x1b1 [158645.538946] [<c103354b>] warn_slowpath_null+0xf/0x13 [158645.539055] [<c14cfacf>] __cfg80211_roamed+0xc2/0x1b1 [158645.539086] [<c14beb5b>] cfg80211_process_rdev_events+0x153/0x1cc [158645.539166] [<c14bd57b>] cfg80211_event_work+0x26/0x36 [158645.539195] [<c10482ae>] process_one_work+0x219/0x38b [158645.539273] [<c14bd555>] ? wiphy_new+0x419/0x419 [158645.539301] [<c10486cb>] worker_thread+0xf6/0x1bf [158645.539379] [<c10485d5>] ? rescuer_thread+0x1b5/0x1b5 [158645.539407] [<c104b3e2>] kthread+0x62/0x67 [158645.539484] [<c104b380>] ? __init_kthread_worker+0x42/0x42 [158645.539514] [<c151309a>] kernel_thread_helper+0x6/0xd Reported-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com> Signed-off-by:
-
Dan Carpenter authored
We recently introduced a new return here but it needs an unlock first. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Mohammed Shafi Shajakhan authored
in my previous patches of handling MCI interrupt I overlooked the case of interrupt status/mask variable being zeroed out in the below code, so ath_isr does not cache the MCI interrupt in the intrstatus. finally MCI interrupt handling won't be handled in ath9k_tasklet for the scheduled interrupts. Fix this by moving the MCI interrupt code in the appropriate position in ar9003_hw_get_isr Cc: Wilson Tsao <wtsao@qca.qualcomm.com> Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by:
Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by:
-
Mohammed Shafi Shajakhan authored
in ar9003_hw_get_isr we bail out if we don't have any primary interrupts and synchronous interrupts, also make sure we don't have any asynchronous interrupts Signed-off-by:
-
-
- 09 Dec, 2011 2 commits
-
-
Nikolay Martynov authored
It looks like the regression was introduced between 20111202 and 20111205 (linux-next tree). Symptoms: connection to AP seem to be established, but no data goes though it in any way. Tested on intel 5300. Peek at the changes have shown that it looks like at least part of the code wasn't merged properly. It was originally committed into iwl_agn.c but code in question was moved to iwl-mac80211.c. This patch puts code in place and my card works again. Signed-off-by:
Nikolay Martynov <mar.kolya@gmail.com> Signed-off-by:
-
John W. Linville authored
CC [M] drivers/net/wireless/wl12xx/tx.o drivers/net/wireless/wl12xx/tx.c: In function ‘wl1271_tx_fill_hdr’: drivers/net/wireless/wl12xx/tx.c:288:6: warning: ‘tx_attr’ may be used uninitialized in this function Signed-off-by:
-
- 08 Dec, 2011 7 commits
-
-
Johannes Berg authored
We track the load only on 8 TIDs, previously this was TID_MAX_LOAD_COUNT. Since IWL_MAX_TID_COUNT is now 8 as well, use that to make the code more easily understandable. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
Now that I corrected IWL_MAX_TID_COUNT to be 8 instead of 9, we can use it in WoWLAN suspend. Signed-off-by:
-
Johannes Berg authored
The driver everywhere uses max TID count as 9, which is wrong, it should be 8. I think the reason it uses 9 here is off-by-one confusion by whoever wrote this. We do use the value IWL_MAX_TID_COUNT for "not QoS/no TID" but that is completely correct even if it is 8 and not 9 since 0-7 are only valid. As a side effect, this fixes the following bug: Open BA session requested for 00:23:cd:16:8a:7e tid 8 ------------[ cut here ]------------ kernel BUG at drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h:350! ... when you do echo "tx start 8" > /sys/kernel/debug/ieee80211/*/*/*/*/agg_status Cc: stable@vger.kernel.org Reported-by:
-
Don Fry authored
Move the calib_results list from the upper layer iwl_priv structure to the lower layer iwl_trans structure. Signed-off-by:
Don Fry <donald.h.fry@intel.com> Signed-off-by:
-
Don Fry authored
Move the low level ucode device_pointers structure to iwl_shared. Signed-off-by:
-
Don Fry authored
The eeprom image is a device level component, move from iwl_priv to iwl_shared, with associated code changes. Signed-off-by:
-
Wey-Yi Guy authored
It is needed by firmware to use the correct rate for BAR frame transmission Signed-off-by:
-
