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

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

On Sun Feb 22, 2026 at 1:05 AM CET, Alexandre Belloni wrote:
> On 21/02/2026 15:33:48+0100, Danilo Krummrich wrote:
>>   (2) Bus device private data vs. class device private data.
>> 
>>   The change to pass a struct rtc_device in class device callbacks of RTC,
>>   rather than the base struct device of the corresponding bus device (e.g. AMBA,
>>   platform, etc.) should not aim at storing all data in rtc->dev.private_data
>>   that was previously stored in rtc->dev.parent->private_data.
>> 
>
> But what you explain here is that the drive is forbidden to use
> rtc->dev.parent->private_data at all because the rust core is already
> using it. What I'm saying is that it won't work because more than half
> of the drivers currently need it.

I think I was explaining the exact opposite, i.e. the driver's bus device
private data is stored in the exact same way as in C, but it has a defined
lifetime (from probe() until remove() and all devres callbacks have been
completed) and is managed by the driver-core.

Look at this example:

	// The bus device private data.
	struct SampleDriver {
	   foo: u32,
	   bar: u32,
	}
	
	impl pci::Driver for SampleDriver {
	    fn probe(pdev: &pci::Device<Core>, info: &Self::IdInfo) -> impl PinInit<Self, Error> {
	        // Return the driver's bus device private data. The driver-core
	        // will do all the work for us and eventually call
	        // `dev_set_drvdata()` on the base `struct device` of `pdev`.
	        Ok(Foo {
	            foo: 42,
	            bar: 24,
	        })
	    }
	
	    fn unbind(pdev: &pci::Device<Core>, self: Pin<&Self>) {
	        // Use the driver's device private data from the method's `self` argument.
	        dev_info!(pdev, "foo: {}, bar: {}\n", self.foo, self.bar);
	
	        // There's also the `Device<Bound>::drvdata()` accessor, let's
	        // use that as well.
	
	        // Get a generic `device::Device` from the `pci::Device`.
	        let dev = pdev.as_ref();
	
	        // Get the `drvdata`; we have to assert the type and let the driver-core
	        // validate that the asserted type is correct.
	        let drvdata = dev.drvdata::<SampleDriver>()?;
	
	        dev_info!(pdev, "foo: {}, bar: {}\n", drvdata.foo, drvdata.bar);
	    }
	}

>> This thread seems to contain quite a bit of confusion and misunderstandings --
>> let me try to clarify.
>> 
>>   (1) How Rust handles bus device private data.
>> 
>>   In Rust the probe() function of a bus implementation (platform, PCI, etc.)
>>   returns an initializer (impl PinInit<T, Error>) for the driver's device
>>   private data.
>> 
>>   The bus implementation takes this initializer and passes it (together with the
>>   underlying struct device) to the driver-core. The driver-core allocates the
>>   required memory, initializes the memory with the given initializer and stores
>>   a pointer to the corresponding object with dev_set_drvdata().
>> 
>>   So, technically, in Rust all platform drivers call platform_set_drvdata().
>> 
>>   (Note that this is also true when the driver's device private data type is
>>   empty (i.e. it has no fields). In this case it could still have a destructor
>>   that must be called when the device private data structure is destroyed. Of
>>   course there is no real memory allocation when the struct's size is zero.)
>> 
>>   The driver's device private data can only be accessed when the bus device is
>>   bound to the driver, i.e. the driver can only access it with a &Device<Bound>;
>>   it (the driver's device private data) is automatically freed by the
>>   driver-core when remove() and all devres callbacks have been completed.
>> 
>>   I.e. the rules are - of course - the same as on the C side, but they are
>>   enforced by the type system and the driver-core code.
>> 
>
> This still doesn't explain how you get the class private data that you
> need when you are in a driver callback that is called from the bus (e.g.
> suspend/resume) from what you explain, the driver doesn't have any
> chance to pass it. The whole goal of a device driver is to be the glue
> between a class device and a bus device as essentially this is the exact
> physical device, just represented differently.

It is not always as simple as "one bus device corresponds to one class device".

Sometimes drivers have to deal with multiple class devices for a single bus
device, sometimes they are separated through the auxiliary bus or MFD.

For instance, take struct net_device. In the context of cfg80211 wireless
drivers may create arbitrary struct net_device instances, depending on how often
the add_virtual_intf() callback is called (through netlink); example in [1].

Now, regarding your question "How to access class device private data from bus
device callbacks?". Nothing prevents a driver from embedding the class device in
its bus device private data in one or the other way.

In the net device example above, the driver would probably keep a list (or
xarray, etc.) of net devices in its bus device private data, as they can be
created and removed at any point of time.

(Note that this is also a good example for when the class device private data
lives shorter than the bus device private data.)

Here is an example of this looks like in code using a DRM device as class
device.

	struct SampleIrqData;

	// The class device private data.
	struct SampleDrm {
	    sched: drm::GpuScheduler,
	}

	// The bus device private data.
	#[pin_data]
	struct SampleDriver {
	    #[pin]
	    irq: irq::Registration<SampleIrqData>,
	    drm: ARef<drm::Device<SampleDrm>, // Refcount of a `drm::Device`.
	}
	
	impl pci::Driver for SampleDriver {
	    fn probe(pdev: &pci::Device<Core>, info: &Self::IdInfo) -> impl PinInit<Self, Error> {
	        let dev = pdev.as_ref();

	        let drm = drm::Device::new(dev, SampleDrm::new()?)?;
	        drm.register();

	        Ok(impl_pin_init!(Self {
	            irq <- irq::Registration::new(...);
	            drm,
	        })
	    }
	
	    fn unbind(pdev: &pci::Device<Core>, self: Pin<&Self>) {
	        self.irq.synchronize();
	        self.drm.flush_scheduler();
	    }
	}

Note that the irq::Registration is dropped when the bus device is unbound,
whereas the GpuScheduler is dropped when the DRM device is dropped.

Of course, depending on the actual class device this difference may be more or
less important, i.e. absolutely crucial in the net device example, less
important for RTC apparently. But it is always good to be precise about
ownership and lifetime of data.

As I already mentioned, I don't think it is good to fold ownership and lifetime
for bus and class devices together in cases where it happens that they are
mostly identical, i.e.:

>>   I think it would be good to keep driver authors finding a common pattern,
>>   where class device callbacks carry the corresponding class device struct
>>   (instead of the parent base struct device).
>>
>>   Especially on the Rust side we now have the chance to make the experience
>>   of writing drivers as consistent as possible, which should help (new)
>>   driver authors a lot in terms of learning the driver lifetime patterns.

[1] https://elixir.bootlin.com/linux/v6.19.2/source/drivers/net/wireless/microchip/wilc1000/netdev.c#L948