kernel/linux.git/net/mac802154/util.c, branch v6.12.80

net: mac802154: Fixup function parameter name in docs

2022-10-26T07:40:34+00:00

The function parameter name was wrong in kdocs. net/mac802154/util.c:27: warning: Function parameter or member 'hw' not described in 'ieee802154_wake_queue' net/mac802154/util.c:27: warning: Excess function parameter 'local' description in 'ieee802154_wake_queue' net/mac802154/util.c:53: warning: Function parameter or member 'hw' not described in 'ieee802154_stop_queue' net/mac802154/util.c:53: warning: Excess function parameter 'local' description in 'ieee802154_stop_queue' Fixing name and description. Signed-off-by: Stefan Schmidt

mac802154: fix atomic_dec_and_test checks

2022-06-14T08:23:51+00:00

We need to call wake_up() when hold_txs reaches zero. The semantic of atomic_dec_and_test() is that it returns true when it's zero. Fixes: f0feb3490473 ("net: mac802154: Introduce a tx queue flushing mechanism") Signed-off-by: Alexander Aring Reviewed-by: Miquel Raynal Link: https://lore.kernel.org/r/20220613043735.1039895-3-aahringo@redhat.com Signed-off-by: Stefan Schmidt

mac802154: util: fix release queue handling

2022-06-14T08:23:00+00:00

The semantic of atomic_dec_and_test() is to return true if zero is reached and we need call ieee802154_wake_queue() when zero is reached. Fixes: 20a19d1df3e4 ("net: mac802154: Bring the ability to hold the transmit queue") Signed-off-by: Alexander Aring Reviewed-by: Miquel Raynal Link: https://lore.kernel.org/r/20220613043735.1039895-2-aahringo@redhat.com Signed-off-by: Stefan Schmidt

net: mac802154: Add a warning in the hot path

2022-06-10T07:48:41+00:00

We should never start a transmission after the queue has been stopped. But because it might work we don't kill the function here but rather warn loudly the user that something is wrong. Set a flag when the queue should remain stopped. Reset this flag when the queue actually gets restarded. Just check this value to know if a transmission is legitimate, warn if it is not. Turn the flags variable into an unsigned long to allow the use of atomic helpers on it. Signed-off-by: Miquel Raynal Acked-by: Alexander Aring Link: https://lore.kernel.org/r/20220519150516.443078-11-miquel.raynal@bootlin.com Signed-off-by: Stefan Schmidt

net: mac802154: Introduce a tx queue flushing mechanism

2022-06-10T07:48:40+00:00

Right now we are able to stop a queue but we have no indication if a transmission is ongoing or not. Thanks to recent additions, we can track the number of ongoing transmissions so we know if the last transmission is over. Adding on top of it an internal wait queue also allows to be woken up asynchronously when this happens. If, beforehands, we marked the queue to be held and stopped it, we end up flushing and stopping the tx queue. Thanks to this feature, we will soon be able to introduce a synchronous transmit API. Signed-off-by: Miquel Raynal Acked-by: Alexander Aring Link: https://lore.kernel.org/r/20220519150516.443078-9-miquel.raynal@bootlin.com Signed-off-by: Stefan Schmidt

net: mac802154: Introduce a helper to disable the queue

2022-06-10T07:48:40+00:00

Sometimes calling the stop queue helper is not enough because it does not hold any lock. In order to be safe and avoid racy situations when trying to (soon) sync the Tx queue, for instance before sending an MLME frame, let's now introduce an helper which actually hold the necessary locks when doing so. Suggested-by: Alexander Aring Signed-off-by: Miquel Raynal Acked-by: Alexander Aring Link: https://lore.kernel.org/r/20220519150516.443078-8-miquel.raynal@bootlin.com Signed-off-by: Stefan Schmidt

net: mac802154: Bring the ability to hold the transmit queue

2022-06-10T07:48:40+00:00

Create a hold_txs atomic variable and increment/decrement it when relevant, ie. when we want to hold the queue or release it: currently all the "stopped" situations are suitable, but very soon we will more extensively use this feature for MLME purposes. Upon release, the atomic counter is decremented and checked. If it is back to 0, then the netif queue gets woken up. This makes the whole process fully transparent, provided that all the users of ieee802154_wake/stop_queue() now call ieee802154_hold/release_queue() instead. In no situation individual drivers should call any of these helpers manually in order to avoid messing with the counters. There are other functions more suited for this purpose which have been introduced, such as the _xmit_complete() and _xmit_error() helpers which will handle all that for them. One advantage is that, as no more drivers call the stop/wake helpers directly, we can safely stop exporting them and only declare the hold/release ones in a header only accessible to the core. Signed-off-by: Miquel Raynal Acked-by: Alexander Aring Link: https://lore.kernel.org/r/20220519150516.443078-6-miquel.raynal@bootlin.com Signed-off-by: Stefan Schmidt

net: mac802154: Follow the count of ongoing transmissions

2022-06-10T07:48:40+00:00

In order to create a synchronous API for MLME command purposes, we need to be able to track the end of the ongoing transmissions. Let's introduce an atomic variable which is incremented when a transmission starts and decremented when relevant so that we know at any moment whether there is an ongoing transmission. The counter gets decremented in the following situations: - The operation is asynchronous and there was a failure during the offloading process. - The operation is synchronous and the synchronous operation failed. - The operation finished, either successfully or not. Signed-off-by: Miquel Raynal Acked-by: Alexander Aring Link: https://lore.kernel.org/r/20220519150516.443078-5-miquel.raynal@bootlin.com Signed-off-by: Stefan Schmidt

net: mac802154: Create an error helper for asynchronous offloading errors

2022-04-25T18:51:12+00:00

A few drivers do the full transmit operation asynchronously, which means that a bus error that happens when forwarding the packet to the transmitter or a timeout happening when offloading the request to the transmitter will not be reported immediately. The solution in this case is to call this new helper to free the necessary resources, restart the queue and always return the same generic TRAC error code: IEEE802154_SYSTEM_ERROR. Suggested-by: Alexander Aring Signed-off-by: Miquel Raynal Acked-by: Alexander Aring Link: https://lore.kernel.org/r/20220407100903.1695973-6-miquel.raynal@bootlin.com Signed-off-by: Stefan Schmidt

net: mac802154: Create an offloaded transmission error helper

2022-04-25T18:51:12+00:00

So far there is only a helper for successful transmissions, which led device drivers to implement their own handling in case of error. Unfortunately, we really need all the drivers to give the hand back to the core once they are done in order to be able to build a proper synchronous API. So let's create a _xmit_error() helper and take this opportunity to fill the new device-global field storing Tx statuses. Suggested-by: Alexander Aring Signed-off-by: Miquel Raynal Acked-by: Alexander Aring Link: https://lore.kernel.org/r/20220407100903.1695973-5-miquel.raynal@bootlin.com Signed-off-by: Stefan Schmidt