- 21 Jan, 2011 10 commits
-
-
Ben Greear authored
Signed-off-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Ben Greear authored
Should help debug strange tx lockup type issues. Signed-off-by:
-
Ben Greear authored
Previous code left it NULL. Signed-off-by:
-
Ben Greear authored
I thought this might help track down stuck queues, etc. Signed-off-by:
-
Ben Greear authored
This particular error isn't about multicast. Signed-off-by:
-
Johannes Berg authored
The notification wait support code is shared between 4965 and other AGN devices, so 4965 also has to initialize the data structures for it, otherwise it crashes. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
Johannes Berg authored
Signed-off-by:
-
Johannes Berg authored
Previously I hacked this with an msleep(300) which was fine since we never had longer PAN time slots, but now that we will have them I need to fix that. Use the new notification wait support to properly wait for the WIPAN deactivation complete signal from the ucode. Signed-off-by:
-
Johannes Berg authored
In order to implement waiting for notifications, add a structure that captures the information, and a list of such structures that will be traversed when a command is received from the ucode. Use sparse checking to make sure calls to the prepare/wait/cancel functions are always nested correctly. Signed-off-by:
-
Johannes Berg authored
It's not used or likely to be needed from other files, so it can be static. Signed-off-by:
-
- 19 Jan, 2011 29 commits
-
-
Felix Fietkau authored
When running as a 4-addr station against an AP that has the 4-addr VLAN interface and the main 3-addr AP interface bridged together, sometimes frames originating from the station were looping back from the 3-addr AP interface, causing the bridge code to emit warnings about receiving frames with its own source address. I'm not sure why this is happening yet, but I think it's a good idea to drop all frames (except 802.1x/EAP frames) that do not match the configured addressing mode, including 4-address frames sent to a 3-address station. User test reports indicate that the problem goes away with this patch. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Johannes Berg authored
Currently, mac80211 always advertises that it may send up to 64 subframes in an aggregate. This is fine, since it's the max, but might as well be set to zero instead since it doesn't have any information. However, drivers might have that information, so allow them to set a variable giving it, which will then be used. The default of zero will be fine since to the peer that means we don't know and it will just use its own limit for the buffer size. Signed-off-by:
-
Johannes Berg authored
The aggregation code currently doesn't implement the buffer size negotiation. It will always request a max buffer size (which is fine, if a little pointless, as the mac80211 code doesn't know and might just use 0 instead), but if the peer requests a smaller size it isn't possible to honour this request. In order to fix this, look at the buffer size in the addBA response frame, keep track of it and pass it to the driver in the ampdu_action callback when called with the IEEE80211_AMPDU_TX_OPERATIONAL action. That way the driver can limit the number of subframes in aggregates appropriately. Note that this doesn't fix any drivers apart from the addition of the new argument -- they all need to be updated separately to use this variable! Signed-off-by:
-
Johannes Berg authored
When mesh is disabled, mac80211 was returning beacons with an empty mesh ID. That isn't desirable, even if drivers shouldn't be trying to get beacons to start with. Signed-off-by:
-
Ben Greear authored
When using a mixture of AP and Station interfaces, the hardware mode was using the type of the last VIF registered. Instead, we should keep track of the number of different types of vifs and set the mode accordingly. In addtion, use the vif type instead of hardware opmode when dealing with beacons. Attempt to move some of the common setup code into smaller methods so we can re-use it when changing vif mode as well as adding/deleting vifs. Signed-off-by:
-
Felix Fietkau authored
Because the sendbar variable was not reset to zero, the stack would send Block ACK requests for all subframes following the one that failed, which could mess up the receiver side block ack window. Signed-off-by:
-
Felix Fietkau authored
Sometimes the first TID in the first AC's list is not available for forming a new aggregate (the BAW might not allow it), however other TIDs may have data available for sending. Prevent a slowdown of other TIDs by going through multiple entries until we've either hit the last one or enough AMPDUs are pending in the hardware queue. Signed-off-by:
-
Rajkumar Manoharan authored
AR9285 carrier leakage calibration related workaround on high temperature is not applicable for AR9271. Signed-off-by:
Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by:
-
Rajkumar Manoharan authored
The ath9k_hw assumes that caldata is valid only for oper channel. But with ath9k_htc case, the caldata is passed for all channels on hw_reset though we are not doing calibration on that channel. So the oper channel's nf history got cleared to default due to mismatch in channel flags. This patch also saves some space. Signed-off-by:
-
Rajkumar Manoharan authored
caldata's channel info is never filled with operating channel info which is causing the operating channel's noise floor history buffer is reset to default nf during channel change. Signed-off-by:
-
Ben Greear authored
Signed-off-by:
-
Wey-Yi Guy authored
mppath is mesh related parameter and maybe unused Signed-off-by:
-
Felix Fietkau authored
The rx error bit parsing was changed to consider PHY errors and various decryption errors separately. While correct according to the documentation, this is causing spurious decryption error reports in some situations. Fix this by restoring the original order of the checks in those places, where the errors are meant to be mutually exclusive. If a CRC error is reported, then MIC failure and decryption errors are irrelevant, and a PHY error is unlikely. Signed-off-by:
-
Luciano Coelho authored
Some devices don't support the maximum AMDPU buffer size of 64, so we need to add an option to configure this in the hardware configuration. This value will be used in the ADDBA response instead of the value suggested in the request, if the latter is greater than the max supported. Signed-off-by:
Luciano Coelho <coelho@ti.com> Tested-by:
Juuso Oikarinen <juuso.oikarinen@nokia.com> Signed-off-by:
-
Nick Ledovskikh authored
Replace MESH_WORK_GROW_MPATH_TABLE by MESH_WORK_GROW_MPP_TABLE in mesh_mpp_table_grow call condition. (Clearly the original was a typo... -- JWL) Signed-off-by:
Nickolay Ledovskikh <nledovskikh@gmail.com> Signed-off-by:
-
Wojciech Dubowik authored
Eeprom read functions are of bool type and not int. Signed-off-by:
Wojciech Dubowik <Wojciech.Dubowik@neratec.com> Signed-off-by:
-
Felix Fietkau authored
Since baseband hangs are rare, but the hang check function has a high false positive rate in some situations, we need to add more reliable indicators. In AP mode we can use blocked beacon transmissions as an indicator, they should be rare enough. In station mode, we can skip the hang check entirely, since a true hang will trigger beacon loss detection, and mac80211 will rescan, which leads to a hw reset that will bring the hardware back to life. To make this more reliable, we need to skip fast channel changes if the hardware appears to be stuck. Signed-off-by:
-
Felix Fietkau authored
There might be some old stale data left, which could confuse tracking of pending tx frames. Signed-off-by:
-
Felix Fietkau authored
txtid->seq_start may not always be up to date, when there is HT non-AMPDU traffic just before starting an AMPDU session. Relying on txtid->seq_next is better, since it is also used to generate the sequence numbers for all QoS data frames. Signed-off-by:
-
Felix Fietkau authored
When a tid pointer is passed to ath_tx_send_normal(), it increases the starting sequence number for the next AMPDU action frame, which should only be done if the sequence number assignment is fresh. In this case it is clearly not. Signed-off-by:
-
RA-Jay Hung authored
Basically fix and fine-tune RT3070/RT3071/RT3090 chip RF initial value when call rt2800_init_rfcsr Signed-off-by:
RA-Jay Hung <jay_hung@ralinktech.com> Acked-by:
Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
-
RA-Jay Hung authored
PCI/PCIE radio off behavior is different from SOC/USB. They mainly use MCU command to disable DMA, TX/RX and enter power saving mode. Signed-off-by:
-
Joel A Fernandes authored
Rewrote code for checking if the destination is proxied by a mesh portal, to facilitate better understanding of the functionality. Signed-off-by:
Joel A Fernandes <agnel.joel@gmail.com> Acked-by:
Javier Cardona <javier@cozybit.com> Signed-off-by:
-
Sujith Manoharan authored
For USB devices, reading the EEPROM data can be offloaded to the target. Use multiple register reads to take advantage of this feature to reduce initialization time. Signed-off-by:
Sujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by:
-
Sujith Manoharan authored
This would decrease latency in reading bulk registers. Signed-off-by:
-
Nishant Sarmukadam authored
set_key callback is defined for mac80211 to install keys for HW crypto in AP mode. Driver currently falls back to SW crypto in STA mode. Add support to configure the keys appropriately in the hardware after the set_key routine is called. Signed-off-by:
Nishant Sarmukadam <nishants@marvell.com> Signed-off-by:
Pradeep Nemavat <pnemavat@marvell.com> Signed-off-by:
Thomas Pedersen <thomas@cozybit.com> Signed-off-by:
-
Nishant Sarmukadam authored
When hw crypto is enabled, set rx status flags appropriately depending on whether hw crypto is enabled for a particular bss. Also report MIC errors to mac80211, so that counter measures can be initiated Signed-off-by:
yogesh powar <yogeshp@marvell.com> Signed-off-by:
-
Nishant Sarmukadam authored
Different tail pads will be needed for crypto depending on the crypto mode. Add support to encapsulate the packets with appropriate pad value. Signed-off-by:
-
Nishant Sarmukadam authored
Add capability to add_dma_header to support padding at tail of the data packet to be transmitted when crypto is enabled. Padding is required for adding crypto information in data packets for supporting 802.11 security modes. Signed-off-by:
-
- 18 Jan, 2011 1 commit
-
-
Linus Torvalds authored
-
