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

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

On 21/02/2026 15:33:48+0100, Danilo Krummrich wrote:
> On Sat Feb 21, 2026 at 12:19 PM CET, Rafael J. Wysocki wrote:
> > On Sat, Feb 21, 2026 at 12:16 PM Alexandre Belloni
> > <alexandre.belloni@bootlin.com> wrote:
> >> > > Out of 29 drivers, 18 are doing so.
> >
> > The vast majority of around 50 platform drivers I've inspected
> > recently use platform_set_drvdata() or equivalent in probe.
> 
> 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.

An i2c RTC is not either an i2c device or an RTC, it is a single device
and we need to be able to tell the framework when something happens on
the bus or we need to be able to talk on the bus when we want to do
something with the device.


>   (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 get that you are trying to avoid most of the issues by using devres
but I'm pretty sure there are cases where this doesn't work.

>   Instead, it gives drivers the option to differentiate in terms of ownership
>   and lifetime.
> 
>   While the bus device private data has a very defined lifetime from probe()
>   until the device is unbound from the driver, class device private data might
>   live shorter than this, or might even out-live driver unbind in some cases. It
>   really depends on the lifetime of the class device itself, which is not
>   generally defined.
> 
>   Now, from a C side point of view this may not look like a big deal, as it
>   (unfortunately) is not that uncommon that struct fields are just initialized
>   and destroyed whenever needed and the code just takes it into account.
> 
>   But at the same time, this is what leads to a lot of lifetime problems and
>   memory bugs and it is one of those things that Rust aims at avoiding by being
>   very strict about initialization, ownership and lifetimes.
> 
>   However, I do also recognize that drivers creating an RTC device are typically
>   very simple and in practice I would not be surprised if it turns out that it
>   happens that drivers keep the struct rtc_device alive from probe() until the
>   bus device is unbound from the driver, i.e. lifetimes just end up being almost
>   the same. But I don't know if that's always the case.
> 
>   Regardless of that, 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.
> 

The whole point of the RTC is to outlive the system but as Linux can't do
anything with the RTC unless it has a bus device to talk to, the class
device and the bus device have the exact same lifetime and we do handle
device appearing and disappearing from the bus. You may think RTC
drivers afe simple but there are plenty of lifetime issues that you will
never get with any other devices because they simply die with the
system.


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