RFC: Breaking API Change: drivers: can: remove run-time RTR filtering, add build-time RTR filter #67127
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
henrikbrixandersen
added
RFC
henrikbrixandersen
force-pushed
the
can_remove_rtr_runtime_filter
branch
2 times, most recently
from
930a20a to
728ae88
Compare
henrikbrixandersen
changed the title
henrikbrixandersen
added
area: API
henrikbrixandersen
force-pushed
the
can_remove_rtr_runtime_filter
branch
from
8a6d583 to
a242bcb
Compare
henrikbrixandersen
force-pushed
the
can_remove_rtr_runtime_filter
branch
2 times, most recently
from
7ba4763 to
a422b39
Compare
henrikbrixandersen
requested review from
aaillet,
karstenkoenig,
manuargue,
erwango,
ABOSTM,
FRASTM,
mmahadevan108 and
dleach02
as code owners
henrikbrixandersen
added
the
Architecture Review
zephyrbot
requested review from
alexanderwachter,
jukkar,
martinjaeger,
rlubos,
ssharks and
str4t0m
henrikbrixandersen
force-pushed
the
can_remove_rtr_runtime_filter
branch
from
a422b39 to
8ec026b
Compare
|
Architecture WG:
|
henrikbrixandersen
removed
the
Architecture Review
|
This PR is ready for review. |
henrikbrixandersen
force-pushed
the
can_remove_rtr_runtime_filter
branch
from
8ec026b to
a6ea46f
Compare
|
Rebased to fix merge conflict after 9eb0a55. |
jukkar
reviewed
Jan 17, 2024
martinjaeger
previously approved these changes
Jan 18, 2024
henrikbrixandersen
force-pushed
the
can_remove_rtr_runtime_filter
branch
from
a6ea46f to
d249c18
Compare
martinjaeger
requested changes
Jan 19, 2024
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 <[email protected]>
Add a note about the removal of the CAN_FILTER_DATA and CAN_FILTER_RTR flags from the CAN controller driver API. Signed-off-by: Henrik Brix Andersen <[email protected]>
henrikbrixandersen
force-pushed
the
can_remove_rtr_runtime_filter
branch
from
d249c18 to
bff7b62
Compare
martinjaeger
approved these changes
Jan 20, 2024
nandojve
approved these changes
Jan 20, 2024
jukkar
approved these changes
Jan 20, 2024
manuargue
approved these changes
Jan 21, 2024
sasataku
added a commit
to sasataku/libcsp
that referenced
this pull request
Jan 24, 2024
In Zephyr, with PR below, `CAN_FILTER_DATA` and `CAN_FILTER_RTR` have been removed. - zephyrproject-rtos/zephyr#67127 Originally, `CAN_FILTER_DATA` was specified explicitly to filter CAN Data Frames, but in reality, in the Zephyr driver, it is possible to filter CAN Data Frames without specifying `CAN_FILTER_DATA`. Therefore, in this commit, `CAN_FILTER_DATA` is removed. Signed-off-by: Takuya Sasaki <[email protected]>
sasataku
added a commit
to sasataku/libcsp
that referenced
this pull request
Jan 24, 2024
In Zephyr, with PR below, `CAN_FILTER_DATA` and `CAN_FILTER_RTR` have been removed. - zephyrproject-rtos/zephyr#67127 Originally, `CAN_FILTER_DATA` was specified explicitly to filter CAN Data Frames, but in reality, in the Zephyr driver, it is possible to filter CAN Data Frames without specifying `CAN_FILTER_DATA`. Therefore, in this commit, `CAN_FILTER_DATA` is removed. Signed-off-by: Takuya Sasaki <[email protected]>
yashi
pushed a commit
to libcsp/libcsp
that referenced
this pull request
Jan 25, 2024
In Zephyr, with PR below, `CAN_FILTER_DATA` and `CAN_FILTER_RTR` have been removed. - zephyrproject-rtos/zephyr#67127 Originally, `CAN_FILTER_DATA` was specified explicitly to filter CAN Data Frames, but in reality, in the Zephyr driver, it is possible to filter CAN Data Frames without specifying `CAN_FILTER_DATA`. Therefore, in this commit, `CAN_FILTER_DATA` is removed. Signed-off-by: Takuya Sasaki <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
RFC: #67128