netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Marek Vasut <marex@denx.de>
Cc: Aleksander Morgado <aleksander@aleksander.es>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	Vostrikov Andrey <andrey.vostrikov@cogentembedded.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Wolfgang Grandegger <wg@grandegger.com>,
	Andrew Lunn <andrew@lunn.ch>
Subject: Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack
Date: Tue, 03 Nov 2015 20:28:43 +0100	[thread overview]
Message-ID: <56390AEB.3000909@hartkopp.net> (raw)
In-Reply-To: <201511032019.29236.marex@denx.de>



On 11/03/2015 08:19 PM, Marek Vasut wrote:
> On Tuesday, November 03, 2015 at 07:03:26 PM, Oliver Hartkopp wrote:
>> On 11/03/2015 06:41 PM, Marek Vasut wrote:
>>> On Tuesday, November 03, 2015 at 06:32:12 PM, Oliver Hartkopp wrote:
>>>
>>> [...]
>>>
>>>> It looks like you need to shift the stuff in user space every time.
>>>>
>>>> So you might better think of something like this:
>>>>     struct a429_frame {
>>>>     
>>>>             __u32   label;   /* ARINC 429 label */
>>>>             __u8    length;  /* always set to 8 */
>>>>             __u8    __pad;   /* padding */
>>>>             __u8    __res0;  /* reserved / padding */
>>>>             __u8    __res1;  /* reserved / padding */
>>>>             __u32   data __attribute__((aligned(8)));
>>>>             __u8    p;       /* p */
>>>>             __u8    ssm;     /* ssm */
>>>>             __u8    sdi;     /* sdi */
>>>>             __u8    __end;   /* padding */
>>>>     
>>>>     };
>>>
>>> You don't want to interpret those P(arity)/SSM/SDI bits, since they
>>> differ depending on whatever the remote party sends. That's why I
>>> decided to just make those into 3-bytes of data and let the userland
>>> application deal with it as seen fit. Besides, the ARINC "FTP" really
>>> uses those 3 bytes as plain data.
>>
>> Ok. I did not know what P was for :-)
> 
> Oh yeah. P is parity and it's optional as well and can be odd/even depending
> on the remote endpoint (sigh).
> 
>> Btw. it can make sense to introduce an union struct where different options
>> to access the content are possible.
> 
> This would be pretty nasty I think. By reading the ARINC specification, the
> SSM can be either 2 or 3 bits, the SDI is who-knows-what depending on the
> remote endpoint and the P is also not always present. I'm not convinced that
> the kernel should interpret the 3 byte ARINC payload in any way. (but I wonder
> if my argument presented above is convincing at all either ...).

Right.

When we define a user visible data structure, this is written into stone.

When ARINC isn't even sure about the detailed interpretation we should
definitely keep our fingers away from doing it ourselves.

Best regards,
Oliver

  reply	other threads:[~2015-11-03 19:29 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-01 23:16 [RFC][PATCH] net: arinc429: Add ARINC-429 stack Marek Vasut
2015-11-02  9:47 ` Marc Kleine-Budde
2015-11-02 11:14   ` Oliver Hartkopp
2015-11-02 18:16     ` Marek Vasut
2015-11-02 20:15       ` Vostrikov Andrey
2015-11-02 20:25         ` Marek Vasut
2015-11-03 10:36           ` Aleksander Morgado
2015-11-03 11:36             ` Marc Kleine-Budde
2015-11-03 15:06               ` Aleksander Morgado
2015-11-03 15:15                 ` Marc Kleine-Budde
2015-11-03 16:10                   ` Aleksander Morgado
2015-11-03 17:32                     ` Oliver Hartkopp
2015-11-03 17:41                       ` Marek Vasut
2015-11-03 18:03                         ` Oliver Hartkopp
2015-11-03 19:19                           ` Marek Vasut
2015-11-03 19:28                             ` Oliver Hartkopp [this message]
2015-11-03 21:43                               ` Marek Vasut
2015-11-04  9:34                                 ` Aleksander Morgado
2015-11-04 13:54                                   ` Marek Vasut
2015-11-04 15:03                                     ` Vostrikov Andrey
2015-11-04 15:07                                       ` Marek Vasut
2015-11-04 15:18                                         ` Vostrikov Andrey
2015-11-04 15:19                                           ` Aleksander Morgado
2015-11-04 15:33                                             ` Marek Vasut
2015-11-04 15:45                                               ` Aleksander Morgado
2015-11-10 16:15                                                 ` Marek Vasut
2015-11-18 16:38                                                   ` Aleksander Morgado
2015-11-18 16:41                                                     ` Marek Vasut
2015-11-03 20:26                       ` Vostrikov Andrey
2015-11-03 21:24                         ` Oliver Hartkopp
2015-11-03 21:41                           ` Marek Vasut
2015-11-04 10:44                             ` Oliver Hartkopp
2015-11-03 21:52                           ` Vostrikov Andrey
2015-11-03 15:19                 ` Marek Vasut
2015-11-03 16:18                   ` Aleksander Morgado
2015-11-03 16:56                     ` Aleksander Morgado
2015-11-03 17:33                       ` Marek Vasut
2015-11-03 20:15                         ` Vostrikov Andrey
2015-11-04  9:31                         ` Aleksander Morgado
2015-11-03 16:47                   ` Aleksander Morgado
2015-11-03 17:37                     ` Marek Vasut
2015-11-03 17:01             ` Oliver Hartkopp
2015-11-04  9:51               ` Aleksander Morgado
2015-11-03 21:44       ` Marek Vasut
2015-11-02 19:41     ` Aleksander Morgado
2015-11-02 19:55       ` Oliver Hartkopp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56390AEB.3000909@hartkopp.net \
    --to=socketcan@hartkopp.net \
    --cc=aleksander@aleksander.es \
    --cc=andrew@lunn.ch \
    --cc=andrey.vostrikov@cogentembedded.com \
    --cc=davem@davemloft.net \
    --cc=marex@denx.de \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=wg@grandegger.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).