netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: netdev@vger.kernel.org, davem@davemloft.net,
	linux-can@vger.kernel.org, kernel@pengutronix.de,
	Oliver Hartkopp <socketcan@hartkopp.net>
Subject: Re: [PATCH 08/17] can: add ISO 15765-2:2016 transport protocol
Date: Fri, 9 Oct 2020 17:57:51 -0700	[thread overview]
Message-ID: <20201009175751.5c54097f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <20201007213159.1959308-9-mkl@pengutronix.de>

On Wed,  7 Oct 2020 23:31:50 +0200 Marc Kleine-Budde wrote:
> From: Oliver Hartkopp <socketcan@hartkopp.net>
> 
> CAN Transport Protocols offer support for segmented Point-to-Point
> communication between CAN nodes via two defined CAN Identifiers.
> 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
> segmentation is needed to transport longer PDUs 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.

A few random things jump out here at a quick scan. Most of them are 
not important enough to have to be addressed, but please follow up on
the 'default y' thing ASAP.

> +/*
> + * Remark on CAN_ISOTP_DEFAULT_RECV_* values:
> + *
> + * We can strongly assume, that the Linux Kernel implementation of
> + * CAN_ISOTP is capable to run with BS=0, STmin=0 and WFTmax=0.
> + * But as we like to be able to behave as a commonly available ECU,
> + * these default settings can be changed via sockopts.
> + * For that reason the STmin value is intentionally _not_ checked for
> + * consistency and copied directly into the flow control (FC) frame.
> + *

spurious empty comment line

> + */
> +
> +#endif /* !_UAPI_CAN_ISOTP_H */
> diff --git a/net/can/Kconfig b/net/can/Kconfig
> index 25436a715db3..021fe03a8ed6 100644
> --- a/net/can/Kconfig
> +++ b/net/can/Kconfig
> @@ -55,6 +55,19 @@ config CAN_GW
>  
>  source "net/can/j1939/Kconfig"
>  
> +config CAN_ISOTP
> +	tristate "ISO 15765-2:2016 CAN transport protocol"
> +	default y

default should not be y unless there is a very good reason.
I don't see such reason here. This is new functionality, users
can enable it if they need it.

> +	help
> +	  CAN Transport Protocols offer support for segmented Point-to-Point
> +	  communication between CAN nodes via two defined CAN Identifiers.
> +	  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
> +	  segmentation is needed to transport longer PDUs 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.
> +
>  source "drivers/net/can/Kconfig"
>  
>  endif

> +#define CAN_ISOTP_VERSION "20200928"

We've been removing such version strings throughout the drivers.
Kernel version should be sufficient for in-tree modules.

> +static enum hrtimer_restart isotp_tx_timer_handler(struct hrtimer *hrtimer)
> +{
> +	struct isotp_sock *so = container_of(hrtimer, struct isotp_sock,
> +					     txtimer);
> +	struct sock *sk = &so->sk;
> +	struct sk_buff *skb;
> +	struct net_device *dev;
> +	struct canfd_frame *cf;
> +	enum hrtimer_restart restart = HRTIMER_NORESTART;
> +	int can_send_ret;
> +	int ae = (so->opt.flags & CAN_ISOTP_EXTEND_ADDR) ? 1 : 0;
> +
> +	switch (so->tx.state) {
> +	case ISOTP_WAIT_FC:
> +	case ISOTP_WAIT_FIRST_FC:
> +
> +		/* we did not get any flow control frame in time */
> +
> +		/* report 'communication error on send' */
> +		sk->sk_err = ECOMM;
> +		if (!sock_flag(sk, SOCK_DEAD))
> +			sk->sk_error_report(sk);
> +
> +		/* reset tx state */
> +		so->tx.state = ISOTP_IDLE;
> +		wake_up_interruptible(&so->wait);
> +		break;
> +
> +	case ISOTP_SENDING:
> +
> +		/* push out the next segmented pdu */
> +		dev = dev_get_by_index(sock_net(sk), so->ifindex);
> +		if (!dev)
> +			break;
> +
> +isotp_tx_burst:
> +		skb = alloc_skb(so->ll.mtu + sizeof(struct can_skb_priv),
> +				gfp_any());

This is always in a timer context, so no need for gfp_any(), right?

> +		if (!skb) {
> +			dev_put(dev);
> +			break;
> +		}
> +
> +		can_skb_reserve(skb);
> +		can_skb_prv(skb)->ifindex = dev->ifindex;
> +		can_skb_prv(skb)->skbcnt = 0;
> +
> +		cf = (struct canfd_frame *)skb->data;
> +		skb_put(skb, so->ll.mtu);
> +
> +		/* create consecutive frame */
> +		isotp_fill_dataframe(cf, so, ae, 0);
> +
> +		/* place consecutive frame N_PCI in appropriate index */
> +		cf->data[ae] = N_PCI_CF | so->tx.sn++;
> +		so->tx.sn %= 16;
> +		so->tx.bs++;
> +
> +		if (so->ll.mtu == CANFD_MTU)
> +			cf->flags = so->ll.tx_flags;
> +
> +		skb->dev = dev;
> +		can_skb_set_owner(skb, sk);
> +
> +		can_send_ret = can_send(skb, 1);
> +		if (can_send_ret)
> +			printk_once(KERN_NOTICE "can-isotp: %s: can_send_ret %d\n",
> +				    __func__, can_send_ret);

pr_notice_once()

> +
> +		if (so->tx.idx >= so->tx.len) {
> +			/* we are done */
> +			so->tx.state = ISOTP_IDLE;
> +			dev_put(dev);
> +			wake_up_interruptible(&so->wait);
> +			break;
> +		}
> +
> +		if (so->txfc.bs && so->tx.bs >= so->txfc.bs) {
> +			/* stop and wait for FC */
> +			so->tx.state = ISOTP_WAIT_FC;
> +			dev_put(dev);
> +			hrtimer_set_expires(&so->txtimer,
> +					    ktime_add(ktime_get(),
> +						      ktime_set(1, 0)));
> +			restart = HRTIMER_RESTART;
> +			break;
> +		}
> +
> +		/* no gap between data frames needed => use burst mode */
> +		if (!so->tx_gap)
> +			goto isotp_tx_burst;
> +
> +		/* start timer to send next data frame with correct delay */
> +		dev_put(dev);
> +		hrtimer_set_expires(&so->txtimer,
> +				    ktime_add(ktime_get(), so->tx_gap));
> +		restart = HRTIMER_RESTART;
> +		break;
> +
> +	default:
> +		WARN_ON_ONCE(1);
> +	}
> +
> +	return restart;
> +}

  reply	other threads:[~2020-10-10  1:20 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-07 21:31 pull-request: can-next 2020-10-07 Marc Kleine-Budde
2020-10-07 21:31 ` [PATCH 01/17] can: af_can: can_rcv_list_find(): fix kernel doc after variable renaming Marc Kleine-Budde
2020-10-07 21:31 ` [PATCH 02/17] can: softing: softing_card_shutdown(): add braces around empty body in an 'if' statement Marc Kleine-Budde
2020-10-07 21:31 ` [PATCH 03/17] can: c_can: reg_map_{c,d}_can: mark as __maybe_unused Marc Kleine-Budde
2020-10-07 21:31 ` [PATCH 04/17] MAINTAINERS: adjust to mcp251xfd file renaming Marc Kleine-Budde
2020-10-07 21:31 ` [PATCH 05/17] can: raw: add missing error queue support Marc Kleine-Budde
2020-10-07 21:31 ` [PATCH 06/17] can: dev: fix type of get_can_dlc() and get_canfd_dlc() macros Marc Kleine-Budde
2020-10-07 21:31 ` [PATCH 07/17] can: dev: add a helper function to calculate the duration of one bit Marc Kleine-Budde
2020-10-07 21:31 ` [PATCH 08/17] can: add ISO 15765-2:2016 transport protocol Marc Kleine-Budde
2020-10-10  0:57   ` Jakub Kicinski [this message]
2020-10-10 14:29     ` Oliver Hartkopp
2020-10-10 15:44       ` Jakub Kicinski
2020-10-10 16:24         ` Oliver Hartkopp
2020-10-10 16:34           ` Jakub Kicinski
2020-10-07 21:31 ` [PATCH 09/17] dt-bindings: can: rcar_can: Add r8a7742 support Marc Kleine-Budde
2020-10-07 21:31 ` [PATCH 10/17] dt-bindings: can: rcar_canfd: Document r8a774e1 support Marc Kleine-Budde
2020-10-07 21:31 ` [PATCH 11/17] dt-bindings: can: rcar_can: " Marc Kleine-Budde
2020-10-07 21:31 ` [PATCH 12/17] dt-bindings: can: flexcan: list supported processors Marc Kleine-Budde
2020-10-07 21:31 ` [PATCH 13/17] dt-bindings: can: flexcan: remove ack_grp and ack_bit from fsl,stop-mode Marc Kleine-Budde
2020-10-07 21:31 ` [PATCH 14/17] can: flexcan: remove ack_grp and ack_bit handling from driver Marc Kleine-Budde
2020-10-14  8:53   ` Joakim Zhang
2020-10-14 10:17     ` Marc Kleine-Budde
2020-10-07 21:31 ` [PATCH 15/17] can: xilinx_can: Limit CANFD brp to 2 Marc Kleine-Budde
2020-10-07 21:31 ` [PATCH 16/17] can: xilinx_can: Check return value of set_reset_mode Marc Kleine-Budde
2020-10-07 21:31 ` [PATCH 17/17] can: xilinx_can: Fix incorrect variable and initialize with a default value Marc Kleine-Budde
2020-10-10  1:09 ` pull-request: can-next 2020-10-07 Jakub Kicinski

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=20201009175751.5c54097f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=kernel@pengutronix.de \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=netdev@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 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).