- 08 6月, 2010 1 次提交
-
-
由 John W. Linville 提交于
In the revert of "iwlwifi: move _agn statistics related structure", I need to use CONFIG_IWLWIFI_DEBUGFS instead of CONFIG_IWLWIFI_DEBUG in the private structure definition. Without this patch, it is possible to get this: drivers/net/wireless/iwlwifi/iwl-rx.c: In function 'iwl_accumulative_statistics': drivers/net/wireless/iwlwifi/iwl-rx.c:304: error: 'struct iwl_priv' has no member named 'accum_statistics' drivers/net/wireless/iwlwifi/iwl-rx.c:305: error: 'struct iwl_priv' has no member named 'delta_statistics' drivers/net/wireless/iwlwifi/iwl-rx.c:306: error: 'struct iwl_priv' has no member named 'max_delta' drivers/net/wireless/iwlwifi/iwl-rx.c:321: error: 'struct iwl_priv' has no member named 'accum_statistics' drivers/net/wireless/iwlwifi/iwl-rx.c:323: error: 'struct iwl_priv' has no member named 'accum_statistics' drivers/net/wireless/iwlwifi/iwl-rx.c:325: error: 'struct iwl_priv' has no member named 'accum_statistics' drivers/net/wireless/iwlwifi/iwl-rx.c:327: error: 'struct iwl_priv' has no member named 'accum_statistics' drivers/net/wireless/iwlwifi/iwl-rx.c:329: error: 'struct iwl_priv' has no member named 'accum_statistics' drivers/net/wireless/iwlwifi/iwl-rx.c:331: error: 'struct iwl_priv' has no member named 'accum_statistics' drivers/net/wireless/iwlwifi/iwl-rx.c: In function 'iwl_reply_statistics': drivers/net/wireless/iwlwifi/iwl-rx.c:484: error: 'struct iwl_priv' has no member named 'accum_statistics' drivers/net/wireless/iwlwifi/iwl-rx.c:486: error: 'struct iwl_priv' has no member named 'delta_statistics' drivers/net/wireless/iwlwifi/iwl-rx.c:488: error: 'struct iwl_priv' has no member named 'max_delta' Reported-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 06 6月, 2010 23 次提交
-
-
由 Daniel Halperin 提交于
Fairly complex code in iwlagn_tx_status_reply_tx handle the status reports for aggregated packet batches sent by the NIC. This code aims to handle the case where the NIC retransmits failed packets from a previous batch; the status information for these packets can sometimes be inserted in the middle of a batch and are actually not in order by sequence number! (I verified this can happen with printk's in the function.) The code in question adaptively identifies the "first" frame of the batch, taking into account that it may not be the one corresponding to the first agg status report, and also handles the case when the set of sent packets wraps the 256-character entry buffer. It generates the agg->bitmap field of sent packets which is later compared to the BlockAck response from the receiver to see which frames of those sent in this batch were ACKed. A small logic error (wrapping by 0xff==255 instead of 0x100==256) was causing the agg->bitmap to be set incorrectly. Fix this wrapping code, and add extensive comments to clarify what is going on. Signed-off-by: NDaniel Halperin <dhalperi@cs.washington.edu> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Daniel Halperin 提交于
Compressed BlockAck frames store the ACKs/NACKs in a 64-bit bitmap that starts at the sequence number of the first frame sent in the aggregated batch. Note that this is a selective ACKnowledgement following selective retransmission; e.g., if frames 1,4-5 in a batch are ACKed then the next transmission will include frames 2-3,6-10 (7 frames). In this latter case, the Compressed BlockAck will not have all meaningful information in the low order bits -- the semantically meaningful bits of the BA will be 0x1f3 (where the low-order frame is seq 2). The driver code originally just looked at the lower (in this case, 7) bits of the BlockAck. In this case, the lower 7 bits of 0x1f3 => only 5 packets, maximum, could ever be ACKed. In reality it should be looking at all of the bits, filtered by those corresponding to packets that were actually sent. This flaw meant that the number of correctly ACked packets could be significantly underreported and might result in asynchronous state between TX and RX sides as well as driver and uCode. Fix this and also add a shortcut that doesn't require the code to loop through all 64 bits of the bitmap but rather stops when no higher packets are ACKed. In my experiments this fix greatly reduces throughput swing, making throughput stable and high. It is also likely related to some of the stalls observed in aggregation mode and maybe some of the buffer underruns observed, e.g., http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1968 http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2098 http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2018Signed-off-by: NDaniel Halperin <dhalperi@cs.washington.edu> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Wey-Yi Guy 提交于
framecnt_to_us is not used, remove it Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Johannes Berg 提交于
The internal scanning created a problem where when userspace tries to scan, the scan gets rejected. Instead of doing that, queue up the user-initiated scan when doing an internal scan. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Johannes Berg 提交于
In "iwlwifi: make scan antenna forcing more generic" I introduced generic scan RX antenna forcing, which here I rename to make it more evident. Also add scan TX antenna forcing, since I will need that as well. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Wey-Yi Guy 提交于
Channel switch host command do not need to allocate huge command buffer since its size is already included in the iwl_device_cmd structure. Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Johannes Berg 提交于
Currently, the driver allocates up to 19 skb pointers for each TFD, of which we have 256 per queue. This means that for each TX queue, we allocate 19k/38k (an order 4 or 5 allocation on 32/64 bit respectively) just for each queue's "txb" array, which contains only the SKB pointers. However, due to the way we use these pointers only the first one can ever be assigned. When the driver was initially written, the idea was that it could be passed multiple SKBs for each TFD and attach all those to implement gather DMA. However, due to constraints in the userspace API and lack of TCP/IP level checksumming in the device, this is in fact not possible. And even if it were, the SKBs would be chained, and we wouldn't need to keep pointers to each anyway. Change this to only keep track of one SKB per TFD, and thereby reduce memory consumption to just one pointer per TFD, which is an order 0 allocation per transmit queue. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Johannes Berg 提交于
When we allocate queues, we currently don't use kzalloc() right now. When we then free those queues again without having used all entries, we may end up trying to free random pointers found in the txb array since it was never initialised. This fixes it simply by using kzalloc(). Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Johannes Berg 提交于
The iwl_hw_txq_free_tfd() function can be called from contexts with IRQs disabled, so it must not call dev_kfree_skb() but rather dev_kfree_skb_any() instead. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Johannes Berg 提交于
When we free a txq that had no txb array allocated, we still try to access it. Fix that, and also free all SKBs that may be in the txb array (although it can just be a single one). Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Wey-Yi Guy 提交于
REPLY_REMOVE_STA command is used Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Johannes Berg 提交于
This variable is now no longer used, so it can be removed completely. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Wey-Yi Guy 提交于
use TIME_UNIT define for beacon internal calculation Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Wey-Yi Guy 提交于
Support channel switch in driver as a separated mac80211 callback function instead of part of mac_config callback; by moving to this approach, uCode can have more control of channel switch timing. Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Wey-Yi Guy 提交于
Move the ucode beacon formation related helper function from 3945 to iwlcore, so both _3945 and _agn devices can utilize those functions. When driver pass the beacon related timing information to uCode in both spectrum measurement and channel switch commands, the beacon timing parameter require in uCode beacon format; those helper functions will do the conversation from uSec to the correct uCode format Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Wey-Yi Guy 提交于
restrict_refcnt is no longer used, remove it from iwl_priv structure Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Shanyu Zhao 提交于
Chain noise calibration data are cleared after the calibration is done in iwlagn_gain_computation() and iwl4965_gain_computation(). This cause the debugfs entries for those data useless. To provide valid debugging info, clear those data right before starting the calibration instead. Signed-off-by: NShanyu Zhao <shanyu.zhao@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Johannes Berg 提交于
This can now be much better achieved using tracing and post-processing of the trace, rather than doing the processing in place in the driver, so remove a lot of code. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Johannes Berg 提交于
For probe request frames sent during scan, we should use the virtual interface's mac address that the scan was initiated on to avoid issues when the wrong address is used. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Johannes Berg 提交于
When we do not have an interface, priv->mac_addr is all zeroes, so the memcpy() is not useful as the RXON buffer has been cleared previously. Therefore, use the interface's address that we are setting up the RXON for, if available. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Johannes Berg 提交于
priv->mac_addr is the address of the operating interface, not the permanent MAC address. They are usually the same, but the user can override the operating address, so we shouldn't set the variable to the permanent one, it is assigned when an interface is added. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Johannes Berg 提交于
There's no microcode that actually uses this variable, and it is reserved for functionality that the driver doesn't support anyway, so we shouldn't be setting it. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
由 Johannes Berg 提交于
iwl_connection_init_rx_config() will already have set up the entire RXON command, so these assignments are duplicate. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
-
- 05 6月, 2010 16 次提交
-
-
由 FUJITA Tomonori 提交于
Now they are unnecessary. We can use the generic DMA API with any bus. Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Michael Buesch <mb@bu3sch.de> Cc: Gary Zambrano <zambrano@broadcom.com> Cc: Stefano Brivio <stefano.brivio@polimi.it> Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: John W. Linville <linville@tuxdriver.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 FUJITA Tomonori 提交于
Note that dma_sync_single_for_device and dma_sync_single_for_cpu support a partial sync. Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Gary Zambrano <zambrano@broadcom.com> Acked-by: NMichael Buesch <mb@bu3sch.de> Acked-by: NDavid S. Miller <davem@davemloft.net> Acked-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 FUJITA Tomonori 提交于
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Stefano Brivio <stefano.brivio@polimi.it> Cc: John W. Linville <linville@tuxdriver.com> Acked-by: NMichael Buesch <mb@bu3sch.de> Acked-by: NDavid S. Miller <davem@davemloft.net> Acked-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 FUJITA Tomonori 提交于
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stefano Brivio <stefano.brivio@polimi.it> Cc: John W. Linville <linville@tuxdriver.com> Acked-by: NMichael Buesch <mb@bu3sch.de> Acked-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 FUJITA Tomonori 提交于
Add dma_dev, a pointer to struct device, to struct ssb_device. We pass it to the generic DMA API with SSB_BUSTYPE_PCI and SSB_BUSTYPE_SSB. ssb_devices_register() sets up it properly. This is preparation for replacing the ssb bus specific DMA API (ssb_dma_*) with the generic DMA API. Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by: NMichael Buesch <mb@bu3sch.de> Cc: Gary Zambrano <zambrano@broadcom.com> Cc: Stefano Brivio <stefano.brivio@polimi.it> Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: John W. Linville <linville@tuxdriver.com> Acked-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 FUJITA Tomonori 提交于
This can be cleanly applied to wireless-2.6 and iwlwifi git trees. = From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Subject: [PATCH] iwlwifi: use the DMA state API instead of the pci equivalents This replace the PCI DMA state API (include/linux/pci-dma.h) with the DMA equivalents since the PCI DMA state API will be obsolete. No functional change. For further information about the background: http://marc.info/?l=linux-netdev&m=127037540020276&w=2Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
The following commit added an entry in 11na and 11ng rate table but missed to update its rate count field. This inconsistency between the rate count and the actual number of rates in the table will leave out the final rate entry (mcs15 with half gi in ht40) while forming the valid rate indices. Not having mcs15+shortGI in ht40 will have a performance impact (on max throughput) of about 10% both in nght40 and naht40 mode. Author: Vasanthakumar Thiagarajan <vasanth@atheros.com> Date: Thu May 13 18:42:38 2010 -0700 ath9k: Enable Short GI in 20 Mhz for ar9287 and later chips This patch enables short GI rx at all rates and tx at mcs15 for 20 Mhz channel width also. Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
For non-AR9271 chips, the credit size is different and has to be configured appropriately. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
AR7010 is dual-band. Setup the channels and rateset for 5GHz band. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
The rate information on the target has to be updated for 2-stream devices, along with the correct chainmask. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
The supported MCS rate set has to be setup properly for 2-stream devices. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
This can be used by ath9k_htc. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
Add the USB device IDs for AR7010 and handle firmware loading properly. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
This patch fixes programming the byte swap registers for chipsets other than AR9271. This is needed for AR7010. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
Do not assign the FW name to driver_info but determine it dynamically on device probe. This facilitates adding new firmware. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luke-Jr 提交于
While the comment removed in this patch claims board_n800.c uses "cx3110x", it was never merged to mainline like this. Mainlined board files for Nokia N8x0 devices are expected "p54spi", and thus don't work because the modalias is "cx3110x". To my knowledge, these devices are the only real-world use of p54spi, and will not work without this change. Tested against my Nokia N810. Signed-off-by: NLuke Dashjr <luke-jr+git@utopios.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-