Remove unnecessary asserts from various CAN controller drivers. These
asserts are all covered by the common CAN subsystem API implementations.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add support for specifying the minimum bitrate supported by a CAN
controller in CAN_DT_DRIVER_CONFIG_GET() and
CAN_DT_DRIVER_CONFIG_INST_GET().
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
On HAL RTD version 1.0.0, there is available Canexcel_Ip_DeactivateMD()
API that have similar capabilities as can_nxp_s32_abort_msg() API,
can use to instead.
Remove the reg grp_ctrl and reg base_dsc_ctrl that unused
after implementation this.
Signed-off-by: Cong Nguyen Huu <cong.nguyenhuu@nxp.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>
Propagate the current CAN controller operation mode to the CAN transceiver
when enabling it.
Some more advanced CAN transceivers, especially those supporting Partial
Networking (CAN PN), require knowledge of the intended CAN operation mode
(e.g. normal mode vs. listen-only mode).
This commit simply prepares the CAN transceiver API for supporting such CAN
transceivers, although no in-tree drivers require this information yet.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
This is driver limitation after removing CAN_FILTER_FDF flag #65108.
CANXL driver need to know CAN_FILTER_FDF for configuring Rx filter
so that it receives CAN classic or CAN FD frames when using non RX_FIFO.
So update driver that just supports CAN classic for non RX_FIFO.
Signed-off-by: Cong Nguyen Huu <cong.nguyenhuu@nxp.com>
A growing number of CAN controllers do not have support for individual RX
hardware filters based on the Remote Transmission Request (RTR) bit. This
leads to various work-arounds on the driver level mixing hardware and
software filtering.
As the use of RTR frames is discouraged by CAN in Automation (CiA) - and
not even supported by newer standards, e.g. CAN FD - this often leads to
unnecessary overhead, added complexity, and worst-case to non-portable
behavior between various CAN controller drivers.
Instead, move to a simpler approach where the ability to accept/reject RTR
frames is globally configured via Kconfig. By default, all incoming RTR
frames are rejected at the driver level, a setting which can be supported
in hardware by most in-tree CAN controllers drivers.
Legacy applications or protocol implementations, where RTR reception is
required, can now select CONFIG_CAN_ACCEPT_RTR to accept incoming RTR
frames matching added CAN filters. These applications or protocols will
need to distinguish between RTR and data frames in their respective CAN RX
frame handling routines.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Remove the CAN_FILTER_FDF flag for filtering on classic CAN/CAN FD frames
as it is not supported natively by any known CAN controller.
Applications can still filter on classic CAN/CAN FD frames in their receive
callback functions as needed.
Fixes: #64554
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
At present, many of the NXP S32 shim drivers do not make use of
devicetree instance-based macros because the NXP S32 HAL relies on an
index-based approach, requiring knowledge of the peripheral instance
index during both compilation and runtime, and this index might not
align with the devicetree instance index.
The proposed solution in this patch eliminates this limitation by
determining the peripheral instance index during compilation
through macrobatics and defining the driver's ISR within the shim
driver itself.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
Unify spelling of CAN Flexible Data-rate abbreviation to "CAN FD" instead
of "CAN-FD". The former aligns with the CAN in Automation (CiA)
recommendation.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Change the CAN controller driver implementations for the
can_remove_rx_filter() API call to be consistent in their validation of the
supplied filter_id.
Fixes: #64398
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
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>
Use clock control API to retrieve the module's frequency and
update the boards using it to provide the source clocks.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
This patch introduces support for NXP S32 CANEXCEL (CANXL) peripheral.
CAN protocol supporting:
- CAN classic
- CAN FD
Remote transmission request is not supported as this feature is not
available on NXP S32 CANXL HAL.
Signed-off-by: Cong Nguyen Huu <cong.nguyenhuu@nxp.com>
