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

["Danilo Krummrich" <dakr@kernel.org>]

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.