- 24 Jul, 2013 8 commits
-
-
Stone Piao authored
Before sending command to firmware, we need to check the frame type. We skip registering the mgmt frame that has already been registered. Signed-off-by:
Stone Piao <piaoyun@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Stone Piao authored
Some GO will send deauth or disassoc packet at the end of WPS handshake, which causes P2P connecion failure due to the race condition between event path and data path. Signed-off-by:
-
Huawei Yang authored
In function 'mwifiex_write_data_complete' it need tx info to find the mwifiex_private to updates statistics and wake up tx queues. Or we may trigger tx queues timeout when transmitting lots of mgmt frames. Signed-off-by:
Huawei Yang <harvey.huawei.yang@gmail.com> Signed-off-by:
-
Avinash Patil authored
Delete packets from TX queues for this mwifiex_private structure when bridged packet count reaches maximum threshold. Bridged packets from each RA List are deleted till they fall to low threshold of 128. Signed-off-by:
Avinash Patil <patila@marvell.com> Signed-off-by:
-
Avinash Patil authored
Maintain total outstanding packet count for RA list instead of total outstanding size as packet count metric seems more reasonable for checking threshold etc. Signed-off-by:
-
Avinash Patil authored
pkt_count is used to determine if BA can be formed on this RA list by comparing it with randomly generated BA threshold. The pkt_count variable name here is ambiguous and does not reflect its usage correctly. Rename it to ba_pkt_count. Signed-off-by:
-
Huawei Yang authored
Under uAP mode mwifiex may stop all net tx queues on forwarding packets. This may stop some tx queues and they never have chance to be waked up. There is also no need to check tx_pending and stop queues here. Because local host has such kind of check when transmitting packets and it's not proper to have forwarding affect local transmitting. Signed-off-by:
-
Eric Dumazet authored
Steinar reported reallocations of skb->head with IPv6, leading to a warning in skb_try_coalesce() It turns out iwl3945 has several problems : 1) skb->truesize is underestimated. We really consume PAGE_SIZE bytes for a fragment, not the frame length. 2) 128 bytes of initial headroom is a bit low and forces reallocations. 3) We can avoid consuming a full page for small enough frames. Reported-by:
Steinar H. Gunderson <sesse@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Paul Stewart <pstew@google.com> Acked-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
- 22 Jul, 2013 32 commits
-
-
Vladimir Kondratiev authored
In production code, don't use -Werror, as it causes random compilation failures due to compiler version and options used. With every new version of gcc, it becomes stricter and report more warnings. Signed-off-by:
Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by:
-
Kalle Valo authored
The git tree is in github.com nowadays. Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
-
Kalle Valo authored
I forgot to add an entry to MAINTAINERS when submitting the driver. Signed-off-by:
-
Kirshenbaum Erez authored
Add support for TCP and UDP HW checksum offloading. RX chain is allways configured for offload mode. In case of checksum error in RX path the DMA L4 error bit(5) will be set to 1 and driver will drop the packet. TX checksum offloading is configrable (ethtool -K). TX descriptors are configured for checksum offload according to the SKB protocol type (TCP/UDP, IPV4/6), Upon mismatch drop the TX packet (checksum required but not TCP/UDP IPV4/6 type). Signed-off-by:
Kirshenbaum Erez <erezk@wilocity.com> Signed-off-by:
-
Vladimir Kondratiev authored
Release fragments in the order of allocation; including one for skb head Signed-off-by:
-
Solomon Peachy authored
Note that the driver doesn't directly use this field, but it should be correctly defined in any case. Signed-off-by:
Solomon Peachy <pizza@shaftnet.org> Signed-off-by:
-
Sujith Manoharan authored
Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
-
Sujith Manoharan authored
* CUS217 specific initvals have to be programmed. * iniAdditional is not used for AR9462/AR9565, remove it. * Handle channel 2484 for regulatory compliance. Signed-off-by:
-
Sujith Manoharan authored
Signed-off-by:
-
Sujith Manoharan authored
Right now, even though these chips support cross-band FCC, the code is non-functional since we bail out early if the channelFlags differ. Fix this so that cross-band FCC works for cards that support this feature. Signed-off-by:
-
Sujith Manoharan authored
Fast Channel Change across 2G/5G bands is supported only by AR9462 and AR9565. Add a HW capability field to indicate this. Signed-off-by:
-
Sujith Manoharan authored
Signed-off-by:
-
John Greene authored
Relegate 2 phy messages to debug status as they create excessive log spam, noted in multiple bugzillas for brcmsmac v3.8 and up. This is a follow on to net-next 99e94940: brcmsmac: Reduce log spam in heavy tx, make err print in debug brcmsmac bcma0:0: phyerr 0x10, rate 0x14 brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) Signed-off-by:
John Greene <jogreene@redhat.com> Signed-off-by:
-
Hauke Mehrtens authored
The return value of bcma_erom_get_addr_desc() is a unsigned value and it could wrap around in the two complement writing. This happens for one core in the BCM4708 SoC. Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
Hauke Mehrtens authored
It is better to return the actual error code than just -1. Signed-off-by:
-
Hauke Mehrtens authored
These are the chipIDs of some ARM based SoCs from the BCM47xx line. Signed-off-by:
-
Hauke Mehrtens authored
To make it possible to use the SoC host interface with ARM SoCs do not depend on the MIPS driver any more. Signed-off-by:
-
Hauke Mehrtens authored
These cores were found on a BCM4708 (chipid 53010), this is a ARM SoC with two Cortex A9 cores. bcma: bus0: Found chip with id 0xCF12, rev 0x00 and package 0x02 bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x2A, class 0x0) bcma: bus0: Core 1 found: DMA (manuf 0x4BF, id 0x502, rev 0x01, class 0x0) bcma: bus0: Core 2 found: GBit MAC (manuf 0x4BF, id 0x82D, rev 0x04, class 0x0) bcma: bus0: Core 3 found: GBit MAC (manuf 0x4BF, id 0x82D, rev 0x04, class 0x0) bcma: bus0: Core 4 found: GBit MAC (manuf 0x4BF, id 0x82D, rev 0x04, class 0x0) bcma: bus0: Core 5 found: GBit MAC (manuf 0x4BF, id 0x82D, rev 0x04, class 0x0) bcma: bus0: Core 6 found: PCIe Gen 2 (manuf 0x4BF, id 0x501, rev 0x01, class 0x0) bcma: bus0: Core 7 found: PCIe Gen 2 (manuf 0x4BF, id 0x501, rev 0x01, class 0x0) bcma: bus0: Core 8 found: ARM Cortex A9 core (ihost) (manuf 0x4BF, id 0x510, rev 0x01, class 0x0) bcma: bus0: Core 9 found: USB 2.0 (manuf 0x4BF, id 0x504, rev 0x01, class 0x0) bcma: bus0: Core 10 found: USB 3.0 (manuf 0x4BF, id 0x505, rev 0x01, class 0x0) bcma: bus0: Core 11 found: SDIO3 (manuf 0x4BF, id 0x503, rev 0x01, class 0x0) bcma: bus0: Core 12 found: ARM Cortex A9 JTAG (manuf 0x4BF, id 0x506, rev 0x01, class 0x0) bcma: bus0: Core 13 found: Denali DDR2/DDR3 memory controller (manuf 0x4BF, id 0x507, rev 0x01, class 0x0) bcma: bus0: Core 14 found: ROM (manuf 0x4BF, id 0x508, rev 0x01, class 0x0) bcma: bus0: Core 15 found: NAND flash controller (manuf 0x4BF, id 0x509, rev 0x01, class 0x0) bcma: bus0: Core 16 found: SPI flash controller (manuf 0x4BF, id 0x50A, rev 0x01, class 0x0) Signed-off-by:
-
Vladimir Kondratiev authored
Finish all SW context modifications prior to notifying hardware It used to be race condition: if HW finish Tx and issue Tx completion IRQ very fast, prior to SW context update in wil_tx_vring, Tx completion will mis-handle descriptor, as SW part will have no skb pointer stored. Signed-off-by:
-
Vladimir Kondratiev authored
Enable adding more data to the SW context. For now, add flag "mapped_as_page", to separate decisions on free-ing skb and type of DMA mapping. This allows linking skb itself to any descriptor of fragmented skb. Signed-off-by:
-
Vladimir Kondratiev authored
No need to modify HW descriptor, as it will be re-initialized on Tx. Signed-off-by:
-
Vladimir Kondratiev authored
When destroying Rx vring, branch for Rx used wrong Tx descriptor: while SW context was taken for "head", HW descriptor was, by mistake, taken from "tail" Signed-off-by:
-
Vladimir Kondratiev authored
FW guys changed header structure; align driver code Signed-off-by:
-
Gabor Juhos authored
The Linksys AE3000 device is based on the RT3573 chipset. The support for this chipset is available already, and the AE3000 device works with the driver. Only managed mode works correctly at the moment, for AP mode additional changes are needed in the driver. Also add a new RT2800USB_RT3573 Kconfig option and only enable support for RT3573 based devices if that is enabled. Signed-off-by:
Gabor Juhos <juhosg@openwrt.org> Acked-by:
Stanislaw Gruszka <stf_xl@wp.pl> Acked-by:
Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by:
-
Gabor Juhos authored
The RT3593 chipset requires different [RT]XWI size values. Modify the driver to use the correct values. Signed-off-by:
-
Gabor Juhos authored
Support for the RT3593 has been implemented in the previous changes, so it is safe to mark it supported in the driver. Signed-off-by:
-
Gabor Juhos authored
Support for the RF3053 has been implemented in the previous changes, so it is safe to mark it supported in the driver. Signed-off-by:
-
Gabor Juhos authored
Signed-off-by:
-
Gabor Juhos authored
Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629 driver. Reference: RT3593_ChipSwitchChannel in chips/rt3593.c Signed-off-by:
-
Gabor Juhos authored
Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629 driver. References: FreqItems3053 in chips/rt3593.c Signed-off-by:
-
Gabor Juhos authored
The actual code uses two default TX power values. This is enough for 1T and for 2T devices however on 3T devices another value is needed for the third chain. Add a new field to struct channel_info and initialize it from the 'rt2800_probe_hw_mode' function. Also modify the 'rt2800_config_channel' to handle the new field as well. Signed-off-by:
-
Gabor Juhos authored
The LNA_A[12] gain values are stored at a different offset in the EEPROM on RT3593 based devices. However the current code unconditionally reads those values from the location used by other chipsets. Fix the code to use the correct EEPROM offset. Based on the DPO_RT5572_LinuxSTA_2.6.0.1_20120629 driver. References: RT3593_EEPROM_RSSI2_OFFSET_ALNAGAIN1_24G_READ in include/chip/rt3593.h RT3593_EEPROM_RSSI2_OFFSET_ALNAGAIN2_5G_READ in include/chip/rt3593.h Signed-off-by:
-
