The ai_attach now takes a bcma_bus object as its parameter to
obtain all required information needed for chip control.
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>
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: 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>
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: 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>
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: 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>
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: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Alwin Beukers <alwin@broadcom.com>
Reviewed-by: Roland Vossen <rvossen@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>
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: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Alwin Beukers <alwin@broadcom.com>
Reviewed-by: Roland Vossen <rvossen@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>
Several fields from the si_pub structure were not used or only set
once but never checked. These fields have been removed.
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Alwin Beukers <alwin@broadcom.com>
Reviewed-by: Roland Vossen <rvossen@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>
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: 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>
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: 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>
bcm4325 and bcm4336 are not supported by brcmfmac. Remove the
drive strength setting code specific for these chips.
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Franky Lin <frankyl@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Franky Lin <frankyl@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Arend van Spriel <arend@broadcom.com>
Reviewed-by: Alwin Beukers <alwin@broadcom.com>
Signed-off-by: Franky Lin <frankyl@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Franky Lin <frankyl@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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: John W. Linville <linville@tuxdriver.com>
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: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Acked-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Acked-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Acked-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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: John W. Linville <linville@tuxdriver.com>
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: John W. Linville <linville@tuxdriver.com>
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: John W. Linville <linville@tuxdriver.com>
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: John W. Linville <linville@tuxdriver.com>
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: John W. Linville <linville@tuxdriver.com>
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: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The stations always chooses 1Mbps for all trasmitting frames,
whenever the AP is configured to lock the supported rates.
As the max phy rate is always set with the 4th from highest phy rate,
this assumption might be wrong if we have less than that. Fix that.
Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Reported-by: Ajay Gummalla <agummalla@google.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
wait_for_completion_interruptible_timeout() returns -ERESTARTSYS if
interrupted so completion_rc needs to be signed. The current code
probably returns -ETIMEDOUT if we hit this situation, but after this
patch is applied it will return -ERESTARTSYS.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Check the IEEE80211_TX_CTL_ASSIGN_SEQ flag from mac80211, then decide how to
set the TX_CMD_FLG_SEQ_CTL_MSK bit. Setting the wrong bit in BAR frame whill
make the firmware to increment the sequence number which is incorrect and
cause unknown behavior.
CC: stable@vger.kernel.org #3.0+
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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 <linville@tuxdriver.com>
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: John W. Linville <linville@tuxdriver.com>
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>
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 <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
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: Nikolay Martynov <mar.kolya@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
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: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Move the low level ucode device_pointers structure to iwl_shared.
Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The eeprom image is a device level component, move from iwl_priv
to iwl_shared, with associated code changes.
Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
P2P still under development. it will not enabled by default, but user
always can enable it manually for testing.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Create new tm command to report devce ID information to userspace
- IWL_TM_CMD_APP2DEV_GET_DEVICE_ID
Signed-off-by: Kenny Hsu <kenny.hsu@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
When uCode encounter problem, it pass a lot of debug data to help debugging
the issue. We only show partial data before, why not display all of those.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Because the testmode support should be the mandatory foundation
of test functionality, it is better to set kernel option
IWLWIFI_DEVICE_SVTOOL automatically instead of user configuration.
Signed-off-by: Kenny Hsu <kenny.hsu@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Create new tm command to report uCode version to userspace
- IWL_TM_CMD_APP2DEV_GET_FW_VERSION
Signed-off-by: Kenny Hsu <kenny.hsu@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
This fixes a Data bus error on some SoCs. The first fix for this
problem did not solve it on all devices.
commit 6ae8ec2786
Author: Rafał Miłecki <zajec5@gmail.com>
Date: Tue Jul 5 17:25:32 2011 +0200
ssb: fix init regression of hostmode PCI core
In ssb_pcicore_fix_sprom_core_index() the sprom on the PCI core is
accessed, but the sprom only exists when the ssb bus is connected over
a PCI bus to the rest of the system and not when the SSB Bus is the
main system bus. SoCs sometimes have a PCI host controller and there
this code will not be executed, but there are some old SoCs with an PCI
controller in client mode around and ssb_pcicore_fix_sprom_core_index()
should not be called on these devices too. The PCI controller on these
devices are unused, but without this fix it results in an Data bus
error when it gets initialized.
Cc: Michael Buesch <m@bues.ch>
Cc: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
