| Age | Commit message (Collapse) | Author |
|---|
|
wfx_tx_get_tid() was used as a wrapper around ieee80211_get_tid(). It
did sometime return WFX_MAX_TID to ask to upper layers to not include
the frame in "buffered" counter. The objective of this behavior is not
clear, but tests has shown that wfx_tx_get_tid() can be replaced by
ieee80211_get_tid() without any regressions.
BTW, it is not necessary to save the tid in tx_rpiv since it can be
retrieved from the 802.11 header.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200115135338.14374-53-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The "link-id" is a slot number provided to the chip. A link-id is
allocated to every station associated with the chip (mainly when the
chip is in AP mode). It is more or less the same thing than the
association ID, but it is limited to 14 values.
Firmware uses the link-id to track the power save status of the
stations.
The current code try to associate a link-id as soon as data are
exchanged with station. It is far easier to rely on sta_add() and
sta_remove().
Until now the value WFX_LINK_ID_NO_ASSOC, was only used when no more
link-id was available. Now, we also use this value for
not-yet-associated stations (that was its primary behavior).
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200115135338.14374-51-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
It simplify the code if field buffered is hosted in the struct sta_priv
instead of in the struct wfx_link_entry. More globally, struct
wfx_link_entry has no real reasons to exist and should be dropped soon.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200115135338.14374-47-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
It seems that purpose of "early_data" was to prevent sending data to
mac80211 before station was completely associated. It is a useless
precaution.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200115135338.14374-46-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
There are no real reason to modify the data received from device. So,
let's mark the arguments constant.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20191217161318.31402-23-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The field 'uploaded' is used as a boolean, so call it a boolean.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20191217161318.31402-5-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Some weird behaviors were observed when connection is really good and
packets are small. It appears that sometime, number of packets in queues
can exceed 255 and generate an overflow in field usage_count.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20191217161318.31402-4-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Device and driver maintain a cache of rate policies (aka.
tx_retry_policy in hardware API).
When hif_reset() is sent to hardware, device resets its cache of rate
policies. In order to keep driver in sync, it is necessary to do the
same on driver.
Note, when driver tries to use a rate policy that has not been defined
on device, data is sent at 1Mbps. So, this patch should fix abnormal
throughput observed sometime after a reset of the interface.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20191217161318.31402-2-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Replace uint8_t to u8, uint16_t to u16, uint32_t to u32
int8_t to s8,int16_t to s16 and int32_t to s32
As per recommendation of checkpatch tool.
Signed-off-by: Jules Irenge <jbi.octave@gmail.com>
Link: https://lore.kernel.org/r/20191111133055.214410-1-jbi.octave@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Fix warnings of no space is necessary after a cast.
Issue detected by checkpatch tool.
Signed-off-by: Jules Irenge <jbi.octave@gmail.com>
Link: https://lore.kernel.org/r/20191019140719.2542-2-jbi.octave@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
tx_policy_init() was already defined in driver cw1200. So, compilation
failed when wfx and cw1200 were both built-in.
In order to keep a coherent naming scheme, this patch prefixes all
"tx_policy_*" functions with "wfx_".
Fixes: 9bca45f3d692 ("staging: wfx: allow to send 802.11 frames")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20191008094232.10014-8-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Three things make this task more complex than it should:
- Chip necessitate to associate a link-id to each station. It is same
thing than association ID but, using 8 bits only.
- Rate policy is sent separately from Tx frames
- Driver try to handle itself power saving of stations and multicast
data
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20190919142527.31797-17-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
