Re: [PATCH] can: flexcan: switch the i.MX series to timestamp based rx-offload

[Marc Kleine-Budde <mkl@pengutronix.de>]

[-- Attachment #1: Type: text/plain, Size: 2858 bytes --]

On 02.01.2022 16:58:13, Dario Binacchi wrote:
> As explained by commit b3cf53e988ce ("can: flexcan: add support for
> timestamp based rx-offload"), the controller has 64 message buffers but
> it uses only 6 for reception. Enabling timestamp mode, instead of FIFO,
> allows you to use the maximum number of messages for reception.
> 
> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> Signed-off-by: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>

NACK - according to the data sheet these controllers cannot receive RTR
messages via mailboxes.

See Section "26.4.8.1 Remote Frames" of the mx25 rev. 2 data sheet:

| When a remote request frame is received by FlexCAN, its ID is compared
| to the IDs of the transmit message buffers with CODE field 0b1010. If
| there is a matching ID, then this message buffer frame is transmitted.
| If the matching message buffer has the RTR bit set, then FlexCAN
| transmits a remote frame as a response.
| 
| A received remote request frame is not stored in a receive buffer. It is
| only used to trigger a transmission of a frame in response. The mask
| registers are not used in remote frame matching, and all ID bits (except
| RTR) of the incoming received frame must match.
| 
| In the case that a remote request frame is received and matches a
| message buffer, this message buffer immediately enters the internal
| arbitration process, but is considered as normal Tx message buffer, with
| no higher priority. The data length of this frame is independent of the
| DLC field in the remote frame that initiated its transmission.
| 
| If the Rx FIFO is enabled (the FEN bit in the MCR is set to 1), FlexCAN
| does not generate an automatic response for remote request frames that
| match the FIFO filtering criteria. If the remote frame matches one of
| the target IDs, it is stored in the FIFO and presented to the ARM. For
| filtering formats A and B, it is possible to select whether remote
| frames are accepted or not. For format C, remote frames are always
| accepted (if they match the ID).

This is in general not acceptable for all users. If you can live with
this limitation, please make it runtime configurable, e.g. via the
ethtool interface.

Not sure which ethtool callback to use, yet, but we can figure this out
together. Please create an RFC patch, where you put the struct
devtype_data into the priv instead of a pointer to it. In a second patch
we can add the ethtool code to change the struct
devtype_data::devtype_data::quirks.

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]