A growing number of CAN controllers do not have support for individual RX
hardware filters based on the Remote Transmission Request (RTR) bit. This
leads to various work-arounds on the driver level mixing hardware and
software filtering.
As the use of RTR frames is discouraged by CAN in Automation (CiA) - and
not even supported by newer standards, e.g. CAN FD - this often leads to
unnecessary overhead, added complexity, and worst-case to non-portable
behavior between various CAN controller drivers.
Instead, move to a simpler approach where the ability to accept/reject RTR
frames is globally configured via Kconfig. By default, all incoming RTR
frames are rejected at the driver level, a setting which can be supported
in hardware by most in-tree CAN controllers drivers.
Legacy applications or protocol implementations, where RTR reception is
required, can now select CONFIG_CAN_ACCEPT_RTR to accept incoming RTR
frames matching added CAN filters. These applications or protocols will
need to distinguish between RTR and data frames in their respective CAN RX
frame handling routines.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Unify spelling of CAN Flexible Data-rate abbreviation to "CAN FD" instead
of "CAN-FD". The former aligns with the CAN in Automation (CiA)
recommendation.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Split out the CAN transceiver API documentation from the CAN controller API
documentation. The CAN transceiver API was introduced in Zephyr v3.1.0.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the documentation for high-level CAN protocols (for now only covering
ISO-TP) from the peripherals section to the connectivity section.
This matches the layout in code, where the CAN controllers are under the
drivers/can directory and the protocols are under the subsys/canbus/
directory.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
