- 10 Mar, 2013 1 commit
-
-
Samuel Ortiz authored
The mei_device field should be called device, not mei_device. Signed-off-by:Samuel Ortiz <sameo@linux.intel.com>
-
- 08 Mar, 2013 5 commits
-
-
Bing Zhao authored
drivers/net/wireless/mwifiex/cfg80211.c:2357 mwifiex_cfg80211_suspend() error: potential null dereference 'mef_entry' (kzalloc returns null) Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Ashok Nagarajan authored
tx_timeout doesn't always lead to a cmd_timeout. There are occurrences where cmd_timeout never gets triggered for a long time and we encounter a kernel crash. In this patch, we track the consecutive timeouts (tx_timeout_cnt). When tx_timeout_cnt exceeds the threshold, trigger a card reset thereby avoiding a kernel crash. Signed-off-by:
Ashok Nagarajan <asnagarajan@chromium.org> Signed-off-by:
Paul Stewart <pstew@chromium.org> Signed-off-by:
-
Jussi Kivilinna authored
Signed-off-by:
Jussi Kivilinna <jussi.kivilinna@iki.fi> Signed-off-by:
-
-
-
- 06 Mar, 2013 34 commits
-
-
Amitkumar Karwar authored
Currently 'magic-packet' and 'patterns' options in 'iw wowlan' command are supported. Appropriate packet filters for wowlan are configured in firmware based on provided patterns and/or magic-packet option. For examples, wake-on ARP request for 192.168.0.100: iw phy0 wowlan enable patterns ff:ff:ff:ff:ff:ff 20+08:06 46+c0:a8:00:64 wake-on RX packets sent from IP address 192.168.0.88: iw phy0 wowlan enable patterns 34+c0:a8:00:58 wake-on RX packets with TCP destination port 80 iw phy0 wowlan enable patterns 44+50 wake-on MagicPacket: iw phy0 wowlan enable magic-packet wake-on MagicPacket or patterns: iw phy0 wowlan enable magic-packet patterns 12+00:11:22:33:44:55 18+00:50:43:21 wake-on IPv4 multicast packets: iw phy0 wowlan enable patterns 01:00:5e wake-on IPv6 multicast packets: iw phy0 wowlan enable patterns 33:33 disable all wowlan options iw phy0 wowlan disable Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
-
Amitkumar Karwar authored
Host sleep wakeup condition is configured using this command. Supports Wake-on: pumb For examples: wake-on any unicast packets: ethtool -s mlan0 wol u wake-on multicast/broadcast packet: ethtool -s mlan0 wol mb wake-on unicast packets and MAC events: ethtool -s mlan0 wol pu wake-on unicast/multicast/broadcast packets and MAC events: ethtool -s mlan0 wol pmbu disable all wake-on options: ethtool -s mlan0 wol d Signed-off-by:
-
Amitkumar Karwar authored
As we are adding a few more macros in this category in next patch, this cleanup work is required. Signed-off-by:
-
Avinash Patil authored
We allocate SKB buffers of 4K size to make sure that we process RX AMSDU of 4K. So when skb->len is lesser than 4K; we should modify skb->truesize. This resolves an issue where kernel has allocated packets with 2K assumption and starts dropping packets for large size data transfer. This fix is already present for USB; extend it to PCIE. Signed-off-by:
Avinash Patil <patila@marvell.com> Signed-off-by:
-
Bing Zhao authored
drivers/net/wireless/mwifiex/pcie.c:1157:9: warning: 'desc2' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/net/wireless/mwifiex/pcie.c:1048:31: note: 'desc2' was declared here drivers/net/wireless/mwifiex/pcie.c:1159:9: warning: 'desc' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/net/wireless/mwifiex/pcie.c:1047:32: note: 'desc' was declared here Reported-by:
-
Bing Zhao authored
drivers/net/wireless/mwifiex/pcie.c:204:12: warning: 'mwifiex_pcie_resume' defined but not used [-Wunused-function] drivers/net/wireless/mwifiex/pcie.c:166:12: warning: 'mwifiex_pcie_suspend' defined but not used [-Wunused-function] The suspend/resume handlers ought to be under CONFIG_PM directive. Reported-by:
-
Bing Zhao authored
move functions up just to avoid static forward declaration for mwifiex_pcie_resume. Signed-off-by:
-
Ben Greear authored
Signed-off-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
-
Ben Greear authored
Signed-off-by:
-
Rafał Miłecki authored
HT-PHY was found only on BCM4331 which is a BCMA-based chipset. This is reallly unlikely we will ever see HT-PHY on SSB thus make the whole code BCMA specific. This will allow us to call various BCMA-specific functions directly (without extra checks). Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
Sujith Manoharan authored
When the RX chainmask is set to 0x2 for AR9462, certain values from chain1 have to be programmed for chain0 also. Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
-
Sujith Manoharan authored
Signed-off-by:
-
Sujith Manoharan authored
Signed-off-by:
-
Sujith Manoharan authored
This flag is used for indicating channel interference and we currently do nothing with it, so remove it. Signed-off-by:
-
Arend van Spriel authored
The function brcmf_proto_hdrpush() increases the header space and fills in the protocol header fields. One field is the data offset which is currently fixed to zero meaning the data follows right after the header. The parameter is added to determine the actual start of data. This will be used for firmware signalling. Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by:
Hante Meuleman <meuleman@broadcom.com> Reviewed-by:
Piotr Haber <phaber@broadcom.com> Signed-off-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
-
Arend van Spriel authored
Adding a packet dequeue function that will return packets that pass the provided match function. Reviewed-by:
-
Arend van Spriel authored
For transmit packets the function brcmf_txcomplete() must be called. This should be done as well when for some reason the transmit fails to assure proper tx post processing. This patch fixes the code paths in brcmf_usb_tx() that forgot to do so. Reviewed-by:
-
Arend van Spriel authored
In the bus-specific driver code each call to brcmf_txcomplete() is following by a free of that packet. This patch moves that free to the brcmf_txcomplete() function. Reviewed-by:
-
Arend van Spriel authored
The firmware and host can exchange signals which are carried within the data packets. These are TLV based signals that are inserted before the actual data, ie. ethernet frame. This commit adds the new source module for this feature and enables RSSI signals from firmware. Reviewed-by:
-
Arend van Spriel authored
Added inline functions to set bitfields in an unsigned integer variable. Reviewed-by:
-
Arend van Spriel authored
In preparation of firmware signalling feature additional headroom is needed to accommodate signalling protocol data between host and firmware. Reviewed-by:
-
Arend van Spriel authored
In brcmf_cfg80211_sched_scan_start() the request parameter was checked for being non-null. However, it never is so remove the check which gets rid of following smatch warning: drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c:2904 brcmf_cfg80211_sched_scan_start() warn: variable dereferenced before check 'request' (see line 2897) Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Arend van Spriel authored
The output of modinfo shows a bit of strangeness because module information macros are used in multiple source files: license: Dual BSD/GPL description: Broadcom 802.11 wireless LAN fullmac driver. author: Broadcom Corporation firmware: brcm/brcmfmac-sdio.txt firmware: brcm/brcmfmac-sdio.bin firmware: brcm/brcmfmac43236b.bin license: Dual BSD/GPL description: Broadcom 802.11n wireless LAN fullmac usb driver. author: Broadcom Corporation This patch cleans it up. Signed-off-by:
-
Arend van Spriel authored
The module parameter definition for brcmf_msg_level has been reworked to a named module parameter with description so modinfo is a bit more informative: parm: debug:level of debug output (int) Reviewed-by:
-
Arend van Spriel authored
Inspired by tracing functionality added by Seth Forshee in the brcmsmac driver, this patch adds similar functionality to brcmfmac. Reviewed-by:
-
Piotr Haber authored
Add support for radio on led indicator. Control led via BCMA gpio driver. Reviewed-by:
-
Nishant Sarmukadam authored
This differs from legacy chips i.e. a 8764 loads firmware image without a helper image b Check interrupt status register for download complete indication. Signed-off-by:
Nishant Sarmukadam <nishants@marvell.com> Signed-off-by:
Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by:
-
Nishant Sarmukadam authored
The patch does the following:- a Add entry in the PCIe table b Add firmware support with API versioning c Reuse most of the 8366 code d Make 8764 specific changes where 8764 differs from 8366 e.g. structure definitions. Signed-off-by:
-
Dan Carpenter authored
It's harmless, but Smatch complains if we use "htc_hdr->eid" before doing the bounds check. Signed-off-by:
-
Chen Gang authored
When make with EXTRA_CFLAGS=-W, it will report error. so give a check in Makefile. Signed-off-by:
Chen Gang <gang.chen@asianux.com> Acked-by:
Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by:
-
Bob Copeland authored
Remove the embedded branch to make the ATH_EP_RND macro a little clearer. The new version also generates better code, saving 24 bytes of text: text data bss dec hex filename 87858 1641 24 89523 15db3 ath9k_orig.ko 87834 1641 24 89499 15d9b ath9k_new.ko Although neither version handles negative values particularly well, the lone caller clamps all negative values to zero anyway. I have verified that the results are the same for the range of possible positive rssi values. Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
-
Dan Carpenter authored
"translate" should either be set or disabled. We also use it an offset into the framing[] array when we're generating the proc file. Framing looks like this: static const char *framing[] = { "Encapsulation", "Translation" } So when we're setting translate we need to restrict the values to either 1 or 0 or it can an out of bounds read. Signed-off-by: -
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
