[PATCH 3.6-rc1] canfd: remove redundant CAN FD flag

* [PATCH 3.6-rc1] canfd: remove redundant CAN FD flag
@ 2012-08-06 16:02 Oliver Hartkopp
  2012-08-07  8:16 ` Marc Kleine-Budde
  0 siblings, 1 reply; 3+ messages in thread
From: Oliver Hartkopp @ 2012-08-06 16:02 UTC (permalink / raw)
  To: Marc Kleine-Budde; +Cc: linux-can

The first idea of the CAN FD implementation started with a new struct
canfd_frame to be used for both CAN FD frames and legacy CAN frames.
The now mainlined implementation supports both CAN frame types simultaneously
and distinguishes them only by their required sizes: CAN_MTU and CANFD_MTU.

Only the struct canfd_frame contains a flags element which is needed for the
additional CAN FD information. As CAN FD implicitly means that the 'Extened
Data Length' mode is enabled the formerly defined CANFD_EDL bit became
redundant and also confusing as an unset bit would be an error and would
always need to be tested.

This patch removes the obsolete CANFD_EDL bit and clarifies the documentation
for the use of struct canfd_frame and the CAN FD relevant flags.

Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>

---

Hello Marc,

when thinking about the extension of the can-utils to support the handling of
CAN FD specific flags in logfiles and console output i stumbled upon an
implementation artifact i would like to fix before 3.6 is released.

The former flags definition turned out to be hard to use and is redundant in
the case of the CANFD_EDL flag.

Do you want to take that patch in your linux-can tree to be pulled for 3.6-rc2
or should i send it to Dave/netdev-ML directly?
The patch is based on Linus' 3.6-rc1 tree.

Thanks,
Oliver

diff --git a/include/linux/can.h b/include/linux/can.h
index 018055e..de49bd3 100644
--- a/include/linux/can.h
+++ b/include/linux/can.h
@@ -74,20 +74,21 @@ struct can_frame {
 /*
  * defined bits for canfd_frame.flags
  *
- * As the default for CAN FD should be to support the high data rate in the
- * payload section of the frame (HDR) and to support up to 64 byte in the
- * data section (EDL) the bits are only set in the non-default case.
- * Btw. as long as there's no real implementation for CAN FD network driver
- * these bits are only preliminary.
+ * The use of struct canfd_frame implies the Extended Data Length (EDL) bit to
+ * be set in the CAN frame bitstream on the wire. The EDL bit switch turns
+ * the CAN controllers bitstream processor into the CAN FD mode which creates
+ * two new options within the CAN FD frame specification:
  *
- * RX: NOHDR/NOEDL - info about received CAN FD frame
- *     ESI         - bit from originating CAN controller
- * TX: NOHDR/NOEDL - control per-frame settings if supported by CAN controller
- *     ESI         - bit is set by local CAN controller
+ * Bit Rate Switch - to indicate a second bitrate is/was used for the payload
+ * Error State Indicator - represents the error state of the transmitting node 
+ *
+ * As the CANFD_ESI bit is internally generated by the transmitting CAN
+ * controller only the CANFD_BRS bit is relevant for real CAN controllers when
+ * building a CAN FD frame for transmission. Setting the CANFD_ESI bit can make
+ * sense for virtual CAN interfaces to test applications with echoed frames.
  */
-#define CANFD_NOHDR 0x01 /* frame without high data rate */
-#define CANFD_NOEDL 0x02 /* frame without extended data length */
-#define CANFD_ESI   0x04 /* error state indicator */
+#define CANFD_BRS 0x01 /* bit rate switch (second bitrate for payload data) */
+#define CANFD_ESI 0x02 /* error state indicator of the transmitting node */
 
 /**
  * struct canfd_frame - CAN flexible data rate frame structure



^ permalink raw reply related	[flat|nested] 3+ messages in thread