summaryrefslogtreecommitdiffstats
path: root/net
Commit message (Collapse)AuthorAgeFilesLines
* mac80211: Minor optimization in ieee80211_rx_h_dataHelmut Schaa2010-11-301-3/+2
| | | | | | | | | | | | | | | | | | Remove a superfluous ieee80211_is_data check as that was checked a few lines before already and we wont't get here for non-data frames at all. Second, the frame was already converted to 802.3 header format and reading the fc and addr1 fields was only possible because the 802.3 header is short enough and didn't overwrite the relevant parts of the 802.11 header. Make the code more obvious by checking the ethernet header's h_dest field. Furthermore reorder the conditions to reduce the number of checks when dynamic powersave is not needed (AP mode for example). Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: fix RX aggregation lockingJohannes Berg2010-11-294-38/+45
| | | | | | | | | | | | | | | | | | | | | The RX aggregation locking documentation was wrong, which led Christian to also code the timer timeout handling for it somewhat wrongly. Fix the documentation, the two places that need to hold the reorder lock across accesses to the structure, and the debugfs code that should just use RCU. Also, remove acquiring the sta->lock across reorder timeouts since it isn't necessary, and change a few places to GFP_KERNEL because the code path here doesn't need atomic allocations as I noticed when reviewing all this. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Acked-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: implement off-channel mgmt TXJohannes Berg2010-11-294-6/+129
| | | | | | | | | | | | This implements the new off-channel TX API in mac80211 with a new work item type. The operation doesn't add a new work item when we're on the right channel and there's no wait time so that for example p2p probe responses will be transmitted without delay. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* nl80211/cfg80211: extend mgmt-tx API for off-channelJohannes Berg2010-11-294-14/+63
| | | | | | | | | | | | | | | | With p2p, it is sometimes necessary to transmit a frame (typically an action frame) on another channel than the current channel. Enable this through the CMD_FRAME API, and allow it to wait for a response. A new command allows that wait to be aborted. However, allow userspace to specify whether or not it wants to allow off-channel TX, it may actually want to use the same channel only. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: implement packet loss notificationJohannes Berg2010-11-242-0/+25
| | | | | | | | | | | For drivers that have accurate TX status reporting we can report the number of consecutive lost packets to userspace using the new cfg80211 CQM event. The threshold is fixed right now, this may need to be improved in the future. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* cfg80211: allow using CQM event to notify packet lossJohannes Berg2010-11-243-0/+61
| | | | | | | | | | | | This adds the ability for drivers to use CQM events to notify about packet loss for specific stations (which could be the AP for the managed mode case). Since the threshold might be determined by the driver (it isn't passed in right now) it will be passed out of the driver to userspace in the event. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: avoid aggregation for VO trafficLuis R. Rodriguez2010-11-241-0/+3
| | | | | | | | | | | This should help with latency issues which can happen when using aggregation. Cc: Felix Fietkau <nbd@openwrt.org> Cc: Matt Smith <matt.smith@atheros.com> Cc: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: reduce the number of retries for nullfunc probingFelix Fietkau2010-11-241-1/+8
| | | | | | | | | Since nullfunc frames are transmitted as unicast frames, they're more reliable than the broadcast probe requests, so we need fewer retries to figure out whether the AP is really gone. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: use nullfunc instead of probe request for connection monitoringFelix Fietkau2010-11-243-26/+72
| | | | | | | | | | | | | | | nullfunc frames are better for connection monitoring, because probe requests are answered even if the AP has already dropped the connection, whereas nullfunc frames from an unassociated station will trigger a disassoc/deauth frame from the AP (WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA), which allows the station to reconnect immediately instead of waiting until it attempts to transmit the next unicast frame. This only works on hardware with reliable tx ACK reporting, any other hardware needs to fall back to the probe request method. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* cfg80211/mac80211: improve ad-hoc multicast rate handlingFelix Fietkau2010-11-243-17/+47
| | | | | | | | | - store the multicast rate as an index instead of the rate value (reduces cpu overhead in a hotpath) - validate the rate values (must match a bitrate in at least one sband) Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: probe the AP when resumingFelix Fietkau2010-11-241-0/+1
| | | | | | | | | Check the connection by probing the AP (either using nullfunc or a probe request). If nullfunc probing is supported and the assoc is no longer valid, the AP will send a disassoc/deauth immediately. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: calculate beacon loss time accuratelyFelix Fietkau2010-11-242-4/+13
| | | | | | | | | | | Instead of using a fixed 2 second timeout, calculate beacon loss interval from the advertised beacon interval and a frame count. With this beacon loss happens after N (default 7) consecutive frames are missed which for a typical setup (100TU beacon interval) is ~700ms (or ~1/3 previous). Signed-off-by: Sam Leffler <sleffler@chromium.org> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: restart beacon miss timer on system resume from suspendFelix Fietkau2010-11-241-0/+1
| | | | | | Signed-off-by: Paul Stewart <pstew@google.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* net/wireless: Use pr_<level> and netdev_<level>Joe Perches2010-11-246-56/+44
| | | | | | | | No change in output for pr_<level> prefixes. netdev_<level> output is different, arguably improved. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Merge branch 'master' of ↵John W. Linville2010-11-247-13/+80
|\ | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
| * cfg80211: fix can_beacon_sec_chan, reenable HT40Mark Mentovai2010-11-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | This follows wireless-testing 9236d838c920e90708570d9bbd7bb82d30a38130 ("cfg80211: fix extension channel checks to initiate communication") and fixes accidental case fall-through. Without this fix, HT40 is entirely blocked. Signed-off-by: Mark Mentovai <mark@moxienet.com> Cc: stable@kernel.org Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * cfg80211: fix extension channel checks to initiate communicationLuis R. Rodriguez2010-11-161-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When operating in a mode that initiates communication and using HT40 we should fail if we cannot use both primary and secondary channels to initiate communication. Our current ht40 allowmap only covers STA mode of operation, for beaconing modes we need a check on the fly as the mode of operation is dynamic and there other flags other than disable which we should read to check if we can initiate communication. Do not allow for initiating communication if our secondary HT40 channel has is either disabled, has a passive scan flag, a no-ibss flag or is a radar channel. Userspace now has similar checks but this is also needed in-kernel. Reported-by: Jouni Malinen <jouni.malinen@atheros.com> Cc: stable@kernel.org Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * Bluetooth: fix not setting security level when creating a rfcomm sessionLuiz Augusto von Dentz2010-11-091-3/+10
| | | | | | | | | | | | | | | | | | | | | | This cause 'No Bonding' to be used if userspace has not yet been paired with remote device since the l2cap socket used to create the rfcomm session does not have any security level set. Signed-off-by: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com> Acked-by: Ville Tervo <ville.tervo@nokia.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
| * Bluetooth: fix endianness conversion in L2CAPGustavo F. Padovan2010-11-091-2/+2
| | | | | | | | | | | | | | Last commit added a wrong endianness conversion. Fixing that. Reported-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
| * Bluetooth: fix unaligned access to l2cap conf datasteven miao2010-11-091-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | In function l2cap_get_conf_opt() and l2cap_add_conf_opt() the address of opt->val sometimes is not at the edge of 2-bytes/4-bytes, so 2-bytes/4 bytes access will cause data misalignment exeception. Use get_unaligned_le16/32 and put_unaligned_le16/32 function to avoid data misalignment execption. Signed-off-by: steven miao <realmz6@gmail.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
| * Bluetooth: Fix non-SSP auth request for HIGH security level socketsJohan Hedberg2010-11-091-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When initiating dedicated bonding a L2CAP raw socket with HIGH security level is used. The kernel is supposed to trigger the authentication request in this case but this doesn't happen currently for non-SSP (pre-2.1) devices. The reason is that the authentication request happens in the remote extended features callback which never gets called for non-SSP devices. This patch fixes the issue by requesting also authentiation in the (normal) remote features callback in the case of non-SSP devices. This rule is applied only for HIGH security level which might at first seem unintuitive since on the server socket side MEDIUM is already enough for authentication. However, for the clients we really want to prefer the server side to decide the authentication requrement in most cases, and since most client sockets use MEDIUM it's better to be avoided on the kernel side for these sockets. The important socket to request it for is the dedicated bonding one and that socket uses HIGH security level. The patch is based on the initial investigation and patch proposal from Andrei Emeltchenko <endrei.emeltchenko@nokia.com>. Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
| * Bluetooth: fix hidp kconfig dependency warningRandy Dunlap2010-11-091-1/+1
| | | | | | | | | | | | | | | | | | | | Fix kconfig dependency warning to satisfy dependencies: warning: (BT_HIDP && NET && BT && BT_L2CAP && INPUT || USB_HID && HID_SUPPORT && USB && INPUT) selects HID which has unmet direct dependencies (HID_SUPPORT && INPUT) Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
| * mac80211: unset SDATA_STATE_OFFCHANNEL when cancelling a scanBrian Cavagnolo2010-11-081-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For client STA interfaces, ieee80211_do_stop unsets the relevant interface's SDATA_STATE_RUNNING state bit prior to cancelling an interrupted scan. When ieee80211_offchannel_return is invoked as part of cancelling the scan, it doesn't bother unsetting the SDATA_STATE_OFFCHANNEL bit because it sees that the interface is down. Normally this doesn't matter because when the client STA interface is brought back up, it will probably issue a scan. But in some cases (e.g., the user changes the interface type while it is down), the SDATA_STATE_OFFCHANNEL bit will remain set. This prevents the interface queues from being started. So we cancel the scan before unsetting the SDATA_STATE_RUNNING bit. Signed-off-by: Brian Cavagnolo <brian@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * cfg80211: fix a crash in dev lookup on dump commandsFelix Fietkau2010-11-081-2/+2
| | | | | | | | | | | | | | | | | | IS_ERR and PTR_ERR were called with the wrong pointer, leading to a crash when cfg80211_get_dev_from_ifindex fails. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | Revert "nl80211/mac80211: Report signal average"John W. Linville2010-11-246-12/+1
| | | | | | | | | | | | | | | | This reverts commit 86107fd170bc379869250eb7e1bd393a3a70e8ae. This patch inadvertantly changed the userland ABI. Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: Disable hw crypto for GTKs on AP VLAN interfacesHelmut Schaa2010-11-221-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using AP VLAN interfaces, each VLAN interface should be in its own broadcast domain. Hostapd achieves this by assigning different GTKs to different AP VLAN interfaces. However, mac80211 drivers are not aware of AP VLAN interfaces and as such mac80211 sends the GTK to the driver in the context of the base AP mode interface. This causes problems when multiple AP VLAN interfaces are used since the driver will use the same key slot for the different GTKs (there's no way for the driver to distinguish the different GTKs from different AP VLAN interfaces). Thus, only the clients associated to one AP VLAN interface (the one that was created last) can actually use broadcast traffic. Fix this by not programming any GTKs for AP VLAN interfaces into the hw but fall back to using software crypto. The GTK for the underlying AP interface is still sent to the driver. That means, broadcast traffic to stations associated to an AP VLAN interface is encrypted in software whereas broadcast traffic to stations associated to the non-VLAN AP interface is encrypted in hardware. Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | cfg80211: Fix regulatory bug with multiple cards and delaysLuis R. Rodriguez2010-11-221-9/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When two cards are connected with the same regulatory domain if CRDA had a delayed response then cfg80211's own set regulatory domain would still be the world regulatory domain. There was a bug on cfg80211's logic such that it assumed that once you pegged a request as the last request it was already the currently set regulatory domain. This would mean we would race setting a stale regulatory domain to secondary cards which had the same regulatory domain since the alpha2 would match. We fix this by processing each regulatory request atomically, and only move on to the next one once we get it fully processed. In the case CRDA is not present we will simply world roam. This issue is only present when you have a slow system and the CRDA processing is delayed. Because of this it is not a known regression. Without this fix when a delay is present with CRDA the second card would end up with an intersected regulatory domain and not allow it to use the channels it really is designed for. When two cards with two different regulatory domains were inserted you'd end up rejecting the second card's regulatory domain request. This fails with mac80211_hswim's regtest=2 (two requests, same alpha2) and regtest=3 (two requests, different alpha2) module parameter options. This was reproduced and tested against mac80211_hwsim using this CRDA delayer: #!/bin/bash echo $COUNTRY >> /tmp/log sleep 2 /sbin/crda.orig And these regulatory tests: modprobe mac80211_hwsim regtest=2 modprobe mac80211_hwsim regtest=3 Reported-by: Mark Mentovai <mark@moxienet.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Tested-by: Mark Mentovai <mark@moxienet.com> Tested-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | cfg80211: move mutex locking to reg_process_pending_hints()Luis R. Rodriguez2010-11-221-8/+8
| | | | | | | | | | | | | | | | | | | | This will be required in the next patch and it makes the next patch easier to review. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Tested-by: Mark Mentovai <mark@moxienet.com> Tested-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | cfg80211: move reg_work and reg_todo aboveLuis R. Rodriguez2010-11-221-2/+3
| | | | | | | | | | | | | | | | | | These will be used earlier in the next few patches. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Tested-by: Mark Mentovai <mark@moxienet.com> Tested-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | cfg80211: put core regulatory request into queueLuis R. Rodriguez2010-11-221-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | This will simplify the synchronization for pending requests. Without this we have a race between the core and when we restore regulatory settings, although this is unlikely its best to just avoid that race altogether. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Tested-by: Mark Mentovai <mark@moxienet.com> Tested-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | nl80211/mac80211: Report signal averageBruno Randolf2010-11-186-1/+12
| | | | | | | | | | | | | | | | | | | | | | Extend nl80211 to report an exponential weighted moving average (EWMA) of the signal value. Since the signal value usually fluctuates between different packets, an average can be more useful than the value of the last packet. This uses the recently added generic EWMA library function. Signed-off-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: fix powersaving clients racesJohannes Berg2010-11-174-7/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code to handle powersaving stations has a race: when the powersave flag is lifted from a station, we could transmit a packet that is being processed for TX at the same time right away, even if there are other frames queued for it. This would cause frame reordering. To fix this, lift the flag only under the appropriate lock that blocks TX. Additionally, the code to allow drivers to block a station while frames for it are on the HW queue is never re-enabled the station, so traffic would get stuck indefinitely. Fix this by clearing the flag for this appropriately. Finally, as an optimisation, don't do anything if the driver unblocks an already unblocked station. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: defines for AC numbersJohannes Berg2010-11-171-1/+10
| | | | | | | | | | | | | | | | | | | | | | In many places we've just hardcoded the AC numbers -- which is a relic from the original mac80211 (d80211). Add constants for them so we know what we're talking about. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: add support for setting the ad-hoc multicast rateFelix Fietkau2010-11-163-6/+19
| | | | | | | | | | Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | cfg80211: add support for setting the ad-hoc multicast rateFelix Fietkau2010-11-161-0/+5
| | | | | | | | | | Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: Add function to get probe request template for current APJuuso Oikarinen2010-11-163-5/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Chipsets with hardware based connection monitoring need to autonomically send directed probe-request frames to the AP (in the event of beacon loss, for example.) For the hardware to be able to do this, it requires a template for the frame to transmit to the AP, filled in with the BSSID and SSID of the AP, but also the supported rate IE's. This patch adds a function to mac80211, which allows the hardware driver to fetch this template after association, so it can be configured to the hardware. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: Add antenna configurationBruno Randolf2010-11-163-0/+92
| | | | | | | | | | | | | | | | | | | | 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: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | cfg80211: Add nl80211 antenna configurationBruno Randolf2010-11-161-1/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Bruno Randolf <br1@einfach.org> -- v7: Made bitmasks 32 bit wide and rebased to latest wireless-testing. Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: support hardware TX fragmentation offloadArik Nemtsov2010-11-165-2/+54
| | | | | | | | | | | | | | | | | | | | | | 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: Arik Nemtsov <arik@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: Remove redundant checks for NULL before calls to crypto_free_cipher()Jesper Juhl2010-11-152-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | crypto_free_cipher() is a wrapper around crypto_free_tfm() which is a wrapper around crypto_destroy_tfm() and the latter can handle being passed a NULL pointer, so checking for NULL in the ieee80211_aes_key_free()/ieee80211_aes_cmac_key_free() wrappers around crypto_free_cipher() is pointless and just increase object code size needlesly and makes us execute extra test/branch instructions that we don't need. Btw; don't we have to many wrappers around wrappers ad nauseam here? Anyway, this patch removes the redundant conditionals. Signed-off-by: Jesper Juhl <jj@chaosbits.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: refactor debugfs function generation codeEliad Peller2010-11-154-55/+52
| | | | | | | | | | | | | | | | | | | | refactor mac80211 debugfs code by using a format&copy function, instead of duplicating the code for each generated function. this change reduces about 600B from mac80211.ko Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: minstrel_ht - reduce the overhead of rate samplingFelix Fietkau2010-11-151-6/+10
| | | | | | | | | | | | | | | | | | | | - reduce the number of retransmission attempts for sample rates - sample lower rates less often - do not use RTS/CTS for sampling frames - increase the time between sampling attempts Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | cfg80211: prefix REG_DBG_PRINT() with cfg80211Luis R. Rodriguez2010-11-151-16/+15
| | | | | | | | | | | | | | | | Everyone's doing it, its the cool thing. Cc: Easwar Krishnan <easwar.krishnan@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | cfg80211: add debug print when processing a channelLuis R. Rodriguez2010-11-151-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | In the worst case you are seeing really odd things you want more information than what is provided right now, for those that insist and want debug info through CONFIG_CFG80211_REG_DEBUG provide a print of when we are processing a channel and with what regulatory rule. Cc: Easwar Krishnan <easwar.krishnan@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | cfg80211: add debug print when disabling a channel on a custom regdLuis R. Rodriguez2010-11-151-0/+5
| | | | | | | | | | | | Cc: Easwar Krishnan <easwar.krishnan@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | cfg80211: add debug prints for when we ignore regulatory hintsLuis R. Rodriguez2010-11-151-3/+39
| | | | | | | | | | | | | | | | | | | | This can help with debugging issues. You will only see these with CONFIG_CFG80211_REG_DEBUG enabled. Cc: Easwar Krishnan <easwar.krishnan@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | cfg80211: fix disabling channels based on hintsLuis R. Rodriguez2010-11-151-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After a module loads you will have loaded the world roaming regulatory domain or a custom regulatory domain. Further regulatory hints are welcomed and should be respected unless the regulatory hint is coming from a country IE as the IEEE spec allows for a country IE to be a subset of what is allowed by the local regulatory agencies. So disable all channels that do not fit a regulatory domain sent from a unless the hint is from a country IE and the country IE had no information about the band we are currently processing. This fixes a few regulatory issues, for example for drivers that depend on CRDA and had no 5 GHz freqencies allowed were not properly disabling 5 GHz at all, furthermore it also allows users to restrict devices further as was intended. If you recieve a country IE upon association we will also disable the channels that are not allowed if the country IE had at least one channel on the respective band we are procesing. This was the original intention behind this design but it was completely overlooked... Cc: David Quan <david.quan@atheros.com> Cc: Jouni Malinen <jouni.malinen@atheros.com> cc: Easwar Krishnan <easwar.krishnan@atheros.com> Cc: stable@kernel.org Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | cfg80211: fix allowing country IEs for WIPHY_FLAG_STRICT_REGULATORYLuis R. Rodriguez2010-11-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We should be enabling country IE hints for WIPHY_FLAG_STRICT_REGULATORY even if we haven't yet recieved regulatory domain hint for the driver if it needed one. Without this Country IEs are not passed on to drivers that have set WIPHY_FLAG_STRICT_REGULATORY, today this is just all Atheros chipset drivers: ath5k, ath9k, ar9170, carl9170. This was part of the original design, however it was completely overlooked... Cc: Easwar Krishnan <easwar.krishnan@atheros.com> Cc: stable@kernel.org Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | cfg80211: pass the reg hint initiator to helpersLuis R. Rodriguez2010-11-151-4/+8
| | | | | | | | | | | | | | | | | | | | This is required later. Cc: Easwar Krishnan <easwar.krishnan@atheros.com> Cc: stable@kernel.org signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | rfkill: remove dead codeStephen Hemminger2010-11-151-14/+0
| | | | | | | | | | | | | | The following code is defined but never used. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
OpenPOWER on IntegriCloud