- 22 Jul, 2013 40 commits
-
-
Kalle Valo authored
I forgot to add an entry to MAINTAINERS when submitting the driver. Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
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 <qca_vkondrat@qca.qualcomm.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:
-
Gabor Juhos authored
The reference code uses hardcoded zero TX mixer gain value for RT3593. Do the same in the rt2x00 driver. Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629 driver. Reference: NICReadEEPROMParameters in common/rtmp_init.c Signed-off-by:
-
Gabor Juhos authored
Move the TX mixer gain reading code into separate helper functions in preparation for RT3593 support. Signed-off-by:
-
Gabor Juhos authored
The TX power values in the EEPROM are using a different format for the RT3593 chip. The default TX power value uses bits 0..4 only. Bits 5..8 contains value for fine grained power control. Additionally, the lower and upper limits of the TX power values are the same for both bands. Improve the rt2800_txpower_to_dev function, in order to compute the correct default power values for the RT3593 chip as well. Signed-off-by:
-
Gabor Juhos authored
Introduce a new helper function for converting the default TX power values from EEPROM into mac80211 values. The change improves the readability and it makes it easier to add support for other chipsets. Signed-off-by:
-
Gabor Juhos authored
On the RT3593 chipset, BBP register 86 must be configured by different values based on the RX antenna numbers. Configure this register from the 'rt2800_config_ant' function. Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629 driver. Reference: RT3593_CONFIG_SET_BY_ANTENNA in include/chip/rt3593.h Signed-off-by:
-
Gabor Juhos authored
The field must be set to 2 instead of 0 for devices with three TX chains. Signed-off-by:
-
Gabor Juhos authored
Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629 driver. References: RTMPReadTxPwrPerRateExt in chips/rt3593.c RT3593_AsicGetTxPowerOffset in chips/rt3593.c Signed-off-by:
-
Gabor Juhos authored
Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629 driver. Reference: RT3593_PostBBPInitialization in chips/rt3553.c Signed-off-by:
-
Gabor Juhos authored
Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629 driver. References: NICInitRT3593RFRegisters in chips/rt3593.c RT3593LoadRFNormalModeSetup in chips/rt3593.c Signed-off-by:
-
Gabor Juhos authored
Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629 driver. References: NICInitRT3593BbpRegisters in chips/rt3593.c NICInitBBP in common/rtmp_init.c NICInitAsicFromEEPROM in common/rtmp_init.c Signed-off-by:
-
