Johannes Berg [Wed, 27 Mar 2013 19:49:58 +0000 (20:49 +0100)]
iwlwifi: dvm: fix the passive-no-RX workaround
Alex Romosan reported that since the mac80211 changes in
"mac80211: start auth/assoc timeout on frame status" and
the subsequent fixes in "mac80211: fix auth/assoc timeout
handling" (commits 1672c0e31917 and 89afe614c0c) there's
sometimes an issue connecting to a 5 GHz network with the
iwlwifi DVM driver.
The reason appears to be that since these commits any bad
TX status makes mac80211 immediately try again, causing
all of the authentication attempts to be quickly rejected
by the firmware as it hasn't heard a beacon yet. Before,
it would wait for the timeout regardless of status.
To fix this, invoke the passive-no-RX workaround when not
associated yet as well. This will cause the first frame
to get lost, but then the driver will stop the queues and
the second attempt will only be transmitted after hearing
a beacon, thus delaying it appropriately to not make the
firmware reject it again.
Reported-by: Alex Romosan <romosan@sycorax.lbl.gov> Tested-by: Alex Romosan <romosan@sycorax.lbl.gov> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There is a race between the restart flow and the workers.
The workers are cancelled after the fw is already killed
and might send HCMD when there is fw to handle them.
Simply check that there is a fw to which the HCMD can be
sent before actually sending it.
Cc: stable@vger.kernel.org Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
As reported by Ben Hutchings, there was a harmless issue in
the checks being done on the lengths of the TBs while
building the TFD for a multi-TB host command.
Cc: stable@vger@kernel.org Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This flow happens when we get a failed single Tx response
on an AMPDU queue. In this case, the frame won't be sent
any more. So we need to move the window on the recipient
side. This is done by a BAR.
Now if we are in the following case: 10, 12 and 13 are ACKed
and 11 isn't.
10 11 12 13.
V X V V
Then, 11 will be sent 16 times as an MPDU (as oppsed to
A-MPDU). If this failed, we are entering the flow described
above. So we need to send a BAR with ssn = 12.
But in this case, the scheduler will tell us to free frames
up to 13 (included).
So, it is perfectly possible to get a failed single Tx
response on an AMPDU queue that makes the scheduler's ssn
jump by more than 1 single packet.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since the device is being restarted, all the Rx / Tx Block
Ack sessions are been wiped out by the driver. So ignore
the requests from mac80211 that stops Tx agg while
reconfiguring the device.
Note that stopping a non-existing Rx BA session is harmless,
so just honor mac80211's request.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Dor Shaish [Wed, 27 Feb 2013 11:01:09 +0000 (13:01 +0200)]
iwlwifi: mvm: Remove overriding calibrations for the 7000 family
This fix removes the override of calibration request values sent
to the FW.
Due to that, the sending of default values to now implemented
calibrations is removed.
Signed-off-by: Dor Shaish <dor.shaish@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Wed, 27 Feb 2013 12:18:50 +0000 (13:18 +0100)]
iwlwifi: use coherent DMA memory for command header
Recently in commit 8a964f44e01ad3bbc208c3e80d931ba91b9ea786
("iwlwifi: always copy first 16 bytes of commands") we fixed
the problem that the hardware writes back to the command and
that could overwrite parts of the data that was still needed
and would thus be corrupted.
Investigating this problem more closely we found that this
write-back isn't really ordered very well with respect to
other DMA traffic. Therefore, it sometimes happened that the
write-back occurred after unmapping the command again which
is clearly an issue and could corrupt the next allocation
that goes to that spot, or (better) cause IOMMU faults.
To fix this, allocate coherent memory for the first 16 bytes
of each command, containing the write-back part, and use it
for all queues. All the dynamic DMA mappings only need to be
TO_DEVICE then. This ensures that even when the write-back
happens "too late" it can't hit memory that has been freed
or a mapping that doesn't exist any more.
Since now the actual command is no longer modified, we can
also remove CMD_WANT_HCMD and get rid of the DMA sync that
was necessary to update the scratch pointer.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Supporting 8K A-MSDU means that we need to allocate order 1
pages for every Rx packet. Even when there is no traffic.
This adds stress on the memory manager. The handling of
compound pages is also less trivial for the memory manager
and not using them will make the allocation code run faster
although I didn't really measure.
Eric also pointed out that having huge buffers with little
data in them is not very nice towards the TCP stack since
the truesize of the skb is huge. This doesn't allow TCP
to have a big Rx window.
See https://patchwork.kernel.org/patch/2167711/ for details.
Note that very few vendors will actually send A-MSDU.
Disable this feature by default.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Tue, 26 Feb 2013 10:32:26 +0000 (11:32 +0100)]
iwlwifi: rename IWL_MAX_CMD_TFDS to IWL_MAX_CMD_TBS_PER_TFD
The IWL_MAX_CMD_TFDS name for this constant is wrong, the
constant really indicates how many TBs we can use in the
driver for a single command TFD, rename the constant and
also add a comment explaining it.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The reason we mapped them bidirectionally was that not doing
so had caused IOMMU exceptions, due to the fact that the HW
writes back into the command. Now that the first part of the
command including the write-back part is always in the first
buffer, we don't need to map the remaining buffer(s) bidi
and can get rid of the special-casing for commands.
This is a requisite patch for another one to fix DMA mapping.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Dor Shaish [Tue, 12 Feb 2013 07:49:00 +0000 (09:49 +0200)]
iwlwifi: mvm: Remove testing of static PIC in PhyDB
The PIC was supposed to be a small signature appended to the
PhyDB data, but the signature isn't really static and thus
attempting to check it just causes the warnings spuriously
so remove them.
Signed-off-by: Dor Shaish <dor.shaish@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Tue, 26 Feb 2013 11:04:18 +0000 (12:04 +0100)]
iwlwifi: fix wakeup status query and packet reporting
The wakeup packet in the status response is padded out
to a multiple of 4 bytes by the firmware for transfer
to the host, take that into account when checking the
length of the command.
Also, the reported wakeup packet includes the FCS but
the userspace API doesn't, so remove that. If it is a
data packet it is reported as an 802.3 packet but I
forgot to take into account and remove the encryption
head/tail, fix all of that as well.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Fri, 22 Feb 2013 13:07:56 +0000 (14:07 +0100)]
iwlwifi: mvm: fix AP/GO mode station removal
When stations are removed while packets are in the queue,
we drain the queues first, and then remove the stations.
If this happens in AP mode while the interface is removed
the MAC context might be removed from the firmware before
we removed the station(s), resulting in a SYSASSERT 3421.
This is because we remove the MAC context from the FW in
stop_ap(), but only flush the station drain work later in
remove_interface().
Refactor the code a bit to have a common MAC context
removal preparation first to solve this.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Mon, 25 Feb 2013 15:01:34 +0000 (16:01 +0100)]
iwlwifi: always copy first 16 bytes of commands
The FH hardware will always write back to the scratch field
in commands, even host commands not just TX commands, which
can overwrite parts of the command. This is problematic if
the command is re-used (with IWL_HCMD_DFL_NOCOPY) and can
cause calibration issues.
Address this problem by always putting at least the first
16 bytes into the buffer we also use for the command header
and therefore make the DMA engine write back into this.
For commands that are smaller than 16 bytes also always map
enough memory for the DMA engine to write back to.
Cc: stable@vger.kernel.org Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Wei Yongjun [Fri, 22 Feb 2013 13:32:20 +0000 (21:32 +0800)]
brcmfmac: fix missing unlock on error in brcmf_notify_vif_event()
Add the missing unlock before return from function brcmf_notify_vif_event()
in the error handling case.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Avinash Patil [Thu, 21 Feb 2013 05:12:58 +0000 (21:12 -0800)]
mwifiex: fix system freeze while reloading driver
Unload sequence for mwifiex PCIE driver is as follows:
1. Invoking cleanup module from kernel results into
pci_unregister_driver
2. Kernel invokes PCIE remove() handler which disconnects all
interfaces.
3. One step during disconnect is to clean PCIE TX rings.
During this we read txbd_rdptr from FW.
While loading driver next time, we see pci_enable_device()
results into system freeze. This may have happened because we
accessed PCI device after unregistering from bus driver.
Removing this ioread() operation resolves this bug.
Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Daniel Drake [Tue, 19 Feb 2013 20:09:47 +0000 (15:09 -0500)]
mwifiex: don't drop carrier flag over suspend
If the system suspends with mwifiex wifi powered on, and is then woken
by an ICMP ping packet, the ping response is discarded by the kernel
because the kernel incorrectly thinks there is no carrier.
I can't see any valid reason to want to report loss of carrier here,
so remove the offending code.
Fixes http://dev.laptop.org/ticket/12554
Signed-off-by: Daniel Drake <dsd@laptop.org> Acked-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Kumar Amit Mehta [Mon, 18 Feb 2013 11:37:44 +0000 (03:37 -0800)]
net: wireless: orinoco: orinoco_usb.c: fix DMA buffers on stack
This patch fixes an instance of DMA buffer on stack(being passed to
usb_control_msg) for the wireless USB version of the Agere Orinoco card driver.
It also fixes the missing audit for the return value of firmware download
routine. Found using smatch.
Signed-off-by: Kumar Amit Mehta <gmate.amit@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jussi Kivilinna [Mon, 18 Feb 2013 08:29:30 +0000 (10:29 +0200)]
rtlwifi: usb: allocate URB control message setup_packet and data buffer separately
rtlwifi allocates both setup_packet and data buffer of control message urb,
using shared kmalloc in _usbctrl_vendorreq_async_write. Structure used for
allocating is:
struct {
u8 data[254];
struct usb_ctrlrequest dr;
};
Because 'struct usb_ctrlrequest' is __packed, setup packet is unaligned and
DMA mapping of both 'data' and 'dr' confuses ARM/sunxi, leading to memory
corruptions and freezes.
Patch changes setup packet to be allocated separately.
[v2]:
- Use WARN_ON_ONCE instead of WARN_ON
Cc: <stable@vger.kernel.org> Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
For STA mode, collect VHT realated IEs from the Beacons or Probe
Responses and append similar VHT related IEs to association
requests.
For AP mode, get VHT related capability information and share it
with cfg80211 at the time of wiphy register. This information is
further used by cfg80211 and hostapd to start an AP with 802.11AC
support.
Currently only 8897 supports 802.11AC.
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Nishant Sarmukadam <nishants@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Frank Huang <frankh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Avinash Patil [Sat, 16 Feb 2013 05:37:54 +0000 (21:37 -0800)]
mwifiex: fix empty TX ring check for PCIe8897 while unloading driver
While unloading driver, we free all pending TX packets by flushing
TX ring. There is unhandled case for PCIE8897 while checking for
ring empty condition.
This patch adds the handling by calling mwifiex_pcie_txbd_empty().
Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Eytan Lifshitz [Fri, 15 Feb 2013 14:31:45 +0000 (16:31 +0200)]
iwlwifi: dvm: fix delayed enter to CT-kill bug
Theoretically, the card may not enter CTKILL:
In case the timer that iwl_prepare_ct_kill_task is setting,
will expire before tt->state revert to its previous state.
Signed-off-by: Eytan Lifshitz <eytan.lifshitz@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Ilan Peer [Mon, 11 Feb 2013 06:50:45 +0000 (08:50 +0200)]
iwlwifi: mvm: Set the scan type according to the vif type
The FW can differentiate between scans, according to the interface
type on which the scan was issues. Supply the interfaces type
information to the FW.
Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Fri, 15 Feb 2013 23:11:34 +0000 (00:11 +0100)]
iwlwifi: mvm: fix time event command handling race
Occasionally, we would run into this warning:
iwlwifi 0000:02:00.0: U iwl_mvm_protect_session extend 0x2601: only 200 ms left
iwlwifi 0000:02:00.0: U iwl_mvm_remove_time_event Removing TE 0x2601
iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TIME_EVENT_CMD (#29), seq: 0x0925, 60 bytes at 37[5]:9
iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command TIME_EVENT_CMD
iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command TIME_EVENT_CMD
iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TIME_EVENT_CMD (#29), seq: 0x0926, 60 bytes at 38[6]:9
iwlwifi 0000:02:00.0: U iwl_mvm_time_event_response TIME_EVENT_CMD response - UID = 0x2601
iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command TIME_EVENT_CMD
iwlwifi 0000:02:00.0: U iwl_mvm_rx_time_event_notif Time event notification - UID = 0x2701 action 1
wlan0: associate with 00:0a:b8:55:a8:30 (try 2/3)
------------[ cut here ]------------
WARNING: at drivers/net/wireless/iwlwifi/mvm/time-event.c:269 iwl_mvm_time_event_send_add+0x163/0x1a0 [iwlmvm]()
Modules linked in: [...]
Call Trace:
[<c1046e42>] warn_slowpath_common+0x72/0xa0
[<c1046e92>] warn_slowpath_null+0x22/0x30
[<f8cad913>] iwl_mvm_time_event_send_add+0x163/0x1a0 [iwlmvm]
[<f8cadead>] iwl_mvm_protect_session+0xcd/0x1c0 [iwlmvm]
[<f8ca2087>] iwl_mvm_mac_mgd_prepare_tx+0x67/0xa0 [iwlmvm]
[<f882a130>] ieee80211_sta_work+0x8f0/0x1070 [mac80211]
The reason is a problem with asynchronous vs. synchronous
commands, what happens here is the following:
* TE 0x2601 is removed, the TIME_EVENT_CMD for that is async
* a new TE (will be 0x2701) is created, the TIME_EVENT_CMD
for that is sync and also uses a notification wait for the
response (to avoid another race condition)
* the response for the TE 0x2601 removal comes from the
firmware, and is handled by the notification wait handler
that's really waiting for the second response, but can't
tell the difference, we therefore see the message
"TIME_EVENT_CMD response - UID = 0x2601" instead of
"TIME_EVENT_CMD response - UID = 0x2701".
Fix this issue by making the TE removal synchronous as well,
this means that we wait for the response to that command
first, before there's any chance of sending a new one.
Also, to detect such issues more easily in the future, add
a warning to the notification handler that detects them.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Fri, 15 Feb 2013 21:47:48 +0000 (22:47 +0100)]
iwlwifi: mvm: fix GO powersave client manipulation
All station commands must include a valid MAC ID,
the ID 0 is randomly valid in some cases, but we
must set the ID properly. Do that by passing the
right station and using its mac_id_n_color.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Tue, 5 Feb 2013 17:10:04 +0000 (18:10 +0100)]
iwlwifi: mvm: program DTIM timings properly
For the firmware to know when DTIM beacons arrive
we have to program the DTIM time in TSF and system
time in the MAC context. Since mac80211 now tracks
the different times (on demand), this becomes easy.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Mon, 18 Feb 2013 13:57:42 +0000 (14:57 +0100)]
cfg80211: fix station change if TDLS isn't supported
Larry noticed (and bisected) that commit df881293c6ba9a12868491a717b25
"cfg80211: Pass TDLS peer's QoS/HT/VHT information during set_station"
broke secure connections. This is is the case only for drivers that
don't support TDLS, where any kind of change, even just the change of
authorized flag that is required for normal operation, was rejected
now. To fix this, remove the checks. I have some patches that will add
proper verification for all the different cases later.
Cc: Jouni Malinen <j@w1.fi> Bisected-by: Larry Finger <Larry.Finger@lwfinger.net> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Thomas Pedersen [Sat, 16 Feb 2013 18:41:05 +0000 (10:41 -0800)]
mac80211: stringify mesh peering events
Convert mesh peering events into strings and make the
debug output a little easier to read. Also stop printing
the llid and plid since these don't change across peering
states and are random numbers anyway so they just amount
to noise.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Thomas Pedersen [Sat, 16 Feb 2013 18:41:04 +0000 (10:41 -0800)]
mac80211: clean up mesh HT operation
ieee80211_ht_cap_ie_to_sta_ht_cap() will clean up the
ht_supported flag and station bandwidth field for us
if the peer beacon doesn't have an HT capability element
(is operating as non-HT).
Also, we don't really need a special station ch_width
member to track the station operating mode any more so use
sta.bandwidth instead.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Fri, 15 Feb 2013 10:47:50 +0000 (11:47 +0100)]
mac80211: fix harmless station flush warning
If an interface is set down while authenticating or
associating, there's a station entry that will be
removed by the flushing in do_stop() and that will
cause a warning. It's otherwise harmless, but avoid
the warning by calling ieee80211_mgd_stop() first.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Seth Forshee [Fri, 15 Feb 2013 19:15:48 +0000 (13:15 -0600)]
mac80211: Fix incorrect use of STA_PR_FMT in trace points
Several tracepoints are using STA_PR_FMT where STA_PR_ARG should be
used, resulting in messages like "phy0 sta:ARG TYPE NOT FIELD BUT 1".
Change these to STA_PR_ARG.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bob Copeland [Fri, 15 Feb 2013 15:18:34 +0000 (10:18 -0500)]
mac80211: enable vif.cab_queue for mesh
Since mesh powersaving was added, pending bcast/mcast frames may go out the
CAB queue now. Unfortunately, the queue was only set up for AP mode, so we
would try to tx on the IEEE80211_INVAL_HW_QUEUE. Allow cab_queue for mesh
interfaces as well.
Fixes the following warning (or crash without MAC80211_VERBOSE_DEBUG):
Even when connecting to an AP that doesn't support VHT,
and even when the local device doesn't support it either,
the downgrade message gets printed. Suppress the message
if HT and/or VHT is disabled.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Adding the flag to mac80211 already without testing was
clearly a mistake, one that we now pay for by having to
reserve bit 13 forever. The problem is cfg80211 doesn't
allow capability/rate changes for station entries that
were added unassociated, so the station entries cannot
be set up properly when marked associated.
Change the NL80211_FEATURE_FULL_AP_CLIENT_STATE value
to make it clear to userspace implementations that all
current kernels don't actually support it, even though
the previous bit is set, and of course also remove the
flag from mac80211 until we test and fix the issues.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Jouni Malinen [Thu, 14 Feb 2013 19:10:54 +0000 (21:10 +0200)]
cfg80211: Pass TDLS peer's QoS/HT/VHT information during set_station
The information of the peer's capabilities is required for the driver
to perform TDLS Peer UAPSD operations. This information of the peer is
passed by the supplicant using NL80211_CMD_SET_STATION command. This
commit enhances the function nl80211_set_station to pass this
information of the peer to the driver in case this command is used
with the TDLS peer STA.
In addition, make the HT/VHT capability configuration handled more
consistently for other STA cases (reject both instead of just HT).
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Jouni Malinen [Thu, 14 Feb 2013 19:10:13 +0000 (21:10 +0200)]
cfg80211: Pass station (extended) capability info to kernel
The information of the peer's capabilities and extended capabilities are
required for the driver to perform TDLS Peer UAPSD operations and off
channel operations. This information of the peer is passed from user space
using NL80211_CMD_SET_STATION command. This commit enhances
the function nl80211_set_station to pass the capability information of
the peer to the driver.
Similarly, there may be need for capability information for other modes,
so allow this to be provided with both add_station and change_station.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Mon, 11 Feb 2013 13:20:05 +0000 (14:20 +0100)]
cfg80211: advertise extended capabilities to userspace
In many cases, userspace may need to know which of the
802.11 extended capabilities ("Extended Capabilities
element") are implemented in the driver or device, to
include them e.g. in beacons, assoc request/response
or other frames. Add a new nl80211 attribute to hold
the extended capabilities bitmap for this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Tue, 12 Feb 2013 13:21:00 +0000 (14:21 +0100)]
mac80211: stop modifying HT SMPS capability
Instead of modifying the HT SMPS capability field
for stations, track the SMPS mode explicitly in a
new field in the station struct and use it in the
drivers that care about it. This simplifies the
code using it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Thomas Pedersen [Thu, 14 Feb 2013 19:20:13 +0000 (11:20 -0800)]
mac80211: cache mesh beacon
Previously, the entire mesh beacon would be generated each
time the beacon timer fired. Instead generate a beacon
head and tail (so the TIM can easily be inserted when mesh
power save is on) when starting a mesh or the MBSS
parameters change.
Also add a mutex for protecting beacon updates and
preventing leaks.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Wed, 12 Dec 2012 16:59:39 +0000 (17:59 +0100)]
nl80211: advertise HT/VHT channel limitations
When drivers or regulatory have limitations on
40, 80 or 160 MHz channels, advertise these to
userspace via nl80211. Also add a new feature
flag to let userspace know this is supported.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Wed, 12 Dec 2012 16:50:39 +0000 (17:50 +0100)]
cfg80211: allow drivers to selectively disable 80/160 MHz
Some drivers might support 80 or 160 MHz only on some
channels for whatever reason, so allow them to disable
these channel widths. Also maintain the new flags when
regulatory bandwidth limitations would disable these
wide channels.
Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Fri, 8 Feb 2013 14:12:14 +0000 (15:12 +0100)]
mac80211: properly track HT/VHT operation changes
A while ago, I made the mac80211 station code never change
the channel type after association. This solved a number of
issues but is ultimately wrong, we should react if the AP
changes the HT operation IE and switches bandwidth. One of
the issues is that we associate as HT40 capable, but if the
AP ever switches to 40 MHz we won't be able to receive such
frames because we never set our channel to 40 MHz.
This addresses this and VHT operation changes. If there's a
change that is incompatible with our setup, e.g. if the AP
decides to change the channel entirely (and for some reason
we still hear the beacon) we'll just disconnect.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Thu, 7 Feb 2013 20:37:29 +0000 (21:37 +0100)]
mac80211: add ieee80211_vif_change_bandwidth
For HT and VHT the current bandwidth can change,
add the function ieee80211_vif_change_bandwidth()
to take care of this. It returns a failure if the
new bandwidth isn't compatible with the existing
channel context, the caller has to handle that.
When it happens, also inform the driver that the
bandwidth changed for this virtual interface (no
drivers would actually care today though.)
Changing to/from HT/VHT isn't allowed though.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Thu, 7 Feb 2013 22:33:32 +0000 (23:33 +0100)]
mac80211: disable HT/VHT if AP has no HT/VHT capability
Having HT/VHT operation IEs but not capability IEs
leads to a strange situation where we configure the
channel to an HT or VHT bandwidth and then can't
actually use it. Prevent this by checking that the
HT and VHT capability IEs are present as well as
the operation IEs; if not, disable HT and/or VHT.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Thu, 7 Feb 2013 21:24:55 +0000 (22:24 +0100)]
mac80211: handle operating mode notif in beacon/assoc response
In beacons and association response frames an AP may include an
operating mode notification element to advertise changes in the
number of spatial streams it can receive. Handle this using the
existing function that handles the action frame, but only handle
NSS changes, not bandwidth changes which aren't allowed here.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Thu, 7 Feb 2013 16:36:12 +0000 (17:36 +0100)]
mac80211: init HT TX data before rate control
In case of connection, the station data is initialised from
the beacon/probe response first and then updated from the
association response. If the latter is different we update
the rate control algorithm and driver. Instead of doing it
this way, set the station data properly with data from the
association response before initializing rate control.
Also simplify the code by passing the station pointer.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Thu, 27 Dec 2012 17:55:36 +0000 (18:55 +0100)]
mac80211: handle VHT operating mode notification
Handle the operating mode notification action frame.
When the supported streams or the bandwidth change
let the driver and rate control algorithm know.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Thu, 27 Dec 2012 17:26:42 +0000 (18:26 +0100)]
mac80211: track number of spatial streams
With VHT, a station can change the number of spatial
streams it can receive on the fly, not unlike spatial
multiplexing in HT. Prepare for that by tracking the
maximum number of spatial streams it can receive when
the connection is established.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Thu, 27 Dec 2012 17:45:41 +0000 (18:45 +0100)]
wireless: define operating mode action frame
Define the action frame format, the VHT category
and its action types and the field format and EID
for operating mode notifications. The frame may
be used outside of VHT context as well, so don't
include "VHT" in the names.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For VHT, many more bandwidth changes are possible. As a first
step, stop toggling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 flag
in the HT capabilities and instead introduce a bandwidth field
indicating the currently usable bandwidth to transmit to the
station. Of course, make all drivers use it.
To achieve this, make ieee80211_ht_cap_ie_to_sta_ht_cap() get
the station as an argument, rather than the new capabilities,
so it can set up the new bandwidth field.
If the station is a VHT station and VHT bandwidth is in use,
also set the bandwidth accordingly.
Doing this allows us to get rid of the supports_40mhz flag as
the HT capabilities now reflect the true capability instead of
the current setting.
While at it, also fix ieee80211_ht_cap_ie_to_sta_ht_cap() to not
ignore HT cap overrides when MCS TX isn't supported (not that it
really happens...)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Thu, 7 Feb 2013 10:58:58 +0000 (11:58 +0100)]
mac80211: pass station to ieee80211_vht_cap_ie_to_sta_vht_cap
Like with HT, make things a bit simpler in future patches by
passing the station to ieee80211_vht_cap_ie_to_sta_vht_cap()
instead of the vht_cap pointer. Also disable VHT here if HT
isn't supported.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Wed, 13 Feb 2013 17:03:00 +0000 (18:03 +0100)]
mac80211: use spin_lock_bh() for TKIP lock
Since no driver calls the TKIP functions from interrupt
context, there's no need to use spin_lock_irqsave().
Just use spin_lock_bh() (and spin_lock() in the TX path
where we're in a BH or they're already disabled.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Wed, 13 Feb 2013 12:50:51 +0000 (13:50 +0100)]
mac80211: don't call bss_info_changed on p2p-device/monitor
Since the idle decision rework, mac80211 started calling
bss_info_changed() for the driver's monitor interface,
which causes a crash for iwlwifi, but drivers generally
don't expect this to happen. Therefore, avoid it.
While at it, also prevent calling it in such cases and
only print a warning. For the P2P Device interface the
idle will no longer be called (no channel context), so
also prevent that and warn on it.
Reported-by: Chaitanya <chaitanya.mgit@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Wed, 13 Feb 2013 14:39:57 +0000 (15:39 +0100)]
mac80211: fix auth/assoc timeout handling
In my commit 1672c0e31917f49d31d30d79067103432bc20cc7
("mac80211: start auth/assoc timeout on frame status")
I broke auth/assoc timeout handling: in case we wait
for the TX status, it now leaves the timeout field set
to 0, which is a valid time and can compare as being
before now ("jiffies"). Thus, if the work struct runs
for some other reason, the auth/assoc is treated as
having timed out.
Fix this by introducing a separate "timeout_started"
variable that tracks whether the timeout has started
and is checked before timing out.
Additionally, for proper TX status handling the change
requires that the skb->dev pointer is set up for all
the frames, so set it up for all frames in mac80211.
Reported-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com> Tested-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Wojciech Dubowik [Thu, 14 Feb 2013 13:08:37 +0000 (14:08 +0100)]
mac80211: fix ieee80211_sta_tx_notify for nullfunc
Function ieee80211_sta_reset_conn_monitor has been
resetting probe_send_count too early and nullfunc
check was never called after succesfull ack.
Reported-by: Magnus Cederlöf <mcider@gmail.com> Tested-by: Magnus Cederlöf <mcider@gmail.com> Signed-off-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Thomas Pedersen [Wed, 13 Feb 2013 20:14:19 +0000 (12:14 -0800)]
mac80211: consolidate MBSS change notification
A few mesh utility functions will call
ieee80211_bss_info_change_notify(), and then the caller
might notify the driver of the same change again. Avoid
this redundancy by propagating the BSS changes and
generally calling bss_info_change_notify() once per
change.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Michael Braun [Wed, 13 Feb 2013 15:49:16 +0000 (16:49 +0100)]
mac80211: fix WPA with VLAN on AP side with ps-sta
When sending a broadcast while at least on of the connected stations is
sleeping, it gets queued and send after a DTIM beacon is sent.
If the packet was to be sent on a vlan interface, the vif used for dequeing
from the per-bss queue does not hold the per-vlan sdata. The correct sdata is
required to use the correct per-vlan broadcast/multicast key.
This patch fixes this by restoring the per-vlan sdata using the skb->dev entry.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add command to trigger radar detection in the driver/FW.
Once radar detection is started it should continuously
monitor for radars as long as the channel active.
If radar is detected usermode notified with 'radar
detected' event.
Scanning and remain on channel functionality must be disabled
while doing radar detection/scanning, and vice versa.
Based on original patch by Victor Goldenshtein <victorg@ti.com>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add new NL80211_CMD_RADAR_DETECT, which starts the Channel
Availability Check (CAC). This command will also notify the
usermode about events (CAC finished, CAC aborted, radar
detected, NOP finished).
Once radar detection has started it should continuously
monitor for radars as long as the channel is active.
This patch enables DFS for AP mode in nl80211/cfg80211.
Based on original patch by Victor Goldenshtein <victorg@ti.com>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
[remove WIPHY_FLAG_HAS_RADAR_DETECT again -- my mistake] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This patch check output of pci_map_single() calls. I missed them on
my previous patch "iwlegacy: check for dma mapping errors", which
fixed only pci_map_page() calls.
To handle remaining possible dma mappings errors, we need to rearrange
ilXXXX_tx_skb() and il_enqueue_hcmd() functions.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Check output of dma_map_single functions which nowadays can fail (when
IOMMU is used). On write_beacon callbacks just print error, similar
like padding error is handled by rt2800_write_beacon.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Avinash Patil [Tue, 12 Feb 2013 22:38:32 +0000 (14:38 -0800)]
mwifiex: device specific sleep cookie handling for PCIe
This patch adds support for handling of PCIe sleep cookie depending
upon device properties. Some PCIe devices need sleep cookie probing
before accessing HW while some others don't. A new sleep_cookie
variable is defined as part of mwifiex_pcie_card_reg strcture and
set/reset as per device capability.
Sleep cookie is allocated/accessed/freed only when flag sleep_cookie
for this particular device is enabled.
Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Larry Finger [Tue, 12 Feb 2013 22:09:02 +0000 (16:09 -0600)]
rtlwifi: Rework Kconfig
As the number of drivers in the rtlwifi family has grown, the Kconfig
section for them has grown unwieldy. This change has two effects: (1)
Variable RTLWIFI_DEBUG is documented, and (2) the entries for the
drivers that depend on RTLWIFI are indented.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Dan Carpenter [Tue, 12 Feb 2013 12:23:14 +0000 (15:23 +0300)]
brcmsmac: fix brcms_c_country_valid()
ccode is not NUL terminated. Presumably insisting on a terminator makes
brcms_c_country_valid() return false when it's not intended. ccode[2]
is sprom->leddc_on_time.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Wed, 23 Jan 2013 21:57:40 +0000 (22:57 +0100)]
cfg80211: configuration for WoWLAN over TCP
Intel Wireless devices are able to make a TCP connection
after suspending, sending some data and waking up when
the connection receives wakeup data (or breaks). Add the
WoWLAN configuration and feature advertising API for it.
Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
projects / linux-beck.git / log