Namespaced the generated headers with `zephyr` to prevent
potential conflict with other headers.
Introduce a temporary Kconfig `LEGACY_GENERATED_INCLUDE_PATH`
that is enabled by default. This allows the developers to
continue the use of the old include paths for the time being
until it is deprecated and eventually removed. The Kconfig will
generate a build-time warning message, similar to the
`CONFIG_TIMER_RANDOM_GENERATOR`.
Updated the includes path of in-tree sources accordingly.
Most of the changes here are scripted, check the PR for more
info.
Signed-off-by: Yong Cong Sin <ycsin@meta.com>
Since the minimum/maximum supported bitrates are now stored in the common
CAN controller driver configuration struct, retrieving these can no longer
fail.
Add new CAN controller API functions can_get_bitrate_min() and
can_get_bitrate_max() reflecting this and deprecate the existing
can_get_min_bitrate() and can_get_max_bitrate().
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add a new CAN controller API function can_get_min_bitrate() for getting the
minimum supported bitrate of a CAN controller/transceiver combination.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Since all CAN controllers drivers seem to support automatic recovery (for
any future drivers for hardware without this hardware capability this can
easily be implemented in the driver), change the Zephyr CAN controller API
policy to:
- Always enable automatic bus recovery upon driver initialization,
regardless of Kconfig options. Since CAN controllers are initialized in
"stopped" state, no unwanted bus-off recovery will be started at this
point.
- Invert and rename the Kconfig CONFIG_CAN_AUTO_BUS_OFF_RECOVERY, which is
enabled by default, to CONFIG_CAN_MANUAL_RECOVERY_MODE, which is disabled
by default. Enabling CONFIG_CAN_MANUAL_RECOVERY_MODE=y enables support
for the can_recover() API function and a new manual recovery mode (see
next bullet). Keeping this guarded by Kconfig allows keeping the flash
footprint down for applications not using manual bus-off recovery.
- Introduce a new CAN controller operational mode
CAN_MODE_MANUAL_RECOVERY. Support for this is only enabled if
CONFIG_CAN_MANUAL_RECOVERY_MODE=y. Having this as a mode allows
applications to inquire whether the CAN controller supports manual
recovery mode via the can_get_capabilities() API function and either fail
or rely on automatic recovery - and it allows CAN controller drivers not
supporting manual recovery mode to fail early in can_set_mode() during
application startup instead of failing when can_recover() is called at a
later point in time.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add system call can_get_transceiver() for getting the CAN transceiver
associated with a CAN controller.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the syscall_handler.h header, used internally only to a dedicated
internal folder that should not be used outside of Zephyr.
Signed-off-by: Anas Nashif <anas.nashif@intel.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>
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>
