The various rt2x00 drivers use different methods to name the different
GPIO register fields indicating the GPIO pin value and the fields
indicating the direction.
Start using a unified naming scheme for the GPIO register fields:
- <csr>_VAL<x> for fields indicating the GPIO pin value.
- <csr>_DIR<x> for fields indicating the GPIO pin direction.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo Van Doorn <ivdoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Ensure that all active GPIO pins are included in the GPIO register
definitions, nothing more and nothing less.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo Van Doorn <ivdoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The latest version of the vendor driver for the rtlwifi family
includes many changes. This patch incorporates the difference
in the main header file.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The rtlwifi family of drivers has the following sparse errors:
CHECK drivers/net/wireless/rtlwifi/usb.c
drivers/net/wireless/rtlwifi/usb.c:122:17: warning: cast to restricted __le32
CHECK drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:1157:13: warning: context imbalance in 'rtl92c_dm_refresh_rate_adaptive_mask' - different lock contexts for basic block
CHECK drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c:1909:30: warning: cast to restricted __le32
CHECK drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
drivers/net/wireless/rtlwifi/rtl8192ce/sw.c:345:1: warning: symbol 'rtl92ce_pci_ids' was not declared. Should it be static?
CHECK drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
drivers/net/wireless/rtlwifi/rtl8192cu/trx.c:494:9: warning: cast from restricted __le16
CHECK drivers/net/wireless/rtlwifi/rtl8192se/fw.c
drivers/net/wireless/rtlwifi/rtl8192se/fw.c:490:17: warning: cast to restricted __le32
drivers/net/wireless/rtlwifi/rtl8192se/fw.c:490:17: warning: cast to restricted __le32
drivers/net/wireless/rtlwifi/rtl8192se/fw.c:494:17: warning: cast to restricted __le32
drivers/net/wireless/rtlwifi/rtl8192se/fw.c:494:17: warning: cast to restricted __le32
drivers/net/wireless/rtlwifi/rtl8192se/fw.c:499:17: warning: cast to restricted __le32
drivers/net/wireless/rtlwifi/rtl8192se/fw.c:499:17: warning: cast to restricted __le32
drivers/net/wireless/rtlwifi/rtl8192se/fw.c:510:25: warning: cast to restricted __le32
drivers/net/wireless/rtlwifi/rtl8192se/fw.c:510:25: warning: cast to restricted __le32
drivers/net/wireless/rtlwifi/rtl8192se/fw.c:607:9: warning: cast to restricted __le16
drivers/net/wireless/rtlwifi/rtl8192se/fw.c:607:9: warning: cast to restricted __le16
drivers/net/wireless/rtlwifi/rtl8192se/fw.c:650:9: warning: cast to restricted __le16
drivers/net/wireless/rtlwifi/rtl8192se/fw.c:650:9: warning: cast to restricted __le16
drivers/net/wireless/rtlwifi/rtl8192se/fw.c:652:9: warning: cast to restricted __le16
drivers/net/wireless/rtlwifi/rtl8192se/fw.c:652:9: warning: cast to restricted __le16
CHECK drivers/net/wireless/rtlwifi/rtl8192se/trx.c
drivers/net/wireless/rtlwifi/rtl8192se/trx.c:758:9: warning: cast from restricted __le32
drivers/net/wireless/rtlwifi/rtl8192se/trx.c:788:17: warning: cast from restricted __le32
drivers/net/wireless/rtlwifi/rtl8192se/trx.c:804:17: warning: cast to restricted __le32
drivers/net/wireless/rtlwifi/rtl8192se/trx.c:804:17: warning: cast to restricted __le32
drivers/net/wireless/rtlwifi/rtl8192se/trx.c:807:17: warning: cast from restricted __le32
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since mwifiex_ds_misc_subsc_evt is used in an asynchronous case,
store the structure in the long-lived mwifiex_private instead of
on the calling stack.
This fixes a problem where the response of the asynchronous
operation would corrupt a stack frame potentially in use by
a different thread.
Signed-off-by: Jeff Disher <disher@chromium.org>
Reviewed-by: Sam Leffler <sleffler@chromium.org>
Tested-by: Jeff Disher <disher@chromium.org>
Acked-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This change adds callback for nl80211 testmode, which can be used
for testing and debugging purposes with driver and firmware.
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Added usb device id to list of supported devices. 43143 is a new
802.11n single stream device.
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Added usb device id to list of supported devices. 43242 is the new
802.11n 2x2 MIMO device.
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
BCM43241 is an 11abg and 2x2 11n Wifi/BT/FM combo chip that
supports 40MHz channel width. This patch intends to enable
the driver support for the chip through SDIO bus interface.
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Arend van Spriel <arend@broadcom.com>
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Franky Lin <frankyl@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
brcmf_usb_tx_ctlpkt sends message using brcmf_usb_send_ctl then
clears boolean and waits for boolean to be set (by another
thread). This can result in situation where flag gets cleared
while result was already received. First clearing the flag and
then sending the data will prevent this.
Reviewed-by: Arend Van Spriel (arend@broadcom.com)
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The TX filter bit for a station would be set by the HW
when a frame is not acked. A frame would be completed with
ATH9K_TXERR_FILT status only when the corresponding filter bit
for the destination station is already set.
Currently, un-acknowledged packets are added to the pending queue
and retried, but the "clear_dest_mask" bit in the descriptor is
set only when the TX status has been ATH9K_TXERR_FILT. This results
in packet loss and the log shows:
wlan0: dropped TX filtered frame, queue_len=0 PS=0 @4309746071
wlan0: dropped TX filtered frame, queue_len=0 PS=0 @4309746076
wlan0: dropped TX filtered frame, queue_len=0 PS=0 @4309746377
...
...
This issue can be resolved by making sure that the destination
mask is cleared when the packet is being retried and the earlier
TX status is ATH9K_TXERR_XRETRY.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove pointless conditional before kfree_skb().
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove pointless conditional before kfree_skb().
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use is_zero_ether_addr() instead of directly using memcmp() to
determine if the ethernet address is all zeros.
Cc: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds support for parsing rates from cfg80211_ap_settings
of start_ap handler. This in turn adds support for 11a and 11b phy
configurations.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We should not disable "cmd_node->wait_q_enabled" flag here before
calling mwifiex_insert_cmd_to_free_q() because we want to wake up
the thread waiting for command completion inside this function.
The wait_q_enabled flag will be disabled internally upon command
completion.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If "iw connect" command is fired for station interface, when
heavy traffic is running on AP interface, internal scan operation
performed before actual association is aborted. In this case we
missed to release semaphore.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Using is_broadcast_ether_addr() instead of directly use
memcmp() to determine if the ethernet address is broadcast
address.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Using is_broadcast_ether_addr() instead of directly use
memcmp() to determine if the ethernet address is broadcast
address.
spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Assign the MCI BT state locally, rather than unnecessarily calling
ar9003_mci_state and updating it.
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Using is_zero_ether_addr() instead of directly use
memcmp() to determine if the ethernet address is all
zeros.
spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Using is_broadcast_ether_addr() instead of directly use
memcmp() to determine if the ethernet address is broadcast
address.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Using is_zero_ether_addr() and is_broadcast_ether_addr() instead of
directly use memcmp() to determine if the ethernet address is all zeros.
spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Using is_zero_ether_addr() instead of directly use
memcmp() to determine if the ethernet address is all
zeros.
spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Using is_zero_ether_addr() instead of directly use
memcmp() to determine if the ethernet address is all
zeros.
spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Using is_zero_ether_addr() and is_broadcast_ether_addr() instead of
directly use memcmp() to determine if the ethernet address is all zeros.
spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Using is_zero_ether_addr() and is_broadcast_ether_addr() instead of
directly use memcmp() to determine if the ethernet address is all zeros.
spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It is not necessary to hold the firmware memory during the whole
driver lifetime, and obviously it does waste memory. Suppose there
are 4 ath9k-htc usb dongles working, kernel has to consume about
4*50KBytes RAM to cache firmware for all dongles. After applying the
patch, kernel only caches one single firmware image in RAM for
all ath9k-htc devices just during system suspend/resume cycle.
When system is ready for loading firmware, ath9k-htc can request
the loading from usersapce. During system resume, ath9k-htc still
can load the firmware which was cached in kernel memory before
system suspend.
Cc: ath9k-devel@lists.ath9k.org
Cc: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
Cc: Jouni Malinen <jouni@qca.qualcomm.com>
Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
bcma_scan_bus allocates a bcma_core for each core found on the bus, but the
memory for cores handled by the bcma driver itself was not being freed when
the bus was unregistered. This patch adds special handling for the PCIE,
MIPS, and GBIT COMMON cores, to ensure that their memory allocation is
freed as well.
Note that this patch doesn't address the memory allocated for the CC core,
as that was corrected in my previous patch "bcma: register cc core driver,
device."
Cc: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Saul St. John <saul.stjohn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the interface is down, the hardware is powered off.
However, the suspend handler currently tries to send host sleep commands
(when wakeup params are set) in this configuration, causing a system hang
when going into suspend (the commands will never complete).
Avoid this by detecting this situation and simply returning from
the suspend handler without doing anything special.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On our system (ARM Cortex-M3 SOC running linux-2.6.33)
frequent crashes were observed in the rt2800usb module
because of the invalid length of the received packet (3392,
46920...). This patch adds the sanity check on the packet
legth. Also, changed WARNING to ERROR in rt2x00lib_rxdone()
so that the bad packet condition would be noticed.
The fix was tested on the latest compat-wireless-3.5.1-1-snpc.
Cc: stable@vger.kernel.org
Signed-off-by: Sergei Poselenov <sposelenov@emcraft.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We need to program the rfkill switch GPIO pin direction to input at
device initialization time, not only when the interface is brought up.
Doing this only when the interface is brought up could lead to rfkill
detecting the switch is turned on erroneously and inability to create
the interface and bringing it up.
Reported-and-tested-by: Andreas Messer <andi@bastelmap.de>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Cc: <stable@vger.kernel.org>
Acked-by: Ivo Van Doorn <ivdoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The register is 16 bits wide, not 32.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Cc: <stable@vger.kernel.org>
Acked-by: Ivo Van Doorn <ivdoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is an RT3572 based device.
Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Cc: <stable@vger.kernel.org>
Acked-by: Ivo Van Doorn <ivdoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The function brcmf_cfg80211_get_station requests the RSSI from
the device. The complete structure used needs to be cleared
before sending the request to firmware. Otherwise the request
fails filling the logs with "Could not get rssi (-2)" messages.
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On both rx and tx there is was a race condition on the queueing
of usb requests. When for example frame gets submitted it is
possible that complete function gets called even before
usb_submit_urb() returns. As a result it is possible that usb
requests get losts, which was noticed on OMAP4 pandaboard
platform. This patch fixes the race condition.
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
URB_ZERO_PACKET should only be set or bulk OUT and this condition
is checked with a WARN_ON in usb_submit_urb(). This patch fixes
brcmfmac to get rid of this warning filling the logs.
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The USB part of the brcmfmac did a dev_kfree_skb() that resulted
in a warning in net/core/skbuff.c:
Jul 11 04:53:33 lb-bun-10 kernel: [53282.667745] WARNING: at
net/core/skbuff.c:490 skb_release_head_state+0xcc/0xe0()
The brcmutil modules provides brcmu_pkt_buf_free_skb() which takes
the context into account. This patch makes use of this function
instead of dev_kfree_skb().
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This feature had been disabled in ath9k because the code to support
it was incomplete, but now the code is in sync with the internal QCA
codebase, so it's time to enable it.
On many newer devices, the calibration is assumed to be done with PA
linearization enabled.
Tests with a particular AR933x device showed that the signal emitted
at full power was highly distorted and unreliable with PA linearization
disabled. With this patch, the signal becomes clear and stability
is improved.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Before PAPRD training can run, the card needs to have sent a packet for
thermal calibration. Sending a dummy packet with the PAPRD training flag
set causes a crash under some circumstance.
Fix the code by replacing the dummy tx with a delay that waits for a
real packet tx to have occurred.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Re-train if the calibrated PA linearization curve is out of bounds
(affects AR933x and AR9485).
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Gertjan van Wingerde