Hi Marc,

On Fri, Jul 29, 2022 at 9:33 AM Marc Kleine-Budde [off-list ref] wrote:

On 29.07.2022 08:52:07, Dario Binacchi wrote:

quoted

Hello Marc and Max,

On Thu, Jul 28, 2022 at 12:57 PM Max Staudt [off-list ref] wrote:

quoted

On Thu, 28 Jul 2022 12:50:49 +0200
Marc Kleine-Budde [off-list ref] wrote:

quoted

On 28.07.2022 12:23:04, Dario Binacchi wrote:

quoted

quoted

quoted

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 :)).

We're all here to learn something!

quoted

I think it is equally clear that it is not worth going down this path.

If you have a static attached serial devices serdev is the way to go.
But slcan has so many drawbacks compared to "real" CAN adapters that I
hope the no one uses them in such a scenario.

quoted

quoted

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.

From my point of view your job is done!

Ok.

quoted

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?

https://elixir.bootlin.com/linux/latest/source/drivers/net/can/usb/gs_usb.c#L951
https://elixir.bootlin.com/linux/latest/source/drivers/net/can/usb/gs_usb.c#L510

and, as done with patches:

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

You can define a way to query bit timing constants and CAN clock rate,
but you have to get this into the "official" firmware. You have to roll
out a firmware update to all devices. What about non official firmware?

quoted

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.

If an adapter follows 100% the official firmware doc the BTR registers
are interpreted as SJA1000 with 8 MHz CAN clock.

I checked the sources and documentation of the usb adapter I used (i.
e. Https://www.fischl.de/usbtin/):
...
sxxyyzz[CR]                 Set can bitrate registers of MCP2515. You
can set non-standard baudrates which are not supported by the "Sx"
command.
                                     xx: CNF1 as hexadecimal value (00-FF)
                                     yy: CNF2 as hexadecimal value (00-FF)
                                     zz: CNF3 as hexadecimal value
...

Different from what is reported by can232_ver3_Manual.pdf :

sxxyy[CR]         Setup with BTR0/BTR1 CAN bit-rates where xx and yy is a hex
                         value. This command is only active if the CAN

And here is the type of control carried out by the slcan_attach for
the btr parameter:
https://github.com/linux-can/can-utils/blob/master/slcan_attach.c#L144
When I would have expected a different check (i. e. if (strlen(btr) > 4).
Therefore it is possible that each adapter uses these bytes in its own
way as well as
in the content and also in the number of bytes.

Thanks and regards,
Dario

See

| https://lore.kernel.org/all/20220728105049.43gbjuctezxzmm4j@pengutronix.de (local)

where I compare the 125 Kbit/s BTR config of the documentation with the
bit timing calculated by the kernel algorithm.

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 |

-- 

Dario Binacchi

Embedded Linux Developer

dario.binacchi@amarulasolutions.com

__________________________________


Amarula Solutions SRL

Via Le Canevare 30, 31100 Treviso, Veneto, IT

T. +39 042 243 5310
info@amarulasolutions.com

www.amarulasolutions.com