[RFC] K-Line protocol via SocketCAN

[RFC] K-Line protocol via SocketCAN

[Marek Vasut]

Hi!

My task now is implementing ISO9141-2 (K-Line) protocol [1] support for
mainline Linux. The protocol is quite simple, very close to standard
UART communication with a few details added to it (see below). In fact,
the K-Line tools often use UART with RX/TX lines tied together to talk
to K-Line devices. The differences from standard UART protocol are:

1) When negotiating the communication, one has to send special fixed
   pattern over the line. The pattern and it's speed should be
   configurable. By default, it's pattern 0x33 at 5Bd/s for K-Line,
   0x8f 0xf9 for KWP2000 protocol.
2) After the initial fixed pattern, line switches to 10400 Bd/s ,
   though the speed must be configurable due to some obscure K-Line
   extensions which run at 250kBd/s.
3) Inter-byte delay must be configurable.
4) The driver must allow configuring RX suppression (since the RX/TX
   lines are tied together, every transmitted byte will be received,
   which should be filtered away).
5) Error reporting should be available
6) Timestamping should be available

I was discussing the implementation internally and also revisited my
(failed) attempt to add arinc429 support to Linux. The idea boiled down
to the following:

I) Since the communication is often done via standard UART with RX/TX
   lines tied together, we could use TTY line discipline to handle the
   K-Line protocol specialties on the UART side.
II) Since the protocol uses rudimentary addressing, there is 1 byte of
    receiving address and 1 byte of transmitter address in each frame,
    it would make sense to support it via socketcan stack. This would
    make the driver very similar to slcan.c .
III) Since we need to configure multiple baudrates of the link, the echo
     suppression and the inter-byte delay, it would make sense to use
     rtnetlink for the configuration. This would need to borrow bits
     from drivers/net/can/dev.c .

To achieve the above, I think I would have to factor out common code
from drivers/net/can/dev.c and extend the netlink interface there with
a few new K-Line specific options to allow me to cater for the baudrate
setup.

I would then be able to register this K-Line device as a standard can
netdevice. I would likely use the .ndo_open() to send the link start
sequence 1).

I would also need some sort of sl_klined.c, similar to slcand.c in
can-utils, in userspace to configure the kline tty device.

Does it make sense to plug this K-Line support into the socketcan,
possibly by making socketcan more universal? What do you think ?

I believe I should be able to get RX and TX timestamps from socketcan,
is that correct ?

One thing which worries me is the rtnetlink. I will need to change the
K-Line linkspeed exactly after transmitting some K-Line data via the
socket and before transmitting more data. How can I assure that the
change done via the rtnetlink happens exactly after the first batch of
data were transmitted over the socket and before the next batch ?

Another option would be to possibly extend the linux tty interface
to allow the inter-byte delay, timestamping and error counting. I
don't like this option, it doesn't feel right.

I will also need to add support for the LIN protocol and SENT protocol
further down the line. I will also likely revisit the Arinc at some
point afterward. So I would like to know how to deal with this protocol
mess.

[1] https://en.wikipedia.org/wiki/On-board_diagnostics

Thanks!
-- 
Best regards,
Marek Vasut

Re: [RFC] K-Line protocol via SocketCAN

[Mirza Krak]

2016-05-20 1:15 GMT+02:00 Marek Vasut <marex@denx.de>:
> I will also need to add support for the LIN protocol and SENT protocol
> further down the line. I will also likely revisit the Arinc at some
> point afterward. So I would like to know how to deal with this protocol
> mess.

FYI, there has been a similar LIN project for quite a while [1]. You
might have seen it earlier?

[1]. http://rtime.felk.cvut.cz/gitweb/linux-lin.git

-- 
Med Vänliga Hälsningar / Best Regards

*******************************************************************
Mirza Krak
Host Mobility AB
mirza.krak@hostmobility.com
Anders Personsgatan 12, 416 64 Göteborg
Sweden
http://www.hostmobility.com
Direct: +46 31 31 32 704
Phone: +46 31 31 32 700
Fax: +46 31 80 67 51
Mobile: +46 730 28 06 22
*******************************************************************

Re: [RFC] K-Line protocol via SocketCAN

[Oliver Hartkopp]

Hi,

I removed Dave Miller from the discussion not to be tagged as SPAM :-)
That's not Daves focus as networking maintainer ...

Here's an update about the LIN Status from Pavel Pisa:

http://marc.info/?l=linux-can&m=146163127517268&w=2

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.

What would be the advantages to put this into kernel space (or into the 
CAN networking infrastructure)?

Regards,
Oliver


On 05/20/2016 08:04 AM, Mirza Krak wrote:
> 2016-05-20 1:15 GMT+02:00 Marek Vasut <marex@denx.de>:
>> I will also need to add support for the LIN protocol and SENT protocol
>> further down the line. I will also likely revisit the Arinc at some
>> point afterward. So I would like to know how to deal with this protocol
>> mess.
>
> FYI, there has been a similar LIN project for quite a while [1]. You
> might have seen it earlier?
>
> [1]. http://rtime.felk.cvut.cz/gitweb/linux-lin.git
>

Re: [RFC] K-Line protocol via SocketCAN

[Marek Vasut]

On 05/20/2016 08:28 AM, Oliver Hartkopp wrote:
> Hi,

Hi!

> 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.

Cheers!

> Regards,
> Oliver
> 
> 
> On 05/20/2016 08:04 AM, Mirza Krak wrote:
>> 2016-05-20 1:15 GMT+02:00 Marek Vasut <marex@denx.de>:
>>> I will also need to add support for the LIN protocol and SENT protocol
>>> further down the line. I will also likely revisit the Arinc at some
>>> point afterward. So I would like to know how to deal with this protocol
>>> mess.
>>
>> FYI, there has been a similar LIN project for quite a while [1]. You
>> might have seen it earlier?
>>
>> [1]. http://rtime.felk.cvut.cz/gitweb/linux-lin.git
>>


-- 
Best regards,
Marek Vasut

Re: [RFC] K-Line protocol via SocketCAN

[Patrick Menschel]

[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]

>> 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.
> 

Hello Marek,

Afaik there is no ECU left that actually needs the "5 Baud INIT".
Most ECUs use the "FAST INIT" procedure, means 25ms low, 25ms high, then
start communication with 10400Baud.

The nasty part are the 25ms low, 25ms high , that is also prior to the 5
Baud Init pattern.

After that, everything on the K-Line is pure serial communication.

I've done a few test myself with an FT232RL based KKL-Interface and
these 25ms low, 25ms high are very hard to realize. No Success at my end.

From my point of view, the 25ms low, 25ms high are the only reason to
move into kernel space and possibly switch the Tx Pin to GPIO and pull
it low/high for 25ms, then switch it back to UART.

Regards,
Patrick



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3709 bytes --]

Re: [RFC] K-Line protocol via SocketCAN

[Marek Vasut]

On 05/22/2016 10:27 PM, Patrick Menschel wrote:
>>> 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.
>>
> 
> Hello Marek,

Hi!

> Afaik there is no ECU left that actually needs the "5 Baud INIT".
> Most ECUs use the "FAST INIT" procedure, means 25ms low, 25ms high, then
> start communication with 10400Baud.

We really do need to support both the slow and fast mode.

> The nasty part are the 25ms low, 25ms high , that is also prior to the 5
> Baud Init pattern.
> 
> After that, everything on the K-Line is pure serial communication.

True

> I've done a few test myself with an FT232RL based KKL-Interface and
> these 25ms low, 25ms high are very hard to realize. No Success at my end.

I wouldn't be surprised if the USB added a lot of non-determinism into
the timing. I use standard 16550 compatible UART core mapped in the CPU
address space.

> From my point of view, the 25ms low, 25ms high are the only reason to
> move into kernel space and possibly switch the Tx Pin to GPIO and pull
> it low/high for 25ms, then switch it back to UART.

That's only part of it, see my previous email in this thread where I
listed some more reasons.

These 25ms low-high might possibly be realized by serial break, no ?

> Regards,
> Patrick
> 
> 


-- 
Best regards,
Marek Vasut

Re: [RFC] K-Line protocol via SocketCAN

[Marek Vasut]

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

Re: [RFC] K-Line protocol via SocketCAN

[Oliver Hartkopp]

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?

>> - 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?

>> 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?

>> - 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?

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

If I would think about your mentioned requirements and ideas I would 
start with pyOBD http://www.obdtester.com/pyobd and probably move this 
to be a PREEMPT_RT task and I would add an interface to specify 
inter-byte delays into the serial driver infrastructure.

Even when trying to think very positively about your question I don't 
see any conjunction to SocketCAN.

Best regards,
Oliver

Re: [RFC] K-Line protocol via SocketCAN

[Marek Vasut]

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 ?

>>> - 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.

>>> 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 ?

>>> - 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.

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.

>> What do you think about putting the KLine support into socketcan stack ?
> 
> If I would think about your mentioned requirements and ideas I would
> start with pyOBD http://www.obdtester.com/pyobd and probably move this
> to be a PREEMPT_RT task and I would add an interface to specify
> inter-byte delays into the serial driver infrastructure.

The python overhead would be waaaay too much. The reason for putting
this into the kernel is to get better timing control.

> Even when trying to think very positively about your question I don't
> see any conjunction to SocketCAN.
> 
> Best regards,
> Oliver


-- 
Best regards,
Marek Vasut

Re: [RFC] K-Line protocol via SocketCAN

[Oliver Hartkopp]

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?

>
>>>> - 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.

>>>> 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 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?

> 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.

Oliver

Re: [RFC] K-Line protocol via SocketCAN

[Marek Vasut]

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

Re: [RFC] K-Line protocol via SocketCAN

[Oliver Hartkopp]

On 06/09/2016 09:21 PM, Marek Vasut wrote:
> On 06/09/2016 08:29 PM, Oliver Hartkopp wrote:

>>> 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 .

ARINC 825 *is* CAN. When people tell you to use the existing 
infrastructure that was a good hint, but K-Line is definitely not CAN.

Your patch set shows that you are adding things to the CAN 
infrastructure that have nothing to do with CAN.

E.g. the K-Line timing you add in patch 4/5 has nothing to do with CAN 
specific configurations.

Additionally I don't know whether the struct kline_frame is the optimal 
solution because it sticks to struct can_frame and does not reflect the 
(optional) K-Line address scheme.

So you could either use the sl_kline.c with PF_PACKET and create a 
separate rtnl configuration for it OR you could create a character 
device which handles K-Line frames and has some ioctls to configure the 
specialized timings.

As K-Line never was multi-user capable by design the chardev approach is 
the most 'natural' concept IMHO.

Regards,
Oliver

Re: [RFC] K-Line protocol via SocketCAN

[Marek Vasut]

On 06/09/2016 10:12 PM, Oliver Hartkopp wrote:
> On 06/09/2016 09:21 PM, Marek Vasut wrote:
>> On 06/09/2016 08:29 PM, Oliver Hartkopp wrote:
> 
>>>> 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 .
> 
> ARINC 825 *is* CAN. When people tell you to use the existing
> infrastructure that was a good hint, but K-Line is definitely not CAN.

Well, I was talking about arinc 429 .

> Your patch set shows that you are adding things to the CAN
> infrastructure that have nothing to do with CAN.
> 
> E.g. the K-Line timing you add in patch 4/5 has nothing to do with CAN
> specific configurations.
> 
> Additionally I don't know whether the struct kline_frame is the optimal
> solution because it sticks to struct can_frame and does not reflect the
> (optional) K-Line address scheme.
> 
> So you could either use the sl_kline.c with PF_PACKET and create a
> separate rtnl configuration for it OR you could create a character
> device which handles K-Line frames and has some ioctls to configure the
> specialized timings.

Is adding a specialized chardev really such a great idea ?

> As K-Line never was multi-user capable by design the chardev approach is
> the most 'natural' concept IMHO.

I could technically just implement this as a ldisc with some additional
ioctls, but is that really such a good idea ?

> Regards,
> Oliver
> 


-- 
Best regards,
Marek Vasut

Re: [RFC] K-Line protocol via SocketCAN

[Oliver Hartkopp]

Hi Marek,

On 06/11/2016 09:42 PM, Marek Vasut wrote:
> On 06/09/2016 10:12 PM, Oliver Hartkopp wrote:
>> On 06/09/2016 09:21 PM, Marek Vasut wrote:
>>> On 06/09/2016 08:29 PM, Oliver Hartkopp wrote:
>>
>>>>> 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 .
>>
>> ARINC 825 *is* CAN. When people tell you to use the existing
>> infrastructure that was a good hint, but K-Line is definitely not CAN.
>
> Well, I was talking about arinc 429 .
>

Ah - I remember that discussion:
https://lwn.net/Articles/663130/
http://thread.gmane.org/gmane.linux.network/385449

What happed to it?

I don't see anything from the patchset in the kernel.

>> Your patch set shows that you are adding things to the CAN
>> infrastructure that have nothing to do with CAN.
>>
>> E.g. the K-Line timing you add in patch 4/5 has nothing to do with CAN
>> specific configurations.
>>
>> Additionally I don't know whether the struct kline_frame is the optimal
>> solution because it sticks to struct can_frame and does not reflect the
>> (optional) K-Line address scheme.
>>
>> So you could either use the sl_kline.c with PF_PACKET and create a
>> separate rtnl configuration for it OR you could create a character
>> device which handles K-Line frames and has some ioctls to configure the
>> specialized timings.
>
> Is adding a specialized chardev really such a great idea ?
>

Why not?

E.g. think about a chardev in /dev/kline0 which is located in 
linux/drivers/misc and which uses a tty under the hood.

I'm not a K-Line specialist like Mirza who was able to point at timings 
that should be handled in user space and not in kernel space.

But if you implement a chardev driver which allows the configuration of 
these kernel relevant K-Line timings and makes use of the tty layer - 
what should be wrong with this approach?

You would have a single user K-Line interface which can handle specific 
struct kline data. Fine.

>> As K-Line never was multi-user capable by design the chardev approach is
>> the most 'natural' concept IMHO.
>
> I could technically just implement this as a ldisc with some additional
> ioctls, but is that really such a good idea ?

Yes. It would be some kind of ldisc for a K-Line chardev driver (and not 
for a netdevice) like other ldiscs in linux/include/uapi/linux/tty.h

Why do you feel this is not a good idea?

Regards,
Oliver

Re: [RFC] K-Line protocol via SocketCAN

[Marek Vasut]

On 06/12/2016 09:28 PM, Oliver Hartkopp wrote:
> Hi Marek,

Hi!

> On 06/11/2016 09:42 PM, Marek Vasut wrote:
>> On 06/09/2016 10:12 PM, Oliver Hartkopp wrote:
>>> On 06/09/2016 09:21 PM, Marek Vasut wrote:
>>>> On 06/09/2016 08:29 PM, Oliver Hartkopp wrote:
>>>
>>>>>> 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 .
>>>
>>> ARINC 825 *is* CAN. When people tell you to use the existing
>>> infrastructure that was a good hint, but K-Line is definitely not CAN.
>>
>> Well, I was talking about arinc 429 .
>>
> 
> Ah - I remember that discussion:
> https://lwn.net/Articles/663130/
> http://thread.gmane.org/gmane.linux.network/385449
> 
> What happed to it?

Priorities shifted. I still hope to return to it and get it into
mainline proper. Since I did some digging in the socketcan recently,
I have a better understanding of it now too. I believe the agreement
there was to put it into the socketcan stack as an extension, does it
still make sense ?

> I don't see anything from the patchset in the kernel.

Yes, sorry about that. I still keep the last email from that thread in
my todo so it won't get lost.

>>> Your patch set shows that you are adding things to the CAN
>>> infrastructure that have nothing to do with CAN.
>>>
>>> E.g. the K-Line timing you add in patch 4/5 has nothing to do with CAN
>>> specific configurations.
>>>
>>> Additionally I don't know whether the struct kline_frame is the optimal
>>> solution because it sticks to struct can_frame and does not reflect the
>>> (optional) K-Line address scheme.
>>>
>>> So you could either use the sl_kline.c with PF_PACKET and create a
>>> separate rtnl configuration for it OR you could create a character
>>> device which handles K-Line frames and has some ioctls to configure the
>>> specialized timings.
>>
>> Is adding a specialized chardev really such a great idea ?
>>
> 
> Why not?
> 
> E.g. think about a chardev in /dev/kline0 which is located in
> linux/drivers/misc and which uses a tty under the hood.
> 
> I'm not a K-Line specialist like Mirza who was able to point at timings
> that should be handled in user space and not in kernel space.

If I start handling the timings in userspace, I won't be able to get to
the precision I need. That's the reason I'd like to put the kline ldisc
in kernel.

> But if you implement a chardev driver which allows the configuration of
> these kernel relevant K-Line timings and makes use of the tty layer -
> what should be wrong with this approach?
> 
> You would have a single user K-Line interface which can handle specific
> struct kline data. Fine.

Hrm. I was just worried about adding new IOCTLs, but if that's fine, I
will reevaluate using just the ldisc.

>>> As K-Line never was multi-user capable by design the chardev approach is
>>> the most 'natural' concept IMHO.
>>
>> I could technically just implement this as a ldisc with some additional
>> ioctls, but is that really such a good idea ?
> 
> Yes. It would be some kind of ldisc for a K-Line chardev driver (and not
> for a netdevice) like other ldiscs in linux/include/uapi/linux/tty.h
> 
> Why do you feel this is not a good idea?

It feels much better now, so I will poke into that.

Thanks!

> Regards,
> Oliver


-- 
Best regards,
Marek Vasut

Re: [RFC] K-Line protocol via SocketCAN

[Oliver Hartkopp]

>> On 06/11/2016 09:42 PM, Marek Vasut wrote:
>>> Well, I was talking about arinc 429 .
>>>
>>
>> Ah - I remember that discussion:
>> https://lwn.net/Articles/663130/
>> http://thread.gmane.org/gmane.linux.network/385449
>>
>> What happed to it?
>
> Priorities shifted. I still hope to return to it and get it into
> mainline proper. Since I did some digging in the socketcan recently,
> I have a better understanding of it now too. I believe the agreement
> there was to put it into the socketcan stack as an extension, does it
> still make sense ?
>

There were intensive discussions about the original patchset and I think 
the copy&paste hell from the PF_CAN won't make it.

Let's see how the K-Line discussion opens your view :-)

(..)

>> E.g. think about a chardev in /dev/kline0 which is located in
>> linux/drivers/misc and which uses a tty under the hood.
>>
>> I'm not a K-Line specialist like Mirza who was able to point at timings
>> that should be handled in user space and not in kernel space.
>
> If I start handling the timings in userspace, I won't be able to get to
> the precision I need. That's the reason I'd like to put the kline ldisc
> in kernel.
>
>> But if you implement a chardev driver which allows the configuration of
>> these kernel relevant K-Line timings and makes use of the tty layer -
>> what should be wrong with this approach?
>>
>> You would have a single user K-Line interface which can handle specific
>> struct kline data. Fine.
>
> Hrm. I was just worried about adding new IOCTLs, but if that's fine, I
> will reevaluate using just the ldisc.
>

Putting the really necessary timing requirements into the kernel into 
the ldisc need some configuration of that ldisc. AFAIK ldisc specific 
ioctls are the way to configure that kind of details.

So let's see what happens when you post it.

>>>> As K-Line never was multi-user capable by design the chardev approach is
>>>> the most 'natural' concept IMHO.
>>>
>>> I could technically just implement this as a ldisc with some additional
>>> ioctls, but is that really such a good idea ?
>>
>> Yes. It would be some kind of ldisc for a K-Line chardev driver (and not
>> for a netdevice) like other ldiscs in linux/include/uapi/linux/tty.h
>>
>> Why do you feel this is not a good idea?
>
> It feels much better now, so I will poke into that.

Thanks!

Oliver

Re: [RFC] K-Line protocol via SocketCAN

[Marek Vasut]

On 06/14/2016 08:10 AM, Oliver Hartkopp wrote:
> 
>>> On 06/11/2016 09:42 PM, Marek Vasut wrote:
>>>> Well, I was talking about arinc 429 .
>>>>
>>>
>>> Ah - I remember that discussion:
>>> https://lwn.net/Articles/663130/
>>> http://thread.gmane.org/gmane.linux.network/385449
>>>
>>> What happed to it?
>>
>> Priorities shifted. I still hope to return to it and get it into
>> mainline proper. Since I did some digging in the socketcan recently,
>> I have a better understanding of it now too. I believe the agreement
>> there was to put it into the socketcan stack as an extension, does it
>> still make sense ?
>>
> 
> There were intensive discussions about the original patchset and I think
> the copy&paste hell from the PF_CAN won't make it.

Yeah, that's pretty clear to me. But does it make sense to extend
socketcan with that arinc429 stuff instead then ?

> Let's see how the K-Line discussion opens your view :-)

Well it certainly was enlightening.

> (..)
> 
>>> E.g. think about a chardev in /dev/kline0 which is located in
>>> linux/drivers/misc and which uses a tty under the hood.
>>>
>>> I'm not a K-Line specialist like Mirza who was able to point at timings
>>> that should be handled in user space and not in kernel space.
>>
>> If I start handling the timings in userspace, I won't be able to get to
>> the precision I need. That's the reason I'd like to put the kline ldisc
>> in kernel.
>>
>>> But if you implement a chardev driver which allows the configuration of
>>> these kernel relevant K-Line timings and makes use of the tty layer -
>>> what should be wrong with this approach?
>>>
>>> You would have a single user K-Line interface which can handle specific
>>> struct kline data. Fine.
>>
>> Hrm. I was just worried about adding new IOCTLs, but if that's fine, I
>> will reevaluate using just the ldisc.
>>
> 
> Putting the really necessary timing requirements into the kernel into
> the ldisc need some configuration of that ldisc. AFAIK ldisc specific
> ioctls are the way to configure that kind of details.
> 
> So let's see what happens when you post it.

Right.

>>>>> As K-Line never was multi-user capable by design the chardev
>>>>> approach is
>>>>> the most 'natural' concept IMHO.
>>>>
>>>> I could technically just implement this as a ldisc with some additional
>>>> ioctls, but is that really such a good idea ?
>>>
>>> Yes. It would be some kind of ldisc for a K-Line chardev driver (and not
>>> for a netdevice) like other ldiscs in linux/include/uapi/linux/tty.h
>>>
>>> Why do you feel this is not a good idea?
>>
>> It feels much better now, so I will poke into that.
> 
> Thanks!

Thanks!


-- 
Best regards,
Marek Vasut

Re: [RFC] K-Line protocol via SocketCAN

[Oliver Hartkopp]

On 06/15/2016 05:42 AM, Marek Vasut wrote:
> On 06/14/2016 08:10 AM, Oliver Hartkopp wrote:
>>
>>>> On 06/11/2016 09:42 PM, Marek Vasut wrote:
>>>>> Well, I was talking about arinc 429 .
>>>>>
>>>>
>>>> Ah - I remember that discussion:
>>>> https://lwn.net/Articles/663130/
>>>> http://thread.gmane.org/gmane.linux.network/385449
>>>>
>>>> What happed to it?
>>>
>>> Priorities shifted. I still hope to return to it and get it into
>>> mainline proper. Since I did some digging in the socketcan recently,
>>> I have a better understanding of it now too. I believe the agreement
>>> there was to put it into the socketcan stack as an extension, does it
>>> still make sense ?
>>>
>>
>> There were intensive discussions about the original patchset and I think
>> the copy&paste hell from the PF_CAN won't make it.
>
> Yeah, that's pretty clear to me. But does it make sense to extend
> socketcan with that arinc429 stuff instead then ?

You might think into the direction of the SLLIN implementation:

Create a ldisc which smells like a CAN interface.
SLLIN doesn't change SocketCAN either.

Regards,
Oliver

Re: [RFC] K-Line protocol via SocketCAN

[Marek Vasut]

On 06/15/2016 08:57 AM, Oliver Hartkopp wrote:
> On 06/15/2016 05:42 AM, Marek Vasut wrote:
>> On 06/14/2016 08:10 AM, Oliver Hartkopp wrote:
>>>
>>>>> On 06/11/2016 09:42 PM, Marek Vasut wrote:
>>>>>> Well, I was talking about arinc 429 .
>>>>>>
>>>>>
>>>>> Ah - I remember that discussion:
>>>>> https://lwn.net/Articles/663130/
>>>>> http://thread.gmane.org/gmane.linux.network/385449
>>>>>
>>>>> What happed to it?
>>>>
>>>> Priorities shifted. I still hope to return to it and get it into
>>>> mainline proper. Since I did some digging in the socketcan recently,
>>>> I have a better understanding of it now too. I believe the agreement
>>>> there was to put it into the socketcan stack as an extension, does it
>>>> still make sense ?
>>>>
>>>
>>> There were intensive discussions about the original patchset and I think
>>> the copy&paste hell from the PF_CAN won't make it.
>>
>> Yeah, that's pretty clear to me. But does it make sense to extend
>> socketcan with that arinc429 stuff instead then ?
> 
> You might think into the direction of the SLLIN implementation:
> 
> Create a ldisc which smells like a CAN interface.
> SLLIN doesn't change SocketCAN either.

The sllin looks like a hack which abuses the can interface by recycling
various bits instead of extending it properly last time I looked into
the code. I don't think that's an approach I want to follow. Anyway, I
don't think sllin should be mixed into the arinc stuff.

The arinc429 requires it's own dedicated controller(s), usually SPI ones
or such, it would have to be plugged into the can device interface or
somewhere there. Certainly not via ldisc.

-- 
Best regards,
Marek Vasut