- 17 11月, 2010 37 次提交
-
-
由 Felix Fietkau 提交于
Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
Merge ath_tx_send_normal and ath_tx_send_ht_normal. Move the paprd state initialization and sequence number assignment to reduce the number of redundant checks. This not only simplifies buffer allocation error handling, but also removes a small inconsistency in the buffer HT flag. This flag should only be set if the frame is also a QoS data frame. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ben Greear 提交于
An earlier review suggested moving the code in a small method that was only called once inline. This patch accomplishes that. Signed-off-by: NBen Greear <greearb@candelatech.com> Acked-by: NBruno Randolf <br1@einfach.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
TX underruns were noticed when RTS/CTS preceded aggregates. This issue was noticed in ar93xx family of chipsets only. The workaround involves padding the RTS or CTS length up to the min packet length of 256 bytes required by the hardware by adding delimiters to the fist descriptor of the aggregate. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
There is a roundng error in delimiter padding computation which causes severe throughput drop with some of AR9003. signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Cc:stable@kernel.org Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Also round off interpolated values this would improve power accuracy by 0.5dB in some cases. Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
It is done for 5Ghz by adding three temperature slopes. Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Attenuation from eeprom is configured into attenuator control register. Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Improper configuration of 0x16288 and 0x16290 would affect transmission. Cc:stable@kernel.org Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
We are currently using the default eeprom default and it doesn't work properly for all ar9003 family chipsets. So add eeprom templates for different versisons and select the eeprom table based on the template version programmed in the eeprom. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
paprd training frame fails in some rates. Fix the rate mask. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
The last 2GHz CTL was not being initialized, so power was being set to 0 instead of 30dbm. Initialize to 30 like other CTLs. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
Add eeprom base extension structures which are needed for AR938x caliberation changes and gain calculation. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
AR9382 needs to be configured for the correct chain mask before running AGC/TxIQ caliberation. Otherwise reset would fail. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bruno Randolf 提交于
Support setting the antenna configuration via cfg/mac80211. At the moment only allow the simple pre-defined configurations we already have (fixed antenna A/B or diversity), but more advanced settings are possible to implement. Signed-off-by: NBruno Randolf <br1@einfach.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bruno Randolf 提交于
Allow antenna configuration by calling driver's function for it. We disallow antenna configuration if the wiphy is already running, mainly to make life easier for 802.11n drivers which need to recalculate HT capabilites. Signed-off-by: NBruno Randolf <br1@einfach.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bruno Randolf 提交于
Allow setting of TX and RX antennas configuration via nl80211. The antenna configuration is defined as a bitmap of allowed antennas to use. This API can be used to mask out antennas which are not attached or should not be used for other reasons like regulatory concerns or special setups. Separate bitmaps are used for RX and TX to allow configuring different antennas for receiving and transmitting. Each bitmap is 32 bit long, each bit representing one antenna, starting with antenna 1 at the first bit. If an antenna bit is set, this means the driver is allowed to use this antenna for RX or TX respectively; if the bit is not set the hardware is not allowed to use this antenna. Using bitmaps has the benefit of allowing for a flexible configuration interface which can support many different configurations and which can be used for 802.11n as well as non-802.11n devices. Instead of relying on some hardware specific assumptions, drivers can use this information to know which antennas are actually attached to the system and derive their capabilities based on that. 802.11n devices should enable or disable chains, based on which antennas are present (If all antennas belonging to a particular chain are disabled, the entire chain should be disabled). HT capabilities (like STBC, TX Beamforming, Antenna selection) should be calculated based on the available chains after applying the antenna masks. Should a 802.11n device have diversity antennas attached to one of their chains, diversity can be enabled or disabled based on the antenna information. Non-802.11n drivers can use the antenna masks to select RX and TX antennas and to enable or disable antenna diversity. While covering chainmasks for 802.11n and the standard "legacy" modes "fixed antenna 1", "fixed antenna 2" and "diversity" this API also allows more rare, but useful configurations as follows: 1) Send on antenna 1, receive on antenna 2 (or vice versa). This can be used to have a low gain antenna for TX in order to keep within the regulatory constraints and a high gain antenna for RX in order to receive weaker signals ("speak softly, but listen harder"). This can be useful for building long-shot outdoor links. Another usage of this setup is having a low-noise pre-amplifier on antenna 1 and a power amplifier on the other antenna. This way transmit noise is mostly kept out of the low noise receive channel. (This would be bitmaps: tx 1 rx 2). 2) Another similar setup is: Use RX diversity on both antennas, but always send on antenna 1. Again that would allow us to benefit from a higher gain RX antenna, while staying within the legal limits. (This would be: tx 0 rx 3). 3) And finally there can be special experimental setups in research and development even with pre 802.11n hardware where more than 2 antennas are available. It's good to keep the API simple, yet flexible. Signed-off-by: NBruno Randolf <br1@einfach.org> -- v7: Made bitmasks 32 bit wide and rebased to latest wireless-testing. Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Joe Perches 提交于
Using %pV reduces the number of printk calls and eliminates any possible message interleaving from other printk calls. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Joe Perches 提交于
Using %pV reduces the number of printk calls and eliminates any possible message interleaving from other printk calls. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Joe Perches 提交于
Using %pV reduces the number of printk calls and eliminates any possible message interleaving from other printk calls. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jussi Kivilinna 提交于
BCM4320a devices seem to sometimes do scanning pretty poorly. This can be workaround by issuing new scan every second, while not yet connected. By this new scanning method device catches beacons much faster. Fixes bug #20822. Reported-by: NLuís Picciochi <Pitxyoki@gmail.com> Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jussi Kivilinna 提交于
BCM4320a devices do not return bss for currently connected AP in bss-list, althought this is required by NDIS specs. Missing bss leads to warning at net/wireless/sme.c:__cfg80211_connect_result(), WARN_ON(!bss). Workaround this by crafting bss manually with information we can read from device. Workaround is only used when device bss-list does not return current bss, and so is only used with BCM4320a devices and not newer BCM4320b ones. Fixes bug #20152. Reported-by: NLuís Picciochi <Pitxyoki@gmail.com> Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Arik Nemtsov 提交于
The lower driver is notified when the fragmentation threshold changes and upon a reconfig of the interface. If the driver supports hardware TX fragmentation, don't fragment packets in the stack. Signed-off-by: NArik Nemtsov <arik@wizery.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rafał Miłecki 提交于
Signed-off-by: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rafał Miłecki 提交于
Signed-off-by: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Brian Cavagnolo 提交于
This eliminates compiler warnings by doing things how the firmware class expects. Signed-off-by: NBrian Cavagnolo <brian@cozybit.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Brian Cavagnolo 提交于
Introduce a firmware loading state machine to manage the process of loading firmware asynchronously and completing initialization upon success. The state machine attempts to load the preferred firmware image. If that fails, and if an alternative firmware image is available, it will attempt to load that one. Signed-off-by: NBrian Cavagnolo <brian@cozybit.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Brian Cavagnolo 提交于
The AP firmware specifies an API version in the GET_HW_SPEC command response. Currently, the driver only supports AP firmware for the 8366, and only supports API v1. In the future, if higher API version firmwares emerge (possibly for different chips), different ops can be selected based on the reported API version. Signed-off-by: NBrian Cavagnolo <brian@cozybit.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Brian Cavagnolo 提交于
The mwl8k can operate in AP or STA mode, depending on the firmware image that is loaded. By default, STA firmware is loaded. Allow the user to override this default mode at module load time. This saves an unnecessary firmware reload for users only interested in AP mode. Also, the firmware image can be swapped to meet the user's add_interface request. For example, suppose the STA firmware is loaded, no STA interface has been added, and the user adds an AP interface. In this case, the AP firmware will be loaded to meet the request. Based on contributions from Pradeep Nemavat <pnemavat@marvell.com>, Yogesh Powar <yogeshp@marvell.com>, and Lennert Buytenhek <buytenh@wantstofly.org>. Signed-off-by: NBrian Cavagnolo <brian@cozybit.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Brian Cavagnolo 提交于
This is in preparation for supporting different fw images for different interface types, and for supporting asynchronous firmware loading. Based on a patch from Pradeep Nemavat <pnemavat@marvell.com> and Yogesh Powar <yogeshp@marvell.com> Signed-off-by: NBrian Cavagnolo <brian@cozybit.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Nishant Sarmukadam 提交于
APIv1 AP firmware does not support the RF_TX_POWER command. It supports the similar TX_POWER command. Signed-off-by: NPradeep Nemavat <pnemavat@marvell.com> Signed-off-by: NNishant Sarmukadam <nishants@marvell.com> Signed-off-by: NBrian Cavagnolo <brian@cozybit.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Brian Cavagnolo 提交于
This reverts change 783391c443728febc669e40597193308460e7b4f. The stabilized AP v1 firmware uses the same tx descriptor as the STA firmware. Signed-off-by: NBrian Cavagnolo <brian@cozybit.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Deepak Saxena 提交于
Certain firmware versions, particularly the 8388 found on the XO-1, do not support the EHS_REMOVE_WAKEUP command that is used to disable WOL. Sending this command to the card will return a failure that would get propagated up the stack and cause suspend to fail. Instead, fall back to an all-zero wakeup mask. This fixes http://dev.laptop.org/ticket/9967Signed-off-by: NDeepak Saxena <dsaxena@laptop.org> Signed-off-by: NDaniel Drake <dsd@laptop.org> [includes fixups by Paul Fox] Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Daniel Drake 提交于
This hunk added by commit 66fceb69 seems erroneous. We don't want to prevent suspend of the whole system if no wakeup params are set. In the case of the usb8388 we do want to keep the card powered up even if there are no wakeup params. This is because it will continue acting as a mesh node. If the mesh is disabled, it would indeed make more sense to power down the card during suspend, as the equivalent hunk does for the SD interface. But that's a separate task; for now just restore the previous behaviour. Signed-off-by: NDaniel Drake <dsd@laptop.org> Acked-by: NDan Williams <dcbw@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 16 11月, 2010 3 次提交
-
-
由 Christian Lamparter 提交于
This patch replaces the handcrafted sign extension cruft with a generic bitop function. Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Andreas Herrmann 提交于
This patch moves code out from wireless drivers where two different functions are defined in three code locations for the same purpose and provides a common function to sign extend a 32-bit value. Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Grazvydas Ignotas 提交于
Make use the newly added method to pass platform data for wl1251 too. This allows to eliminate some redundant code. Cc: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com> Acked-by: NKalle Valo <kvalo@adurom.com> Acked-by: NLuciano Coelho <luciano.coelho@nokia.com> Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-