| Message ID | 20221127190244.888414-1-christoph.fritz@hexdev.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | LIN support for Linux | expand |
Hello Christoph, are you already aware of this LIN project that uses the Linux SocketCAN infrastructure and implements the LIN protocol based on a serial tty adaption (which the serial LIN protocol mainly is)? https://github.com/lin-bus IIRC the implementation of the master/slave timings was the biggest challenge and your approach seems to offload this problem to your USB-attached hardware right? Can I assume there will be a similar CAN-controlled programming interface to create real time master/slave protocol frames like in a usual CAN/LIN adapter (e.g. https://www.peak-system.com/PCAN-LIN.213.0.html) ?? Best regards, Oliver On 27.11.22 20:02, Christoph Fritz wrote: > The intention of this series is to kick off a discussion about how to > support LIN (ISO 17987) [0] in Linux. > > This series consist of two patches which are two individual proposals > for adding LIN abstraction into the kernel. > > One approach is to add LIN ontop of CANFD: > [RFC] can: introduce LIN abstraction > > The other approach is adding a new type of CAN-socket: > [RFC] can: Add LIN proto skeleton > > These patches are abstracting LIN so that actual device drivers can > make use of it. > > For reference, the LIN-ontop-of-CANFD variant already has a device > driver using it (not part of this series). It is a specially built USB > LIN-BUS adapter hardware called hexLIN [1]. Its purpose is mainly to > test, adapt and discuss different LIN APIs for mainline Linux kernel. > But it can already be used productively as a Linux LIN node in > controller (master) and responder (slave) mode. By sysfs, hexLIN > supports different checksum calculations and setting up a > responder-table. > > For more info about hexLIN, see link below [1]. > > We are looking for partners with Linux based LIN projects for funding. > > [0]: https://en.wikipedia.org/wiki/Local_Interconnect_Network > [1]: https://hexdev.de/hexlin/ > > Christoph Fritz (1): > [RFC] can: Introduce LIN bus as CANFD abstraction > > Richard Weinberger (1): > [RFC] can: Add LIN proto skeleton > > drivers/net/can/Kconfig | 10 ++ > drivers/net/can/Makefile | 1 + > drivers/net/can/lin.c | 181 +++++++++++++++++++++++++++ > include/net/lin.h | 30 +++++ > include/uapi/linux/can.h | 8 +- > include/uapi/linux/can/lin.h | 15 +++ > include/uapi/linux/can/netlink.h | 1 + > net/can/Kconfig | 5 + > net/can/Makefile | 3 + > net/can/lin.c | 207 +++++++++++++++++++++++++++++++ > 10 files changed, 460 insertions(+), 1 deletion(-) > create mode 100644 drivers/net/can/lin.c > create mode 100644 include/net/lin.h > create mode 100644 include/uapi/linux/can/lin.h > create mode 100644 net/can/lin.c >
Hello Oliver > are you already aware of this LIN project that uses the Linux SocketCAN > infrastructure and implements the LIN protocol based on a serial tty > adaption (which the serial LIN protocol mainly is)? > > https://github.com/lin-bus Sure, that's why I initially added Pavel Pisa to the recipients of this RFC patch series. When there is an internal kernel API for LIN, his sllin (tty-line-discipline driver for LIN) could be adjusted and finally go mainline. Adding LIN only as a tty-line-discipline does not fit all the currently available hardware. Another argument against a tty-line-discipline only approach as a LIN-API is, that there is no off the shelf standard computer UART with LIN-break-detection (necessary to meet timing constraints), so it always needs specially crafted hardware like USB adapters or PCIe-cards. For the handful of specialized embedded UARTs with LIN-break-detection I guess it could make more sense to go the RS485-kind-of-path and integrate LIN support into the tty-driver while not using a tty-line-discipline there at all. > IIRC the implementation of the master/slave timings was the biggest Currently sllin only supports master mode, I guess because of the tight timing constraints. > challenge and your approach seems to offload this problem to your > USB-attached hardware right? The hexLIN USB adapter processes slave mode answer table on its own, just to meet timing constraints. For master mode, it is currently not offloaded (but could be if really necessary). The amount of offloading (if any at all) is totally up to the device and its device-driver (the entity actually processing data). So sllin does not do offloading but can only work in relaxed timing constrained environments. An UART with built in LIN-break-detection (there are a few) might be able to fully meet timing constraints without offloading (as well as e.g. a PCIe card). > Can I assume there will be a similar CAN-controlled programming interface to > create real time master/slave protocol frames like in a usual CAN/LIN > adapter (e.g. https://www.peak-system.com/PCAN-LIN.213.0.html) ?? I already did some tests letting hexLIN and PCAN talk to each other in a real time manner. Please see my preliminary PDF docu at https://hexdev.de/hexlin/ Thanks -- Christoph
Hello Christoph and Oliver, On Monday 28 of November 2022 11:16:05 Christoph Fritz wrote: > > are you already aware of this LIN project that uses the Linux SocketCAN > > infrastructure and implements the LIN protocol based on a serial tty > > adaption (which the serial LIN protocol mainly is)? > > > > https://github.com/lin-bus > > Sure, that's why I initially added Pavel Pisa to the recipients of this > RFC patch series. When there is an internal kernel API for LIN, his > sllin (tty-line-discipline driver for LIN) could be adjusted and finally > go mainline. Some layer common for UART based and dedicated LIN hardware would be usesfull. The main think to decide is if the solution encoding LIN interface control into CAN messages is the right one and how the encoding should work. Actual mapping keeps LIN and CAN data 1:1 and puts control into identifier and flags. It has advantage that common SocketCAN infrastructure can be used. There is disadvantage that in the case of real CAN to LIN gateway connected to CAN bus almost whole identifiers range is occupied by gateway control. If the response table control and LIN identifier is part of the data field then I can imagine, that more real gateway devices can be be connected to the single CAN bus. But if there is not standard followed by all such gateways producers then it is not of much help. So probably actual mechanism is reasonable. > Adding LIN only as a tty-line-discipline does not fit all the currently > available hardware. Another argument against a tty-line-discipline only > approach as a LIN-API is, that there is no off the shelf standard > computer UART with LIN-break-detection (necessary to meet timing > constraints), so it always needs specially crafted hardware like USB > adapters or PCIe-cards. Break is not so big problem, slave side baudate automatic setup is and then control of Rx FIFO depth and if not possible then its switchinch off which needs generic UART level API longterm https://github.com/lin-bus/linux-lin/issues/13 > For the handful of specialized embedded UARTs with LIN-break-detection I > guess it could make more sense to go the RS485-kind-of-path and > integrate LIN support into the tty-driver while not using a > tty-line-discipline there at all. The state automata is required and its implementation in userspace complicates the design and would result in higher latencies (memory context switch etc.) but may be not so critical for 19200 baud or similar. Kernel with RT preempt support is quite capable and for master side there is time when driver does not lost Rx characters. > > IIRC the implementation of the master/slave timings was the biggest > > Currently sllin only supports master mode, I guess because of the tight > timing constraints. On the UART with FIFO control, there is no problem with response latency on moderately loaded fully preemptive kernel and slLIN supports both modes. I see as the main problem for actual integration of both modes to select acceptable names for standard defined entities "master node" and "slave task". May it be "coordinator", "initiator" and "responder" or "target".... Probably N_SLLIN and N_SLLIN_SLAVE are unacceptable today... > > challenge and your approach seems to offload this problem to your > > USB-attached hardware right? > > The hexLIN USB adapter processes slave mode answer table on its own, > just to meet timing constraints. For master mode, it is currently not > offloaded (but could be if really necessary). Yes, for USB the responses uploading to device is a must and API has to count with it. > The amount of offloading (if any at all) is totally up to the device and > its device-driver (the entity actually processing data). So sllin does > not do offloading but can only work in relaxed timing constrained > environments. > An UART with built in LIN-break-detection (there are a few) might be > able to fully meet timing constraints without offloading (as well as > e.g. a PCIe card). In theory request/response loop up to RT user space task but keeping in the kernel is better and less error prone to applications errors. > > Can I assume there will be a similar CAN-controlled programming interface > > to create real time master/slave protocol frames like in a usual CAN/LIN > > adapter (e.g. https://www.peak-system.com/PCAN-LIN.213.0.html) ?? > > I already did some tests letting hexLIN and PCAN talk to each other in a > real time manner. Please see my preliminary PDF docu at > https://hexdev.de/hexlin/ Best wishes, Pavel Pisa phone: +420 603531357 e-mail: pisa@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/ personal: http://cmp.felk.cvut.cz/~pisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ RISC-V education: https://comparch.edu.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
All, On Mon, Nov 28, 2022 at 10:09 AM Pavel Pisa <pisa@cmp.felk.cvut.cz> wrote: > > Hello Christoph and Oliver, > > On Monday 28 of November 2022 11:16:05 Christoph Fritz wrote: > > > are you already aware of this LIN project that uses the Linux SocketCAN > > > infrastructure and implements the LIN protocol based on a serial tty > > > adaption (which the serial LIN protocol mainly is)? > > > > > > https://github.com/lin-bus > > > > Sure, that's why I initially added Pavel Pisa to the recipients of this > > RFC patch series. When there is an internal kernel API for LIN, his > > sllin (tty-line-discipline driver for LIN) could be adjusted and finally > > go mainline. > > Some layer common for UART based and dedicated LIN hardware would > be usesfull. The main think to decide is if the solution encoding > LIN interface control into CAN messages is the right one and how > the encoding should work. Actual mapping keeps LIN and CAN data > 1:1 and puts control into identifier and flags. It has advantage > that common SocketCAN infrastructure can be used. There is disadvantage > that in the case of real CAN to LIN gateway connected to CAN bus > almost whole identifiers range is occupied by gateway control. > If the response table control and LIN identifier is part of the data > field then I can imagine, that more real gateway devices can be > be connected to the single CAN bus. But if there is not standard > followed by all such gateways producers then it is not of much help. > So probably actual mechanism is reasonable. > > > Adding LIN only as a tty-line-discipline does not fit all the currently > > available hardware. Another argument against a tty-line-discipline only > > approach as a LIN-API is, that there is no off the shelf standard > > computer UART with LIN-break-detection (necessary to meet timing > > constraints), so it always needs specially crafted hardware like USB > > adapters or PCIe-cards. > > Break is not so big problem, slave side baudate automatic setup > is and then control of Rx FIFO depth and if not possible then its > switchinch off which needs generic UART level API longterm > > https://github.com/lin-bus/linux-lin/issues/13 > > > For the handful of specialized embedded UARTs with LIN-break-detection I > > guess it could make more sense to go the RS485-kind-of-path and > > integrate LIN support into the tty-driver while not using a > > tty-line-discipline there at all. > > The state automata is required and its implementation in userspace > complicates the design and would result in higher latencies > (memory context switch etc.) but may be not so critical for 19200 baud > or similar. Kernel with RT preempt support is quite capable and for > master side there is time when driver does not lost Rx characters. > > > > IIRC the implementation of the master/slave timings was the biggest > > > > Currently sllin only supports master mode, I guess because of the tight > > timing constraints. > > On the UART with FIFO control, there is no problem with response > latency on moderately loaded fully preemptive kernel and slLIN > supports both modes. > > I see as the main problem for actual integration of both modes > to select acceptable names for standard defined entities "master node" > and "slave task". May it be "coordinator", "initiator" and "responder" > or "target".... Probably N_SLLIN and N_SLLIN_SLAVE are unacceptable > today... > > > > challenge and your approach seems to offload this problem to your > > > USB-attached hardware right? > > > > The hexLIN USB adapter processes slave mode answer table on its own, > > just to meet timing constraints. For master mode, it is currently not > > offloaded (but could be if really necessary). > > Yes, for USB the responses uploading to device is a must and API has > to count with it. > > > The amount of offloading (if any at all) is totally up to the device and > > its device-driver (the entity actually processing data). So sllin does > > not do offloading but can only work in relaxed timing constrained > > environments. > > An UART with built in LIN-break-detection (there are a few) might be > > able to fully meet timing constraints without offloading (as well as > > e.g. a PCIe card). > > In theory request/response loop up to RT user space task but keeping in > the kernel is better and less error prone to applications errors. > > > > Can I assume there will be a similar CAN-controlled programming interface > > > to create real time master/slave protocol frames like in a usual CAN/LIN > > > adapter (e.g. https://www.peak-system.com/PCAN-LIN.213.0.html) ?? > > > > I already did some tests letting hexLIN and PCAN talk to each other in a > > real time manner. Please see my preliminary PDF docu at > > https://hexdev.de/hexlin/ Marc gave me a heads on on this discussion and I have some insight. I've spent quite a bit of time trying to craft a solution for the LIN problem. Even with a TTY solution the best I was able to achieve was 40ms turnaround between the header and response which exceeded the timeout of the master. This was in userspace and I assume that a kernel solution would better be able to meet the timing but this solution would only work for devices with embedded UART. I did create a solution that uses the gs_usb driver using "pseduo" CAN frames that currently supports slave and monitor mode. I had no use cases for master mode up to this point so it has not yet been implemented. The framework is there if it needs to be added. The README contains the HOWTO on usage of the driver. Right now it's a hack but could be better designed using message flags or a seperate CAN channel. In my design the device contains a slave response table which is configured via CAN frames via socketcan. Currently up to 10 master frames can be responded to. It also allows the LIN node to be put into monitor mode and gate those messages to the host via a CAN message. https://github.com/ryedwards/budgetcan_fw Thanks, --Ryan
Hello Ryan, On Monday 28 of November 2022 18:02:04 Ryan Edwards wrote: > On Mon, Nov 28, 2022 at 10:09 AM Pavel Pisa <pisa@cmp.felk.cvut.cz> wrote: ... > > > I already did some tests letting hexLIN and PCAN talk to each other in > > > a real time manner. Please see my preliminary PDF docu at > > > https://hexdev.de/hexlin/ > > Marc gave me a heads on on this discussion and I have some insight. > > I've spent quite a bit of time trying to craft a solution for the LIN > problem. Even with a TTY solution the best I was able to achieve was > 40ms turnaround between the header and response which exceeded the > timeout of the master. This is indication of some serious problem. We have been able to achieve right timing even from userspace on PC 10 years ago when RT task priorities are used and mlock all even on standard kernel... Yes under load that could be a problem but on RT kernel and in kernel slLIN driver it was reliable even on relatively slow MPC5200. See FIGURE 3: Master: MPC5200 with slLIN; Slave: MPC5200 with slLIN of our comprehensive RTLWS 20212 UART-based LIN-bus Support for Linux with SocketCAN Interface article. For the complete protocol designed on basis of Oliver's proposal and then our finalization see complete report for VolkWagen. The timing is shown there as well Figure 5.2: Master: MPC5200 with sllin; Slave: MPC5200 with sllin https://github.com/lin-bus/linux-lin/wiki The problem with typical UARTs is then when they have enabled FIFO then drivers select trigger level higher than one and sometimes even minimal level is 1/4 of Rx FIFO depth. Then when trigger level is not reached the Rx interrupt waits for eventual more characters to come for (typically) 3 character times. So this is a problem. Because of 1/4 FIFO minimal threshold for 16C450+ UARTs, it is only solution to achieve right slave/response function to switch off the FIFO, there some internal API for that but not exposed o drivers. For 16V450, there is option echo 1 >/sys/class/tty/ttyS0/rx_trig_bytes See https://github.com/lin-bus/linux-lin/issues/13 > This was in userspace and I assume that a > kernel solution would better be able to meet the timing but this > solution would only work for devices with embedded UART. Yes, and on fully preemptive it is not problem. We run control loops in userpace at 5 kHz on Xilinx Zynq systems and used up to 30 kHz on PC for mainboard without MSI issues. So this seems that problems are in programing area. We have achieved correct slLIN functionality on more embedded systems, AM335x, MPC5200 etc. But it required to check UART driver and found how to set Rx trigger level to 1 or disable FIFO. Often by nasty parch. But most hardware could provide knob to tune required parameters. Some RFC for the proposed API there https://marc.info/?l=linux-serial&m=164259988122122&w=2 int (*rx_trigger)(struct uart_port *, int mode, int *rx_trigger_bytes, int *rx_trigger_iddle_time) I think that all/the most of the UART HW I have seen can adjust what necessary, in the worst case by switching FIFO off in UART_RX_TRIGGER_MODE_CHECK_ROUND_DOWN mode. > I did create a solution that uses the gs_usb driver using "pseduo" CAN > frames that currently supports slave and monitor mode. I had no use > cases for master mode up to this point so it has not yet been > implemented. The framework is there if it needs to be added. The set of frames has been defined in slLIN 10 years ago and there is even defined control for LIN 1.0 and 2.0 check sum selection for individual IDs. I do not insist that our design is the best mapping but try to compare it to yours and describe advantages that the best decision can be made for futire. > The README contains the HOWTO on usage of the driver. Right now it's > a hack but could be better designed using message flags or a seperate > CAN channel. > > In my design the device contains a slave response table which is > configured via CAN frames via socketcan. Currently up to 10 master > frames can be responded to. I think that even on embedded HW it is not problem to keep data for all 64 LIN IDs. So I would not complicate thing with some mapping etc. We have reused already present BCM (SocketCAN Broadcast Manager) to periodically send LIN headers. > It also allows the LIN node to be put > into monitor mode and gate those messages to the host via a CAN > message. > > https://github.com/ryedwards/budgetcan_fw Great, version connected over USB with local response table is more reliable with timing than software solution on big(err) complex system like Linux kernel is. So if the well defined open protocol is designed or some CAN USB devices one is reused for LIN than it is advantage. I would be happy if the project moves forward. The critical is some settlement on unified API. Please, compare and map functionality between our solution and your proposal and we can discuss what worth to keep or change. slLIN solution seems to be used in more project not only that two for Volkswagen and Digiteq Automotive, I have directly participated. Best wishes, Pavel Pisa phone: +420 603531357 e-mail: pisa@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/ personal: http://cmp.felk.cvut.cz/~pisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ RISC-V education: https://comparch.edu.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
Hello Pavel, On Mon, Nov 28, 2022 at 12:52 PM Pavel Pisa <pisa@cmp.felk.cvut.cz> wrote: > > Hello Ryan, > > On Monday 28 of November 2022 18:02:04 Ryan Edwards wrote: > > On Mon, Nov 28, 2022 at 10:09 AM Pavel Pisa <pisa@cmp.felk.cvut.cz> wrote: > > Marc gave me a heads on on this discussion and I have some insight. > > > > I've spent quite a bit of time trying to craft a solution for the LIN > > problem. Even with a TTY solution the best I was able to achieve was > > 40ms turnaround between the header and response which exceeded the > > timeout of the master. > > This is indication of some serious problem. We have been able to > achieve right timing even from userspace on PC 10 years ago > when RT task priorities are used and mlock all even on standard kernel... > Yes under load that could be a problem but on RT kernel and in kernel > slLIN driver it was reliable even on relatively slow MPC5200. > > See FIGURE 3: Master: MPC5200 with slLIN; Slave: MPC5200 with slLIN > of our comprehensive RTLWS 20212 UART-based LIN-bus Support for Linux > with SocketCAN Interface article. For the complete protocol designed > on basis of Oliver's proposal and then our finalization see complete > report for VolkWagen. The timing is shown there as well > Figure 5.2: Master: MPC5200 with sllin; Slave: MPC5200 with sllin > > https://github.com/lin-bus/linux-lin/wiki > > The problem with typical UARTs is then when they have enabled FIFO > then drivers select trigger level higher than one and sometimes > even minimal level is 1/4 of Rx FIFO depth. Then when trigger > level is not reached the Rx interrupt waits for eventual > more characters to come for (typically) 3 character times. > So this is a problem. Because of 1/4 FIFO minimal threshold > for 16C450+ UARTs, it is only solution to achieve right slave/response > function to switch off the FIFO, there some internal API for that > but not exposed o drivers. For 16V450, there is option > > echo 1 >/sys/class/tty/ttyS0/rx_trig_bytes > > See https://github.com/lin-bus/linux-lin/issues/13 This test was done 2-3 years ago on a RaspberryPi. I was testing as a slave and had a hard time responding to the master any faster than 40ms. I assume based on the work that you've done that I must have not been accessing the TTY correctly. Wish I would have found the work already done on linux-lin. Would have saved me some time and headaches. > > The README contains the HOWTO on usage of the driver. Right now it's > > a hack but could be better designed using message flags or a seperate > > CAN channel. > > > > In my design the device contains a slave response table which is > > configured via CAN frames via socketcan. Currently up to 10 master > > frames can be responded to. > > I think that even on embedded HW it is not problem to keep > data for all 64 LIN IDs. So I would not complicate thing with some mapping > etc. We have reused already present BCM (SocketCAN Broadcast Manager) > to periodically send LIN headers. > > > It also allows the LIN node to be put > > into monitor mode and gate those messages to the host via a CAN > > message. > > > > https://github.com/ryedwards/budgetcan_fw > > Great, version connected over USB with local response table > is more reliable with timing than software solution on big(err) > complex system like Linux kernel is. So if the well defined > open protocol is designed or some CAN USB devices one is reused > for LIN than it is advantage. > > I would be happy if the project moves forward. The critical is > some settlement on unified API. Please, compare and map functionality > between our solution and your proposal and we can discuss what > worth to keep or change. slLIN solution seems to be used in more > project not only that two for Volkswagen and Digiteq Automotive, > I have directly participated. > I think that what I have built is a high level embedded solution. The fundamental code is the same as it was developed from the state diagram in the LIN specification. I understand now that this project is to build on and implement the work already done on slLIN. I'll review the slLIN driver and see if there is any input I can provide based on the work I've done in my code. I'd be very interested if the driver could be implemented in a way that easily allows for dynamic slave repsonses. Thanks, --Ryan
Thanks for all the participation and feedback. Here is my attempt at a
summary of what we have discussed so far:
- Common goal: A solid LIN UAPI and API
- LIN fits CAN well and could be embedded into Linux CAN infrastructure
- LIN support cannot be a tty-line-discipline driver for all devices
out there
- slLIN should become a user of this API
- slLIN itself needs some more options in the line-discipline
configuraion (to tweak UART FIFO settings and e.g. enable
LIN-break-detection for supported UARTs) _or_ tty-LIN support
becomes something more like RS485 and get integrated into
tty-drivers directly.
- LIN devices with off loading capabilities are a bit special.
- one approach is to have a kfifo for the slavetable (64 entries a 8
bytes + checksum and some extra flags for some LIN special cases)
while updating it from userland through CAN or a simple sysfs
interface
- when we agree that "dumb" UARTs have no need for an
in-kernel-off-load slavetable (because of RT-Linux), then there
are only devices left (e.g. some USB adapters) maintaining their
own table, so a simple e.g. sysfs update mechanism would be
enough (without the need for an in-kernel kfifo buffer).
- LIN slavetable might need another name
- LIN needs rx, tx, set bitrate, set checksum variant and maybe update
a slavetable (or whatever it is called then...)
What do you think? Any objections, corrections, enhancements?
My question is: Which approach of an API is favored: Patch 1 or 2 of
this RFC series or something completely different?
Thanks
-- Christoph
> - LIN devices with off loading capabilities are a bit special.
For networking in general, we try very hard to make offload to
hardware not special at all. It should just transparently work.
One example of this is Ethernet switches which Linux controls. The
ports of the switch are just normal Linux interfaces. You can put an
IP address onto the ports in the normal way, you can add a port to a
linux bridge in the normal way. If the switch can perform bridging in
hardware, the linux bridge will offload it to the hardware. But for
the user, its just a port added to a bridge, nothing special. And
there are a lot more examples like this.
I don't know CAN at all, but please try to avoid doing anything
special for hardware offload. We don't want one way for software, and
then 42 different ways for 42 different offload engines. Just one uAPI
which works for everything.
Andrew
Hi Christoph, all, On 28.11.22 11:16, Christoph Fritz wrote: >> IIRC the implementation of the master/slave timings was the biggest > > Currently sllin only supports master mode, I guess because of the tight > timing constraints. I think this has to be corrected. In the master mode the SocketCAN Broadcast Manager (BCM) is configured to periodically send LIN headers (according to LIN schedule table). https://www.kernel.org/doc/html/latest/networking/can.html#broadcast-manager-protocol-sockets-sock-dgram This is a very easy approach to precisely send the the LIN frames from kernel space and also atomically change the content of (all) the configured LIN frames while the schedule table is continuously processed. Sending LIN frames directly from *userspace* (and handling timers there) was *never* intended for real LIN communication - although the examples (with cangen) in the document look like this. Same applies to the slave mode: If you check out https://raw.githubusercontent.com/wiki/lin-bus/linux-lin/sllin-doc.pdf on page 11 you are able to enable the slave mode with insmod ./sllin.ko master=0 The 'trick' about this mode is that the RTR-functionality of the BCM is able process the incoming CAN/LIN identifier and *instantly* send back some pre-defined data for that specific LIN-ID, so that the SLLIN driver sends/answers the 'data' section of the received LIN-ID within the required timing constrains for LIN slaves. Not sure if the info about this concept got lost somehow, but the CAN_BCM is the key for handling the LIN protocol and offload the LIN scheduling (master/slave) to the kernel for the comparably dumb tty interfaces. Best regards, Oliver