Re: [RFC] K-Line protocol via SocketCAN

[Marek Vasut <marex@denx.de>]

On 05/20/2016 01:59 PM, Marek Vasut wrote:
> On 05/20/2016 08:28 AM, Oliver Hartkopp wrote:
>> Hi,
> 
> Hi!

Hi again,

>> I removed Dave Miller from the discussion not to be tagged as SPAM :-)
>> That's not Daves focus as networking maintainer ...
> 
> Heh, all right.
> 
>> Here's an update about the LIN Status from Pavel Pisa:
>>
>> http://marc.info/?l=linux-can&m=146163127517268&w=2
> 
> I am aware of the sllin. There is also freediag , which implements kline
> protocol.
> 
>> I remember a K-Line implementation for Linux where we had a MPC5200 UART
>> which we programmed with bit-banging of some control line to do the
>> 5bit/s opening pattern.
>> After that we went to 10400 bit/s and did some K-Line communication.
>> All this was done by a user space application on /dev/ttyS0.
> 
> Yes, and this does make perfect sense until you start dealing with
> faster modes and need more precise timing. The K-Line is limited by
> 250kBaud/s bus speed.
> 
>> What would be the advantages to put this into kernel space (or into the
>> CAN networking infrastructure)?
> 
> I see two for putting this into the kernel:
> - At faster bus speeds, you can achieve more precise timing if this is
>   in the kernel, both of the inter-byte delay and also for the
>   timestamps. Having this in the kernel even allows usage of the
>   realtime extensions if needed.
> - Dedicated hardware driver can plug into such K-Line infrastructure.
>   Such hardware might be needed to support the faster modes to further
>   increase the timing precision.
> 
> And two for using socketcan/network interface:
> - The addressing support of the network stack can be mapped to K-Line
>   bus addresses.
> - The rtnl can be used as an extensible interface for configuring the
>   K-Line parameters.

What do you think about putting the KLine support into socketcan stack ?

-- 
Best regards,
Marek Vasut