- 16 Apr, 2010 38 commits
-
-
Felix Fietkau authored
Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
-
Senthil Balasubramanian authored
Also, no need for the udelay(2) on AR9003 hardware. Signed-off-by:
Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by:
-
Senthil Balasubramanian authored
The AR9003 family requires a change on the loop and can also skip testing the PHY timing registers. This chip test can now be used by all Atheros hardware families, including legacy. We can eventually move this out to the generic ath module. Signed-off-by:
-
Vasanthakumar Thiagarajan authored
* Set rx buf size in register 0x60 * Set rxdp on the respective hw rx queue (HP and LP queues) * Process rx descriptor Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
-
Vasanthakumar Thiagarajan authored
Signed-off-by:
-
Vasanthakumar Thiagarajan authored
Signed-off-by:
-
Vasanthakumar Thiagarajan authored
HP & LP queue depth and rx status length. Signed-off-by:
-
Vasanthakumar Thiagarajan authored
AR9003 supports extended DMA (EDMA), this comes with some bells and whistles on top of the legacy DMA that we are used to. Mark AR9003 and later chips EDMA capable. Signed-off-by:
-
Luis R. Rodriguez authored
Signed-off-by:
-
Luis R. Rodriguez authored
ANI is still being debugged on AR9003 by our systems team so it should not yet be enabled yet. When ANI will be enabled all ANI functionality is expected to be enabled so fill the ANI functionality to all for AR9003 for now as well. Cc: Enis Akay <Enis.Akay@atheros.com> Signed-off-by:
-
Luis R. Rodriguez authored
Signed-off-by:
-
Luis R. Rodriguez authored
This allows us to add SREV checks on these helpers. Signed-off-by:
-
Luis R. Rodriguez authored
This add stubs for PHY support for the AR9003 hardware family. Signed-off-by:
-
Senthil Balasubramanian authored
Also, clean up and reorganize the AR9287 macro to have better ordering. We won't add the PCI ID to the supported device list until we have some functional code for it. Signed-off-by:
-
Luis R. Rodriguez authored
The PLL control computation used to program the AR_RTC_PLL_CONTROL register varies between our harware so just add a private callback for it. AR9003 will use its own callback. Signed-off-by:
-
Luis R. Rodriguez authored
Signed-off-by:
-
Luis R. Rodriguez authored
This is not required for the AR9003 family. Signed-off-by:
-
Luis R. Rodriguez authored
The PHY split is easier done in a few steps. First move the RF ops to the private ops and rename them accordingly. We split PHY stuff up first for the AR5008 and AR9002 families. There are some callbacks that AR9002 share with the AR5008 familiy so we set those first, if AR9002 has some different callbacks it will override them upon hardware init. Signed-off-by:
-
Luis R. Rodriguez authored
This is used only once by ath9k_hw_process_ini() to write an array of phy registers through REG_WRITE_ARRAY(), but we already call REG_WRITE_ARRAY() multiple times on the same caller so just remove this pointless wrapper. We'll eventually just move the ath9k_hw_process_ini() caller as an callback to abstract away between different hardware families. Although this change is subtle I should note that this does change the delay pattern on writing the next series of registers. REG_WRITE_ARRAY() uses a counter for each register write and does a udelay(1) every 64 writes. By removing this call it means that the counter is processed for all the iniBB_RfGain registers and is incremented on ath9k_hw_process_ini(), before this the after the call ath9k_hw_write_regs() was made the register counter was kept at the same index number prior to the call. Signed-off-by:
-
Luis R. Rodriguez authored
AR9003 does not have a reset control for AHB. Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
-
Felix Fietkau authored
This is not a stable code fix as this register is not used anywhere. Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
-
Felix Fietkau authored
AR9300 will be the first device supported of the AR9003 family. AR9300 1.0 hardware exists but it is not going to be sold anywhere so we completely skip its support. Signed-off-by:
-
Luis R. Rodriguez authored
ath9k supports the AR5008, AR9001 and AR9002 family of Atheros chipsets, all 802.11n. The new breed of 802.11n chips, the AR9003 family will be supported as well soon. To help with its support we're going to add a few callbacks for hardware routines which differ considerably instead of adding branch checks for the revision at runtime. Signed-off-by:
-
Dan Williams authored
Davinci platforms apparently need more time in-between helper firmware blocks. Even though this is an increased delay, we only take this hit once at initialization time. Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Dan Williams authored
Consolidate a bunch of C&P code that waits for the firmware to be ready. Signed-off-by:
-
Larry Finger authored
In preparation for new rtl818x devices, move the existing rtl818x configuration into the rtl818x directory. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Acked-by:
Hin-Tak Leung <htl10@users.sourceforge.net> Signed-off-by:
-
Grazvydas Ignotas authored
wl1251 is embedded chip that can be connected using SDIO bus, and is not an actual SDIO card. For this reason there is a need to pass some board specific data, like 'EEPROM is attached' flag or power control callback. However currently there is no way to pass this data through SDIO subsystem, so this patch registers dummy platform_device to allow that, until we have a better solution to this. Signed-off-by:
Grazvydas Ignotas <notasas@gmail.com> Acked-by:
Kalle Valo <kvalo@adurom.com> Signed-off-by:
-
Christian Lamparter authored
This patch fixes a bug which was just recently introduced by ("p54pci: prevent stuck rx-ring on slow system"). make M=drivers/net/wireless/p54 C=2 CF=-D__CHECK_ENDIAN__ CHECK drivers/net/wireless/p54/p54pci.c drivers/net/wireless/p54/p54pci.c:143:11: warning: cast to restricted __le32 CC [M] drivers/net/wireless/p54/p54pci.o Reported-by:Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Xose Vazquez Perez authored
0x0e66,0x0009 HWUN2 Hawking Technologies Hi-Gain Wireless-150N USB Adapter w/ Upgradable Antenna 0x0e66,0x000b HWDN2 Hawking Technologies Hi-Gain USB Wireless-150N Dish Adapter 0x0e66,0x0013 Hawking Technologies Hi-Gain Wireless-N USB Adapter 0x0e66,0x0017 Hawking Wireless-N Network Adapter 0x0e66,0x0018 Hawking Wireless-N Network Adapter Hawking Technologies Technical Support guys say: All our N adapters use the same chipset. Ralink RT 2870 chipset. Signed-off-by:
Xose Vazquez Perez <xose.vazquez@gmail.com> Acked-by:
Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by:
-
Helmut Schaa authored
rt2800pci used the callback write_tx_desc to write the tx descriptor but also to update the txwi which is part of the dma mapped skb. Since the memory was already DMA mapped _before_ the call to write_tx_desc the device didn't get the txwi data at all or only sporadically. The call order is basically as follows (from rt2x00queue.c): 1) write_tx_data 2) rt2x00queue_map_txskb 3) write_tx_desc Hence, we shouldn't touch the skb in write_tx_desc anymore. To fix this issue create a new rt2800pci_write_tx_data callback and use it for updating the txwi _before_ the memory gets DMA mapped. The tx descriptor is still written (as before) in write_tx_desc. This patch allows basic TX on an rt305x soc device but I'm pretty sure that it will fix pci based cards as well. I can associate just fine with an AP now but I wasn't able to get a wpa secured connection working yet. Signed-off-by:
Helmut Schaa <helmut.schaa@googlemail.com> Acked-by:
-
Helmut Schaa authored
Extend the write_tx_data callback with a txdesc parameter to allow access to the tx desciptor while preparing the tx data. Signed-off-by:
-
Nishant Sarmukadam authored
In a scenario, where a cfg80211 driver (station mode) does not send assoc request and assoc response IEs in cfg80211_connect_result after a successful association to an AP, cfg80211 sends IWEVASSOCREQIE and IWEVASSOCRESPIE to the user space application with NULL data. This can cause an issue at the event recipient. An example of this is when cfg80211 sends IWEVASSOCREQIE and IWEVASSOCRESPIE events with NULL event body to wpa_supplicant. The wpa_supplicant overwrites the assoc request and assoc response IEs for this station with NULL data. If the association is WPA/WPA2, the wpa_supplicant is not able to generate EAPOL handshake messages, since the IEs are NULL. With the patch, req_ie and resp_ie will be NULL by avoiding the assignment if the driver has not sent the IEs to cfg80211. The event sending code sends the events only if resp_ie and req_ie are not NULL. This will ensure that the events are not sent with NULL event body. Signed-off-by:
Nishant Sarmukadam <nishants@marvell.com> Reviewed-by:
-
Grazvydas Ignotas authored
Some wl1251 hardware configurations (like in WG7210 module) have EEPROM attached where NVS data is kept, which includes MAC address. In such configurations, let's read default MAC address from EEPROM, instead of using random one. Signed-off-by:
-
- 14 Apr, 2010 2 commits
-
-
Xose Vazquez Perez authored
A very useful information was provided by Sitecom R&D guys: Please find the information regarding our latest Ralink adapters below; WL-302 - VID: 0x0DF6, PID: 0x002D - Ralink RT2771 WL-315 - VID: 0x0DF6, PID: 0x0039 - Ralink RT2770 WL-319 - VID: 0x182D, PID: 0x0037 - Ralink RT2860 WL-321 - VID: 0x0DF6, PID: 0x003B - Ralink RT2770 WL-324 - VID: 0x0DF6, PID: 0x003D - Ralink RT2870 WL-329 - VID: 0x0DF6, PID: 0x0041 - Ralink RT3572 WL-343 - VID: 0x0DF6, PID: 0x003E - Ralink RT3070 WL-344 - VID: 0x0DF6, PID: 0x0040 - Ralink RT3071 WL-345 - VID: 0x0DF6, PID: 0x0042 - Ralink RT3072 WL-608 - VID: 0x0DF6, PID: 0x003F - Ralink RT2070 Note: PID: 0x003C, 0x004A, and 0x004D: --these products do not exist; devices were never produced/shipped-- The WL-349v4 USB dongle (0x0df6,0x0050) will be shipped soon (it isn't available yet), and uses a Ralink RT3370 chipset. Signed-off-by:
-
Christian Lamparter authored
This patch adds the following 5 entries to the usbid device table: * Netgear WNA1000 * Proxim ORiNOCO Dual Band 802.11n USB Adapter * 3Com Dual Band 802.11n USB Adapter * H3C Dual Band 802.11n USB Adapter * WNC Generic 11n USB dongle CC: <stable@kernel.org> Signed-off-by:
-
