From: Francesco Valla <valla.francesco@gmail.com>
To: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-can@vger.kernel.org
Subject: Re: [PATCH] can: isotp: remove ISO 15675-2 specification version where possible
Date: Fri, 26 Apr 2024 15:02:07 +0200 [thread overview]
Message-ID: <ZiulzzGIM9CXQMY-@fedora> (raw)
In-Reply-To: <20240420194746.4885-1-socketcan@hartkopp.net>
Hello,
just one small observation below. Other that that (FWIW):
Acked-by: Francesco Valla <valla.francesco@gmail.com>
On Sat, Apr 20, 2024 at 09:47:46PM +0200, Oliver Hartkopp wrote:
> With the new ISO 15765-2:2024 release the former documentation and comments
> have to be reworked. This patch removes the ISO specification version/date
> where possible.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
> ---
> include/uapi/linux/can/isotp.h | 2 +-
> net/can/Kconfig | 11 +++++------
> net/can/isotp.c | 11 ++++++-----
> 3 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/include/uapi/linux/can/isotp.h b/include/uapi/linux/can/isotp.h
> index 6cde62371b6f..bd990917f7c4 100644
> --- a/include/uapi/linux/can/isotp.h
> +++ b/include/uapi/linux/can/isotp.h
> @@ -1,10 +1,10 @@
> /* SPDX-License-Identifier: ((GPL-2.0-only WITH Linux-syscall-note) OR BSD-3-Clause) */
> /*
> * linux/can/isotp.h
> *
> - * Definitions for isotp CAN sockets (ISO 15765-2:2016)
> + * Definitions for ISO 15765-2 CAN transport protocol sockets
> *
> * Copyright (c) 2020 Volkswagen Group Electronic Research
> * All rights reserved.
> *
> * Redistribution and use in source and binary forms, with or without
> diff --git a/net/can/Kconfig b/net/can/Kconfig
> index cb56be8e3862..af64a6f76458 100644
> --- a/net/can/Kconfig
> +++ b/net/can/Kconfig
> @@ -54,20 +54,19 @@ config CAN_GW
> by the netlink configuration interface known e.g. from iptables.
>
> source "net/can/j1939/Kconfig"
>
> config CAN_ISOTP
> - tristate "ISO 15765-2:2016 CAN transport protocol"
> + tristate "ISO 15765-2 CAN transport protocol"
> help
> CAN Transport Protocols offer support for segmented Point-to-Point
> communication between CAN nodes via two defined CAN Identifiers.
> + This protocol driver implements segmented data transfers for CAN CC
> + (aka Classical CAN, CAN 2.0B) and CAN FD frame types which were
> + introduced with ISO 15765-2:2016.
ISO 15765-2 also supports CAN2.0A networks, so I'd drop CAN 2.0B here.
> As CAN frames can only transport a small amount of data bytes
> - (max. 8 bytes for 'classic' CAN and max. 64 bytes for CAN FD) this
> + (max. 8 bytes for CAN CC and max. 64 bytes for CAN FD) this
> segmentation is needed to transport longer Protocol Data Units (PDU)
> as needed e.g. for vehicle diagnosis (UDS, ISO 14229) or IP-over-CAN
> traffic.
> - This protocol driver implements data transfers according to
> - ISO 15765-2:2016 for 'classic' CAN and CAN FD frame types.
> - If you want to perform automotive vehicle diagnostic services (UDS),
> - say 'y'.
>
> endif
> diff --git a/net/can/isotp.c b/net/can/isotp.c
> index 25bac0fafc83..16046931542a 100644
> --- a/net/can/isotp.c
> +++ b/net/can/isotp.c
> @@ -70,25 +70,26 @@
> #include <linux/can/isotp.h>
> #include <linux/slab.h>
> #include <net/sock.h>
> #include <net/net_namespace.h>
>
> -MODULE_DESCRIPTION("PF_CAN isotp 15765-2:2016 protocol");
> +MODULE_DESCRIPTION("PF_CAN ISO 15765-2 transport protocol");
> MODULE_LICENSE("Dual BSD/GPL");
> MODULE_AUTHOR("Oliver Hartkopp <socketcan@hartkopp.net>");
> MODULE_ALIAS("can-proto-6");
>
> #define ISOTP_MIN_NAMELEN CAN_REQUIRED_SIZE(struct sockaddr_can, can_addr.tp)
>
> #define SINGLE_MASK(id) (((id) & CAN_EFF_FLAG) ? \
> (CAN_EFF_MASK | CAN_EFF_FLAG | CAN_RTR_FLAG) : \
> (CAN_SFF_MASK | CAN_EFF_FLAG | CAN_RTR_FLAG))
>
> -/* ISO 15765-2:2016 supports more than 4095 byte per ISO PDU as the FF_DL can
> - * take full 32 bit values (4 Gbyte). We would need some good concept to handle
> - * this between user space and kernel space. For now set the static buffer to
> - * something about 8 kbyte to be able to test this new functionality.
> +/* Since ISO 15765-2:2016 the CAN isotp protocol supports more than 4095
> + * byte per ISO PDU as the FF_DL can take full 32 bit values (4 Gbyte).
> + * We would need some good concept to handle this between user space and
> + * kernel space. For now set the static buffer to something about 8 kbyte
> + * to be able to test this new functionality.
> */
> #define DEFAULT_MAX_PDU_SIZE 8300
>
> /* maximum PDU size before ISO 15765-2:2016 extension was 4095 */
> #define MAX_12BIT_PDU_SIZE 4095
> --
> 2.39.2
>
next prev parent reply other threads:[~2024-04-26 13:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-20 19:47 [PATCH] can: isotp: remove ISO 15675-2 specification version where possible Oliver Hartkopp
2024-04-22 5:50 ` Vincent Mailhol
2024-04-22 17:40 ` Oliver Hartkopp
2024-04-23 2:15 ` Vincent Mailhol
2024-04-26 13:02 ` Francesco Valla [this message]
2024-04-29 17:21 ` 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=ZiulzzGIM9CXQMY-@fedora \
--to=valla.francesco@gmail.com \
--cc=linux-can@vger.kernel.org \
--cc=socketcan@hartkopp.net \
/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.