Commit graph

10 commits

Author SHA1 Message Date
Henrik Brix Andersen 71fe0f413b drivers: can: remove unnecessary asserts
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>
2024-04-24 09:53:06 +02:00
Henrik Brix Andersen 6d35ec718f drivers: can: add support for specifying minimum supported CAN bitrate
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>
2024-03-12 10:43:36 +01:00
Henrik Brix Andersen a57db0ddcb drivers: can: rework support for manual bus-off recovery
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>
2024-03-02 18:26:48 +01:00
Mathieu Choplain 6ff47b15db drivers: can: add missing argument to LOG_ERR call
PR #64399 introduced checks for out-of-bounds filter IDs
in CAN drivers, along with logging of said IDs; however,
the call to LOG_ERR in the native POSIX/Linux driver is
missing the 'filter_id' argument.

This commit adds the missing argument to ensure proper
data is printed when the LOG_ERR call is performed.

Signed-off-by: Mathieu Choplain <mathieu.choplain@st.com>
2024-02-25 20:45:29 -05:00
Henrik Brix Andersen 3436c93387 drivers: can: remove run-time RTR filtering, add build-time RTR filter
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>
2024-01-21 11:00:31 +01:00
Henrik Brix Andersen 75117a0deb drivers: can: remove CAN_FILTER_FDF flag
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>
2024-01-19 09:55:43 +01:00
Henrik Brix Andersen b55051ca9e drivers: can: native_linux: flexcan: use common config and data structures
Use the common CAN controller driver configuration and data structures.

Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
2024-01-19 09:45:29 +01:00
Alberto Escolar Piedras 5382f827d6 drivers can_native_linux: Avoid using ssize
ssize is a POSIX.1-2001 extension, which may or may
not be provided by the C library, or may be defined
to a different size in the host and embedded C library.

Two internal functions were returning ssize, but
one of them was a trampoline into the same host API,
which is already provided by the native simulator
so let's just use that instead.

The other is only carrying data that fits into an
int and is anyhow being cast in/to ints, so let's just
avoid the trouble by defining it as returning int.

Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
2024-01-15 21:59:56 +01:00
Henrik Brix Andersen c067f4d263 drivers: can: native_linux: add missing return value check
Check return value from linux_socketcan_set_mode_fd() function call.

Fixes: #66798

Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
2023-12-22 09:49:39 +01:00
Henrik Brix Andersen fe74ffe2d5 drivers: can: drop POSIX from the native Linux SocketCAN driver name
Rename the native Linux SocketCAN driver to reflect that it can can now be
used in both native_posix and native_sim (with or without an embedded
C-library).

Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
2023-12-12 14:28:26 +00:00
Renamed from drivers/can/can_native_posix_linux.c (Browse further)