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>
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>
Remove the "z" prefix from the public CAN controller API types as this
makes them appear as internal APIs.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add API function for getting the supported capabilities of a CAN
controller. This allows for writing portable CAN applications.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Convert the can_mode enum to a bit field to prepare for future extensions
(CAN-FD mode, transmitter delay compensation, one-shot mode, 3-samples
mode, ...).
Rename the existing modes:
- CAN_NORMAL_MODE -> CAN_MODE_NORMAL
- CAN_SILENT_MODE -> CAN_MODE_LISTENONLY
- CAN_LOOPBACK_MODE -> CAN_MODE_LOOPBACK
These mode names align with the Linux naming for CAN control modes.
The old CAN_SILENT_LOOPBACK_MODE can be set with the bitmask
(CAN_MODE_LISTENONLY | CAN_MODE_LOOPBACK).
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the CAN data phase API functions to timing_data_* for consistency:
- can_get_timing_min_data() -> can_get_timing_data_min()
- can_get_timing_max_data() -> can_get_timing_data_max()
- .timing_min_data -> timing_data_min
- .timing_max_data -> timing_data_max
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Pass a copy of outbound argument structs to the implementation functions
as recommended for Zephyr system calls.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Verify read access to the timing and timing_data parameters in
z_vrfy_can_set_timing() and pass a copy of these structs to the
implementation as recommended for Zephyr system calls.
Remove unnecessary typecasts.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The can_get_max_bitrate() is an optional API function. Limit validation
to the CAN device driver pointer.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Verify the get_state API call in z_vrfy_can_get_state(). Adjust sizeof()
arguments to match the rest of the file.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Verify the add_rx_filter API call in z_vrfy_can_add_rx_filter_msgq() as
this is used by the underlying implementation. Remove unnecessary
typecasts.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Do not attempt to verify that the current thread has access to the void
*user_data argument to z_vrfy_can_send(). The size of the data is not
known and no driver code will try to dereference it (it may not even be
a valid pointer).
Remove unnecessary typecasts from z_vrfy_can_send().
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Convert can_calc_timing() + can_calc_timing_data() to syscalls and use
the newly added syscalls calls for determing the minimum/maximum
supported timing parameter values.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add CAN system calls for getting the minimum/maximum timing values
supported by a given CAN controller device driver instance:
- can_get_timing_min()
- can_get_timing_max()
- can_get_timing_min_data()
- can_get_timing_max_data();
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add support for getting the maximum supported bitrate in bits/s for CAN
controller/transceiver combination and check that a requested bitrate is
within the supported range.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
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>
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>
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>
There was a verification function for can_set_bitrate calling a syscall
implementation. But, can_set_bitrate is not a syscall and does not need
to be because it is accessing the driver through other syscalls.
Fixes#34734
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
The previous API can't change the sampling-point and only allowed
bitrates that fit the time segments.
The new API allows for shifting the sampling-point and adjusts the
number of time quantum in a bit to all more possible bitrates.
The functions to calculate the timings are moved to the can_common file.
They can be used for all drivers.
Signed-off-by: Alexander Wachter <alexander@wachter.cloud>
Now that device_api attribute is unmodified at runtime, as well as all
the other attributes, it is possible to switch all device driver
instance to be constant.
A coccinelle rule is used for this:
@r_const_dev_1
disable optional_qualifier
@
@@
-struct device *
+const struct device *
@r_const_dev_2
disable optional_qualifier
@
@@
-struct device * const
+const struct device *
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Convert all canbus related API/samples/tests/subsys
to the new timeout API with k_timeout_t.
Signed-off-by: Alexander Wachter <alexander@wachter.cloud>
This commit extends the CAN API with the following functions:
- can_get_state
- can_recover
- can_register_state_change_isr
This functions can be used to get the error-counters and the state
of the CAN controller. The recover function can be used to recover
from bus-off state when automatic recovery is disabled.
Signed-off-by: Alexander Wachter <alexander.wachter@student.tugraz.at>
These calls are not accessible in CI test, nor do they get built on
common platforms (in at least one case I found a typo which proved the
code was truly unused). These changes are blind, so live in a
separate commit. But the nature of the port is mechanical, all other
syscalls in the system work fine, and any errors should be easily
corrected.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
move can.h to drivers/can.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
can_attach_msgq can be implemented as a wrapper of can_attach_isr.
This is implemented as a common function for all drives and reduces
the complexity of the specific drivers. Since this is common to
multi instances of drivers too, it is removed from the API struct.
Signed-off-by: Alexander Wachter <alexander.wachter@student.tugraz.at>
This commit extends the CAN api can_send function by an argument
that is passed to the isr callback.
With this extension it is possible to distinguish between sent masseges
when they use the same callback.
Signed-off-by: Alexander Wachter <alexander.wachter@student.tugraz.at>
Update reserved function names starting with one underscore, replacing
them as follows:
'_k_' with 'z_'
'_K_' with 'Z_'
'_handler_' with 'z_handl_'
'_Cstart' with 'z_cstart'
'_Swap' with 'z_swap'
This renaming is done on both global and those static function names
in kernel/include and include/. Other static function names in kernel/
are renamed by removing the leading underscore. Other function names
not starting with any prefix listed above are renamed starting with
a 'z_' or 'Z_' prefix.
Function names starting with two or three leading underscores are not
automatcally renamed since these names will collide with the variants
with two or three leading underscores.
Various generator scripts have also been updated as well as perf,
linker and usb files. These are
drivers/serial/uart_handlers.c
include/linker/kobject-text.ld
kernel/include/syscall_handler.h
scripts/gen_kobject_list.py
scripts/gen_syscall_header.py
Signed-off-by: Patrik Flykt <patrik.flykt@intel.com>
* Registration of interrupt context callbacks from user mode
is forbidden.
- Remove can_attach_isr() as a system call
- Enforce that can_send() has a NULL callback parameter
* k_msgq are kernel objects that do not live in user memory.
Fix the checks for it in can_attach_msgq().
* CAN API documentation was with the API struct typedefs and
not the actual APIs. Moved.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Change the parameter types from can_msg to zcan_frame and from
can_filter to zcan_filter.
Signed-off-by: Alexander Wachter <alexander.wachter@student.tugraz.at>
