Include a pointer to the CAN controller device for the CAN
transmit, receive, and state change callback functions.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Stop using redundant DEV_DATA/DEV_CFG macros and use dev->data and
dev->config instead.
Follows #41918.
Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
The CAN_BUS_UNKNOWN CAN controller state is only used to indicate that
the current CAN controller state could not be read.
Remove it and change the signature of the can_get_state() API function
to return an integer indicating success or failure.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add optional user data argument to can_set_state_change_callback() to
comply with Zephyr API design guidelines.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename a few CAN API functions for clarity and consistency with other
Zephyr RTOS APIs.
CAN_DEFINE_MSGQ() becomes CAN_MSGQ_DEFINE() to match K_MSGQ_DEFINE().
can_attach_isr() becomes can_add_rx_filter() since a filter callback
function is not an interrupt service routine (although it is called in
isr context). The word "attach" is replaced with "add" since filters are
added, not attached. This matches the terminology used is other Zephyr
APIs better.
can_detach() becomes can_remove_rx_filter() to pair with
can_add_rx_filter().
can_attach_msgq() becomes can_add_rx_filter_msgq() and documentation is
updated to mention its relationship with can_add_rx_filter().
can_register_state_change_isr() becomes can_set_state_change_callback()
since a state change callback function is not an interrupt service
routine (although it is called in isr context). The word "register" is
replaced with "set" since only one state change callback can be in
place.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Deprecate the use of CAN-specific error return values and replace them
with standard errno values.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Catch up on the CAN driver API argument naming changes:
- Unify naming of callback function pointers as "callback".
- Unify naming of user-specified callback function arguments as
"user_data".
- Instances and pointers to struct zcan_frame are named "frame",
not "msg", to avoid confusion with the CAN message queue support.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The maximum number of concurrent filters depends on the hardware and
the driver implementation. This API allows the application to obtain
the maximum number of available filters.
Signed-off-by: Martin Jäger <martin@libre.solar>
Refactors all of the CAN drivers to use a shared driver class
initialization priority configuration, CONFIG_CAN_INIT_PRIORITY, to
allow configuring CAN drivers separately from other devices. This is
similar to other driver classes like I2C and SPI.
The default is set to CONFIG_KERNEL_INIT_PRIORITY_DEVICE to preserve the
existing default initialization priority for most drivers. The exception
is the mcp2515 driver which has a dependency on a SPI driver and must
therefore initialize later than the default device priority.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
This driver is for classic CAN, it makes use of CAN interface
in FIFO mode.
This driver support Standard ID as well as Extended ID.
Tested on H3ULCB, Ebisu platform, with external adapter and
in loopback mode.
Signed-off-by: Julien Massot <julien.massot@iot.bzh>
