[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <58a773bd-0db4-bade-f8a2-46e850df9b0b@hartkopp.net>
Date: Mon, 28 Nov 2022 09:21:44 +0100
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: Christoph Fritz <christoph.fritz@...dev.de>,
Pavel Pisa <pisa@....felk.cvut.cz>,
Richard Weinberger <richard@....at>,
Andreas Lauser <andreas.lauser@...tion.io>,
Wolfgang Grandegger <wg@...ndegger.com>,
Marc Kleine-Budde <mkl@...gutronix.de>,
"David S . Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Jonathan Corbet <corbet@....net>
Cc: linux-can@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 0/2] LIN support for Linux
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
>
Powered by blists - more mailing lists