netdev - Re: [PATCH wpan-next v3 07/11] net: ieee802154: at86rf230: Provide meaningful error codes when possible

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAB_54W5f87H2umyRsjAZ--x_BiN8D7taG4BnyEXx1EWQyQSyBA@mail.gmail.com>
Date:   Sun, 13 Mar 2022 16:16:45 -0400
From:   Alexander Aring <alex.aring@...il.com>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     Stefan Schmidt <stefan@...enfreihafen.org>,
        linux-wpan - ML <linux-wpan@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        David Girault <david.girault@...vo.com>,
        Romuald Despres <romuald.despres@...vo.com>,
        Frederic Blain <frederic.blain@...vo.com>,
        Nicolas Schodet <nico@...fr.eu.org>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH wpan-next v3 07/11] net: ieee802154: at86rf230: Provide
 meaningful error codes when possible

Hi,

On Thu, Mar 3, 2022 at 1:25 PM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
>
> Either the spi operation failed, or the device encountered an error. In
> both case, we know more or less what happened thanks to the spi call
> return code or the content of the TRAC register otherwise. Use them in
> order to propagate one step above the error.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com>
> ---
>  drivers/net/ieee802154/at86rf230.c | 25 +++++++++++++++++++++++--
>  1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c
> index 12ee071057d2..5f19266b3045 100644
> --- a/drivers/net/ieee802154/at86rf230.c
> +++ b/drivers/net/ieee802154/at86rf230.c
> @@ -370,7 +370,27 @@ static inline void
>  at86rf230_async_error(struct at86rf230_local *lp,
>                       struct at86rf230_state_change *ctx, int rc)
>  {
> -       dev_err(&lp->spi->dev, "spi_async error %d\n", rc);
> +       int reason;
> +
> +       switch (rc) {
> +       case TRAC_CHANNEL_ACCESS_FAILURE:
> +               reason = IEEE802154_CHANNEL_ACCESS_FAILURE;
> +               break;
> +       case TRAC_NO_ACK:
> +               reason = IEEE802154_NO_ACK;
> +               break;
> +       case TRAC_INVALID:
> +               reason = IEEE802154_SYSTEM_ERROR;
> +               break;
> +       default:
> +               reason = rc;
> +       }
> +

Actually the rc value here is not a TRAC status register value... and
it should not be one.

The reason is because this function can also be called during a non-tx
state change failure whereas the trac register is only valid when the
transmission "is successfully offloaded to device" and delivers us an
error of the transmission operation on the device. It is called during
the tx case only if there was a "state transition error" and then it
should report IEEE802154_SYSTEM_ERROR in
at86rf230_async_error_recover_complete(). Whereas I think we can use
IEEE802154_SYSTEM_ERROR as a non-specific 802.15.4 error code, because
a bus error of a state transition is not 802.15.4 specific.

- Alex