From: Oliver Hartkopp <oliver@hartkopp.net>
To: Wolfgang Grandegger <wg@grandegger.com>
Cc: David Miller <davem@davemloft.net>,
Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: [PATCH net-2.6] can: Fix data length code handling in rx path
Date: Sat, 12 Dec 2009 18:37:18 +0100 [thread overview]
Message-ID: <4B23D4CE.30005@hartkopp.net> (raw)
In-Reply-To: <4B23C602.7050302@grandegger.com>
Wolfgang Grandegger wrote:
> Hi Oliver,
>
> Oliver Hartkopp wrote:
>> A valid CAN dataframe can have a data length code (DLC) of 0 .. 8 data bytes.
>>
>> When reading the CAN controllers register the 4-bit value may contain values
>> from 0 .. 15 which may exceed the reserved space in the socket buffer!
>>
>> The ISO 11898-1 Chapter 8.4.2.3 (DLC field) says that register values > 8
>> should be reduced to 8 without any error reporting or frame drop.
>>
>> This patch introduces a new helper macro to cast a given 4-bit data length
>> code (dlc) to __u8 and ensure the DLC value to be max. 8 bytes.
>>
>> The different handlings in the rx path of the CAN netdevice drivers are fixed.
>>
>> Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
>
> Please send you patches inline next time please. For the bfin_can and
> the ems_usb driver your patch now masks the dlc with 0xf. Are you sure
> this is needed or even correct?
Yes. Both needed to be fixed.
The bfin_can has an u16 value which is not reduced to 4-bits before.
The ems_usb driver gets a u8 value via USB urb, which comes from a SJA1000 and
needs the same handling as in the sja1000 driver. There's no guarantee that
the USB adapter handles the values correctly - so masking is appropriate here.
> Also, s/__u8/u8/, please.
can_frame.can_dlc is the target and it is defined as '__u8' in
include/linux/can.h.
As discussed on SocketCAN-ML we agreed the at91_can.c to be the 'correct'
implementation - and that's what i posted here on your request ... :-)
IMO the patch remains 100% correct.
Best regards,
Oliver
next prev parent reply other threads:[~2009-12-13 3:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-12 14:13 [PATCH net-2.6] can: Fix data length code handling in rx path Oliver Hartkopp
[not found] ` <4B23A501.9000208-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
2009-12-12 16:34 ` Wolfgang Grandegger
2009-12-12 17:37 ` Oliver Hartkopp [this message]
2009-12-12 18:06 ` Wolfgang Grandegger
2009-12-12 18:58 ` Oliver Hartkopp
2009-12-12 18:09 ` Wolfgang Grandegger
2009-12-14 3:47 ` David Miller
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=4B23D4CE.30005@hartkopp.net \
--to=oliver@hartkopp.net \
--cc=davem@davemloft.net \
--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 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.