Re: [RFC] K-Line protocol via SocketCAN

[Marek Vasut <marex@denx.de>]

On 06/09/2016 08:29 PM, Oliver Hartkopp wrote:
> On 06/09/2016 05:00 PM, Marek Vasut wrote:
>> On 06/05/2016 02:07 PM, Oliver Hartkopp wrote:
>>> On 06/01/2016 04:26 AM, Marek Vasut wrote:
>>>
>>>>>> 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.
>>>
>>> A topic for the serial driver infrastructure?
>>
>> Can you elaborate a bit please ?
> 
> No. If you have requirements for in-time transmission that could no be
> solved in user space, you might add some handler or functionality that
> adds this feature. So where would you add that for a K-Line driver? In
> the video driver infrastructure?

Huh ?

>>>>> - 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.
>>>
>>> Which K-Line infrastructure?
>>
>> The one which would be added to socketcan. The patches don't seem too
>> disruptive in fact.
>>
> 
> Why don't you just post them? I'm pretty tired of these pointless
> discussions exchanging our arguments again and again.

Done

>>>>> And two for using socketcan/network interface:
>>>>> - The addressing support of the network stack can be mapped to K-Line
>>>>>     bus addresses.
>>>
>>> The K-Line addressing is totally different from CAN addressing. Why do
>>> you think the stuff in linux/net/can has any conjunction to K-Line
>>> addressing?
>>
>> Let me just ask what you mean by "totally different" first ?
>>
> 
> CAN Frame: 11/29 bit ID and max 8 or 64 (CAN FD) byte frame length
> KWP2000 Message: (optional!) 8 bit target address 8 bit receiver address
> and 1 .. 255 data bytes
> 
> => totally different!

The capacity for flexible addressing is part of the socketcan apparently .

>>>>> - The rtnl can be used as an extensible interface for configuring the
>>>>>     K-Line parameters.
>>>
>>> The idea of SocketCAN using the Linux networking infrastructure and
>>> network interfaces is the multi-user capability which is enabled through
>>> this layering.
>>>
>>> IIRC K-Line is ONE point-to-point connection which is not multi-user
>>> capable - so what would be the benefit to implement a K-Line serial
>>> driver as network device and then configure it via rtnl?
>>
>> I am more interested in the RTNL configuration interface, since the
>> kline has way too many parameters and the RTNL scales well in that
>> aspect.
> 
> If like rtnl so much why don't you create a K-Line netdevice driver for
> it and use the PF_PACKET socket to exchange data with the netdevice?

Because last time I did that with the arinc, I was told to integrate
that into the socketcan instead.

>> When using the socket interface, I can also add various flags to the
>> packet and control the properties of the data that are to be transmitted
>> via the KLine interface. That's real convenient.
> 
> But that has nothing to do with PF_CAN.

So I should add another orthogonal infrastructure ? That's what I did
with the arinc and I was told the exact opposite, so I am really
confused here .

> Oliver
> 


-- 
Best regards,
Marek Vasut