Merge tag 'linux-can-next-for-5.11-20201120' of...

      - const: per

  clock-frequency:

    $ref: /schemas/types.yaml#/definitions/uint32

    description: |

      The oscillator frequency driving the flexcan device, filled in by the

      boot loader. This property should only be used the used operating system

      by default.

      0: clock source 0 (oscillator clock)

      1: clock source 1 (peripheral clock)

    $ref: /schemas/types.yaml#/definitions/uint32

    $ref: /schemas/types.yaml#/definitions/uint8

    default: 1

    minimum: 0

    maximum: 1

        interrupts = <48 0x2>;

        interrupt-parent = <&mpic>;

        clock-frequency = <200000000>;

        fsl,clk-source = <0>;

        fsl,clk-source = /bits/ 8 <0>;

    };

  - |

    #include <dt-bindings/interrupt-controller/irq.h>

on the socket as usual. There are also CAN specific socket options

described below.

The basic CAN frame structure and the sockaddr structure are defined

in include/linux/can.h:

The Classical CAN frame structure (aka CAN 2.0B), the CAN FD frame structure

and the sockaddr structure are defined in include/linux/can.h:

.. code-block:: C

    struct can_frame {

            canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */

            __u8    can_dlc; /* frame payload length in byte (0 .. 8) */

            union {

                    /* CAN frame payload length in byte (0 .. CAN_MAX_DLEN)

                     * was previously named can_dlc so we need to carry that

                     * name for legacy support

                     */

                    __u8 len;

                    __u8 can_dlc; /* deprecated */

            };

            __u8    __pad;   /* padding */

            __u8    __res0;  /* reserved / padding */

            __u8    __res1;  /* reserved / padding */

            __u8    len8_dlc; /* optional DLC for 8 byte payload length (9 .. 15) */

            __u8    data[8] __attribute__((aligned(8)));

    };

Remark: The len element contains the payload length in bytes and should be

used instead of can_dlc. The deprecated can_dlc was misleadingly named as

it always contained the plain payload length in bytes and not the so called

'data length code' (DLC).

To pass the raw DLC from/to a Classical CAN network device the len8_dlc

element can contain values 9 .. 15 when the len element is 8 (the real

payload length for all DLC values greater or equal to 8).

The alignment of the (linear) payload data[] to a 64bit boundary

allows the user to define their own structs and unions to easily access

the CAN payload. There is no given byteorder on the CAN bus by

                    /* transport protocol class address info (e.g. ISOTP) */

                    struct { canid_t rx_id, tx_id; } tp;

                    /* J1939 address information */

                    struct {

                            /* 8 byte name when using dynamic addressing */

                            __u64 name;

                            /* pgn:

                             * 8 bit: PS in PDU2 case, else 0

                             * 8 bit: PF

                             * 1 bit: DP

                             * 1 bit: reserved

                             */

                            __u32 pgn;

                            /* 1 byte address */

                            __u8 addr;

                    } j1939;

                    /* reserved for future CAN protocols address information */

            } can_addr;

    };

bytes of payload (struct can_frame) like the CAN_RAW socket. Therefore e.g.

the CAN_RAW socket supports a new socket option CAN_RAW_FD_FRAMES that

switches the socket into a mode that allows the handling of CAN FD frames

and (legacy) CAN frames simultaneously (see :ref:`socketcan-rawfd`).

and Classical CAN frames simultaneously (see :ref:`socketcan-rawfd`).

The struct canfd_frame is defined in include/linux/can.h:

length and the DLC has a 1:1 mapping in the range of 0 .. 8. To preserve

the easy handling of the length information the canfd_frame.len element

contains a plain length value from 0 .. 64. So both canfd_frame.len and

can_frame.can_dlc are equal and contain a length information and no DLC.

can_frame.len are equal and contain a length information and no DLC.

For details about the distinction of CAN and CAN FD capable devices and

the mapping to the bus-relevant data length code (DLC), see :ref:`socketcan-can-fd-driver`.

.. code-block:: C

  #define CAN_MTU   (sizeof(struct can_frame))   == 16  => 'legacy' CAN frame

  #define CAN_MTU   (sizeof(struct can_frame))   == 16  => Classical CAN frame

  #define CANFD_MTU (sizeof(struct canfd_frame)) == 72  => CAN FD frame

            printf("got CAN FD frame with length %d\n", cfd.len);

            /* cfd.flags contains valid data */

    } else if (nbytes == CAN_MTU) {

            printf("got legacy CAN frame with length %d\n", cfd.len);

            printf("got Classical CAN frame with length %d\n", cfd.len);

            /* cfd.flags is undefined */

    } else {

            fprintf(stderr, "read: invalid CAN(FD) frame\n");

            printf("%02X ", cfd.data[i]);

When reading with size CANFD_MTU only returns CAN_MTU bytes that have

been received from the socket a legacy CAN frame has been read into the

been received from the socket a Classical CAN frame has been read into the

provided CAN FD structure. Note that the canfd_frame.flags data field is

not specified in the struct can_frame and therefore it is only valid in

CANFD_MTU sized CAN FD frames.

To build a CAN FD aware application use struct canfd_frame as basic CAN

data structure for CAN_RAW based applications. When the application is

executed on an older Linux kernel and switching the CAN_RAW_FD_FRAMES

socket option returns an error: No problem. You'll get legacy CAN frames

socket option returns an error: No problem. You'll get Classical CAN frames

or CAN FD frames and can process them the same way.

When sending to CAN devices make sure that the device is capable to handle

RX_RTR_FRAME:

	Send reply for RTR-request (placed in op->frames[0]).

CAN_FD_FRAME:

	The CAN frames following the bcm_msg_head are struct canfd_frame's

Broadcast Manager Transmission Timers

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    stats       - SocketCAN core statistics (rx/tx frames, match ratios, ...)

    reset_stats - manual statistic reset

    version     - prints the SocketCAN core version and the ABI version

    version     - prints SocketCAN core and ABI version (removed in Linux 5.10)

Writing Own CAN Protocol Modules

    dev->type  = ARPHRD_CAN; /* the netdevice hardware type */

    dev->flags = IFF_NOARP;  /* CAN has no arp */

    dev->mtu = CAN_MTU; /* sizeof(struct can_frame) -> legacy CAN interface */

    dev->mtu = CAN_MTU; /* sizeof(struct can_frame) -> Classical CAN interface */

    or alternative, when the controller supports CAN with flexible data rate:

    dev->mtu = CANFD_MTU; /* sizeof(struct canfd_frame) -> CAN FD interface */

        [ fd { on | off } ]

        [ fd-non-iso { on | off } ]

        [ presume-ack { on | off } ]

        [ cc-len8-dlc { on | off } ]

        [ restart-ms TIME-MS ]

        [ restart ]

second bit timing has to be specified in order to enable the CAN FD bitrate.

Additionally CAN FD capable CAN controllers support up to 64 bytes of

payload. The representation of this length in can_frame.can_dlc and

payload. The representation of this length in can_frame.len and

canfd_frame.len for userspace applications and inside the Linux network

layer is a plain value from 0 .. 64 instead of the CAN 'data length code'.

The data length code was a 1:1 mapping to the payload length in the legacy

The data length code was a 1:1 mapping to the payload length in the Classical

CAN frames anyway. The payload length to the bus-relevant DLC mapping is

only performed inside the CAN drivers, preferably with the helper

functions can_dlc2len() and can_len2dlc().

functions can_fd_dlc2len() and can_fd_len2dlc().

The CAN netdevice driver capabilities can be distinguished by the network

devices maximum transfer unit (MTU)::

  MTU = 16 (CAN_MTU)   => sizeof(struct can_frame)   => 'legacy' CAN device

  MTU = 16 (CAN_MTU)   => sizeof(struct can_frame)   => Classical CAN device

  MTU = 72 (CANFD_MTU) => sizeof(struct canfd_frame) => CAN FD capable device

The CAN device MTU can be retrieved e.g. with a SIOCGIFMTU ioctl() syscall.

N.B. CAN FD capable devices can also handle and send legacy CAN frames.

N.B. CAN FD capable devices can also handle and send Classical CAN frames.

When configuring CAN FD capable CAN controllers an additional 'data' bitrate

has to be set. This bitrate for the data phase of the CAN FD frame has to be

PGN

---

The J1939 protocol uses the 29-bit CAN identifier with the following structure:

  ============  ==============  ====================

  29 bit CAN-ID

  --------------------------------------------------

  Bit positions within the CAN-ID

  --------------------------------------------------

  28 ... 26     25 ... 8        7 ... 0

  ============  ==============  ====================

  Priority      PGN             SA (Source Address)

  ============  ==============  ====================

The PGN (Parameter Group Number) is a number to identify a packet. The PGN

is composed as follows:

1 bit  : Reserved Bit

1 bit  : Data Page

8 bits : PF (PDU Format)

8 bits : PS (PDU Specific)

  ============  ==============  =================  =================

  PGN

  ------------------------------------------------------------------

  Bit positions within the CAN-ID

  ------------------------------------------------------------------

  25            24              23 ... 16          15 ... 8

  ============  ==============  =================  =================

  R (Reserved)  DP (Data Page)  PF (PDU Format)    PS (PDU Specific)

  ============  ==============  =================  =================

In J1939-21 distinction is made between PDU1 format (where PF < 240) and PDU2

format (where PF >= 240). Furthermore, when using the PDU2 format, the PS-field

contains a so-called Group Extension, which is part of the PGN. When using PDU2

format, the Group Extension is set in the PS-field.

  ==============  ========================

  PDU1 Format (specific) (peer to peer)

  ----------------------------------------

  Bit positions within the CAN-ID

  ----------------------------------------

  23 ... 16       15 ... 8

  ==============  ========================

  00h ... EFh     DA (Destination address)

  ==============  ========================

  ==============  ========================

  PDU2 Format (global) (broadcast)

  ----------------------------------------

  Bit positions within the CAN-ID

  ----------------------------------------

  23 ... 16       15 ... 8

  ==============  ========================

  F0h ... FFh     GE (Group Extenstion)

  ==============  ========================

On the other hand, when using PDU1 format, the PS-field contains a so-called

Destination Address, which is _not_ part of the PGN. When communicating a PGN

from user space to kernel (or vice versa) and PDU2 format is used, the PS-field

	}

	reg_mid = at91_can_id_to_reg_mid(cf->can_id);

	reg_mcr = ((cf->can_id & CAN_RTR_FLAG) ? AT91_MCR_MRTR : 0) |

		(cf->can_dlc << 16) | AT91_MCR_MTCR;

		(cf->len << 16) | AT91_MCR_MTCR;

	/* disable MB while writing ID (see datasheet) */

	set_mb_mode(priv, mb, AT91_MB_MODE_DISABLED);

	/* This triggers transmission */

	at91_write(priv, AT91_MCR(mb), reg_mcr);

	stats->tx_bytes += cf->can_dlc;

	stats->tx_bytes += cf->len;

	/* _NOTE_: subtract AT91_MB_TX_FIRST offset from mb! */

	can_put_echo_skb(skb, dev, mb - get_mb_tx_first(priv));

	cf->data[1] = CAN_ERR_CRTL_RX_OVERFLOW;

	stats->rx_packets++;

	stats->rx_bytes += cf->can_dlc;

	stats->rx_bytes += cf->len;

	netif_receive_skb(skb);

}

		cf->can_id = (reg_mid >> 18) & CAN_SFF_MASK;

	reg_msr = at91_read(priv, AT91_MSR(mb));

	cf->can_dlc = get_can_dlc((reg_msr >> 16) & 0xf);

	cf->len = can_cc_dlc2len((reg_msr >> 16) & 0xf);

	if (reg_msr & AT91_MSR_MRTR)

		cf->can_id |= CAN_RTR_FLAG;

	at91_read_mb(dev, mb, cf);

	stats->rx_packets++;

	stats->rx_bytes += cf->can_dlc;

	stats->rx_bytes += cf->len;

	netif_receive_skb(skb);

	can_led_event(dev, CAN_LED_EVENT_RX);

	at91_poll_err_frame(dev, cf, reg_sr);

	dev->stats.rx_packets++;

	dev->stats.rx_bytes += cf->can_dlc;

	dev->stats.rx_bytes += cf->len;

	netif_receive_skb(skb);

	return 1;

	at91_irq_err_state(dev, cf, new_state);

	dev->stats.rx_packets++;

	dev->stats.rx_bytes += cf->can_dlc;

	dev->stats.rx_bytes += cf->len;

	netif_rx(skb);

	priv->can.state = new_state;

				  struct can_frame *frame, int idx)

{

	struct c_can_priv *priv = netdev_priv(dev);

	u16 ctrl = IF_MCONT_TX | frame->can_dlc;

	u16 ctrl = IF_MCONT_TX | frame->len;

	bool rtr = frame->can_id & CAN_RTR_FLAG;

	u32 arb = IF_ARB_MSGVAL;

	int i;

	if (priv->type == BOSCH_D_CAN) {

		u32 data = 0, dreg = C_CAN_IFACE(DATA1_REG, iface);

		for (i = 0; i < frame->can_dlc; i += 4, dreg += 2) {

		for (i = 0; i < frame->len; i += 4, dreg += 2) {

			data = (u32)frame->data[i];

			data |= (u32)frame->data[i + 1] << 8;

			data |= (u32)frame->data[i + 2] << 16;

			priv->write_reg32(priv, dreg, data);

		}

	} else {

		for (i = 0; i < frame->can_dlc; i += 2) {

		for (i = 0; i < frame->len; i += 2) {

			priv->write_reg(priv,

					C_CAN_IFACE(DATA1_REG, iface) + i / 2,

					frame->data[i] |

		return -ENOMEM;

	}

	frame->can_dlc = get_can_dlc(ctrl & 0x0F);

	frame->len = can_cc_dlc2len(ctrl & 0x0F);

	arb = priv->read_reg32(priv, C_CAN_IFACE(ARB1_REG, iface));

		int i, dreg = C_CAN_IFACE(DATA1_REG, iface);

		if (priv->type == BOSCH_D_CAN) {

			for (i = 0; i < frame->can_dlc; i += 4, dreg += 2) {

			for (i = 0; i < frame->len; i += 4, dreg += 2) {

				data = priv->read_reg32(priv, dreg);

				frame->data[i] = data;

				frame->data[i + 1] = data >> 8;

				frame->data[i + 3] = data >> 24;

			}

		} else {

			for (i = 0; i < frame->can_dlc; i += 2, dreg++) {

			for (i = 0; i < frame->len; i += 2, dreg++) {

				data = priv->read_reg(priv, dreg);

				frame->data[i] = data;

				frame->data[i + 1] = data >> 8;

	}

	stats->rx_packets++;

	stats->rx_bytes += frame->can_dlc;

	stats->rx_bytes += frame->len;

	netif_receive_skb(skb);

	return 0;

	 * transmit as we might race against do_tx().

	 */

	c_can_setup_tx_object(dev, IF_TX, frame, idx);

	priv->dlc[idx] = frame->can_dlc;

	priv->dlc[idx] = frame->len;

	can_put_echo_skb(skb, dev, idx);

	/* Update the active bits */

	}

	stats->rx_packets++;

	stats->rx_bytes += cf->can_dlc;

	stats->rx_bytes += cf->len;

	netif_receive_skb(skb);

	return 1;

	}

	stats->rx_packets++;

	stats->rx_bytes += cf->can_dlc;

	stats->rx_bytes += cf->len;

	netif_receive_skb(skb);

	return 1;

}