Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1406619pxk; Fri, 2 Oct 2020 08:49:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxWGkUA+fSQnJwQOJG7Yl4jkikm34oDKJveGHFeZd2hOvprxps6FSWF8VOrUcg9A5RuPjGJ X-Received: by 2002:a17:907:2115:: with SMTP id qn21mr2898618ejb.278.1601653797540; Fri, 02 Oct 2020 08:49:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601653797; cv=none; d=google.com; s=arc-20160816; b=sT+oipZ8JzqNQnNH/z0zNF3yKJQDCmRvvgknRO+FhDRelIIHOsa3RbX2Ztq7En557d Bin+RNNEuGCnlJCDmGqjY0qwFDDE17EBkK7VGt3q/ZsrSMfz1hEmrIlhSWSXicAZqenW bWcR5QAKNJ+c0Ffaz9a9akJ7HUaZPVgOIklUer3wDv2VIN5cvSz4T93cQ1zIJ5w4NUWK jsQaskXfVg58fX4XhHBj90cAYHhju0WPC8i6biF/Q4BTumwDYJiMgjOJ8OLVBjvMjW9M fEq5PEhHYI7ooI1gE7y1mbccmxoXgl6wHCy8gKl0dnbWJ3rVGCp1/Bto2UiAyTkehdhy xXcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=nM5jpeN1uMLtrQwSBKVBNJhjHiPfpGTMjgaM8msu0bE=; b=LPIBQPHNMuJuTwWgUZXX2xnSwb9Eb3h04pA5OLuG7ivcNgwjDLky8u2t30ru4noP9U t19Lwb1j5VW395ODLZZ9GI4iaF9jLh5Udsk++19gBqVPO1iSm8M5V2ImKOfd2P29Mgxe 0Xj2QMtQBTcVwjKwxMVRXOJ8+n+yJ+k6m0UuwLipiz1sdI1skGxZXw4R9k2mA4ZR5XBY JkeUROuCGFEJY3zRaiVJXNiIt2zEBZEPaO3aVQ3vtyU0xK8wtkzRkrjLgw21VlPmJL6M O4+/eWJkwDPvHGL9DhYF9XECCIqqhYE2avsrXr1ZZWIO2p0eOOXuKnjmpJcLh+Mj4bvb X8fg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dn25si1276486edb.268.2020.10.02.08.49.33; Fri, 02 Oct 2020 08:49:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388092AbgJBPsR (ORCPT + 99 others); Fri, 2 Oct 2020 11:48:17 -0400 Received: from smtp13.smtpout.orange.fr ([80.12.242.135]:25395 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2387948AbgJBPsM (ORCPT ); Fri, 2 Oct 2020 11:48:12 -0400 Received: from tomoyo.flets-east.jp ([153.230.197.127]) by mwinf5d76 with ME id b3o32300V2lQRaH033o6Y2; Fri, 02 Oct 2020 17:48:11 +0200 X-ME-Helo: tomoyo.flets-east.jp X-ME-Auth: bWFpbGhvbC52aW5jZW50QHdhbmFkb28uZnI= X-ME-Date: Fri, 02 Oct 2020 17:48:11 +0200 X-ME-IP: 153.230.197.127 From: Vincent Mailhol To: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-can@vger.kernel.org, Wolfgang Grandegger , Marc Kleine-Budde , "David S . Miller" Cc: Vincent Mailhol , Jakub Kicinski , Oliver Neukum , Greg Kroah-Hartman , Masahiro Yamada , Arunachalam Santhanam , linux-usb@vger.kernel.org (open list:USB ACM DRIVER) Subject: [PATCH v3 3/7] can: dev: add a helper function to get the correct length of Classical frames Date: Sat, 3 Oct 2020 00:41:47 +0900 Message-Id: <20201002154219.4887-4-mailhol.vincent@wanadoo.fr> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20201002154219.4887-1-mailhol.vincent@wanadoo.fr> References: <20200926175810.278529-1-mailhol.vincent@wanadoo.fr> <20201002154219.4887-1-mailhol.vincent@wanadoo.fr> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- Changes in v3: - Make get_can_len() return u8. - Make the skb const. 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 132b4133f9d0..791c452d98e1 100644 --- a/include/linux/can/dev.h +++ b/include/linux/can/dev.h @@ -177,6 +177,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