Skip to contentSkip to conversation

can: remove CAN FD compatibility for CAN 2.0 sockets

PATCH In review Oliver Hartkopp 2 participants 4 messages Mar 1, 2014 – Mar 3, 2014

Subsystems (4)
lore
Share & tools
lore

Oliver Hartkopp

author maintainer
#0 lore raw

PATCH v2 1/1 can: remove CAN FD compatibility for CAN 2.0 sockets

In commit e2d265d3b587 (canfd: add support for CAN FD in CAN_RAW sockets) CAN FD frames with a payload length up to 8 byte are passed to legacy sockets where the CAN FD support was not enabled by the application.

After some discussions with developers at a fair this well meant feature leads to confusion as no clean switch for CAN / CAN FD is provided to the application programmer. Additionally a compatibility like this for legacy CAN_RAW sockets requires some compatibility handling for the sending, e.g. make CAN2.0 frames a CAN FD frame with BRS at transmission time (?!?).

This will become a mess when people start to develop applications with real CAN FD hardware. This patch reverts the bad compatibility code together with the documentation describing the removed feature.

---

Documentation/networking/can.txt +0 -6
index f3089d4..0cbe6ec 100644
@@ -554,12 +554,6 @@ solution for a couple of reasons:
   not specified in the struct can_frame and therefore it is only valid in
   CANFD_MTU sized CAN FD frames.
 
-  As long as the payload length is <=8 the received CAN frames from CAN FD
-  capable CAN devices can be received and read by legacy sockets too. When
-  user-generated CAN FD frames have a payload length <=8 these can be send
-  by legacy CAN network interfaces too. Sending CAN FD frames with payload
-  length > 8 to a legacy CAN network interface returns an -EMSGSIZE error.
-
   Implementation hint for new CAN applications:
 
   To build a CAN FD aware application use struct canfd_frame as basic CAN
net/can/raw.c +5 -21
index 8be757c..081e81f 100644
@@ -121,13 +121,9 @@ static void raw_rcv(struct sk_buff *oskb, void *data)
 	if (!ro->recv_own_msgs && oskb->sk == sk)
 		return;
 
-	/* do not pass frames with DLC > 8 to a legacy socket */
-	if (!ro->fd_frames) {
-		struct canfd_frame *cfd = (struct canfd_frame *)oskb->data;
-
-		if (unlikely(cfd->len > CAN_MAX_DLEN))
-			return;
-	}
+	/* do not pass non-CAN2.0 frames to a legacy socket */
+	if (!ro->fd_frames && oskb->len != CAN_MTU)
+		return;
 
 	/* clone the given skb to be able to enqueue it into the rcv queue */
 	skb = skb_clone(oskb, GFP_ATOMIC);
@@ -738,9 +734,7 @@ static int raw_recvmsg(struct kiocb *iocb, struct socket *sock,
 		       struct msghdr *msg, size_t size, int flags)
 {
 	struct sock *sk = sock->sk;
-	struct raw_sock *ro = raw_sk(sk);
 	struct sk_buff *skb;
-	int rxmtu;
 	int err = 0;
 	int noblock;
 
@@ -751,20 +745,10 @@ static int raw_recvmsg(struct kiocb *iocb, struct socket *sock,
 	if (!skb)
 		return err;
 
-	/*
-	 * when serving a legacy socket the DLC <= 8 is already checked inside
-	 * raw_rcv(). Now check if we need to pass a canfd_frame to a legacy
-	 * socket and cut the possible CANFD_MTU/CAN_MTU length to CAN_MTU
-	 */
-	if (!ro->fd_frames)
-		rxmtu = CAN_MTU;
-	else
-		rxmtu = skb->len;
-
-	if (size < rxmtu)
+	if (size < skb->len)
 		msg->msg_flags |= MSG_TRUNC;
 	else
-		size = rxmtu;
+		size = skb->len;
 
 	err = memcpy_toiovec(msg->msg_iov, skb->data, size);
 	if (err < 0) {
#1 lore raw
Quoted 10 lines · Oliver Hartkopp

In commit e2d265d3b587 (canfd: add support for CAN FD in CAN_RAW sockets) CAN FD frames with a payload length up to 8 byte are passed to legacy sockets where the CAN FD support was not enabled by the application.

After some discussions with developers at a fair this well meant feature leads to confusion as no clean switch for CAN / CAN FD is provided to the application programmer. Additionally a compatibility like this for legacy CAN_RAW sockets requires some compatibility handling for the sending, e.g. make CAN2.0 frames a CAN FD frame with BRS at transmission time (?!?).

Quoted 6 lines

This will become a mess when people start to develop applications with real CAN FD hardware. This patch reverts the bad compatibility code together with the documentation describing the removed feature.

Thx, applied to can and included in my latest pull request.

Marc

Signature · 4 lines
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |
#3 lore raw
Quoted 9 lines · Oliver Hartkopp
Quoted 4 lines · Marc Kleine-Budde
Quoted 2 lines

Thx, applied to can and included in my latest pull request.

Do you plan to send a can-next pull request with the CAN FD driver extensions (v9) the next days too?

Yes, but that's for net-next.

Marc

Signature · 4 lines
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |