Remove the CAN_STM32FD_CLOCK_DIVISOR configuration option,
and add configuration via dts property clk-divider instead.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
The configurable CAN clock divider CAN_STM32FD_CLOCK_DIVISOR
was not applied during initialization, because write protection
was not disabled.
While the clock divider was not applied, it was still used in clock rate
calculation, therefore resulting in incorrect bus speed setup.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
Use domain clocks if they are defined in dts.
Until now domain clock sources could be selected via kconfig.
STM32 platform now can configure domain clock sources via
clock control driver, therefore this commit makes use of it.
The configuration is shared between canfd instances, so a domain clock
has to be defined for only one instance. Otherwise, only the
configuration from the latest initialized instance will remain.
The dependency on clock source PCLK1 for CAN_STM32FD_CLOCK_DIVISOR
was removed, because the divider also divides other clocks.
Note that setting that divider does not work at all at the moment,
because the write protection is not disabled.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Many device pointers are initialized at compile and never changed. This
means that the device pointer can be constified (immutable).
Automated using:
```
perl -i -pe 's/const struct device \*(?!const)(.*)= DEVICE/const struct
device *const $1= DEVICE/g' **/*.c
```
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Change the error code for can_send() when the CAN controller is in bus off
state from -ENETDOWN to -ENETUNREACH.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the can_state enumerations to contain the word STATE to make their
meaning more clear:
- CAN_ERROR_ACTIVE => CAN_STATE_ERROR_ACTIVE
- CAN_ERROR_WARNING => CAN_STATE_ERROR_WARNING
- CAN_ERROR_PASSIVE => CAN_STATE_ERROR_PASSIVE
- CAN_BUS_OFF => CAN_STATE_BUS_OFF
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Expand the error return values reported by the CAN timing calculation
functions to be able to distinguish between an an out of range
bitrate/sample point, an unsupported bitrate, and a resulting sample point
outside the guard limit.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the check for the maximum allowed CAN bitrate to the corresponding
can_calc_timing()/can_calc_timing_data() function.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the NXP FlexCAN driver internal functions and macros to not use
"zcan", "zframe", and "zfilter" to avoid confusion after "struct can_frame"
and "struct can_filter" renaming.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the mcp2515 driver internal functions to not use "zcan" to avoid
confusion after "struct can_frame" renaming.
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>
Remove the Kconfig option for configuring the maximum value of the CAN-FD
Data Length Code in order to ensure standard compliance.
Allowing users to configure the max DLC allows the user to save a number of
bytes per CAN frame in RAM, but it also renders the Zephyr CAN-FD
implementation non-compliant with the CAN-FD standard.
There are no guarantees that a Zephyr CAN-FD node will not receive a CAN
frame with a DLC higher than the Kconfig limit, which opens up for all
sorts of bugs when trying to handle received CAN-FD frames.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The previous driver implementation aimed to maximize the amount of
filters, which resulted in a fairly complex implementation.
Background: The bxCAN assigns a number to the filters in the order they
appear in the filter banks. This number is used to match messages in
the FIFO with their filter. If the scale or mode of a filter bank is
changed, all following filter numbers get an offset and the assigned
callbacks have to be shifted accordingly.
The required additional space for the shifting operations resulted in
non-deterministic behaviour and the maximum number of filters could not
be determined at compile-time, which made several tests like
tests/drivers/can/api fail.
This implementation uses a more simple but reliable approach for
filtering and and reserves fixed space for extended and standard ID
filters in the available banks (configurable via Kconfig).
The list mode is not used, which may reduce the total number of usable
filters depending on the application.
The maximum amount of filters is 14 if all filters use ext. IDs,
28 if all use std IDs and something in between if mixed IDs are used.
Also see issue #47986 for more detailed background information.
Signed-off-by: Martin Jäger <martin@libre.solar>
Namespace local functions, enums, structs and defines with stm32/STM32
to distinguish them from global CAN API.
Also rename some internal conversion functions to make their meaning
more clear and delete unused defines.
Signed-off-by: Martin Jäger <martin@libre.solar>
Add ESP32 TWAI CAN controller driver. The TWAI is register-compatible with
the NXP SJA1000 CAN controller.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
MISRA C:2012 Rule 14.4 (The controlling expression of an if statement
and the controlling expression of an iteration-statement shall have
essentially Boolean type.)
Use `do { ... } while (false)' instead of `do { ... } while (0)'.
Use comparisons with zero instead of implicitly testing integers.
The commit is a subset of the original auditable-branch commit:
5d02614e34a86b549c7707d3d9f0984bc3a5f22a
Signed-off-by: Simon Hein <SHein@baumer.com>
Update CAN drivers to use DT_HAS_<compat>_ENABLED Kconfig symbol to expose
the driver and enable it by default based on devicetree.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Check the frame ID type and RTR bit when comparing loopback CAN frames
against installed RX filters.
Fixes: #47904
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
When installing a RX filter, the driver uses "filter->rtr &
filter->rtr_mask" for setting the filter mask. It should just be using
filter->rtr_mask, otherwise filters for non-RTR frames will match RTR
frames as well.
When transmitting a RTR frame, the hardware automatically switches the
mailbox used for TX to RX in order to receive the reply. This, however,
does not match the Zephyr CAN driver model, where mailboxes are dedicated
to either RX or TX. Attempting to reuse the TX mailbox (which was
automatically switched to an RX mailbox by the hardware) fails on the first
call, after which the mailbox is reset and can be reused for TX. To
overcome this, the driver must abort the RX mailbox operation when the
hardware performs the TX to RX switch.
Fixes: #47902
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The Bosch M_CAN IP does not support RX filtering of the RTR bit, so the
driver handles this bit in software.
If a recevied frame matches a filter with RTR enabled, the RTR bit of the
frame must match that of the filter in order to be passed to the RX
callback function. If the RTR bits do not match the frame must be dropped.
Improve the readability of the the logic for determining if a frame should
be dropped and add a missing FIFO acknowledge write for dropped frames.
Fixes: #47204
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the CAN bus network driver from drivers/can to drivers/net as it
implements a network driver, not a CAN controller driver.
Use a separate Kconfig for enabling the CAN bus network driver instead of
piggybacking on the SocketCAN Kconfig. This allows for other
(e.g. out-of-tree) SocketCAN transports.
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>
Switch from using a driver-specific, compile-time devicetree one-shot
property to supporting the newly added CAN_MODE_ONE_SHOT flag for
enabling/disabling one-shot mode at run-time.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Fix issue #45168.
When setting high bit timing, the controller is timing
out when trying to switch from an internal mode to another.
To fix this issue, we add some delay when switching modes.
Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
Fix issue #45169.
With this CAN controller, changing bit timing has to be done in controller
reset mode, resetting some registers to their default values.
TCR register, that is enabling loopback mode is one of these.
Because of this reset, the controller switch back from loopback
to normal mode without the test suite being notified, preventing
receiving sent frames afterwards.
To fix this issue, we are now storing useful registers values before
switching to reset mode and restoring these values in halt mode
before going back in operation mode.
Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
CAN1 and CAN2 share the memory for the filter banks.
This commit adds an offset for filters installed for CAN2, allowing to
use both CAN instances simultaneously.
The hardware allows to freely split the avalable 28 filters between
CAN1 and CAN2. In order to simplify the driver implementation, it only
supports an equal split of 14 filters per instance. This is the same
amount of filters as available in MCUs with only a single CAN.
Signed-off-by: Martin Jäger <martin@libre.solar>
Remove two functions which were only called from one place and did
not improve readibility of the code.
Signed-off-by: Martin Jäger <martin@libre.solar>
This commit unifies the driver initialization for can1 and can2
instances so that a single macro can be used.
Enabling the master clock for can2 as introduced in 8ab81b02 had to
be moved to devicetree in order to have the same CAN_STM32_CONFIG_INST
macro for all instances.
Signed-off-by: Martin Jäger <martin@libre.solar>
the return is missing at the end of function which causes compilation
warning and block the build on github.
"warning: control reaches end of non-void function [-Wreturn-type]
92 | }| ^"
Signed-off-by: TLIG Dhaou <dhaou.tlig-ext@st.com>
The FDCAN clock was being enabled using HAL APIs instead of the generic
clock control API.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
For devices with more than one CAN peripherals, CAN1 is the master and
its clock has to be enabled also if only CAN2 is used.
Signed-off-by: Martin Jäger <martin@libre.solar>
Assertions in can_mcan failed because the driver expects values
strictly greater than 0
Signed-off-by: Tomislav Milkovic <tomislav.milkovic95@gmail.com>
Add support for enabling/disabling CAN-FD frame transmission/reception at
run-time.
Fixes: #45303
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
