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]

Message-ID: <20220407100513.4b8378b6@xps13>
Date:   Thu, 7 Apr 2022 10:05:13 +0200
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Alexander Aring <alex.aring@...il.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 Alexander,

alex.aring@...il.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@...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).

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