[PATCH v5 00/11] ieee802154: Better Tx error handling

[PATCH v5 00/11] ieee802154: Better Tx error handling

[Miquel Raynal]

The idea here is to provide a fully synchronous Tx API and also be able
to be sure that a transfer has finished. This will be used later by
another series. However, while working on this task, it appeared
necessary to first rework the way MLME errors were (not) propagated to
the upper layers. This small series tries to tackle exactly that, before
introducing the synchronous API.

Changes in v5:
* Introduced a new helper which should be used upon bus errors. We don't
  ask users to provide an error code (which would be misleading) and
  instead forward IEEE802154_SYSTEM_ERROR which is our generic code.
* Dropped most of my changes in the at86rf320 driver in ordre to do
  things a little bit differently:
  - the existing error path is renamed to clearly identify that it
    handles bus errors.
  - trac errors are handled in a separate path and the core helper is
    used to return the trac value.
* Merged the revert commit with the following commit forwarding trac
  errors to the core.

Changes in v4:
* Reverted the at86rf320 patch introducing trac values for debugfs
  purposes as suggested by Alex. Reintroduced some of its content in a
  subsequent patch to filter out offloaded transmission error cases.
* Used IEEE802154_SYSTEM_ERROR as a non specific error code.

Changes in v3:
* Split the series into two parts, this is the "error handling" halve.
* Reworked the error path to not handle the ifs_handling situation
  anymore.
* Enhanced the list of MLME status codes available.
* Improved the error handling by collecting the error codes, somethimes
  by changing device drivers directly to propagate these MLME
  statuses. Then, once in the core, save one global Tx status value so
  that in the case of synchronous transfers we can check the return
  value and eventually error out.
* Prevented the core to stop the device before the end of the last
  transmission to avoid deadlocks by just sync'ing the last Tx
  transfer.

Changes in v2:
* Adapted with the changes already merged/refused.

Miquel Raynal (11):
  net: ieee802154: Enhance/fix the names of the MLME return codes
  net: ieee802154: Fill the list of MLME return codes
  net: mac802154: Save a global error code on transmissions
  net: mac802154: Create a transmit error helper
  net: mac802154: Create a transmit bus error helper
  net: ieee802154: at86rf230: Rename the asynchronous error helper
  net: ieee802154: at86rf230: Call _xmit_bus_error() when a bus error
    occurs
  net: ieee802154: at86rf230: Drop debugfs support
  net: ieee802154: atusb: Call _xmit_error() when a transmission fails
  net: ieee802154: ca8210: Use core return codes instead of hardcoding
    them
  net: ieee802154: ca8210: Call _xmit_error() when a transmission fails

 drivers/net/ieee802154/Kconfig     |   7 --
 drivers/net/ieee802154/at86rf230.c | 154 ++++++------------------
 drivers/net/ieee802154/atusb.c     |   5 +-
 drivers/net/ieee802154/ca8210.c    | 182 +++++++++++------------------
 include/linux/ieee802154.h         |  81 +++++++++++--
 include/net/mac802154.h            |  19 +++
 net/mac802154/ieee802154_i.h       |   2 +
 net/mac802154/util.c               |  26 ++++-
 8 files changed, 225 insertions(+), 251 deletions(-)

-- 
2.27.0

[PATCH v5 01/11] net: ieee802154: Enhance/fix the names of the MLME return codes

[Miquel Raynal]

Let's keep these definitions as close to the specification as possible
while they are not yet in use. The names get slightly longer, but we
gain the minor cost of being able to search the spec more easily.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 include/linux/ieee802154.h | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/linux/ieee802154.h b/include/linux/ieee802154.h
index 95c831162212..01d945c8b2e1 100644
--- a/include/linux/ieee802154.h
+++ b/include/linux/ieee802154.h
@@ -136,16 +136,16 @@ enum {
 	IEEE802154_SUCCESS = 0x0,
 
 	/* The beacon was lost following a synchronization request. */
-	IEEE802154_BEACON_LOSS = 0xe0,
+	IEEE802154_BEACON_LOST = 0xe0,
 	/*
 	 * A transmission could not take place due to activity on the
 	 * channel, i.e., the CSMA-CA mechanism has failed.
 	 */
-	IEEE802154_CHNL_ACCESS_FAIL = 0xe1,
+	IEEE802154_CHANNEL_ACCESS_FAILURE = 0xe1,
 	/* The GTS request has been denied by the PAN coordinator. */
-	IEEE802154_DENINED = 0xe2,
+	IEEE802154_DENIED = 0xe2,
 	/* The attempt to disable the transceiver has failed. */
-	IEEE802154_DISABLE_TRX_FAIL = 0xe3,
+	IEEE802154_DISABLE_TRX_FAILURE = 0xe3,
 	/*
 	 * The received frame induces a failed security check according to
 	 * the security suite.
@@ -185,9 +185,9 @@ enum {
 	 * A PAN identifier conflict has been detected and communicated to the
 	 * PAN coordinator.
 	 */
-	IEEE802154_PANID_CONFLICT = 0xee,
+	IEEE802154_PAN_ID_CONFLICT = 0xee,
 	/* A coordinator realignment command has been received. */
-	IEEE802154_REALIGMENT = 0xef,
+	IEEE802154_REALIGNMENT = 0xef,
 	/* The transaction has expired and its information discarded. */
 	IEEE802154_TRANSACTION_EXPIRED = 0xf0,
 	/* There is no capacity to store the transaction. */
@@ -203,7 +203,7 @@ enum {
 	 * A SET/GET request was issued with the identifier of a PIB attribute
 	 * that is not supported.
 	 */
-	IEEE802154_UNSUPPORTED_ATTR = 0xf4,
+	IEEE802154_UNSUPPORTED_ATTRIBUTE = 0xf4,
 	/*
 	 * A request to perform a scan operation failed because the MLME was
 	 * in the process of performing a previously initiated scan operation.
-- 
2.27.0

[PATCH v5 02/11] net: ieee802154: Fill the list of MLME return codes

[Miquel Raynal]

There are more codes than already listed, let's be a bit more
exhaustive. This will allow to drop device drivers local definitions of
these codes.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 include/linux/ieee802154.h | 67 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 66 insertions(+), 1 deletion(-)

diff --git a/include/linux/ieee802154.h b/include/linux/ieee802154.h
index 01d945c8b2e1..f1f9412b6ac6 100644
--- a/include/linux/ieee802154.h
+++ b/include/linux/ieee802154.h
@@ -134,7 +134,35 @@ enum {
 	 * a successful transmission.
 	 */
 	IEEE802154_SUCCESS = 0x0,
-
+	/* The requested operation failed. */
+	IEEE802154_MAC_ERROR = 0x1,
+	/* The requested operation has been cancelled. */
+	IEEE802154_CANCELLED = 0x2,
+	/*
+	 * Device is ready to poll the coordinator for data in a non beacon
+	 * enabled PAN.
+	 */
+	IEEE802154_READY_FOR_POLL = 0x3,
+	/* Wrong frame counter. */
+	IEEE802154_COUNTER_ERROR = 0xdb,
+	/*
+	 * The frame does not conforms to the incoming key usage policy checking
+	 * procedure.
+	 */
+	IEEE802154_IMPROPER_KEY_TYPE = 0xdc,
+	/*
+	 * The frame does not conforms to the incoming security level usage
+	 * policy checking procedure.
+	 */
+	IEEE802154_IMPROPER_SECURITY_LEVEL = 0xdd,
+	/* Secured frame received with an empty Frame Version field. */
+	IEEE802154_UNSUPPORTED_LEGACY = 0xde,
+	/*
+	 * A secured frame is received or must be sent but security is not
+	 * enabled in the device. Or, the Auxiliary Security Header has security
+	 * level of zero in it.
+	 */
+	IEEE802154_UNSUPPORTED_SECURITY = 0xdf,
 	/* The beacon was lost following a synchronization request. */
 	IEEE802154_BEACON_LOST = 0xe0,
 	/*
@@ -204,11 +232,48 @@ enum {
 	 * that is not supported.
 	 */
 	IEEE802154_UNSUPPORTED_ATTRIBUTE = 0xf4,
+	/* Missing source or destination address or address mode. */
+	IEEE802154_INVALID_ADDRESS = 0xf5,
+	/*
+	 * MLME asked to turn the receiver on, but the on time duration is too
+	 * big compared to the macBeaconOrder.
+	 */
+	IEEE802154_ON_TIME_TOO_LONG = 0xf6,
+	/*
+	 * MLME asaked to turn the receiver on, but the request was delayed for
+	 * too long before getting processed.
+	 */
+	IEEE802154_PAST_TIME = 0xf7,
+	/*
+	 * The StartTime parameter is nonzero, and the MLME is not currently
+	 * tracking the beacon of the coordinator through which it is
+	 * associated.
+	 */
+	IEEE802154_TRACKING_OFF = 0xf8,
+	/*
+	 * The index inside the hierarchical values in PIBAttribute is out of
+	 * range.
+	 */
+	IEEE802154_INVALID_INDEX = 0xf9,
+	/*
+	 * The number of PAN descriptors discovered during a scan has been
+	 * reached.
+	 */
+	IEEE802154_LIMIT_REACHED = 0xfa,
+	/*
+	 * The PIBAttribute parameter specifies an attribute that is a read-only
+	 * attribute.
+	 */
+	IEEE802154_READ_ONLY = 0xfb,
 	/*
 	 * A request to perform a scan operation failed because the MLME was
 	 * in the process of performing a previously initiated scan operation.
 	 */
 	IEEE802154_SCAN_IN_PROGRESS = 0xfc,
+	/* The outgoing superframe overlaps the incoming superframe. */
+	IEEE802154_SUPERFRAME_OVERLAP = 0xfd,
+	/* Any other error situation. */
+	IEEE802154_SYSTEM_ERROR = 0xff,
 };
 
 /* frame control handling */
-- 
2.27.0

[PATCH v5 03/11] net: mac802154: Save a global error code on transmissions

[Miquel Raynal]

So far no error is returned from a failing transmission. However it
might sometimes be useful, and particularly easy to use during sync
transfers (for certain MLME commands). Let's create an internal variable
for that, global to the device. Right now only success are registered,
which is rather useless, but soon we will have more situations filling
this field.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 net/mac802154/ieee802154_i.h | 2 ++
 net/mac802154/util.c         | 5 ++++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/net/mac802154/ieee802154_i.h b/net/mac802154/ieee802154_i.h
index 702560acc8ce..1381e6a5e180 100644
--- a/net/mac802154/ieee802154_i.h
+++ b/net/mac802154/ieee802154_i.h
@@ -56,6 +56,8 @@ struct ieee802154_local {
 
 	struct sk_buff *tx_skb;
 	struct work_struct tx_work;
+	/* A negative Linux error code or a null/positive MLME error status */
+	int tx_result;
 };
 
 enum {
diff --git a/net/mac802154/util.c b/net/mac802154/util.c
index f2078238718b..0bf46f174de3 100644
--- a/net/mac802154/util.c
+++ b/net/mac802154/util.c
@@ -58,8 +58,11 @@ enum hrtimer_restart ieee802154_xmit_ifs_timer(struct hrtimer *timer)
 void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff *skb,
 			      bool ifs_handling)
 {
+	struct ieee802154_local *local = hw_to_local(hw);
+
+	local->tx_result = IEEE802154_SUCCESS;
+
 	if (ifs_handling) {
-		struct ieee802154_local *local = hw_to_local(hw);
 		u8 max_sifs_size;
 
 		/* If transceiver sets CRC on his own we need to use lifs
-- 
2.27.0

[PATCH v5 04/11] net: mac802154: Create a transmit error helper

[Miquel Raynal]

So far there is only a helper for successful transmission, 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 <alex.aring@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 include/net/mac802154.h | 10 ++++++++++
 net/mac802154/util.c    | 11 +++++++++++
 2 files changed, 21 insertions(+)

diff --git a/include/net/mac802154.h b/include/net/mac802154.h
index 2c3bbc6645ba..abbe88dc9df5 100644
--- a/include/net/mac802154.h
+++ b/include/net/mac802154.h
@@ -498,4 +498,14 @@ void ieee802154_stop_queue(struct ieee802154_hw *hw);
 void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff *skb,
 			      bool ifs_handling);
 
+/**
+ * ieee802154_xmit_error - frame transmission failed
+ *
+ * @hw: pointer as obtained from ieee802154_alloc_hw().
+ * @skb: buffer for transmission
+ * @reason: error code
+ */
+void ieee802154_xmit_error(struct ieee802154_hw *hw, struct sk_buff *skb,
+			   int reason);
+
 #endif /* NET_MAC802154_H */
diff --git a/net/mac802154/util.c b/net/mac802154/util.c
index 0bf46f174de3..ec523335336c 100644
--- a/net/mac802154/util.c
+++ b/net/mac802154/util.c
@@ -91,6 +91,17 @@ void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff *skb,
 }
 EXPORT_SYMBOL(ieee802154_xmit_complete);
 
+void ieee802154_xmit_error(struct ieee802154_hw *hw, struct sk_buff *skb,
+			   int reason)
+{
+	struct ieee802154_local *local = hw_to_local(hw);
+
+	local->tx_result = reason;
+	ieee802154_wake_queue(hw);
+	dev_kfree_skb_any(skb);
+}
+EXPORT_SYMBOL(ieee802154_xmit_error);
+
 void ieee802154_stop_device(struct ieee802154_local *local)
 {
 	flush_workqueue(local->workqueue);
-- 
2.27.0

[PATCH v5 05/11] net: mac802154: Create a transmit bus error helper

[Miquel Raynal]

A few drivers do the full transmit operation asynchronously, which means
that a bus error that happens when forwarding the packet 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
the queue and return a generic TRAC error code: IEEE802154_SYSTEM_ERROR.

Suggested-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 include/net/mac802154.h |  9 +++++++++
 net/mac802154/util.c    | 10 ++++++++++
 2 files changed, 19 insertions(+)

diff --git a/include/net/mac802154.h b/include/net/mac802154.h
index abbe88dc9df5..5240d94aad8e 100644
--- a/include/net/mac802154.h
+++ b/include/net/mac802154.h
@@ -498,6 +498,15 @@ void ieee802154_stop_queue(struct ieee802154_hw *hw);
 void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff *skb,
 			      bool ifs_handling);
 
+/**
+ * ieee802154_xmit_bus_error - frame could not be delivered to the trasmitter
+ *                             because of a bus error
+ *
+ * @hw: pointer as obtained from ieee802154_alloc_hw().
+ * @skb: buffer for transmission
+ */
+void ieee802154_xmit_bus_error(struct ieee802154_hw *hw, struct sk_buff *skb);
+
 /**
  * ieee802154_xmit_error - frame transmission failed
  *
diff --git a/net/mac802154/util.c b/net/mac802154/util.c
index ec523335336c..79ba803c40c9 100644
--- a/net/mac802154/util.c
+++ b/net/mac802154/util.c
@@ -102,6 +102,16 @@ void ieee802154_xmit_error(struct ieee802154_hw *hw, struct sk_buff *skb,
 }
 EXPORT_SYMBOL(ieee802154_xmit_error);
 
+void ieee802154_xmit_bus_error(struct ieee802154_hw *hw, struct sk_buff *skb)
+{
+	struct ieee802154_local *local = hw_to_local(hw);
+
+	local->tx_result = IEEE802154_SYSTEM_ERROR;
+	ieee802154_wake_queue(hw);
+	dev_kfree_skb_any(skb);
+}
+EXPORT_SYMBOL(ieee802154_xmit_bus_error);
+
 void ieee802154_stop_device(struct ieee802154_local *local)
 {
 	flush_workqueue(local->workqueue);
-- 
2.27.0

[PATCH v5 06/11] net: ieee802154: at86rf230: Rename the asynchronous error helper

[Miquel Raynal]

In theory there are two distinct error path:
- The bus error when forwarding a packet to the transceiver fails.
- The transmitter error, after the transmission has been offloaded.

Right now in this driver only the former situation is properly handled,
so rename the different helpers to reflect this situation before
improving the support of the other path.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/net/ieee802154/at86rf230.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c
index 563031ce76f0..cafc786aab57 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
@@ -336,7 +336,7 @@ static const struct regmap_config at86rf230_regmap_spi_config = {
 };
 
 static void
-at86rf230_async_error_recover_complete(void *context)
+at86rf230_async_bus_error_recover_complete(void *context)
 {
 	struct at86rf230_state_change *ctx = context;
 	struct at86rf230_local *lp = ctx->lp;
@@ -352,7 +352,7 @@ at86rf230_async_error_recover_complete(void *context)
 }
 
 static void
-at86rf230_async_error_recover(void *context)
+at86rf230_async_bus_error_recover(void *context)
 {
 	struct at86rf230_state_change *ctx = context;
 	struct at86rf230_local *lp = ctx->lp;
@@ -363,17 +363,17 @@ at86rf230_async_error_recover(void *context)
 	}
 
 	at86rf230_async_state_change(lp, ctx, STATE_RX_AACK_ON,
-				     at86rf230_async_error_recover_complete);
+				     at86rf230_async_bus_error_recover_complete);
 }
 
 static inline void
-at86rf230_async_error(struct at86rf230_local *lp,
-		      struct at86rf230_state_change *ctx, int rc)
+at86rf230_async_bus_error(struct at86rf230_local *lp,
+			  struct at86rf230_state_change *ctx, int rc)
 {
 	dev_err(&lp->spi->dev, "spi_async error %d\n", rc);
 
 	at86rf230_async_state_change(lp, ctx, STATE_FORCE_TRX_OFF,
-				     at86rf230_async_error_recover);
+				     at86rf230_async_bus_error_recover);
 }
 
 /* Generic function to get some register value in async mode */
@@ -390,7 +390,7 @@ at86rf230_async_read_reg(struct at86rf230_local *lp, u8 reg,
 	ctx->msg.complete = complete;
 	rc = spi_async(lp->spi, &ctx->msg);
 	if (rc)
-		at86rf230_async_error(lp, ctx, rc);
+		at86rf230_async_bus_error(lp, ctx, rc);
 }
 
 static void
@@ -405,7 +405,7 @@ at86rf230_async_write_reg(struct at86rf230_local *lp, u8 reg, u8 val,
 	ctx->msg.complete = complete;
 	rc = spi_async(lp->spi, &ctx->msg);
 	if (rc)
-		at86rf230_async_error(lp, ctx, rc);
+		at86rf230_async_bus_error(lp, ctx, rc);
 }
 
 static void
@@ -640,7 +640,7 @@ at86rf230_sync_state_change(struct at86rf230_local *lp, unsigned int state)
 	rc = wait_for_completion_timeout(&lp->state_complete,
 					 msecs_to_jiffies(100));
 	if (!rc) {
-		at86rf230_async_error(lp, &lp->state, -ETIMEDOUT);
+		at86rf230_async_bus_error(lp, &lp->state, -ETIMEDOUT);
 		return -ETIMEDOUT;
 	}
 
@@ -762,7 +762,7 @@ at86rf230_rx_trac_check(void *context)
 	rc = spi_async(lp->spi, &ctx->msg);
 	if (rc) {
 		ctx->trx.len = 2;
-		at86rf230_async_error(lp, ctx, rc);
+		at86rf230_async_bus_error(lp, ctx, rc);
 	}
 }
 
@@ -839,7 +839,7 @@ static irqreturn_t at86rf230_isr(int irq, void *data)
 	ctx->msg.complete = at86rf230_irq_status;
 	rc = spi_async(lp->spi, &ctx->msg);
 	if (rc) {
-		at86rf230_async_error(lp, ctx, rc);
+		at86rf230_async_bus_error(lp, ctx, rc);
 		enable_irq(irq);
 		return IRQ_NONE;
 	}
@@ -881,7 +881,7 @@ at86rf230_write_frame(void *context)
 	rc = spi_async(lp->spi, &ctx->msg);
 	if (rc) {
 		ctx->trx.len = 2;
-		at86rf230_async_error(lp, ctx, rc);
+		at86rf230_async_bus_error(lp, ctx, rc);
 	}
 }
 
-- 
2.27.0

[PATCH v5 07/11] net: ieee802154: at86rf230: Call _xmit_bus_error() when a bus error occurs

[Miquel Raynal]

ieee802154_xmit_bus_error() is the right helper to call when a transmission
has failed. Let's use it instead of open-coding it. This also has the
advantage of forwarding a generic IEEE80254_SYSTEM_ERROR reason.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/net/ieee802154/at86rf230.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c
index cafc786aab57..f219732ab301 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
@@ -346,8 +346,7 @@ at86rf230_async_bus_error_recover_complete(void *context)
 
 	if (lp->was_tx) {
 		lp->was_tx = 0;
-		dev_kfree_skb_any(lp->tx_skb);
-		ieee802154_wake_queue(lp->hw);
+		ieee802154_xmit_bus_error(lp->hw, lp->tx_skb);
 	}
 }
 
-- 
2.27.0

[PATCH v5 08/11] net: ieee802154: at86rf230: Drop debugfs support

[Miquel Raynal]

Commit 493bc90a9683 ("at86rf230: add debugfs support") brought trac
support as part of a debugfs feature, in order to add some testing
capabilities involving ack handling.

As we want to collect trac errors but do not need the debugfs feature
anymore, let's partially revert this commit, keeping the Tx trac
handling part which still makes sense. This allows to return the trac
error directly to the core with the recently introduced
ieee802154_xmit_error() helper.

Suggested-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/net/ieee802154/Kconfig     |   7 --
 drivers/net/ieee802154/at86rf230.c | 127 +++++------------------------
 2 files changed, 21 insertions(+), 113 deletions(-)

diff --git a/drivers/net/ieee802154/Kconfig b/drivers/net/ieee802154/Kconfig
index 0f7c6dc2ed15..95da876c5613 100644
--- a/drivers/net/ieee802154/Kconfig
+++ b/drivers/net/ieee802154/Kconfig
@@ -33,13 +33,6 @@ config IEEE802154_AT86RF230
 	  This driver can also be built as a module. To do so, say M here.
 	  the module will be called 'at86rf230'.
 
-config IEEE802154_AT86RF230_DEBUGFS
-	depends on IEEE802154_AT86RF230
-	bool "AT86RF230 debugfs interface"
-	depends on DEBUG_FS
-	help
-	  This option compiles debugfs code for the at86rf230 driver.
-
 config IEEE802154_MRF24J40
 	tristate "Microchip MRF24J40 transceiver driver"
 	depends on IEEE802154_DRIVERS && MAC802154
diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c
index f219732ab301..45622db486f5 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
@@ -23,7 +23,6 @@
 #include <linux/skbuff.h>
 #include <linux/of_gpio.h>
 #include <linux/ieee802154.h>
-#include <linux/debugfs.h>
 
 #include <net/mac802154.h>
 #include <net/cfg802154.h>
@@ -72,19 +71,11 @@ struct at86rf230_state_change {
 	void (*complete)(void *context);
 	u8 from_state;
 	u8 to_state;
+	int trac;
 
 	bool free;
 };
 
-struct at86rf230_trac {
-	u64 success;
-	u64 success_data_pending;
-	u64 success_wait_for_ack;
-	u64 channel_access_failure;
-	u64 no_ack;
-	u64 invalid;
-};
-
 struct at86rf230_local {
 	struct spi_device *spi;
 
@@ -104,8 +95,6 @@ struct at86rf230_local {
 	u8 tx_retry;
 	struct sk_buff *tx_skb;
 	struct at86rf230_state_change tx;
-
-	struct at86rf230_trac trac;
 };
 
 #define AT86RF2XX_NUMREGS 0x3F
@@ -652,7 +641,11 @@ at86rf230_tx_complete(void *context)
 	struct at86rf230_state_change *ctx = context;
 	struct at86rf230_local *lp = ctx->lp;
 
-	ieee802154_xmit_complete(lp->hw, lp->tx_skb, false);
+	if (ctx->trac == IEEE802154_SUCCESS)
+		ieee802154_xmit_complete(lp->hw, lp->tx_skb, false);
+	else
+		ieee802154_xmit_error(lp->hw, lp->tx_skb, ctx->trac);
+
 	kfree(ctx);
 }
 
@@ -671,30 +664,21 @@ at86rf230_tx_trac_check(void *context)
 {
 	struct at86rf230_state_change *ctx = context;
 	struct at86rf230_local *lp = ctx->lp;
+	u8 trac = TRAC_MASK(ctx->buf[1]);
 
-	if (IS_ENABLED(CONFIG_IEEE802154_AT86RF230_DEBUGFS)) {
-		u8 trac = TRAC_MASK(ctx->buf[1]);
-
-		switch (trac) {
-		case TRAC_SUCCESS:
-			lp->trac.success++;
-			break;
-		case TRAC_SUCCESS_DATA_PENDING:
-			lp->trac.success_data_pending++;
-			break;
-		case TRAC_CHANNEL_ACCESS_FAILURE:
-			lp->trac.channel_access_failure++;
-			break;
-		case TRAC_NO_ACK:
-			lp->trac.no_ack++;
-			break;
-		case TRAC_INVALID:
-			lp->trac.invalid++;
-			break;
-		default:
-			WARN_ONCE(1, "received tx trac status %d\n", trac);
-			break;
-		}
+	switch (trac) {
+	case TRAC_SUCCESS:
+	case TRAC_SUCCESS_DATA_PENDING:
+		ctx->trac = IEEE802154_SUCCESS;
+		break;
+	case TRAC_CHANNEL_ACCESS_FAILURE:
+		ctx->trac = IEEE802154_CHANNEL_ACCESS_FAILURE;
+		break;
+	case TRAC_NO_ACK:
+		ctx->trac = IEEE802154_NO_ACK;
+		break;
+	default:
+		ctx->trac = IEEE802154_SYSTEM_ERROR;
 	}
 
 	at86rf230_async_state_change(lp, ctx, STATE_TX_ON, at86rf230_tx_on);
@@ -736,25 +720,6 @@ at86rf230_rx_trac_check(void *context)
 	u8 *buf = ctx->buf;
 	int rc;
 
-	if (IS_ENABLED(CONFIG_IEEE802154_AT86RF230_DEBUGFS)) {
-		u8 trac = TRAC_MASK(buf[1]);
-
-		switch (trac) {
-		case TRAC_SUCCESS:
-			lp->trac.success++;
-			break;
-		case TRAC_SUCCESS_WAIT_FOR_ACK:
-			lp->trac.success_wait_for_ack++;
-			break;
-		case TRAC_INVALID:
-			lp->trac.invalid++;
-			break;
-		default:
-			WARN_ONCE(1, "received rx trac status %d\n", trac);
-			break;
-		}
-	}
-
 	buf[0] = CMD_FB;
 	ctx->trx.len = AT86RF2XX_MAX_BUF;
 	ctx->msg.complete = at86rf230_rx_read_frame_complete;
@@ -950,10 +915,6 @@ at86rf230_start(struct ieee802154_hw *hw)
 {
 	struct at86rf230_local *lp = hw->priv;
 
-	/* reset trac stats on start */
-	if (IS_ENABLED(CONFIG_IEEE802154_AT86RF230_DEBUGFS))
-		memset(&lp->trac, 0, sizeof(struct at86rf230_trac));
-
 	at86rf230_awake(lp);
 	enable_irq(lp->spi->irq);
 
@@ -1581,47 +1542,6 @@ at86rf230_detect_device(struct at86rf230_local *lp)
 	return rc;
 }
 
-#ifdef CONFIG_IEEE802154_AT86RF230_DEBUGFS
-static struct dentry *at86rf230_debugfs_root;
-
-static int at86rf230_stats_show(struct seq_file *file, void *offset)
-{
-	struct at86rf230_local *lp = file->private;
-
-	seq_printf(file, "SUCCESS:\t\t%8llu\n", lp->trac.success);
-	seq_printf(file, "SUCCESS_DATA_PENDING:\t%8llu\n",
-		   lp->trac.success_data_pending);
-	seq_printf(file, "SUCCESS_WAIT_FOR_ACK:\t%8llu\n",
-		   lp->trac.success_wait_for_ack);
-	seq_printf(file, "CHANNEL_ACCESS_FAILURE:\t%8llu\n",
-		   lp->trac.channel_access_failure);
-	seq_printf(file, "NO_ACK:\t\t\t%8llu\n", lp->trac.no_ack);
-	seq_printf(file, "INVALID:\t\t%8llu\n", lp->trac.invalid);
-	return 0;
-}
-DEFINE_SHOW_ATTRIBUTE(at86rf230_stats);
-
-static void at86rf230_debugfs_init(struct at86rf230_local *lp)
-{
-	char debugfs_dir_name[DNAME_INLINE_LEN + 1] = "at86rf230-";
-
-	strncat(debugfs_dir_name, dev_name(&lp->spi->dev), DNAME_INLINE_LEN);
-
-	at86rf230_debugfs_root = debugfs_create_dir(debugfs_dir_name, NULL);
-
-	debugfs_create_file("trac_stats", 0444, at86rf230_debugfs_root, lp,
-			    &at86rf230_stats_fops);
-}
-
-static void at86rf230_debugfs_remove(void)
-{
-	debugfs_remove_recursive(at86rf230_debugfs_root);
-}
-#else
-static void at86rf230_debugfs_init(struct at86rf230_local *lp) { }
-static void at86rf230_debugfs_remove(void) { }
-#endif
-
 static int at86rf230_probe(struct spi_device *spi)
 {
 	struct ieee802154_hw *hw;
@@ -1718,16 +1638,12 @@ static int at86rf230_probe(struct spi_device *spi)
 	/* going into sleep by default */
 	at86rf230_sleep(lp);
 
-	at86rf230_debugfs_init(lp);
-
 	rc = ieee802154_register_hw(lp->hw);
 	if (rc)
-		goto free_debugfs;
+		goto free_dev;
 
 	return rc;
 
-free_debugfs:
-	at86rf230_debugfs_remove();
 free_dev:
 	ieee802154_free_hw(lp->hw);
 
@@ -1742,7 +1658,6 @@ static int at86rf230_remove(struct spi_device *spi)
 	at86rf230_write_subreg(lp, SR_IRQ_MASK, 0);
 	ieee802154_unregister_hw(lp->hw);
 	ieee802154_free_hw(lp->hw);
-	at86rf230_debugfs_remove();
 	dev_dbg(&spi->dev, "unregistered at86rf230\n");
 
 	return 0;
-- 
2.27.0

[PATCH v5 09/11] net: ieee802154: atusb: Call _xmit_error() when a transmission fails

[Miquel Raynal]

ieee802154_xmit_error() is the right helper to call when a transmission
has failed. Let's use it instead of open-coding it.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/net/ieee802154/atusb.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
index f27a5f535808..d04db4d07a64 100644
--- a/drivers/net/ieee802154/atusb.c
+++ b/drivers/net/ieee802154/atusb.c
@@ -271,9 +271,8 @@ static void atusb_tx_done(struct atusb *atusb, u8 seq)
 		 * unlikely case now that seq == expect is then true, but can
 		 * happen and fail with a tx_skb = NULL;
 		 */
-		ieee802154_wake_queue(atusb->hw);
-		if (atusb->tx_skb)
-			dev_kfree_skb_irq(atusb->tx_skb);
+		ieee802154_xmit_error(atusb->hw, atusb->tx_skb,
+				      IEEE802154_SYSTEM_ERROR);
 	}
 }
 
-- 
2.27.0

[PATCH v5 10/11] net: ieee802154: ca8210: Use core return codes instead of hardcoding them

[Miquel Raynal]

All the error codes defined in this driver are generic and already
defined in the ieee802154 main header. Let's just get rid of these extra
definition and switch to the core's values.

There is no functional change.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/net/ieee802154/ca8210.c | 178 ++++++++++++--------------------
 1 file changed, 68 insertions(+), 110 deletions(-)

diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
index fc74fa0f1ddd..116aece191cd 100644
--- a/drivers/net/ieee802154/ca8210.c
+++ b/drivers/net/ieee802154/ca8210.c
@@ -89,48 +89,6 @@
 #define CA8210_TEST_INT_FILE_NAME "ca8210_test"
 #define CA8210_TEST_INT_FIFO_SIZE 256
 
-/* MAC status enumerations */
-#define MAC_SUCCESS                     (0x00)
-#define MAC_ERROR                       (0x01)
-#define MAC_CANCELLED                   (0x02)
-#define MAC_READY_FOR_POLL              (0x03)
-#define MAC_COUNTER_ERROR               (0xDB)
-#define MAC_IMPROPER_KEY_TYPE           (0xDC)
-#define MAC_IMPROPER_SECURITY_LEVEL     (0xDD)
-#define MAC_UNSUPPORTED_LEGACY          (0xDE)
-#define MAC_UNSUPPORTED_SECURITY        (0xDF)
-#define MAC_BEACON_LOST                 (0xE0)
-#define MAC_CHANNEL_ACCESS_FAILURE      (0xE1)
-#define MAC_DENIED                      (0xE2)
-#define MAC_DISABLE_TRX_FAILURE         (0xE3)
-#define MAC_SECURITY_ERROR              (0xE4)
-#define MAC_FRAME_TOO_LONG              (0xE5)
-#define MAC_INVALID_GTS                 (0xE6)
-#define MAC_INVALID_HANDLE              (0xE7)
-#define MAC_INVALID_PARAMETER           (0xE8)
-#define MAC_NO_ACK                      (0xE9)
-#define MAC_NO_BEACON                   (0xEA)
-#define MAC_NO_DATA                     (0xEB)
-#define MAC_NO_SHORT_ADDRESS            (0xEC)
-#define MAC_OUT_OF_CAP                  (0xED)
-#define MAC_PAN_ID_CONFLICT             (0xEE)
-#define MAC_REALIGNMENT                 (0xEF)
-#define MAC_TRANSACTION_EXPIRED         (0xF0)
-#define MAC_TRANSACTION_OVERFLOW        (0xF1)
-#define MAC_TX_ACTIVE                   (0xF2)
-#define MAC_UNAVAILABLE_KEY             (0xF3)
-#define MAC_UNSUPPORTED_ATTRIBUTE       (0xF4)
-#define MAC_INVALID_ADDRESS             (0xF5)
-#define MAC_ON_TIME_TOO_LONG            (0xF6)
-#define MAC_PAST_TIME                   (0xF7)
-#define MAC_TRACKING_OFF                (0xF8)
-#define MAC_INVALID_INDEX               (0xF9)
-#define MAC_LIMIT_REACHED               (0xFA)
-#define MAC_READ_ONLY                   (0xFB)
-#define MAC_SCAN_IN_PROGRESS            (0xFC)
-#define MAC_SUPERFRAME_OVERLAP          (0xFD)
-#define MAC_SYSTEM_ERROR                (0xFF)
-
 /* HWME attribute IDs */
 #define HWME_EDTHRESHOLD       (0x04)
 #define HWME_EDVALUE           (0x06)
@@ -551,58 +509,58 @@ static int link_to_linux_err(int link_status)
 		return link_status;
 	}
 	switch (link_status) {
-	case MAC_SUCCESS:
-	case MAC_REALIGNMENT:
+	case IEEE802154_SUCCESS:
+	case IEEE802154_REALIGNMENT:
 		return 0;
-	case MAC_IMPROPER_KEY_TYPE:
+	case IEEE802154_IMPROPER_KEY_TYPE:
 		return -EKEYREJECTED;
-	case MAC_IMPROPER_SECURITY_LEVEL:
-	case MAC_UNSUPPORTED_LEGACY:
-	case MAC_DENIED:
+	case IEEE802154_IMPROPER_SECURITY_LEVEL:
+	case IEEE802154_UNSUPPORTED_LEGACY:
+	case IEEE802154_DENIED:
 		return -EACCES;
-	case MAC_BEACON_LOST:
-	case MAC_NO_ACK:
-	case MAC_NO_BEACON:
+	case IEEE802154_BEACON_LOST:
+	case IEEE802154_NO_ACK:
+	case IEEE802154_NO_BEACON:
 		return -ENETUNREACH;
-	case MAC_CHANNEL_ACCESS_FAILURE:
-	case MAC_TX_ACTIVE:
-	case MAC_SCAN_IN_PROGRESS:
+	case IEEE802154_CHANNEL_ACCESS_FAILURE:
+	case IEEE802154_TX_ACTIVE:
+	case IEEE802154_SCAN_IN_PROGRESS:
 		return -EBUSY;
-	case MAC_DISABLE_TRX_FAILURE:
-	case MAC_OUT_OF_CAP:
+	case IEEE802154_DISABLE_TRX_FAILURE:
+	case IEEE802154_OUT_OF_CAP:
 		return -EAGAIN;
-	case MAC_FRAME_TOO_LONG:
+	case IEEE802154_FRAME_TOO_LONG:
 		return -EMSGSIZE;
-	case MAC_INVALID_GTS:
-	case MAC_PAST_TIME:
+	case IEEE802154_INVALID_GTS:
+	case IEEE802154_PAST_TIME:
 		return -EBADSLT;
-	case MAC_INVALID_HANDLE:
+	case IEEE802154_INVALID_HANDLE:
 		return -EBADMSG;
-	case MAC_INVALID_PARAMETER:
-	case MAC_UNSUPPORTED_ATTRIBUTE:
-	case MAC_ON_TIME_TOO_LONG:
-	case MAC_INVALID_INDEX:
+	case IEEE802154_INVALID_PARAMETER:
+	case IEEE802154_UNSUPPORTED_ATTRIBUTE:
+	case IEEE802154_ON_TIME_TOO_LONG:
+	case IEEE802154_INVALID_INDEX:
 		return -EINVAL;
-	case MAC_NO_DATA:
+	case IEEE802154_NO_DATA:
 		return -ENODATA;
-	case MAC_NO_SHORT_ADDRESS:
+	case IEEE802154_NO_SHORT_ADDRESS:
 		return -EFAULT;
-	case MAC_PAN_ID_CONFLICT:
+	case IEEE802154_PAN_ID_CONFLICT:
 		return -EADDRINUSE;
-	case MAC_TRANSACTION_EXPIRED:
+	case IEEE802154_TRANSACTION_EXPIRED:
 		return -ETIME;
-	case MAC_TRANSACTION_OVERFLOW:
+	case IEEE802154_TRANSACTION_OVERFLOW:
 		return -ENOBUFS;
-	case MAC_UNAVAILABLE_KEY:
+	case IEEE802154_UNAVAILABLE_KEY:
 		return -ENOKEY;
-	case MAC_INVALID_ADDRESS:
+	case IEEE802154_INVALID_ADDRESS:
 		return -ENXIO;
-	case MAC_TRACKING_OFF:
-	case MAC_SUPERFRAME_OVERLAP:
+	case IEEE802154_TRACKING_OFF:
+	case IEEE802154_SUPERFRAME_OVERLAP:
 		return -EREMOTEIO;
-	case MAC_LIMIT_REACHED:
+	case IEEE802154_LIMIT_REACHED:
 		return -EDQUOT;
-	case MAC_READ_ONLY:
+	case IEEE802154_READ_ONLY:
 		return -EROFS;
 	default:
 		return -EPROTO;
@@ -754,7 +712,7 @@ static void ca8210_rx_done(struct cas_control *cas_ctl)
 
 	ca8210_net_rx(priv->hw, buf, len);
 	if (buf[0] == SPI_MCPS_DATA_CONFIRM) {
-		if (buf[3] == MAC_TRANSACTION_OVERFLOW) {
+		if (buf[3] == IEEE802154_TRANSACTION_OVERFLOW) {
 			dev_info(
 				&priv->spi->dev,
 				"Waiting for transaction overflow to stabilise...\n");
@@ -1128,7 +1086,7 @@ static u8 tdme_setsfr_request_sync(
 	);
 	if (ret) {
 		dev_crit(&spi->dev, "cascoda_api_downstream returned %d", ret);
-		return MAC_SYSTEM_ERROR;
+		return IEEE802154_SYSTEM_ERROR;
 	}
 
 	if (response.command_id != SPI_TDME_SETSFR_CONFIRM) {
@@ -1137,7 +1095,7 @@ static u8 tdme_setsfr_request_sync(
 			"sync response to SPI_TDME_SETSFR_REQUEST was not SPI_TDME_SETSFR_CONFIRM, it was %d\n",
 			response.command_id
 		);
-		return MAC_SYSTEM_ERROR;
+		return IEEE802154_SYSTEM_ERROR;
 	}
 
 	return response.pdata.tdme_set_sfr_cnf.status;
@@ -1151,7 +1109,7 @@ static u8 tdme_setsfr_request_sync(
  */
 static u8 tdme_chipinit(void *device_ref)
 {
-	u8 status = MAC_SUCCESS;
+	u8 status = IEEE802154_SUCCESS;
 	u8 sfr_address;
 	struct spi_device *spi = device_ref;
 	struct preamble_cfg_sfr pre_cfg_value = {
@@ -1220,7 +1178,7 @@ static u8 tdme_chipinit(void *device_ref)
 		goto finish;
 
 finish:
-	if (status != MAC_SUCCESS) {
+	if (status != IEEE802154_SUCCESS) {
 		dev_err(
 			&spi->dev,
 			"failed to set sfr at %#03x, status = %#03x\n",
@@ -1287,7 +1245,7 @@ static u8 tdme_checkpibattribute(
 	const void   *pib_attribute_value
 )
 {
-	u8 status = MAC_SUCCESS;
+	u8 status = IEEE802154_SUCCESS;
 	u8 value;
 
 	value  = *((u8 *)pib_attribute_value);
@@ -1296,52 +1254,52 @@ static u8 tdme_checkpibattribute(
 	/* PHY */
 	case PHY_TRANSMIT_POWER:
 		if (value > 0x3F)
-			status = MAC_INVALID_PARAMETER;
+			status = IEEE802154_INVALID_PARAMETER;
 		break;
 	case PHY_CCA_MODE:
 		if (value > 0x03)
-			status = MAC_INVALID_PARAMETER;
+			status = IEEE802154_INVALID_PARAMETER;
 		break;
 	/* MAC */
 	case MAC_BATT_LIFE_EXT_PERIODS:
 		if (value < 6 || value > 41)
-			status = MAC_INVALID_PARAMETER;
+			status = IEEE802154_INVALID_PARAMETER;
 		break;
 	case MAC_BEACON_PAYLOAD:
 		if (pib_attribute_length > MAX_BEACON_PAYLOAD_LENGTH)
-			status = MAC_INVALID_PARAMETER;
+			status = IEEE802154_INVALID_PARAMETER;
 		break;
 	case MAC_BEACON_PAYLOAD_LENGTH:
 		if (value > MAX_BEACON_PAYLOAD_LENGTH)
-			status = MAC_INVALID_PARAMETER;
+			status = IEEE802154_INVALID_PARAMETER;
 		break;
 	case MAC_BEACON_ORDER:
 		if (value > 15)
-			status = MAC_INVALID_PARAMETER;
+			status = IEEE802154_INVALID_PARAMETER;
 		break;
 	case MAC_MAX_BE:
 		if (value < 3 || value > 8)
-			status = MAC_INVALID_PARAMETER;
+			status = IEEE802154_INVALID_PARAMETER;
 		break;
 	case MAC_MAX_CSMA_BACKOFFS:
 		if (value > 5)
-			status = MAC_INVALID_PARAMETER;
+			status = IEEE802154_INVALID_PARAMETER;
 		break;
 	case MAC_MAX_FRAME_RETRIES:
 		if (value > 7)
-			status = MAC_INVALID_PARAMETER;
+			status = IEEE802154_INVALID_PARAMETER;
 		break;
 	case MAC_MIN_BE:
 		if (value > 8)
-			status = MAC_INVALID_PARAMETER;
+			status = IEEE802154_INVALID_PARAMETER;
 		break;
 	case MAC_RESPONSE_WAIT_TIME:
 		if (value < 2 || value > 64)
-			status = MAC_INVALID_PARAMETER;
+			status = IEEE802154_INVALID_PARAMETER;
 		break;
 	case MAC_SUPERFRAME_ORDER:
 		if (value > 15)
-			status = MAC_INVALID_PARAMETER;
+			status = IEEE802154_INVALID_PARAMETER;
 		break;
 	/* boolean */
 	case MAC_ASSOCIATED_PAN_COORD:
@@ -1353,16 +1311,16 @@ static u8 tdme_checkpibattribute(
 	case MAC_RX_ON_WHEN_IDLE:
 	case MAC_SECURITY_ENABLED:
 		if (value > 1)
-			status = MAC_INVALID_PARAMETER;
+			status = IEEE802154_INVALID_PARAMETER;
 		break;
 	/* MAC SEC */
 	case MAC_AUTO_REQUEST_SECURITY_LEVEL:
 		if (value > 7)
-			status = MAC_INVALID_PARAMETER;
+			status = IEEE802154_INVALID_PARAMETER;
 		break;
 	case MAC_AUTO_REQUEST_KEY_ID_MODE:
 		if (value > 3)
-			status = MAC_INVALID_PARAMETER;
+			status = IEEE802154_INVALID_PARAMETER;
 		break;
 	default:
 		break;
@@ -1522,9 +1480,9 @@ static u8 mcps_data_request(
 
 	if (ca8210_spi_transfer(device_ref, &command.command_id,
 				command.length + 2))
-		return MAC_SYSTEM_ERROR;
+		return IEEE802154_SYSTEM_ERROR;
 
-	return MAC_SUCCESS;
+	return IEEE802154_SUCCESS;
 }
 
 /**
@@ -1553,11 +1511,11 @@ static u8 mlme_reset_request_sync(
 		&response.command_id,
 		device_ref)) {
 		dev_err(&spi->dev, "cascoda_api_downstream failed\n");
-		return MAC_SYSTEM_ERROR;
+		return IEEE802154_SYSTEM_ERROR;
 	}
 
 	if (response.command_id != SPI_MLME_RESET_CONFIRM)
-		return MAC_SYSTEM_ERROR;
+		return IEEE802154_SYSTEM_ERROR;
 
 	status = response.pdata.status;
 
@@ -1600,7 +1558,7 @@ static u8 mlme_set_request_sync(
 	 */
 	if (tdme_checkpibattribute(
 		pib_attribute, pib_attribute_length, pib_attribute_value)) {
-		return MAC_INVALID_PARAMETER;
+		return IEEE802154_INVALID_PARAMETER;
 	}
 
 	if (pib_attribute == PHY_CURRENT_CHANNEL) {
@@ -1636,11 +1594,11 @@ static u8 mlme_set_request_sync(
 		command.length + 2,
 		&response.command_id,
 		device_ref)) {
-		return MAC_SYSTEM_ERROR;
+		return IEEE802154_SYSTEM_ERROR;
 	}
 
 	if (response.command_id != SPI_MLME_SET_CONFIRM)
-		return MAC_SYSTEM_ERROR;
+		return IEEE802154_SYSTEM_ERROR;
 
 	return response.pdata.status;
 }
@@ -1678,11 +1636,11 @@ static u8 hwme_set_request_sync(
 		command.length + 2,
 		&response.command_id,
 		device_ref)) {
-		return MAC_SYSTEM_ERROR;
+		return IEEE802154_SYSTEM_ERROR;
 	}
 
 	if (response.command_id != SPI_HWME_SET_CONFIRM)
-		return MAC_SYSTEM_ERROR;
+		return IEEE802154_SYSTEM_ERROR;
 
 	return response.pdata.hwme_set_cnf.status;
 }
@@ -1714,13 +1672,13 @@ static u8 hwme_get_request_sync(
 		command.length + 2,
 		&response.command_id,
 		device_ref)) {
-		return MAC_SYSTEM_ERROR;
+		return IEEE802154_SYSTEM_ERROR;
 	}
 
 	if (response.command_id != SPI_HWME_GET_CONFIRM)
-		return MAC_SYSTEM_ERROR;
+		return IEEE802154_SYSTEM_ERROR;
 
-	if (response.pdata.hwme_get_cnf.status == MAC_SUCCESS) {
+	if (response.pdata.hwme_get_cnf.status == IEEE802154_SUCCESS) {
 		*hw_attribute_length =
 			response.pdata.hwme_get_cnf.hw_attribute_length;
 		memcpy(
@@ -1770,7 +1728,7 @@ static int ca8210_async_xmit_complete(
 			"Link transmission unsuccessful, status = %d\n",
 			status
 		);
-		if (status != MAC_TRANSACTION_OVERFLOW) {
+		if (status != IEEE802154_TRANSACTION_OVERFLOW) {
 			dev_kfree_skb_any(priv->tx_skb);
 			ieee802154_wake_queue(priv->hw);
 			return 0;
@@ -2436,7 +2394,7 @@ static int ca8210_test_check_upstream(u8 *buf, void *device_ref)
 		if (ret) {
 			response[0]  = SPI_MLME_SET_CONFIRM;
 			response[1] = 3;
-			response[2] = MAC_INVALID_PARAMETER;
+			response[2] = IEEE802154_INVALID_PARAMETER;
 			response[3] = buf[2];
 			response[4] = buf[3];
 			if (cascoda_api_upstream)
-- 
2.27.0

[PATCH v5 11/11] net: ieee802154: ca8210: Call _xmit_error() when a transmission fails

[Miquel Raynal]

ieee802154_xmit_error() is the right helper to call when a transmission
has failed. Let's use it instead of open-coding it.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/net/ieee802154/ca8210.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
index 116aece191cd..b1eb74200f23 100644
--- a/drivers/net/ieee802154/ca8210.c
+++ b/drivers/net/ieee802154/ca8210.c
@@ -1729,11 +1729,11 @@ static int ca8210_async_xmit_complete(
 			status
 		);
 		if (status != IEEE802154_TRANSACTION_OVERFLOW) {
-			dev_kfree_skb_any(priv->tx_skb);
-			ieee802154_wake_queue(priv->hw);
+			ieee802154_xmit_error(priv->hw, priv->tx_skb, status);
 			return 0;
 		}
 	}
+
 	ieee802154_xmit_complete(priv->hw, priv->tx_skb, true);
 
 	return 0;
-- 
2.27.0

Re: [PATCH v5 05/11] net: mac802154: Create a transmit bus error helper

[Alexander Aring]

Hi,

On Wed, Apr 6, 2022 at 11:34 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> A few drivers do the full transmit operation asynchronously, which means
> that a bus error that happens when forwarding the packet 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
> the queue and return a generic TRAC error code: IEEE802154_SYSTEM_ERROR.
>
> Suggested-by: Alexander Aring <alex.aring@gmail.com>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
>  include/net/mac802154.h |  9 +++++++++
>  net/mac802154/util.c    | 10 ++++++++++
>  2 files changed, 19 insertions(+)
>
> diff --git a/include/net/mac802154.h b/include/net/mac802154.h
> index abbe88dc9df5..5240d94aad8e 100644
> --- a/include/net/mac802154.h
> +++ b/include/net/mac802154.h
> @@ -498,6 +498,15 @@ void ieee802154_stop_queue(struct ieee802154_hw *hw);
>  void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff *skb,
>                               bool ifs_handling);
>
> +/**
> + * ieee802154_xmit_bus_error - frame could not be delivered to the trasmitter
> + *                             because of a bus error
> + *
> + * @hw: pointer as obtained from ieee802154_alloc_hw().
> + * @skb: buffer for transmission
> + */
> +void ieee802154_xmit_bus_error(struct ieee802154_hw *hw, struct sk_buff *skb);
> +
>  /**
>   * ieee802154_xmit_error - frame transmission failed
>   *
> diff --git a/net/mac802154/util.c b/net/mac802154/util.c
> index ec523335336c..79ba803c40c9 100644
> --- a/net/mac802154/util.c
> +++ b/net/mac802154/util.c
> @@ -102,6 +102,16 @@ void ieee802154_xmit_error(struct ieee802154_hw *hw, struct sk_buff *skb,
>  }
>  EXPORT_SYMBOL(ieee802154_xmit_error);
>
> +void ieee802154_xmit_bus_error(struct ieee802154_hw *hw, struct sk_buff *skb)
> +{
> +       struct ieee802154_local *local = hw_to_local(hw);
> +
> +       local->tx_result = IEEE802154_SYSTEM_ERROR;
> +       ieee802154_wake_queue(hw);
> +       dev_kfree_skb_any(skb);
> +}
> +EXPORT_SYMBOL(ieee802154_xmit_bus_error);
> +

why not calling ieee802154_xmit_error(..., IEEE802154_SYSTEM_ERROR) ?
Just don't give the user a chance to pick a error code if something
bad happened.

- Alex

Re: [PATCH v5 06/11] net: ieee802154: at86rf230: Rename the asynchronous error helper

[Alexander Aring]

Hi,

On Wed, Apr 6, 2022 at 11:34 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> In theory there are two distinct error path:
> - The bus error when forwarding a packet to the transceiver fails.
> - The transmitter error, after the transmission has been offloaded.
>
> Right now in this driver only the former situation is properly handled,
> so rename the different helpers to reflect this situation before
> improving the support of the other path.
>

I have no idea what I should think about this patch.

On the driver layer there only exists "bus errors" okay, whatever
error because spi_async() returns an error and we try to recover from
it. Also async_error() will be called when there is a timeout because
the transceiver took too long for some state change... In this case
most often this async_error() is called if spi_async() returns an
error but as I said it's not always the case (e.g. timeout)... it is
some kind of hardware issue (indicated by 802.15.4 SYSTEM_ERROR for
upper layer) and probably if it occurs we can't recover anyway from it
(maybe rfkill support can do it, which does a whole transceiver reset
routine, but this is always user triggered so far I know).

However if you want that patch in that's it's fine for me, but for me
this if somebody looks closely into the code it's obvious that in most
cases it's called when spi_async() returns an error (which is not
always the case see timeout).

- Alex

Re: [PATCH v5 09/11] net: ieee802154: atusb: Call _xmit_error() when a transmission fails

[Alexander Aring]

Hi,

On Wed, Apr 6, 2022 at 11:34 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> ieee802154_xmit_error() is the right helper to call when a transmission
> has failed. Let's use it instead of open-coding it.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
>  drivers/net/ieee802154/atusb.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
> index f27a5f535808..d04db4d07a64 100644
> --- a/drivers/net/ieee802154/atusb.c
> +++ b/drivers/net/ieee802154/atusb.c
> @@ -271,9 +271,8 @@ static void atusb_tx_done(struct atusb *atusb, u8 seq)
>                  * unlikely case now that seq == expect is then true, but can
>                  * happen and fail with a tx_skb = NULL;
>                  */
> -               ieee802154_wake_queue(atusb->hw);
> -               if (atusb->tx_skb)
> -                       dev_kfree_skb_irq(atusb->tx_skb);
> +               ieee802154_xmit_error(atusb->hw, atusb->tx_skb,
> +                                     IEEE802154_SYSTEM_ERROR);

That should then call the xmit_error for ANY other reason which is not
802.15.4 specific which is the bus_error() function?

- Alex

Re: [PATCH v5 05/11] net: mac802154: Create a transmit bus error helper

[Miquel Raynal]

Hi Alexander,

alex.aring@gmail.com wrote on Wed, 6 Apr 2022 17:43:30 -0400:

> Hi,
> 
> On Wed, Apr 6, 2022 at 11:34 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > A few drivers do the full transmit operation asynchronously, which means
> > that a bus error that happens when forwarding the packet 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
> > the queue and return a generic TRAC error code: IEEE802154_SYSTEM_ERROR.
> >
> > Suggested-by: Alexander Aring <alex.aring@gmail.com>
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> >  include/net/mac802154.h |  9 +++++++++
> >  net/mac802154/util.c    | 10 ++++++++++
> >  2 files changed, 19 insertions(+)
> >
> > diff --git a/include/net/mac802154.h b/include/net/mac802154.h
> > index abbe88dc9df5..5240d94aad8e 100644
> > --- a/include/net/mac802154.h
> > +++ b/include/net/mac802154.h
> > @@ -498,6 +498,15 @@ void ieee802154_stop_queue(struct ieee802154_hw *hw);
> >  void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff *skb,
> >                               bool ifs_handling);
> >
> > +/**
> > + * ieee802154_xmit_bus_error - frame could not be delivered to the trasmitter
> > + *                             because of a bus error
> > + *
> > + * @hw: pointer as obtained from ieee802154_alloc_hw().
> > + * @skb: buffer for transmission
> > + */
> > +void ieee802154_xmit_bus_error(struct ieee802154_hw *hw, struct sk_buff *skb);
> > +
> >  /**
> >   * ieee802154_xmit_error - frame transmission failed
> >   *
> > diff --git a/net/mac802154/util.c b/net/mac802154/util.c
> > index ec523335336c..79ba803c40c9 100644
> > --- a/net/mac802154/util.c
> > +++ b/net/mac802154/util.c
> > @@ -102,6 +102,16 @@ void ieee802154_xmit_error(struct ieee802154_hw *hw, struct sk_buff *skb,
> >  }
> >  EXPORT_SYMBOL(ieee802154_xmit_error);
> >
> > +void ieee802154_xmit_bus_error(struct ieee802154_hw *hw, struct sk_buff *skb)
> > +{
> > +       struct ieee802154_local *local = hw_to_local(hw);
> > +
> > +       local->tx_result = IEEE802154_SYSTEM_ERROR;
> > +       ieee802154_wake_queue(hw);
> > +       dev_kfree_skb_any(skb);
> > +}
> > +EXPORT_SYMBOL(ieee802154_xmit_bus_error);
> > +  
> 
> why not calling ieee802154_xmit_error(..., IEEE802154_SYSTEM_ERROR) ?
> Just don't give the user a chance to pick a error code if something
> bad happened.

Oh ok, I assumed, based on your last comment, that you wanted a
dedicated helper for that, but if just calling xmit_error() with the
a fixed value is enough I'll drop this commit.

Thanks,
Miquèl

Re: [PATCH v5 06/11] net: ieee802154: at86rf230: Rename the asynchronous error helper

[Miquel Raynal]

Hi Alexander,

alex.aring@gmail.com wrote on Wed, 6 Apr 2022 17:57:41 -0400:

> Hi,
> 
> On Wed, Apr 6, 2022 at 11:34 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > In theory there are two distinct error path:
> > - The bus error when forwarding a packet to the transceiver fails.
> > - The transmitter error, after the transmission has been offloaded.
> >
> > Right now in this driver only the former situation is properly handled,
> > so rename the different helpers to reflect this situation before
> > improving the support of the other path.
> >  
> 
> I have no idea what I should think about this patch.
> 
> On the driver layer there only exists "bus errors" okay, whatever
> error because spi_async() returns an error and we try to recover from
> it. Also async_error() will be called when there is a timeout because
> the transceiver took too long for some state change... In this case
> most often this async_error() is called if spi_async() returns an
> error but as I said it's not always the case (e.g. timeout)... it is
> some kind of hardware issue (indicated by 802.15.4 SYSTEM_ERROR for
> upper layer) and probably if it occurs we can't recover anyway from it
> (maybe rfkill support can do it, which does a whole transceiver reset
> routine, but this is always user triggered so far I know).
> 
> However if you want that patch in that's it's fine for me, but for me
> this if somebody looks closely into the code it's obvious that in most
> cases it's called when spi_async() returns an error (which is not
> always the case see timeout).

I thought it would clarify the situation but I overlooked the timeout
situation. Actually I did wrote it before understanding what was wrong
with the patch coming next (I assume my new approach is fine?), and
the two changes are fully independent, so I'll drop this patch too.

Thanks,
Miquèl

Re: [PATCH v5 09/11] net: ieee802154: atusb: Call _xmit_error() when a transmission fails

[Miquel Raynal]

Hi Alexander,

alex.aring@gmail.com wrote on Wed, 6 Apr 2022 17:58:59 -0400:

> Hi,
> 
> On Wed, Apr 6, 2022 at 11:34 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > ieee802154_xmit_error() is the right helper to call when a transmission
> > has failed. Let's use it instead of open-coding it.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> >  drivers/net/ieee802154/atusb.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
> > index f27a5f535808..d04db4d07a64 100644
> > --- a/drivers/net/ieee802154/atusb.c
> > +++ b/drivers/net/ieee802154/atusb.c
> > @@ -271,9 +271,8 @@ static void atusb_tx_done(struct atusb *atusb, u8 seq)
> >                  * unlikely case now that seq == expect is then true, but can
> >                  * happen and fail with a tx_skb = NULL;
> >                  */
> > -               ieee802154_wake_queue(atusb->hw);
> > -               if (atusb->tx_skb)
> > -                       dev_kfree_skb_irq(atusb->tx_skb);
> > +               ieee802154_xmit_error(atusb->hw, atusb->tx_skb,
> > +                                     IEEE802154_SYSTEM_ERROR);  
> 
> That should then call the xmit_error for ANY other reason which is not
> 802.15.4 specific which is the bus_error() function?

I'll drop the bus error function so we can stick to a regular
_xmit_error() call.

Besides, we do not have any trac information nor any easy access to
what failed exactly, so it's probably best anyway.

Thanks,
Miquèl

Re: [PATCH v5 05/11] net: mac802154: Create a transmit bus error helper

[Miquel Raynal]

miquel.raynal@bootlin.com wrote on Thu, 7 Apr 2022 09:56:05 +0200:

> Hi Alexander,
> 
> alex.aring@gmail.com wrote on Wed, 6 Apr 2022 17:43:30 -0400:
> 
> > Hi,
> > 
> > On Wed, Apr 6, 2022 at 11:34 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > >
> > > A few drivers do the full transmit operation asynchronously, which means
> > > that a bus error that happens when forwarding the packet 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
> > > the queue and return a generic TRAC error code: IEEE802154_SYSTEM_ERROR.
> > >
> > > Suggested-by: Alexander Aring <alex.aring@gmail.com>
> > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > ---
> > >  include/net/mac802154.h |  9 +++++++++
> > >  net/mac802154/util.c    | 10 ++++++++++
> > >  2 files changed, 19 insertions(+)
> > >
> > > diff --git a/include/net/mac802154.h b/include/net/mac802154.h
> > > index abbe88dc9df5..5240d94aad8e 100644
> > > --- a/include/net/mac802154.h
> > > +++ b/include/net/mac802154.h
> > > @@ -498,6 +498,15 @@ void ieee802154_stop_queue(struct ieee802154_hw *hw);
> > >  void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff *skb,
> > >                               bool ifs_handling);
> > >
> > > +/**
> > > + * ieee802154_xmit_bus_error - frame could not be delivered to the trasmitter
> > > + *                             because of a bus error
> > > + *
> > > + * @hw: pointer as obtained from ieee802154_alloc_hw().
> > > + * @skb: buffer for transmission
> > > + */
> > > +void ieee802154_xmit_bus_error(struct ieee802154_hw *hw, struct sk_buff *skb);
> > > +
> > >  /**
> > >   * ieee802154_xmit_error - frame transmission failed
> > >   *
> > > diff --git a/net/mac802154/util.c b/net/mac802154/util.c
> > > index ec523335336c..79ba803c40c9 100644
> > > --- a/net/mac802154/util.c
> > > +++ b/net/mac802154/util.c
> > > @@ -102,6 +102,16 @@ void ieee802154_xmit_error(struct ieee802154_hw *hw, struct sk_buff *skb,
> > >  }
> > >  EXPORT_SYMBOL(ieee802154_xmit_error);
> > >
> > > +void ieee802154_xmit_bus_error(struct ieee802154_hw *hw, struct sk_buff *skb)
> > > +{
> > > +       struct ieee802154_local *local = hw_to_local(hw);
> > > +
> > > +       local->tx_result = IEEE802154_SYSTEM_ERROR;
> > > +       ieee802154_wake_queue(hw);
> > > +       dev_kfree_skb_any(skb);
> > > +}
> > > +EXPORT_SYMBOL(ieee802154_xmit_bus_error);
> > > +    
> > 
> > why not calling ieee802154_xmit_error(..., IEEE802154_SYSTEM_ERROR) ?
> > Just don't give the user a chance to pick a error code if something
> > bad happened.  
> 
> Oh ok, I assumed, based on your last comment, that you wanted a
> dedicated helper for that, but if just calling xmit_error() with the
> a fixed value is enough I'll drop this commit.

I am re-reading your comment and actually you want this helper, but you
advise to call ieee802154_xmit_error() instead of re-writing its
content, which I agree with. So I will adapt the series in this
direction, hopefully that will match your expectations.

Thanks,
Miquèl

Re: [PATCH v5 06/11] net: ieee802154: at86rf230: Rename the asynchronous error helper

[Alexander Aring]

Hi,

On Thu, Apr 7, 2022 at 4:05 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Alexander,
>
> alex.aring@gmail.com wrote on Wed, 6 Apr 2022 17:57:41 -0400:
>
> > Hi,
> >
> > On Wed, Apr 6, 2022 at 11:34 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > In theory there are two distinct error path:
> > > - The bus error when forwarding a packet to the transceiver fails.
> > > - The transmitter error, after the transmission has been offloaded.
> > >
> > > Right now in this driver only the former situation is properly handled,
> > > so rename the different helpers to reflect this situation before
> > > improving the support of the other path.
> > >
> >
> > I have no idea what I should think about this patch.
> >
> > On the driver layer there only exists "bus errors" okay, whatever
> > error because spi_async() returns an error and we try to recover from
> > it. Also async_error() will be called when there is a timeout because
> > the transceiver took too long for some state change... In this case
> > most often this async_error() is called if spi_async() returns an
> > error but as I said it's not always the case (e.g. timeout)... it is
> > some kind of hardware issue (indicated by 802.15.4 SYSTEM_ERROR for
> > upper layer) and probably if it occurs we can't recover anyway from it
> > (maybe rfkill support can do it, which does a whole transceiver reset
> > routine, but this is always user triggered so far I know).
> >
> > However if you want that patch in that's it's fine for me, but for me
> > this if somebody looks closely into the code it's obvious that in most
> > cases it's called when spi_async() returns an error (which is not
> > always the case see timeout).
>
> I thought it would clarify the situation but I overlooked the timeout
> situation. Actually I did wrote it before understanding what was wrong
> with the patch coming next (I assume my new approach is fine?), and
> the two changes are fully independent, so I'll drop this patch too.
>

new patch is perfect, I like hw_error().

- Alex

Re: [PATCH v5 09/11] net: ieee802154: atusb: Call _xmit_error() when a transmission fails

[Alexander Aring]

Hi,

On Thu, Apr 7, 2022 at 4:06 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Alexander,
>
> alex.aring@gmail.com wrote on Wed, 6 Apr 2022 17:58:59 -0400:
>
> > Hi,
> >
> > On Wed, Apr 6, 2022 at 11:34 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > ieee802154_xmit_error() is the right helper to call when a transmission
> > > has failed. Let's use it instead of open-coding it.
> > >
> > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > ---
> > >  drivers/net/ieee802154/atusb.c | 5 ++---
> > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
> > > index f27a5f535808..d04db4d07a64 100644
> > > --- a/drivers/net/ieee802154/atusb.c
> > > +++ b/drivers/net/ieee802154/atusb.c
> > > @@ -271,9 +271,8 @@ static void atusb_tx_done(struct atusb *atusb, u8 seq)
> > >                  * unlikely case now that seq == expect is then true, but can
> > >                  * happen and fail with a tx_skb = NULL;
> > >                  */
> > > -               ieee802154_wake_queue(atusb->hw);
> > > -               if (atusb->tx_skb)
> > > -                       dev_kfree_skb_irq(atusb->tx_skb);
> > > +               ieee802154_xmit_error(atusb->hw, atusb->tx_skb,
> > > +                                     IEEE802154_SYSTEM_ERROR);
> >
> > That should then call the xmit_error for ANY other reason which is not
> > 802.15.4 specific which is the bus_error() function?
>
> I'll drop the bus error function so we can stick to a regular
> _xmit_error() call.
>

Okay, this error is only hardware related.

> Besides, we do not have any trac information nor any easy access to
> what failed exactly, so it's probably best anyway.

This is correct, Somebody needs to write support for it for atusb firmware. [0]
However some transceivers can't yet or will never (because lack of
functionality?) report such errors back... they will act a little bit
weird.

However, this return value is a BIG step moving into the right
direction that other drivers can follow.

I think for MLME ops we can definitely handle some transmit errors now
and retry so that we don't wait for anything when we know the
transceiver was never submitting.

- Alex

[0] http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/atusb/fw

Re: [PATCH v5 09/11] net: ieee802154: atusb: Call _xmit_error() when a transmission fails

[Alexander Aring]

Hi,

On Mon, Apr 25, 2022 at 8:35 AM Alexander Aring <alex.aring@gmail.com> wrote:
>
> Hi,
>
> On Thu, Apr 7, 2022 at 4:06 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Alexander,
> >
> > alex.aring@gmail.com wrote on Wed, 6 Apr 2022 17:58:59 -0400:
> >
> > > Hi,
> > >
> > > On Wed, Apr 6, 2022 at 11:34 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > ieee802154_xmit_error() is the right helper to call when a transmission
> > > > has failed. Let's use it instead of open-coding it.
> > > >
> > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > ---
> > > >  drivers/net/ieee802154/atusb.c | 5 ++---
> > > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
> > > > index f27a5f535808..d04db4d07a64 100644
> > > > --- a/drivers/net/ieee802154/atusb.c
> > > > +++ b/drivers/net/ieee802154/atusb.c
> > > > @@ -271,9 +271,8 @@ static void atusb_tx_done(struct atusb *atusb, u8 seq)
> > > >                  * unlikely case now that seq == expect is then true, but can
> > > >                  * happen and fail with a tx_skb = NULL;
> > > >                  */
> > > > -               ieee802154_wake_queue(atusb->hw);
> > > > -               if (atusb->tx_skb)
> > > > -                       dev_kfree_skb_irq(atusb->tx_skb);
> > > > +               ieee802154_xmit_error(atusb->hw, atusb->tx_skb,
> > > > +                                     IEEE802154_SYSTEM_ERROR);
> > >
> > > That should then call the xmit_error for ANY other reason which is not
> > > 802.15.4 specific which is the bus_error() function?
> >
> > I'll drop the bus error function so we can stick to a regular
> > _xmit_error() call.
> >
>
> Okay, this error is only hardware related.
>
> > Besides, we do not have any trac information nor any easy access to
> > what failed exactly, so it's probably best anyway.
>
> This is correct, Somebody needs to write support for it for atusb firmware. [0]
> However some transceivers can't yet or will never (because lack of
> functionality?) report such errors back... they will act a little bit
> weird.
>
> However, this return value is a BIG step moving into the right
> direction that other drivers can follow.
>
> I think for MLME ops we can definitely handle some transmit errors now
> and retry so that we don't wait for anything when we know the
> transceiver was never submitting.
>

s/submitting/transmitted/

I could more deeper into that topic:

1.

In my opinion this result value was especially necessary for MLME-ops,
for others which do not directly work with MAC... they provide an
upper layer protocol if they want something reliable.

2.

Later on we can do statistics like what was already going around in
the linux-wpan community to have something like whatever dump to see
all neighbors and see how many ack failures there, etc. Some people
want to make some predictions about link quality here. The kernel
should therefore only capture some stats and the $WHATEVER userspace
capable netlink monitor daemon should make some heuristic by dumping
those stats.

3.

Sometimes even IP capable protocols (using 6LoWPAN) want to know if
ack was received or not, as mentioned. But this required additional
handling in the socket layers... I didn't look into that topic yet but
I know wireless solved it because they have some similar problems.

- Alex

Re: [PATCH v5 09/11] net: ieee802154: atusb: Call _xmit_error() when a transmission fails

[Miquel Raynal]

Hi Alexander,

alex.aring@gmail.com wrote on Mon, 25 Apr 2022 09:05:49 -0400:

> Hi,
> 
> On Mon, Apr 25, 2022 at 8:35 AM Alexander Aring <alex.aring@gmail.com> wrote:
> >
> > Hi,
> >
> > On Thu, Apr 7, 2022 at 4:06 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > >
> > > Hi Alexander,
> > >
> > > alex.aring@gmail.com wrote on Wed, 6 Apr 2022 17:58:59 -0400:
> > >  
> > > > Hi,
> > > >
> > > > On Wed, Apr 6, 2022 at 11:34 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > > >
> > > > > ieee802154_xmit_error() is the right helper to call when a transmission
> > > > > has failed. Let's use it instead of open-coding it.
> > > > >
> > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > ---
> > > > >  drivers/net/ieee802154/atusb.c | 5 ++---
> > > > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
> > > > > index f27a5f535808..d04db4d07a64 100644
> > > > > --- a/drivers/net/ieee802154/atusb.c
> > > > > +++ b/drivers/net/ieee802154/atusb.c
> > > > > @@ -271,9 +271,8 @@ static void atusb_tx_done(struct atusb *atusb, u8 seq)
> > > > >                  * unlikely case now that seq == expect is then true, but can
> > > > >                  * happen and fail with a tx_skb = NULL;
> > > > >                  */
> > > > > -               ieee802154_wake_queue(atusb->hw);
> > > > > -               if (atusb->tx_skb)
> > > > > -                       dev_kfree_skb_irq(atusb->tx_skb);
> > > > > +               ieee802154_xmit_error(atusb->hw, atusb->tx_skb,
> > > > > +                                     IEEE802154_SYSTEM_ERROR);  
> > > >
> > > > That should then call the xmit_error for ANY other reason which is not
> > > > 802.15.4 specific which is the bus_error() function?  
> > >
> > > I'll drop the bus error function so we can stick to a regular
> > > _xmit_error() call.
> > >  
> >
> > Okay, this error is only hardware related.
> >  
> > > Besides, we do not have any trac information nor any easy access to
> > > what failed exactly, so it's probably best anyway.  
> >
> > This is correct, Somebody needs to write support for it for atusb firmware. [0]
> > However some transceivers can't yet or will never (because lack of
> > functionality?) report such errors back... they will act a little bit
> > weird.
> >
> > However, this return value is a BIG step moving into the right
> > direction that other drivers can follow.
> >
> > I think for MLME ops we can definitely handle some transmit errors now
> > and retry so that we don't wait for anything when we know the
> > transceiver was never submitting.
> >  
> 
> s/submitting/transmitted/
> 
> I could more deeper into that topic:
> 
> 1.
> 
> In my opinion this result value was especially necessary for MLME-ops,
> for others which do not directly work with MAC... they provide an
> upper layer protocol if they want something reliable.
> 
> 2.
> 
> Later on we can do statistics like what was already going around in
> the linux-wpan community to have something like whatever dump to see
> all neighbors and see how many ack failures there, etc. Some people
> want to make some predictions about link quality here. The kernel
> should therefore only capture some stats and the $WHATEVER userspace
> capable netlink monitor daemon should make some heuristic by dumping
> those stats.

I like the idea of having a per-device dump of the stats. It would be
really straightforward to implement with the current scan
implementation that I am about to share. We already have a per PAN
structure (with information like ID, channel, last time it was seen,
strength, etc). We might improve this structure with counters for all
the common mac errors. Maybe an option to the "pans dump" command
(again, in the pipe) might be a good start to get all the stats, like
"pans dump [stats]". I'll keep this in mind.

> 3.
> 
> Sometimes even IP capable protocols (using 6LoWPAN) want to know if
> ack was received or not, as mentioned. But this required additional
> handling in the socket layers... I didn't look into that topic yet but
> I know wireless solved it because they have some similar problems.

I did not look at the upper layers yet, but that would indeed be a nice
use case of these MAC statuses.

Thanks,
Miquèl

Re: [PATCH v5 09/11] net: ieee802154: atusb: Call _xmit_error() when a transmission fails

[Alexander Aring]

Hi,

On Mon, Apr 25, 2022 at 9:16 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Alexander,
>
> alex.aring@gmail.com wrote on Mon, 25 Apr 2022 09:05:49 -0400:
>
> > Hi,
> >
> > On Mon, Apr 25, 2022 at 8:35 AM Alexander Aring <alex.aring@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > On Thu, Apr 7, 2022 at 4:06 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > Hi Alexander,
> > > >
> > > > alex.aring@gmail.com wrote on Wed, 6 Apr 2022 17:58:59 -0400:
> > > >
> > > > > Hi,
> > > > >
> > > > > On Wed, Apr 6, 2022 at 11:34 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > >
> > > > > > ieee802154_xmit_error() is the right helper to call when a transmission
> > > > > > has failed. Let's use it instead of open-coding it.
> > > > > >
> > > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > > ---
> > > > > >  drivers/net/ieee802154/atusb.c | 5 ++---
> > > > > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
> > > > > > index f27a5f535808..d04db4d07a64 100644
> > > > > > --- a/drivers/net/ieee802154/atusb.c
> > > > > > +++ b/drivers/net/ieee802154/atusb.c
> > > > > > @@ -271,9 +271,8 @@ static void atusb_tx_done(struct atusb *atusb, u8 seq)
> > > > > >                  * unlikely case now that seq == expect is then true, but can
> > > > > >                  * happen and fail with a tx_skb = NULL;
> > > > > >                  */
> > > > > > -               ieee802154_wake_queue(atusb->hw);
> > > > > > -               if (atusb->tx_skb)
> > > > > > -                       dev_kfree_skb_irq(atusb->tx_skb);
> > > > > > +               ieee802154_xmit_error(atusb->hw, atusb->tx_skb,
> > > > > > +                                     IEEE802154_SYSTEM_ERROR);
> > > > >
> > > > > That should then call the xmit_error for ANY other reason which is not
> > > > > 802.15.4 specific which is the bus_error() function?
> > > >
> > > > I'll drop the bus error function so we can stick to a regular
> > > > _xmit_error() call.
> > > >
> > >
> > > Okay, this error is only hardware related.
> > >
> > > > Besides, we do not have any trac information nor any easy access to
> > > > what failed exactly, so it's probably best anyway.
> > >
> > > This is correct, Somebody needs to write support for it for atusb firmware. [0]
> > > However some transceivers can't yet or will never (because lack of
> > > functionality?) report such errors back... they will act a little bit
> > > weird.
> > >
> > > However, this return value is a BIG step moving into the right
> > > direction that other drivers can follow.
> > >
> > > I think for MLME ops we can definitely handle some transmit errors now
> > > and retry so that we don't wait for anything when we know the
> > > transceiver was never submitting.
> > >
> >
> > s/submitting/transmitted/
> >
> > I could more deeper into that topic:
> >
> > 1.
> >
> > In my opinion this result value was especially necessary for MLME-ops,
> > for others which do not directly work with MAC... they provide an
> > upper layer protocol if they want something reliable.
> >
> > 2.
> >
> > Later on we can do statistics like what was already going around in
> > the linux-wpan community to have something like whatever dump to see
> > all neighbors and see how many ack failures there, etc. Some people
> > want to make some predictions about link quality here. The kernel
> > should therefore only capture some stats and the $WHATEVER userspace
> > capable netlink monitor daemon should make some heuristic by dumping
> > those stats.
>
> I like the idea of having a per-device dump of the stats. It would be
> really straightforward to implement with the current scan
> implementation that I am about to share. We already have a per PAN
> structure (with information like ID, channel, last time it was seen,
> strength, etc). We might improve this structure with counters for all
> the common mac errors. Maybe an option to the "pans dump" command
> (again, in the pipe) might be a good start to get all the stats, like
> "pans dump [stats]". I'll keep this in mind.
>

sounds to me like a per pan filtering use case... which can be
implemented in the kernel, but nowadays there might be more generic
ways of filtering out dumps in the kernel (eBPF?). However we need to
talk about this again if there are some patches. But yes there should
be plenty of information about neighbors whichever frame was received
(which also includes transmission case in that way if an ACK was
received or not if ack request bit was set, channel access failures,
etc?). There exists a difference between if we know some address
information (MAC) or it's PHY related like channel access failure.
Most people are interested in per node information (we have address
information).

> > 3.
> >
> > Sometimes even IP capable protocols (using 6LoWPAN) want to know if
> > ack was received or not, as mentioned. But this required additional
> > handling in the socket layers... I didn't look into that topic yet but
> > I know wireless solved it because they have some similar problems.
>
> I did not look at the upper layers yet, but that would indeed be a nice
> use case of these MAC statuses.
>

I am a little bit worried about that, because at some point we run in
fragmentation of IPv6/6LoWPAN, and then one packet gets into several
802.15.4 frames... whereas such information is per frame. If all has
the same result - no problems. There is a special handling needed
which need to be documented well, e.g. I would say if one frame had no
ack back I would say it should report back to user space that no ack
came back... if possible provide detailed information but I think that
isn't easier to get back to user space than just a bit if ack was back
or not.

Again this is something where a socket error queue needs to be involved.

- Alex