Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks

[Alexandre Belloni <alexandre.belloni@bootlin.com>]

On 24/02/2026 17:35:23+0100, Danilo Krummrich wrote:
> On Tue Feb 24, 2026 at 4:01 PM CET, Alexandre Belloni wrote:
> > On 24/02/2026 01:12:32+0100, Danilo Krummrich wrote:
> >> 	impl pci::Driver for SampleDriver {
> >> 	    fn probe(pdev: &pci::Device<Core>, info: &Self::IdInfo) -> impl PinInit<Self, Error> {
> >> 	        let dev = pdev.as_ref();
> >> 
> >> 	        let rtc_data = impl_pin_init!(SampleRtcData {
> >> 	            io: iomap_region_sized::<BAR0_SIZE>(0, c"my_rtc/bar0")?,
> >> 	            hw_variant: VendorVariant::StV1,
> >> 	        });
> >> 
> >> 	        let rtc = rtc::Device::new(dev, rtc_data)?;
> >> 
> >> 	        // Internally calls `devres::register(rtc::Registration::new())`.
> >> 	        rtc::Registration::register(rtc)?;
> >> 
> >> 	        Ok(impl_pin_init!(Self {
> >> 	            // Give the IRQ handler a reference count of the `rtc::Device`.
> >> 	            irq <- irq::Registration::new(..., rtc.clone()),
> >> 	            rtc,
> >> 	        })
> >
> > I can't really read rust yet but this seems to open a race condition
> > with userspace if irq::Registration::new(...) fails, there is an
> > ordering constraint you missed.
> 
> (I did not have any specific hardware in mind when sketching this up (e.g. an
> IRQ could also only be needed in bus device callbacks, e.g. for loading firmware
> etc.). But for RTC it obviously is common that it is relevant to the class
> device too.)
> 
> So, I assume you mean because there could already be an ioctl before the IRQ has
> been successfully registered, and this ioctl may wait for an IRQ?
> 
> In this case the irq::Registration should go into rtc_data instead to account
> for this dependency. Unfortunately, this is a semantic dependency that we can't
> always catch at compile time.
> 
> The reason we sometimes can is because, if you would need access to the
> irq::Registration from ioctls (e.g. for calling synchronize(), enable(),
> disable() etc.) it would be caught, because you couldn't access it without it
> being in rtc_data in the first place, and being forced to have it in rtc_data
> guarantees that the ordering can't be wrong.

No, once you register the rtc, the character device will appear in
userspace and may be opened, at this point, probe is not allowed to fail
anymore which you are allowing by trying to register the IRQ so late.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com