Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

inesmaria08
Copy link
Contributor

Pull Request Overview

This pull request fixes the rp2040 chip's rtc driver to register its deferred call. Before this fix, the DateTimeComponent was registering it. This meant that any board that does not use the DateTime 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

  • Updated the relevant files in /docs, or no updates are required.

Formatting

  • Ran make prepush.

Copy link
Contributor

@bradjc bradjc left a 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);
Copy link
Member

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?

Copy link
Contributor

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.

Copy link
Contributor

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);
.

Copy link
Member

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).

Copy link
Contributor

@alexandruradovici alexandruradovici Jul 12, 2024

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.

@lschuermann lschuermann added the last-call Final review period for a pull request. label Jul 12, 2024
@ppannuto ppannuto added bug P-Upkeep This a relatively minor change, or one that is limited in scope, and requires less scrutiny. labels Jul 12, 2024
@ppannuto ppannuto added this pull request to the merge queue Jul 12, 2024
Merged via the queue into tock:master with commit 803fc0a Jul 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug component last-call Final review period for a pull request. P-Upkeep This a relatively minor change, or one that is limited in scope, and requires less scrutiny.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants