Switch from using DEVICE_DT_DEFINE()/DEVICE_DT_INST_DEFINE() to using
CAN_DEVICE_DT_DEFINE()/CAN_DEVICE_DT_INST_DEFINE() for remaining drivers.
This unifies CAN controller device driver initialization regardless of the
driver implementing CAN statistics support or not.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the can_utils_filter_match() utility function to
can_frame_matches_filter(), move it to the public
include/zephyr/drivers/can.h header file, and add a missing mismatch for
standard (11-bit) ID frames passing extended (29-bit) filters.
This allows using the utility function in out-of-tree CAN drivers.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add support FD frame filter to configure type frame for
each Rx msg to receive corresponding frames (classic, FD frames).
The Bosch M_CAN driver does not support FD frame filter,
so inmplement driver to handle it in software.
Signed-off-by: Cong Nguyen Huu <cong.nguyenhuu@nxp.com>
The can_frame and can_filter structs support a number of different flags
(standard/extended CAN ID type, Remote Transmission Request, CAN-FD format,
Bit Rate Switch, ...). Each of these flags is represented as a discrete bit
in the given structure.
This design pattern requires every user of these structs to initialize all
of these flags to either 0 or 1, which does not scale well for future flag
additions.
Some of these flags have associated enumerations to be used for assignment,
some do not. CAN drivers and protocols tend to rely on the logical value of
the flag instead of using the enumeration, leading to a very fragile
API. The enumerations are used inconsistently between the can_frame and
can_filter structures, which further complicates the API.
Instead, convert these flags to bitfields with separate flag definitions
for the can_frame and can_filter structures. This API allows for future
extensions without having to revisit existing users of the two
structures. Furthermore, this allows driver to easily check for unsupported
flags in the respective API calls.
As this change leads to the "id_mask" field of the can_filter to be the
only mask present in that structure, rename it to "mask" for simplicity.
Fixes: #50776
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Given the recent change to the CAN controller can_send() API wrapper,
assume that a callback is always provided at the driver level.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Up until now, the Zephyr CAN controller drivers set a default bitrate (or
timing) specified via devicetree and start the CAN controller in their
respective driver initialization functions.
This is fine for CAN nodes using only one fixed bitrate, but if the bitrate
is set by the user (e.g. via a DIP-switch or other HMI which is very
common), the CAN driver will still initialise with the default
bitrate/timing at boot and use this until the application has determined
the requested bitrate/timing and set it using
can_set_bitrate()/can_set_timing().
During this period, the CAN node will potentially destroy valid CAN frames
on the CAN bus (which is using the soon-to-be-set-by-the-application
bitrate) by sending error frames. This causes interruptions to the ongoing
CAN bus traffic when a Zephyr-based CAN node connected to the bus is
(re-)booted.
Instead, require all configuration (setting bitrate, timing, or mode) to
take place when the CAN controller is stopped. This maps nicely to entering
"reset mode" (called "configuration mode" or "freeze mode" for some CAN
controller implementations) when stopping and exiting this mode when
starting the CAN controller.
Fixes: #45304
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
This driver provides an interface to SocketCAN interfaces of the Linux
system running a Zephyr application with the native_posix board. These
interfaces may be virtual or actual CAN buses.
Signed-off-by: Martin Jäger <martin@libre.solar>
