uapsd_queues and uapsd_max_sp_len are relevant only for managed
interfaces, and can be configured differently for each vif.
Move them from the local struct to sdata->u.mgd, and update
the debugfs functions accordingly.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some debugfs write functions call kstrto* functions, which
assume the string is null-terminated. Make it valid by changing
ieee80211_if_write() to use static buffer instead of allocating
one, and set the last char to NULL.
(The write functions try to parse some integer/mac address,
so 64 bytes buffer should be enough)
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The current max throughput rate is known to be good as otherwise it
wouldn't be the max throughput rate. Since rate sampling can introduce
some overhead (by adding RTS for example or due to not aggregating the
frame) don't sample the max throughput rate.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
TX status fifo is limited to 16 elements. When we send more frames than
that, we can easily loose status, what is not good for rate scaling
algorithm.
On my testing the change does not degrade performance, actually make
is slightly better. Additionally with the patch I can see much less
various rt2x00 warnings in dmesg.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Tx statuses of aggregated subframes contain packetid of first subframe
in the AMPDU. We can not identify AMPDU subframes based on packedid, so
simply assume that status match first pending frame in the queue. Thats
mostly the same what 2800pci do.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently we read tx status register after each urb data transfer. As
callback procedure also trigger reading, that causing we have many
"threads" of reading status. To prevent that introduce TX_STATUS_READING
flags, and check if we are already in process of sequential reading
TX_STA_FIFO, before requesting new reads.
Change timer to hrtimer, that make TX_STA_FIFO overruns less possible.
Use 200 us for initial timeout, and then reschedule in 100 us period,
this values probably have to be tuned.
Make changes on txdone work. Schedule it from
rt2800usb_tx_sta_fifo_read_completed() callback when first valid status
show up. Check in callback if tx status timeout happens, and schedule
work on that condition too. That make possible to remove tx status
timeout from generic watchdog. I moved that to rt2800usb.
Loop in txdone work, that should prevent situation when we queue work,
which is already processed, and after finish work is not rescheduled
again.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Patch change txdone code to make it similar like txdone in rt2800pci,
process only one entry from queue matching tx status.
Before we processed all pending entries from queue until PACKEDID match,
that caused that we do not report tx statuses correctly.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 provides short preamble information and ERP protection
information on a per-BSS basis, which can be used. Remove flags
stored in the driver, which was incorrect since they were being used
in a global manner.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
SC_OP_TXAGGR and SC_OP_RXAGGR are not really needed.
The HT capabilities of the station and HW can be used instead.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The logic to determine whether to use FCC is a bit convoluted.
Use a small helper function to decide whether FCC is to be
used.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It is not needed and will not be used anyway since
unsupported interfaces are not allowed to be created.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There is no need to mask out SWBA/BMISS from the
interrupt mask in start().
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2800 already reports the tx ack status of each frame back to mac80211.
Advertise this by setting IEEE80211_HW_REPORTS_TX_ACK_STATUS for rt2800.
This allows some mac80211 features like frame loss notifications to work
with rt2800.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
"hscfg" is declared as struct mwifiex_ds_hs_cfg. Use same structure
name for calculating it's size.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
For files sta_event.c and sta_ioctl.c
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>
For sta_cmd.c and sta_cmdresp.c
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>
For files main.c, main.h and pcie.c
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>
For files fw.h, init.c and join.c
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>
For files cfg80211.c, cfp.c, and cmdevt.c
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>
When regulatory information changes our HT behavior (e.g,
when we get a country code from the AP we have just associated
with), we should use this information to change the power with
which we transmit, and what channels we transmit. Sometimes
the channel parameters we derive from regulatory information
contradicts the parameters we used in association. For example,
we could have associated specifying HT40, but the regulatory
rules we apply may forbid HT40 operation.
In the situation above, we should reconfigure ourselves to
transmit in HT20 only, however it makes no sense for us to
disable receive in HT40, since if we associated with these
parameters, the AP has every reason to expect we can and
will receive packets this way. The code in mac80211 does
not have the capability of sending the appropriate action
frames to signal a change in HT behaviour so the AP has
no clue we can no longer receive frames encoded this way.
In some broken AP implementations, this can leave us
effectively deaf if the AP never retries in lower HT rates.
This change breaks up the channel_type parameter in the
ieee80211_enable_ht function into a separate receive and
transmit part. It honors the channel flags set by regulatory
in order to configure the rate control algorithm, but uses
the capability flags to configure the channel on the radio,
since these were used in association to set the AP's transmit
rate.
Signed-off-by: Paul Stewart <pstew@chromium.org>
Cc: Sam Leffler <sleffler@chromium.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Reviewed-by: Luis R Rodriguez <mcgrof@frijolero.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This value is not really very useful by itself,
yet some drivers (including iwlwifi until I can
figure out what it should do) use it. At least
rename it to "last_tsf" to indicate the meaning
and add a note that it may be really old.
I suspect the value may become useful combined
with the rx_status->mactime, but we don't (yet)
store that value and pass it to the driver.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is intended to be the timestamp sent by the
peer in the beacon/probe response, not any form
of host timestamp. Clarify the documentation and
variable names.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The cfg80211_inform_bss() timestamp argument is
intended to be the TSF, not any form of host
timestamp.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Renaming the long fuctions and variable names from 11n_rxreoder.c
file to shorter ones for better readability.
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>
For the delay of 10 uSec or more usleep_range is prefered.
Unlike udelay, sleep_range avoids large number of undesired
interrupts.
Ref Documentation/timers/timers-howto.txt
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>
There exist different functions with very long names
to derive the channel frequency and power tripplet
based on band and channel/freq.
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>
This saves some space and adds better readability.
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>
Not linearizing every SKB will help actually pass
non-linear SKBs all the way up when on an encrypted
connection. For now, linearize TKIP completely as
it is lower performance and I don't quite grok all
the details.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is better done inside the WEP decrypt
function where it doesn't have to check all
the conditions any more since they've been
tested already.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Recent changes in udev are causing problems for drivers that load firmware
from the probe routine. As b43 has such a structure, it must be changed.
As this driver loads more than 1 firmware file, changing to the asynchronous routine
request_firmware_nowait() would be complicated. In this implementation, the probe
routine starts a queue that calls the firmware loading routines.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Recent changes in udev are causing problems for drivers that load firmware
from the probe routine. As b43legacy has such a structure, it must be changed.
As this driver loads 3 or 4 firmware files, changing to the asynchronous routine
request_firmware_nowait() would be complicated. In this implementation, the probe
routine starts a work queue that calls the firmware loading routines.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commit 7504a3e1 ("ath6kl: add padding to firmware log records") accidentally
changed debug.c mode from 100644 to 100755. Revert that back to original.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath6kl/cfg80211.c:589: WARNING: max() should probably be
max_t(u16, vif->listen_intvl_t, ATH6KL_MAX_WOW_LISTEN_INTL)
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
My patch 24fc32b3 ("ath6kl: add ath6kl_bmi_write_hi32()") caused a regression
in ath6kl_upload_board_file() and the board_address variable was not
properly initialised in some cases:
ath6kl/init.c:1068:6: warning: ‘board_address’ may be used uninitialized
in this function
Most likely this broke ar6004 support but I can't test that right now.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The authentication and association handshake
already happens in the context of the new BSS,
and the basic rates are needed at least for
the ACK response frame to the authentication
or association response frames. Therefore the
basic rates should already be configured into
the driver when those frames are sent.
Change the logic to set up the basic rates in
the connection preparation that happens for
authentication and association (if needed).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As associating is possible without first authenticating
(for FT over DS) association also has to be able to
switch to the right channel, insert the station entry
etc. Factor out this common code into a new function
called ieee80211_prep_connection().
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The BSSID has been set a lot earlier already and
didn't change again in ieee80211_set_associated().
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Felix Fietkau
Eliad Peller
Helmut Schaa
Stanislaw Gruszka
Sujith Manoharan
Amitkumar Karwar
Yogesh Ashok Powar
Paul Stewart
Johannes Berg
Yegor Yefremov
Larry Finger
John W. Linville
Kalle Valo