From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oliver Hartkopp Subject: Re: [RFC] K-Line protocol via SocketCAN Date: Thu, 9 Jun 2016 22:12:57 +0200 Message-ID: <5759CDC9.2010204@hartkopp.net> References: <573E491E.1000906@denx.de> <573EAE9D.20006@hartkopp.net> <573EFC23.2040906@denx.de> <574E47C8.4000709@denx.de> <575415F5.3070306@hartkopp.net> <57598472.3070207@denx.de> <5759B597.3060009@hartkopp.net> <5759C1D1.1000001@denx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.220]:60881 "EHLO mo4-p00-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750772AbcFIUNJ (ORCPT ); Thu, 9 Jun 2016 16:13:09 -0400 In-Reply-To: <5759C1D1.1000001@denx.de> Sender: linux-can-owner@vger.kernel.org List-ID: To: Marek Vasut , Mirza Krak Cc: "linux-can@vger.kernel.org" , Marc Kleine-Budde , Wolfgang Grandegger 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