All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Andri Yngvason <andri.yngvason@marel.com>,
	Oliver Hartkopp <socketcan@hartkopp.net>,
	Wolfgang Grandegger <wg@grandegger.com>
Cc: linux-can@vger.kernel.org
Subject: Re: Inconsistent error state transition error frames
Date: Wed, 10 Sep 2014 12:29:23 +0200	[thread overview]
Message-ID: <54102803.4070404@pengutronix.de> (raw)
In-Reply-To: <541025B5.9070901@marel.com>

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

On 09/10/2014 12:19 PM, Andri Yngvason wrote:
>> diff --git a/include/uapi/linux/can/error.h
>> b/include/uapi/linux/can/error.h
>> index c247446..c290f30 100644
>> --- a/include/uapi/linux/can/error.h
>> +++ b/include/uapi/linux/can/error.h
>> @@ -58,10 +58,12 @@
>>   #define CAN_ERR_RESTARTED    0x00000100U /* controller restarted */
>>     /* arbitration lost in bit ... / data[0] */
>> +#define CAN_ERR_LOSTARB_BYTE 0
>>   #define CAN_ERR_LOSTARB_UNSPEC   0x00 /* unspecified */
>>                         /* else bit number in bitstream */
>>     /* error status of CAN-controller / data[1] */
>> +#define CAN_ERR_CRTL_BYTE 1
>>   #define CAN_ERR_CRTL_UNSPEC      0x00 /* unspecified */
>>   #define CAN_ERR_CRTL_RX_OVERFLOW 0x01 /* RX buffer overflow */
>>   #define CAN_ERR_CRTL_TX_OVERFLOW 0x02 /* TX buffer overflow */
>> @@ -73,6 +75,7 @@
>>                         /* the protocol-defined level of 127)  */
>>     /* error in CAN protocol (type) / data[2] */
>> +#define CAN_ERR_PROT_BYTE 2
>>   #define CAN_ERR_PROT_UNSPEC      0x00 /* unspecified */
>>   #define CAN_ERR_PROT_BIT         0x01 /* single bit error */
>>   #define CAN_ERR_PROT_FORM        0x02 /* frame format error */
>> @@ -84,6 +87,7 @@
>>   #define CAN_ERR_PROT_TX          0x80 /* error occurred on
>> transmission */
>>     /* error in CAN protocol (location) / data[3] */
>> +#define CAN_ERR_PROT_LOC_BYTE 3
>>   #define CAN_ERR_PROT_LOC_UNSPEC  0x00 /* unspecified */
>>   #define CAN_ERR_PROT_LOC_SOF     0x03 /* start of frame */
>>   #define CAN_ERR_PROT_LOC_ID28_21 0x02 /* ID bits 28 - 21 (SFF: 10 -
>> 3) */
>> @@ -106,6 +110,7 @@
>>   #define CAN_ERR_PROT_LOC_INTERM  0x12 /* intermission */
>>     /* error status of CAN-transceiver / data[4] */
>> +#define CAN_ERR_TRX_BYTE 4
>>   /*                                             CANH CANL */
>>   #define CAN_ERR_TRX_UNSPEC             0x00 /* 0000 0000 */
>>   #define CAN_ERR_TRX_CANH_NO_WIRE       0x04 /* 0000 0100 */
>> @@ -118,6 +123,10 @@
>>   #define CAN_ERR_TRX_CANL_SHORT_TO_GND  0x70 /* 0111 0000 */
>>   #define CAN_ERR_TRX_CANL_SHORT_TO_CANH 0x80 /* 1000 0000 */
>>   -/* controller specific additional information / data[5..7] */
>> +/* controller specific additional information / data[5] */
>> +
>> +/* controller error counter values / data[6..7] */
>> +#define CAN_ERR_TXERR_BYTE 6
>> +#define CAN_ERR_RXERR_BYTE 7
>>     #endif /* _UAPI_CAN_ERROR_H */
>>
> I'm not sure what's considered good practice in kernel code but wouldn't
> it be better to use a macro like this instead?
>     #define CAN_ERR_CRTL_DATA(frame) ((frame)->data[1])
> which would be used like this:
>     if(CAN_ERR_CRTL_DATA(frame) & CAN_ERR_CRTL_whatever) ...

I'm not sure....but...

Make it a static inline function and give it a proper name, something
like can_err_frame_get_ctrl(). Maybe without err_....

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2014-09-10 10:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-08 16:26 Inconsistent error state transition error frames Andri Yngvason
2014-09-08 16:36 ` Marc Kleine-Budde
2014-09-09 10:48   ` Wolfgang Grandegger
2014-09-09 11:59     ` Andri Yngvason
2014-09-09 13:53       ` Wolfgang Grandegger
2014-09-09 14:49         ` Andri Yngvason
2014-09-09 15:41           ` Wolfgang Grandegger
2014-09-09 18:08             ` Oliver Hartkopp
2014-09-10 10:19               ` Andri Yngvason
2014-09-10 10:29                 ` Marc Kleine-Budde [this message]
2014-09-10 11:53                   ` Wolfgang Grandegger
2014-09-10 19:08                     ` Oliver Hartkopp
2014-09-11 10:03                       ` Andri Yngvason

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=54102803.4070404@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=andri.yngvason@marel.com \
    --cc=linux-can@vger.kernel.org \
    --cc=socketcan@hartkopp.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.