Re: [RFC PATCH v2 1/5] rtc: migrate driver data to RTC device

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

On Thu Jan 15, 2026 at 12:23 AM CET, Ke Sun wrote:
> RTC ops callbacks receive struct device * as the first parameter.
> Traditionally this is rtc->dev.parent (the physical bus device), but Rust
> drivers store driver data on rtc->dev itself,

This is not only about Rust. Class device private data should be stored in the
driver_data field of the struct device embedded in the class device in general.

> so callbacks need &rtc->dev  to access it.

Class device callbacks should just carry the class device itself, rather than
the embedded struct device.

> We considered switching all callbacks to use rtc->dev directly, but that would
> require modifying  182 RTC drivers and extensive testing/validation work.

I don't know if it's that bad, the change would be trivial. You just need to
repeat it pretty often. :) Tools like Coccinelle [1] can help a lot with such
refactorings.

> Instead, we propose an alternative approach:
>
> - Added RTC_OPS_USE_RTC_DEV flag (currently stored in rtc->features bitmap)
> - Created rtc_ops_dev() helper that returns &rtc->dev if flag is set, 
> otherwise
>     rtc->dev.parent. Default behavior (returning rtc->dev.parent) maintains
>     backward compatibility
> - Updated all rtc->ops->callback call sites to use rtc_ops_dev(rtc)

Not sure if that intermediate step is needed, but it doesn't seem unreasonable
to me.

While eventually this is up to the RTC subsystem maintainer, from a driver-core
perspective this refactoring is encouraged:

Drivers should generally distinguish between stuff that is stored in the private
data of the bus device and private data of the class device, e.g. since they
have independent lifecycles and not all data might be relevant in all scopes.

Forcing drivers to also store the class device private data in the parent bus
device private data can be considered an anti-pattern.

[1] https://docs.kernel.org/dev-tools/coccinelle.html