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

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]

Date:   Wed, 6 Apr 2022 17:57:41 -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 v5 06/11] net: ieee802154: at86rf230: Rename the
 asynchronous error helper

Hi,

On Wed, Apr 6, 2022 at 11:34 AM Miquel Raynal <miquel.raynal@...tlin.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