mbox series

[v6,00/10] ieee802154: Better Tx error handling

Message ID 20220407100903.1695973-1-miquel.raynal@bootlin.com (mailing list archive)
Headers show
Series ieee802154: Better Tx error handling | expand

Message

Miquel Raynal April 7, 2022, 10:08 a.m. UTC
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 v6:
* Dropped the renaming of the asynchronous error functions in the
  at86rf320 driver to avoid confusions between asynchronous bus errors
  and timeout errors.
* Called the _xmit_error() helper from _xmit_bus_error() to avoid hard
  coding almost the exact same lines.
* Renamed _xmit_bus_error() into _xmit_hw_error() which I think fits
  better the purpose of the helper: we signify a hardware error when
  offloading the frame to the hardware.
* Improved a little bit the kdoc of _xmit_error() to mention that we are
  returning here the errors from successfully offloaded transmissions.
* Called _xmit_hw_error() from atsub.c.

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 order 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 (10):
  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 an offloaded transmission error helper
  net: mac802154: Create an error helper for asynchronous offloading
    errors
  net: ieee802154: at86rf230: Call _xmit_hw_error() when failing to
    offload frames
  net: ieee802154: at86rf230: Forward Tx trac errors
  net: ieee802154: atusb: Call _xmit_hw_error() upon transmission error
  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 | 130 ++++-----------------
 drivers/net/ieee802154/atusb.c     |   4 +-
 drivers/net/ieee802154/ca8210.c    | 181 +++++++++++------------------
 include/linux/ieee802154.h         |  81 +++++++++++--
 include/net/mac802154.h            |  19 +++
 net/mac802154/ieee802154_i.h       |   2 +
 net/mac802154/util.c               |  22 +++-
 8 files changed, 207 insertions(+), 239 deletions(-)

Comments

Alexander Aring April 25, 2022, 12:37 p.m. UTC | #1
Hi,

On Thu, Apr 7, 2022 at 6:09 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> 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.
>

Acked-by: Alexander Aring <aahringo@redhat.com>

Thanks!

- Alex
Stefan Schmidt April 25, 2022, 7:25 p.m. UTC | #2
Hello.

On 25.04.22 14:37, Alexander Aring wrote:
> Hi,
> 
> On Thu, Apr 7, 2022 at 6:09 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>>
>> 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.
>>
> 
> Acked-by: Alexander Aring <aahringo@redhat.com>
> 
> Thanks!


These patches have been applied to the wpan-next tree and will be
part of the next pull request to net-next. Thanks!

regards
Stefan Schmidt