-
-
Notifications
You must be signed in to change notification settings - Fork 771
Fixing deferred calls registering for rp2040 rtc #4098
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
Fixing deferred calls registering for rp2040 rtc #4098
Conversation
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.
This is a real problem with Tock we need to think more about so that this doesn't happen in the future. But I appreciate the fix.
@@ -67,7 +67,6 @@ impl<D: 'static + date_time::DateTime<'static> + kernel::deferred_call::Deferred | |||
let grant_date_time = self.board_kernel.create_grant(self.driver_num, &grant_dt); | |||
|
|||
let date_time = s.write(DateTimeCapsule::new(self.rtc, grant_date_time)); | |||
kernel::deferred_call::DeferredCallClient::register(self.rtc); |
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.
Shouldn't boards that do use the DateTime driver still have their deferred call be registered through that component? For instance, the Nucleo F429ZI also uses this component and may rely on this line to be present, right?
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 think that each driver that creates a DeferredCall
instance needs to register the deferred call. In the case here, the DateTimeCapsule
does not create a new DeferredCall
instance and has no idea if the underlying rtc
actually creates one.
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.
The stm32 chip does register its deferred call here
kernel::deferred_call::DeferredCallClient::register(&self.rtc); |
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.
Gotcha, this makes sense to me! Just wanted to check that this PR doesn't inadvertently break any other boards.
It seems then that the STM board instantiation worked, but double-registered the deferred call? Looking at the kernel code, that looks like it just works right now. I'm wondering whether it'd make sense to panic in this case (perhaps configurable behind a flag).
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 think we need to check this in a better way, the bug was very subtle, took us a while to figure it out.
Pull Request Overview
This pull request fixes the rp2040 chip's
rtc
driver to register its deferred call. Before this fix, theDateTimeComponent
was registering it. This meant that any board that does not use theDateTime
driver, like the Pico Explorer Base, panics at init due to unregistered deferred call.Testing Strategy
This pull request was tested on Raspberry Pi Pico (connected to Pico Explorer Base).
TODO or Help Wanted
N/A
Documentation Updated
/docs
, or no updates are required.Formatting
make prepush
.