From: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
To: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-can@vger.kernel.org, Marc Kleine-Budde <mkl@pengutronix.de>,
Wolfgang Grandegger <wg@grandegger.com>
Cc: Arunachalam Santhanam <arunachalam.santhanam@in.bosch.com>,
Vincent Mailhol <mailhol.vincent@wanadoo.fr>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Masahiro Yamada <masahiroy@kernel.org>
Subject: [PATCH v4 2/4] can: dev: add a helper function to get the correct length of Classical frames
Date: Sat, 17 Oct 2020 02:20:23 +0900 [thread overview]
Message-ID: <20201016172053.229281-1-mailhol.vincent@wanadoo.fr> (raw)
In-Reply-To: <20201016171402.229001-1-mailhol.vincent@wanadoo.fr>
In classical CAN, the length of the data (i.e. CAN payload) is not
always equal to the DLC! If the frame is a Remote Transmission Request
(RTR), data length is always zero regardless of DLC value and else, if
the DLC is greater than 8, the length is 8. Contrary to common belief,
ISO 11898-1 Chapter 8.4.2.3 (DLC field) do allow DLCs greater than 8
for Classical Frames and specifies that those DLCs shall indicate that
the data field is 8 bytes long.
Above facts are widely unknown and so many developpers uses the "len"
field of "struct canfd_frame" to get the length of classical CAN
frames: this is incorrect!
This patch introduces function get_can_len() which can be used in
remediation. The function takes the SKB as an input in order to be
able to determine if the frame is classical or FD.
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
---
Changes in v4: None
Changes in v3:
- Make get_can_len() return u8.
- Make the skb const.
Reference: https://lkml.org/lkml/2020/9/30/883
Changes in v2: None
---
include/linux/can/dev.h | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
index 41ff31795320..d90890172d2a 100644
--- a/include/linux/can/dev.h
+++ b/include/linux/can/dev.h
@@ -192,6 +192,29 @@ u8 can_dlc2len(u8 can_dlc);
/* map the sanitized data length to an appropriate data length code */
u8 can_len2dlc(u8 len);
+/*
+ * get_can_len(skb) - get the length of the CAN payload.
+ *
+ * In classical CAN, the length of the data (i.e. CAN payload) is not
+ * always equal to the DLC! If the frame is a Remote Transmission
+ * Request (RTR), data length is always zero regardless of DLC value
+ * and else, if the DLC is greater than 8, the length is 8. Contrary
+ * to common belief, ISO 11898-1 Chapter 8.4.2.3 (DLC field) do allow
+ * DLCs greater than 8 for Classical Frames and specifies that those
+ * DLCs shall indicate that the data field is 8 bytes long.
+ */
+static inline u8 get_can_len(const struct sk_buff *skb)
+{
+ const struct canfd_frame *cf = (const struct canfd_frame *)skb->data;
+
+ if (can_is_canfd_skb(skb))
+ return min_t(u8, cf->len, CANFD_MAX_DLEN);
+ else if (cf->can_id & CAN_RTR_FLAG)
+ return 0;
+ else
+ return min_t(u8, cf->len, CAN_MAX_DLEN);
+}
+
struct net_device *alloc_candev_mqs(int sizeof_priv, unsigned int echo_skb_max,
unsigned int txqs, unsigned int rxqs);
#define alloc_candev(sizeof_priv, echo_skb_max) \
--
2.26.2
next prev parent reply other threads:[~2020-10-16 17:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-16 17:13 [PATCH v4 0/4] can: add support for ETAS ES58X CAN USB Vincent Mailhol
2020-10-16 17:13 ` [PATCH v4 1/4] can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ context Vincent Mailhol
2020-10-16 17:20 ` Vincent Mailhol [this message]
2020-10-16 17:22 ` [PATCH v4 3/4] can: dev: __can_get_echo_skb(): fix the return length Vincent Mailhol
2020-10-16 17:23 ` [PATCH v4 4/4] can: usb: etas_es58X: add support for ETAS ES58X CAN USB interfaces Vincent Mailhol
2020-10-19 18:49 ` [PATCH v4 0/4] can: add support for ETAS ES58X CAN USB Marc Kleine-Budde
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=20201016172053.229281-1-mailhol.vincent@wanadoo.fr \
--to=mailhol.vincent@wanadoo.fr \
--cc=arunachalam.santhanam@in.bosch.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--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).