Re: [RFC PATCH v1 4/4] rust: add PL031 RTC driver

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

(Cc: Greg, Rafael)

On Tue Jan 6, 2026 at 3:51 AM CET, Ke Sun wrote:
> Following the platform driver implementation, the AMBA driver stores its 
> drvdata in amba_device->dev. However,
> the RTC driver also stores its drvdata in the parent device (which is 
> also amba_device->dev), causing a conflict.

A simple driver usually has two devices to deal with:

  (1) The bus device, which represents the actual physical device sitting on
      some bus, e.g. PCI or platform.

  (2) A class device, which represents the higher level functionality - i.e. the
      class the device belongs to - to the upper layers, e.g. RTC, DRM, PWM,
      etc.

The bus device does not belong to the driver per se, it only gets bound to a
driver.  This relationship remains until the driver itself is unregistered, the
physical device falls off the bus or they are manually unbound from each other.

The driver's bus device private data only lives as long as the two are bound and
the lifetime is managed by the bus abstraction, e.g. platform or AMBA.

The class device is created by the driver to represent its functionality to the
upper layers; its lifetime is defined by the driver.

Other than the bus device private data, the class device private data typically
lives as long as the class device itself.

In the relationship between the two, the bus device becomes the parent device of
the class device.

If the class device implementation guarantees that it is unregistered when the
parent (bus) device is unbound (which is the most common case), i.e. no more
class device callbacks happen afterwards, the abstraction can treat the parent
device as &Device<Bound>, which allows drivers to directly access device
resources from the parent device without further synchronization.

The short answer for your question is, store the class device private data
within the class device itself, not within the parent device.

Alternatively, if the class device implementation does guarantee that in all its
callbacks the parent device is bound, i.e. you have a &Device<Bound>, you can
also access the bus device private data with Device<Bound>::drvdata().

In this case you can technically also omit having separate private data for the
class device at all.

However, while this is actually been done in quite some C drivers, I do not
recommend this:

  - At least in C this can become pretty error prone, given that bus device
    resources are only valid to access as long as the device is bound to the
    driver; in Rust we do protect against device resource accesses after driver
    unbind though.

  - Separating the private data properly encourages driver authors to actually
    think about ownership and lifetime of objects, eventually leading to better
    driver design.

A common pattern you will see in drivers is that the data relevant for the class
device goes into the class device private data and the class device itself is
stored within the bus device private data.

I hope this helps!

- Danilo