All of lore.kernel.org
 help / color / mirror / Atom feed
* lack of bus-off recovery in slcan driver
@ 2022-02-14 16:46 Ico Glass
  2022-02-14 21:29 ` Marc Kleine-Budde
  0 siblings, 1 reply; 2+ messages in thread
From: Ico Glass @ 2022-02-14 16:46 UTC (permalink / raw)
  To: linux-can

Hello,

One of our customers uses the lawicel CANUSB can interface with the
slcan driver, and we have noticed that in some tests where we introduce
electrical errors to the bus the driver becomes unresponse, being no longer
able to either send or receive any CAN frames. Reattaching the interface
seems to mitigate the error.

The suspicion is that the interface drops into bus-off mode; the serial
protocol documentation of the CAN interface talks about an 'F' command
for querying status bits, but it seems that the slcan driver does not
implement this and has no knowledge of the interface is in a defunct
state.

`ip restart` or `ip restart-ms` both seem to be not implemented for this
driver unfortunately:

   RTNETLINK answers: Operation not supported

Is there a clean programmatic method for detecting and recovering from
error states using the slcan driver? Is this CANUSB interface a good
choice to use in production, or should we consider it "hobby quality"
only?

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: lack of bus-off recovery in slcan driver
  2022-02-14 16:46 lack of bus-off recovery in slcan driver Ico Glass
@ 2022-02-14 21:29 ` Marc Kleine-Budde
  0 siblings, 0 replies; 2+ messages in thread
From: Marc Kleine-Budde @ 2022-02-14 21:29 UTC (permalink / raw)
  To: Ico Glass; +Cc: linux-can

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]

On 14.02.2022 17:46:11, Ico Glass wrote:
> One of our customers uses the lawicel CANUSB can interface with the
> slcan driver, and we have noticed that in some tests where we introduce
> electrical errors to the bus the driver becomes unresponse, being no longer
> able to either send or receive any CAN frames. Reattaching the interface
> seems to mitigate the error.
> 
> The suspicion is that the interface drops into bus-off mode; the serial
> protocol documentation of the CAN interface talks about an 'F' command
> for querying status bits, but it seems that the slcan driver does not
> implement this and has no knowledge of the interface is in a defunct
> state.
> 
> `ip restart` or `ip restart-ms` both seem to be not implemented for this
> driver unfortunately:
> 
>    RTNETLINK answers: Operation not supported
> 
> Is there a clean programmatic method for detecting and recovering from
> error states using the slcan driver? Is this CANUSB interface a good
> choice to use in production, or should we consider it "hobby quality"
> only?

See github for the discussion:

https://github.com/linux-can/can-utils/issues/344

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-02-14 21:29 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-14 16:46 lack of bus-off recovery in slcan driver Ico Glass
2022-02-14 21:29 ` Marc Kleine-Budde

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.