Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add CAN FD flags to CAN header #3110

Merged

Conversation

j4r0u53k
Copy link
Contributor

@j4r0u53k j4r0u53k commented Mar 19, 2021

Summary

The first commit 333345a adds EDL, BRS and ESI bits added to struct can_hdr_s.

The `ch_unused' field is useless (adjacent fields in packed structs are aligned to the next byte), but some
drivers explicitly set this field to zero, so it is kept there for backward compatibility of the API.

When started using DLC > 8 a bug in can_write was revealed. This is fixed (or I would better say work arounded with respect to keeping maximum backward compatibility and not possibly breaking other components) in commit 571dd60.

Impact

These changes are API backward compatible.

Testing

Tested on Bosch M_CAN controller on SAMv7 chip (needs additional changes to that driver not included in this pull request).

@j4r0u53k j4r0u53k changed the title Add CAN FD flags to can header Add CAN FD flags to CAN header Mar 19, 2021
Copy link
Contributor

@davids5 davids5 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@xiaoxiang781216
Copy link
Contributor

@j4r0u53k please fetch the latest master, rebase your change and push -f again.

EDL, BRS and ESI bits added to struct can_hdr_s.

The `ch_unused' field is useless (adjacent fields in
packed structs are aligned to the next byte), but some
drivers explicitly set this field to zero, so it is kept there
for API backward compatibility.

Signed-off-by: Jaroslav Beran <jara.beran@gmail.com>
Because buflen is size_t (unsigned) and nsent is ssize_t (signed)
of the same size, (buflen - nsent) results in unsigned and
overflows if nsent > buflen.

This happens when sending CAN FD frame with DLC > 8 and a user
gets the buflen parameter as a result of CAN_MSGLEN(len)
where `len' is the size of data which is less then a size
for some extended DLC  (e.g. 26 bytes is sent in a message with
DLC 0xD, which has 32 bytes of data).

The correct buflen value should be rather
  CAN_MSGLEN(can_dlc2bytes(can_bytes2dlc(len)))

Signed-off-by: Jaroslav Beran <jara.beran@gmail.com>
@j4r0u53k j4r0u53k force-pushed the add-can-fd-flags-to-can-header branch from 571dd60 to b875eb9 Compare March 19, 2021 23:31
@xiaoxiang781216 xiaoxiang781216 merged commit 7c96a25 into apache:master Mar 20, 2021
@btashton btashton added this to To-Add in Release Notes - 10.1.0 Apr 12, 2021
@jerpelea jerpelea moved this from To-Add to drivers in Release Notes - 10.1.0 Apr 13, 2021
@jerpelea jerpelea moved this from drivers to Added in Release Notes - 10.1.0 Apr 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

3 participants