Use different timing duration check for different type of force reset,
force reset request can come from different source and based on
different reason; one type of reset request should not block other type of
reset request.
Adding structure to keep track of different force reset request.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Until now it was only possible to have one synchronous command running at
any time. If a synchronous command is in progress when a second request
arrives then the second command will fail. Create a new mutex specific for
this purpose to only allow one synchronous command at a time, but enable
other commands to wait instead of fail if a synchronous command is in
progress.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This change monitors the tx statistics to detect the drop in throughput.
When the throughput drops, the ratio of the actual_ack_count and the expected_
ack_count also drops. At the same time, the aggregated ba_timeout (the number
of ba timeout retries) also rises. If the actual_ack_count/expected_ack_count
ratio is 0 and the number of ba timeout retries rises to 16, no tx packets
(tcp, udp, or ping - icmp) can be delivered. The driver recovers from this
situation by reseting the uCode firmware. If the actual_ack_count/expected_
ack_count ratio drops below 50% (but not 0) and the aggregated ba_timeout
retries just exceed 5 (but not 16), then the driver can reset the radio to
bring the throughput up.
Signed-off-by: Trieu 'Andrew' Nguyen <trieux.t.nguyen@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
To ensure that card is in a sane state during probe we add a reset call.
This change was prompted by users of kdump who was not able to bring up the
wireless driver in the kdump kernel. The problem here was that the primary
kernel, which is not running at the time, left the wireless card up and
running. When the kdump kernel starts it is thus possible to immediately
receive interrupts from firmware after registering interrupt, but without
being ready to deal with interrupts from firmware yet.
Reported-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
get_tx_stats() will be removed from mac80211.
Compile-tested only.
Cc: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: Kalle Valo <kalle.valo@iki.fi>
Acked-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When running directed active scans we currently end up sending both the SSID
probe requests and an additional broadcast one.
This is due to the fact that we always leave the probe request template SSID IE
length to 0. Instead we should set it to the first SSID to scan, and fill the
direct_scan array with the remaining SSIDs to scan for. This way we only send
what we've been asked to: a broadcast probe request when no directed scan is
requested, and directed probe requests otherwise.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There's no need to queue a work struct from
within a work struct, just move the code to
execute directly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Change in uCode to include a unique identifier as part of sysassert,
in order to tell the difference, add the "ADVANCED SYSASSERT" description
when dump nic error to indicate the difference.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
In hostap AP mode, every time the client sends the AP
a packet the STA_NOTIFY_AWAKE code is sent from mac80211.
This results in a command being sent to the uCode even if
the client was not asleep.
The following simple patch has fixed the issue for me without any
degradation that I can find.
Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
In iwlagn the support for spectrum measurement command has been
disabled since v2.6.29 without any requests for it. In addition to this
when this command is indeed enabled it has been found to trigger firmware
SYSASSERT on at least 4965 and 5100 hardware (see
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1952 ). Since then
this code has been bitrotting and cannot just be enabled without porting.
Remove support for spectrum measurement command from iwlagn. It can be
added back if there is a future need and the firmware problem it triggers
has been fixed. Support for the spectrim measurement notification remains
as it has been enabled all the time.
In addition to this remove the 3945 spectrum measurement command Kconfig
option and make this command always supported. The code added by this
enabling is minimal and only run when user triggers a spectrum measurement
request via sysfs.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
sparse correctly warns about symbol not
being static, make static to shut it up.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It is better to first notify cfg80211 about the hw
rfkill state (so the rfkill device that will be
registered won't have the wrong state while being
registered), and the power/tt variable init can
(and probably should) also be done first.
Also rename iwl_setup_mac to
iwl_mac_setup_register to better describe what it
really does.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add function pointer for broadcast station addition so that we can call it
in from iwlcore at a later time. We only distinguish between iwlagn and
iwl3945 broadcast station addition. For the iwl3945 station addition we add
that function to iwlcore since that is where most station functionality
resides, making it part of iwl3945 will require significant code
reorganization that will dilute station management functionality. This
seems to be an efficient solution.
It may seem as though we are removing error checking when adding the 3945
broadcast station but this error checking was never really necessary since
the function returns the station id and the broadcast station id is always
set.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add support to configure missed beacon threshold, by default, if receive
"missed beacon" notification from uCode and has more than 5 consecutive
beacon missed, then perform sensitivity calibration; with this change,
allow user to adjust the missed beacon threshold from debugfs in case
more sensitivity calibration required for better performance in noisy
environment
The default value (=5) should be good enough for the normal condition,
but for very noisy environment, more sensitivity calibration could help
improve the throughput, so by setting the missed beacon threshold to
lower number, user might experience better performance result.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When a TKIP key is updated, we should pass the station
pointer instead of just the address, since drivers can
use that to store their own data. We also need to pass
the virtual interface pointer.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When dumping event log in debugfs, iwl_dump_nic_event_log()
should return the correct error code instead of let the calling
function makes it own assumption.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 do not check the return code now, what if mac80211 does start
using the return code? IEEE80211_AMPDU_TX_OPERATIONAL is a valid action,
just iwlwifi driver do not need to take any action for it; so instead of
return "-EINVAL", it is a good program practice to return "-EOPNOTSUPP"
to make sure mac80211 will not get wrong impression.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Instead of hard-coding the SM PS mode per hardware,
this makes iwlwifi support the new mac80211 API for
controlling the SM PS mode.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This feature enables the on-screen uCode event log dump. The original
method will append the event log to syslog; with this capability,
we also enable the user to write script to capture the
events which provide additional flexibility to help uCode debugging
Method
1) change to debugfs directory (sys/kernel/debug/phyX/iwlagn/data)
2) #cat log_event
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In order to help uCode debugging, adding the capability to provide
continuous uCode event logging function.
uCode events is located in round-robin event queue and filled by uCode,
by enable continuous event logging, driver check the write pointer
and log the newly added events in iwl_bg_ucode_trace() timer function.
There is still possibility of missing events if event queue being
wrapped before next event dump; but with this capability, we can have
much better understanding of the uCode behavior during runtime; it can
help to debug the uCode related issues.
Methods to enable/disable the continuous event log:
step 1: enable ucode trace timer
"echo 1 >
/sys/kernel/debug/ieee80211/phyX/iwlagn/debug/ucode_tracing"
step 2: start ftrace
sudo ./trace-cmd record -e iwlwifi_ucode:* sleep 1d
step 3: stop ftrace
sudo ./trace-cmd report trace.dat
step 4: disable ucode trace timer
"echo 0 >
/sys/kernel/debug/ieee80211/phyX/iwlagn/debug/ucode_tracing"
use "ucode_tracing" debugfs file to display number of event
queue wrapped when driver attempt the continuous event logging. If event
queue being wrapped more than once when driver has opportunity to log
the event; it indicated there are events missing in the event log trace.
This continuous event log function only available for 4965 and newer
NICs.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Change name from RF_CARD_DISABLED to CT_CARD_DISABLED to match the
indication from uCode, also log the debug message when the condition
detected in iwl_rx_card_state_notif()
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Recent powersaving work resulted in power management ops being called
during EEPROM initialization. The lock used by these functions is not
initialized at this time. Ensure lock is initialized before it is used.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When trigger event log dumping from debugfs, the entire event log
should be dumped and the size should match the number of events being
dump.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
error_event_table_ptr is only set upon receipt of REPLY_ALIVE. Until
then both event log and error log will fail. Add information to indicate
which uCode encounter the failure case.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
To help iwlagn uCode debugging, event log will dump to syslog when driver
detect uCode error occurred, but this only happen when compile with
CONFIG_IWLWIFI_DEBUG and debug flag is enabled; which is not always
the case. Also, there is another problem, if the flag is set, the entire
event log buffer will be dump to syslog, it can flood the syslog and
make it very difficult to debug the problem.
Change the default to only dump last 20 entries of event log to syslog
unless the following condition meets:
1. both compile with CONFIG_IWLWIFI_DEBUG and debug flag
is enabled, and then dump the entire event buffer to syslog.
2. dump event log request from debugfs
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Acked-by: Ben Cahill <ben.m.cahill@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
uCode error log contain information as to what the error was and where
it occurred necessary to debug any uCode issues.
Always log the information without special debug flag, this can help to
capture the important information when error happened.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Acked-by: Ben Cahill <ben.m.cahill@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Update the PCI_ID list for 5xx0 series.
Remove all the PCI_IDs which never made into production or not longer in
production.
Also make sure the supported bands(a/b/g/n) match specified PCI_IDs
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Setting "Spatial multiplexing Power Save" as part of
per device configuration parameter.
Report to uCode based on priv->conf setting, so driver can
have more control of how different devices should operate
in power save mode.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
LED blinking rate is based on tx/rx traffic, the most reasonable place
to do it is after update the traffic byte counts
This fixes the recent LED blinking breakage on 3945 introduced by "iwlwifi:
separate led function from statistic notification"
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Tested-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
CSR_INT_COALESCING previously had only one, but now has two single-byte fields.
With only one single-byte field (lowest order byte) it was okay to write via
iwl_write32(), but now with two, an iwl_write32() to the lower order field
clobbers the other field (odd-address CSR_INT_PERIODIC_REG, offset 0x5), and an
iwl_write32() to CSR_INT_PERIODIC_REG could clobber the lowest byte of the
next-higher register (CSR_INT, offset 0x8).
Fortunately, no bad side effects have been produced by the iwl_write32()
usage, due to order of execution (low order byte was always written before
higher order byte), and the fact that writing "0" to the low byte of the
next higher register has no effect (only action is when writing "1"s).
Nonetheless, this cleans up the accesses so no bad side effects might occur
in the future, if execution order changes, or more bit fields get added to
CSR_INT_COALESCING.
Add some comments regarding periodic interrupt usage.
Signed-off-by: Ben Cahill <ben.m.cahill@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We've accumulated a number of options for wiphys
which make more sense as flags as we keep adding
more. Convert the existing ones.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (42 commits)
cxgb3: fix premature page unmap
ibm_newemac: Fix EMACx_TRTR[TRT] bit shifts
vlan: Fix register_vlan_dev() error path
gro: Fix illegal merging of trailer trash
sungem: Fix Serdes detection.
net: fix mdio section mismatch warning
ppp: fix BUG on non-linear SKB (multilink receive)
ixgbe: Fixing EEH handler to handle more than one error
net: Fix the rollback test in dev_change_name()
Revert "isdn: isdn_ppp: Use SKB list facilities instead of home-grown implementation."
TI Davinci EMAC : Fix Console Hang when bringing the interface down
smsc911x: Fix Console Hang when bringing the interface down.
mISDN: fix error return in HFCmulti_init()
forcedeth: mac address fix
r6040: fix version printing
Bluetooth: Fix regression with L2CAP configuration in Basic Mode
Bluetooth: Select Basic Mode as default for SOCK_SEQPACKET
Bluetooth: Set general bonding security for ACL by default
r8169: Fix receive buffer length when MTU is between 1515 and 1536
can: add the missing netlink get_xstats_size callback
...
The entire aggregation code currently operates on the
hw pointer and station addresses, but that needs to
change to make stations purely per-vif; As one step
preparing for that make the aggregation code callable
with the station, or by the combination of virtual
interface and station address.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Using the new mac80211 functionality, this makes
iwlwifi handle unicast PS buffering correctly.
The device works like this:
* when a station goes to sleep, the microcode notices
this and marks the station as asleep
* when the station is marked asleep, the microcode
refuses to transmit to the station and rejects all
frames queued to it with the failure status code
TX_STATUS_FAIL_DEST_PS (a previous patch handled
this correctly)
* when we need to send frames to the station _although_
it is asleep, we need to tell the ucode how many,
and this is asynchronous with sending so we cannot
just send the frames, we need to wait for all other
frames to be flushed, and then update the counter
before sending out the poll response frames. This
is handled partially in the driver and partially in
mac80211.
In order to do all this correctly, we need to
* keep track of how many frames are pending for each
associated client station (avoid doing it for other
stations to avoid the atomic ops)
* tell mac80211 that we driver-block the PS status
while there are still frames pending on the queues,
and once they are all rejected (due to the dest sta
being in PS) unblock mac80211
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Handle BSS_CHANGED_BEACON_ENABLED to enable the sending
of beacons. Also set the correct HT RXON and QoS config.
Signed-off-by: Daniel C Halperin <daniel.c.halperin@intel.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When sending beacon commands to the uCode, we must
inform it of the offset in the beacon frame of the
TIM Element so it can transmit packets from the
correct queue. This functionality is implemented
in iwl_set_beacon_tim().
Fix a bug setting the rate_n_flags for the beacon
packet. First, it should not use the station table's
rate (it's a management frame), and second it needs
to properly configure the TX antennas.
Finally, also, clean up and comment relevant functions.
Signed-off-by: Daniel C Halperin <daniel.c.halperin@intel.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When issue REPLY_STATISTICS_CMD to uCode, two possible flag
can be set in the configuration flags
bit 0: Clear statistics
0: Do not clear Statistics counters
1: Clear to zero Statistics counters
Allow "clear" parameter to be set from the caller.
Add debugfs file to clear the statistics counters to help monitor and
debug the uCode behavior.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
drop the non-production PCI-IDs for 6x50 series
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add txq_id info to "Tx queue requesting wakeup" debug message
Add "Rx queue requesting wakeup" debug message
Move clear of CSR_GP_CNTRL_REG_FLAG_MAC_ACCESS_REQ to be after nearby
iwl_write_prph(), since iwl_write_prph() sets it and clears it. Almost
removed it entirely, but just making sure in case someone removes the
iwl_write_prph()! Also remove unneeded priv->lock usage; this is now
handled by priv->reg_lock within iwl_clear_bit().
Join a couple of lines that had unneeded line returns.
Signed-off-by: Ben Cahill <ben.m.cahill@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Follow-up to "update write pointers for all tx queues after wakeup"; that
patch changed iwl_irq_tasklet_legacy(), but not iwl_irq_tasklet(), so
newer devices were not covered.
Comments from original patch:
Wakeup interrupt has been updating write pointers (indexes, actually) only
for tx queues 0-5. This is adequate just for 3945, but inadequate for other
devices, all of which have more tx queues. Now updating all tx/command queues,
so device can be aware of all new tx and host commands enqueued while
device was asleep.
This can potentially improve data traffic bandwidth and/or latency.
Signed-off-by: Ben Cahill <ben.m.cahill@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Take advantage of device's auto-increment for SRAM reads to eliminate extra
write address accesses.
Grab/release NIC access before/after entire read sequence, rather than for
each read individually.
After a quick check of dmesg logs, this seems to double Event Log dump speed,
reducing from about 20 milliseconds to about 10 milliseconds for 512 entries
using 3945.
Signed-off-by: Ben Cahill <ben.m.cahill@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If device provides bad values for Event Log parameters (due to being asleep
or SRAM corruption, etc.), the size can be very, very large (e.g. 0xa5a5a5a5),
which can flood system log.
Sanity-check capacity and next_entry values and limit to reasonable size dump.
Signed-off-by: Ben Cahill <ben.m.cahill@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove the support for all the PCI_IDs never make into production
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Different channel has different configuration, need to pass correct
configuration to uCode when send "channel switch" command to uCode.
Invalid configuration will cause sysassert in uCode and produce
un-expected result.
Even it is a very small windows, but we also need to consider and handle
the case if commit_rxon occurred before the "channel switch
announcement" notification received from uCode.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
To help debug rx related issues, if IWL_DEBUG_RADIO flag is set, print
the rxon configuration when rxon host command send to uCode.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When 802.11g was introduced, we had RTS/CTS and CTS-to-Self protection
mechanisms. In an HT Beacon, HT stations use the "Operating Mode" field
in the HT Information Element to determine whether or not to use
protection.
The Operating Mode field has 4 possible settings: 0-3:
Mode 0: If all stations in the BSS are 20/40 MHz HT capable, or if the
BSS is 20/40 MHz capable, or if all stations in the BSS are 20 MHz HT
stations in a 20 MHz BSS
Mode 1: used if there are non-HT stations or APs using the primary or
secondary channels
Mode 2: if only HT stations are associated in the BSS and at least one
20 MHz HT station is associated.
Mode 3: used if one or more non-HT stations are associated in the BSS.
When in operating modes 1 or 3, and the Use_Protection field is 1 in the
Beacon's ERP IE, all HT transmissions must be protected using RTS/CTS or
CTS-to-Self.
By default, CTS-to-self is the preferred protection mechanism for less
overhead and higher throughput; but using the full RTS/CTS will better
protect the inner exchange from interference, especially in
highly-congested environment.
For 6000 series WIFI NIC, RTS/CTS protection mechanism is the
recommended choice for HT traffic based on the HW design.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
