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:   Fri, 29 Jul 2022 08:52:07 +0200
From:   Dario Binacchi <>
To:     Max Staudt <>, Marc Kleine-Budde <>
        Oliver Hartkopp <>,,
        Amarula patchwork <>,
        Jeroen Hofstee <>,
        "David S. Miller" <>,
        Eric Dumazet <>,
        Jakub Kicinski <>,
        Paolo Abeni <>,
        Wolfgang Grandegger <>,
Subject: Re: [RFC PATCH v3 8/9] can: slcan: add support to set bit time
 register (btr)

Hello Marc and Max,

On Thu, Jul 28, 2022 at 12:57 PM Max Staudt <> wrote:
> On Thu, 28 Jul 2022 12:50:49 +0200
> Marc Kleine-Budde <> wrote:
> > On 28.07.2022 12:23:04, Dario Binacchi wrote:
> > > > > Does it make sense to use the device tree
> > > >
> > > > The driver doesn't support DT and DT only works for static serial
> > > > interfaces.
> >
> > Have you seen my remarks about Device Tree?
> Dario, there seems to be a misunderstanding about the Device Tree.
> It is used *only* for hardware that is permanently attached, present at
> boot, and forever after. Not for dyamically added stuff, and definitely
> not for ldiscs that have to be attached manually by the user.
> The only exception to this is if you have an embedded device with an
> slcan adapter permanently attached to one of its UARTs. Then you can
> use the serdev ldisc adapter to attach the ldisc automatically at boot.

It is evident that I am lacking some skills (I will try to fix it :)).
I think it is
equally clear that it is not worth going down this path.

> If you are actively developing for such a use case, please let us know,
> so we know what you're after and can help you better :)

I don't have a use case, other than to try, if possible, to make the driver
autonomous from slcand / slcan_attach for the CAN bus setup.

Returning to Marc's previous analysis:
"... Some USB CAN drivers query the bit timing const from the USB device."

Can we think of taking the gs_usb driver as inspiration for getting/setting the
bit timings?

and, as done with patches:

can: slcan: extend the protocol with CAN state info
can: slcan: extend the protocol with error info

further extend the protocol to get/set the bit timing from / to the adapter ?
In the case of non-standard bit rates, the driver would try, depending on the
firmware of the adapter, to calculate and set the bit timings autonomously.

Thanks and regards,

> Max


Dario Binacchi

Embedded Linux Developer


Amarula Solutions SRL

Via Le Canevare 30, 31100 Treviso, Veneto, IT

T. +39 042 243 5310

Powered by blists - more mailing lists