linux.git/drivers/staging/wfx/queue.c, branch v5.10.258

staging: wfx: update copyrights dates

2020-10-07T10:55:47+00:00

Most of the files have been modified in 2020, so update the copyright
notices.

Signed-off-by: Jérôme Pouiller 
Link: https://lore.kernel.org/r/20201007101943.749898-6-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman

staging: wfx: fix QoS priority for slow buses

2020-10-07T10:55:47+00:00

The device is in charge of respecting the QoS constraints. The driver
have to ensure that all the queues contain data and the device choose
the right queue to send.

The things starts to be more difficult when the bandwidth of the bus is
lower than the bandwidth of the WiFi. The device quickly sends the
frames of the highest priority queue. Then, it starts to send frames
from a lower priority queue. Though, there are still some high priority
frames waiting in the driver.

To work around this problem, this patch add some priorities to each
queue. The weigh of the queue was (roughly) calculated experimentally by
checking the speed ratio of each queue when the bus does not limit the
traffic:
    - Be/Bk -> 20Mbps/10Mbps
    - Vi/Be -> 36Mbps/180Kbps
    - Vo/Be -> 35Mbps/600Kbps
    - Vi/Vo -> 24Mbps/12Mbps

So, if we fix the weigh of the Background to 1, the weight of Best
Effort should be 2. The weight of Video should be 116. However, since
there is only 32 queues, it make no sense to use a value greater than
64[1]. And finally, the weight of the Voice is set to 128.

[1] Because of this approximation, with very slow bus, we can still
observe frame starvation when we measure the speed ratio of Vi/Be. It is
around 35Mbps/1Mbps (instead of 36Mbps/180Kbps). However, it is still in
accepted error range.

Signed-off-by: Jérôme Pouiller 
Link: https://lore.kernel.org/r/20201007101943.749898-5-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman

staging: wfx: add tracepoint "queues_stats"

2020-07-03T08:33:07+00:00

It is useful to check which queue the driver choose to send to the
hardware.

Signed-off-by: Jérôme Pouiller 
Link: https://lore.kernel.org/r/20200701150707.222985-5-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman

staging: wfx: correctly retrieve vif ID from Tx confirmation

2020-07-03T08:33:07+00:00

The device is able to send multiple Tx confirmations in the one reply.
In this case, there is only one vif identifier for all the
confirmations.

Unfortunately, to generate this kind of messages the device squashes all
the confirmations whatever their vif ID and use the vif ID of the first
confirmation. So, the driver cannot rely on the vif ID mentioned in the
header. Fortunately, using the packet_id, the driver can retrieve the Tx
request and the associated vif.

Signed-off-by: Jérôme Pouiller 
Link: https://lore.kernel.org/r/20200701150707.222985-4-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman

staging: wfx: check the vif ID of the Tx confirmations

2020-07-03T08:33:06+00:00

When the driver has sent a frame on a virtual interface (vif), it
expects to receive the confirmation on the same vif.

This patch add a check for that.

Signed-off-by: Jérôme Pouiller 
Link: https://lore.kernel.org/r/20200701150707.222985-3-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman

staging: wfx: associate tx_queues to vifs

2020-07-03T08:33:06+00:00

The device handles 4 queues (one per AC) for each virtual interface (and
maximum 4 virtual interfaces). Until now the driver unified the queue of
all interfaces and handled only 4 queues for whole device.

This architecture did not allow to balance the traffic between the vif. So,
this patch relocate the queues into the vif and change the API accordingly.

Signed-off-by: Jérôme Pouiller 
Link: https://lore.kernel.org/r/20200701150707.222985-2-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman

staging: wfx: drop useless loop

2020-06-16T19:22:51+00:00

It is guarantee that the loop will stop at first iteration. So drop the
loop.

Fixes: 6bf418c50f98a ("staging: wfx: change the way to choose frame to send")
Signed-off-by: Jérôme Pouiller 
Link: https://lore.kernel.org/r/20200529121603.1050891-2-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman

staging: wfx: fix AC priority

2020-06-16T19:22:50+00:00

In order to work properly all the queues of the device must be filled (the
device chooses itself the queue to use depending of AC parameters and
other things). It is the job of wfx_tx_queues_get_skb() to choose which
queue must be filled. However, the sorting algorithm was inverted, so it
prioritized the already filled queue! Consequently, the AC priorities was
badly broken.

Fixes: 6bf418c50f98a ("staging: wfx: change the way to choose frame to send")
Signed-off-by: Jérôme Pouiller 
Link: https://lore.kernel.org/r/20200529121603.1050891-1-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman

staging: wfx: drop unused function wfx_pending_requeue()

2020-05-27T08:18:08+00:00

The function wfx_pending_requeue() is not used anymore since the
commit 7a44644c9379e ("staging: wfx: introduce
wfx_set_default_unicast_key()")

Fixes: 7a44644c9379e ("staging: wfx: introduce wfx_set_default_unicast_key()")
Signed-off-by: Jérôme Pouiller 
Link: https://lore.kernel.org/r/20200526171821.934581-4-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman

staging: wfx: remove false-positive WARN()

2020-05-15T14:00:54+00:00

The function wfx_tx_flush() wait for there is no more queued frames in
hardware queue. Then, for the sanity, it checks that there is no more
pending frame on any AC queue.

However, there is a race here. It may happens that hardware queues are
empty, but the counters of the AC queues are not yet updated. So, it may
produce false-positive warning.

The easiest way to solve the problem is just to remove the sanity check.

Signed-off-by: Jérôme Pouiller 
Link: https://lore.kernel.org/r/20200515083325.378539-18-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman