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