-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
RFC: Breaking API Change: drivers: can: rework support for manual bus-off recovery #69460
RFC: Breaking API Change: drivers: can: rework support for manual bus-off recovery #69460
Conversation
933a96b
to
629a39b
Compare
629a39b
to
453e4d9
Compare
36cc408
to
d4e44a6
Compare
e645eb0
to
8992d05
Compare
RFC ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
Only got one minor non-blocking comment which may be applied to some other drivers as well.
can_mode_t supported = CAN_MODE_LOOPBACK | CAN_MODE_LISTENONLY; | ||
struct can_mcan_data *data = dev->data; | ||
uint32_t cccr; | ||
uint32_t test; | ||
int err; | ||
|
||
#ifdef CONFIG_CAN_FD_MODE | ||
if ((mode & ~(CAN_MODE_LOOPBACK | CAN_MODE_LISTENONLY | CAN_MODE_FD)) != 0U) { | ||
LOG_ERR("unsupported mode: 0x%08x", mode); | ||
return -ENOTSUP; | ||
if (IS_ENABLED(CONFIG_CAN_MANUAL_RECOVERY_MODE)) { | ||
supported |= CAN_MODE_MANUAL_RECOVERY; | ||
} | ||
#else /* CONFIG_CAN_FD_MODE */ | ||
if ((mode & ~(CAN_MODE_LOOPBACK | CAN_MODE_LISTENONLY)) != 0U) { | ||
|
||
if (IS_ENABLED(CONFIG_CAN_FD_MODE)) { | ||
supported |= CAN_MODE_FD; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not call can_mcan_get_capabilities
here in order to avoid code duplication?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, it seems that all drivers can benefit from this and avoid issues like #69460 (comment) :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, yes - I too noticed that pattern when converting the drivers. I didn't want to mix that change into this PR, but I'm preparing to move this generic check into the can_set_mode()
implementation function itself.
Look good to me. zephyr/drivers/can/can_nxp_s32_canxl.c Line 153 in 8992d05
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missing capability for manual recovery mode in NXP S32 CAXL driver as pointed out above
f5b8907
Nicely spotted, thanks. I have updated the patch. |
f5b8907
to
71f1775
Compare
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 <[email protected]>
List the changes to the CAN bus-off recovery functionality. Signed-off-by: Henrik Brix Andersen <[email protected]>
71f1775
to
9426740
Compare
Rebased on |
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.
RFC: #69459