RFC: API change: drivers: can: remove CAN_FILTER_FDF flag

[henrikbrixandersen]

Introduction

The CAN_FILTER_FDF was added in #52483 on the premise that the NXP S32 CANEXCEL driver (added in #52450) needed to know whether a CAN filter should match a classic CAN or a CAN FD frame; it could not match both.

This was opposite of all other in-tree supported CAN controllers, which are unable to filter on classic CAN/CAN FD in hardware. In order to maintain a uniform behaviour across the in-tree CAN FD capable CAN controller drivers, support for this flag was added to these by amending their hardware filtering with a software-based filter, which would discard frames not matching the presence/non-presence of the CAN_FILTER_FDF flag.

Problem description

Unfortunately, this added software-based filtering (or rather, the mix of hardware- and software-based filtering) leads to issues like the one reported in #64554.

Investigation of how this flag was used in the NXP S32 CANEXCEL IP core revealed that the premise presented in #52483 was false. The NXP S32 CANEXCEL IP core has the ability to filter on classic/FD vs. CAN XL frames, but not between classic CAN and CAN FD frames. The NXP HAL API Canexcel_Ip_SetRxIndividualMask () leads to this false conclusion (see https://github.com/zephyrproject-rtos/hal_nxp/blob/78d1912dbc2b5f6e114d7fd19a31053716a3b01d/s32/drivers/s32ze/Can_CANEXCEL/include/CanEXCEL_Ip.h#L93C48-L93C48), while in fact the implementation only distinguishes between CAN XL frames/non-XL frames (see https://github.com/zephyrproject-rtos/hal_nxp/blob/78d1912dbc2b5f6e114d7fd19a31053716a3b01d/s32/drivers/s32ze/Can_CANEXCEL/src/CanEXCEL_Ip.c#L297). This is in line with the reference manual for the CANEXCEL IP core.

Proposed change

The CAN_FILTER_FDF flag should never have been introduced. It leads to overhead, false promises of the API, and issues like those reported in #64554. I propose this flag is removed again as no known CAN controllers provide hardware support for filtering between classic CAN and CAN FD frames.

Detailed RFC

Please see #65108

Proposed change (Detailed)

Please see #65108

Dependencies

The detailed RFC currently includes the proposed changes from #65058 in order to completely remove the mix of hardware- and software-based filtering from the Bosch M_CAN driver backend.

Concerns and Unresolved Questions

None.

Alternatives

None.

[henrikbrixandersen]

@manuargue, @congnguyenhuu, @dleach02, @str4t0m, @martinjaeger, @alexanderwachter: FYI

[martinjaeger]

@henrikbrixandersen Your explanations make sense and I agree to remove the software filtering based on FD flag.

The FDF bit in the CAN frame is not part of the arbitration field, but belongs to the control field. So it does not make much sense to filter based on the FDF flag either.

[carlescufi]

Architecture WG:

• No objections

[henrikbrixandersen]

@manuargue, @congnguyenhuu: Any opinions on this?

[manuargue]

@manuargue, @congnguyenhuu: Any opinions on this?

@henrikbrixandersen based on my general knowledge of CAN and the evidence presented here, it seems to me your proposal is the right move. I have no objections.