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
--
2.30.2
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: [email protected]
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 <[email protected]> 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 <[email protected]> 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: [email protected]
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 <[email protected]> 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 <[email protected]> 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