Re: [RFC][PATCH 0/2] LIN support for Linux

[Christoph Fritz <christoph.fritz@hexdev.de>]

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