Linux CAN drivers development
 help / color / mirror / Atom feed
From: Christoph Fritz <christoph.fritz@hexdev.de>
To: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Pavel Pisa <pisa@cmp.felk.cvut.cz>,
	Richard Weinberger <richard@nod.at>,
	Andreas Lauser <andreas.lauser@mbition.io>,
	Wolfgang Grandegger <wg@grandegger.com>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-can@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 0/2] LIN support for Linux
Date: Mon, 28 Nov 2022 11:16:05 +0100	[thread overview]
Message-ID: <Y4SKZb9woV5XE1bU@mars> (raw)
In-Reply-To: <58a773bd-0db4-bade-f8a2-46e850df9b0b@hartkopp.net>

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

  reply	other threads:[~2022-11-28 10:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-27 19:02 [RFC][PATCH 0/2] LIN support for Linux Christoph Fritz
2022-11-27 19:02 ` [PATCH 1/2] [RFC] can: Introduce LIN bus as CANFD abstraction Christoph Fritz
2022-11-27 19:02 ` [PATCH 2/2] [RFC] can: Add LIN proto skeleton Christoph Fritz
2022-11-28  8:21 ` [RFC][PATCH 0/2] LIN support for Linux Oliver Hartkopp
2022-11-28 10:16   ` Christoph Fritz [this message]
2022-11-28 14:49     ` Pavel Pisa
2022-11-28 17:02       ` Ryan Edwards
2022-11-28 17:52         ` Pavel Pisa
2022-11-28 18:47           ` Ryan Edwards
2022-11-28 21:48             ` Christoph Fritz
2022-11-28 22:47               ` Andrew Lunn
2022-11-30 21:02     ` Oliver Hartkopp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y4SKZb9woV5XE1bU@mars \
    --to=christoph.fritz@hexdev.de \
    --cc=andreas.lauser@mbition.io \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pisa@cmp.felk.cvut.cz \
    --cc=richard@nod.at \
    --cc=socketcan@hartkopp.net \
    --cc=wg@grandegger.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox