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

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

On 08/01/2026 15:06:46+0100, Danilo Krummrich wrote:
> On Thu Jan 8, 2026 at 3:01 PM CET, Alexandre Belloni wrote:
> > On 08/01/2026 14:52:08+0100, Danilo Krummrich wrote:
> >> On Thu Jan 8, 2026 at 2:45 PM CET, Ke Sun wrote:
> >> >
> >> > On 1/8/26 19:12, Danilo Krummrich wrote:
> >> >> On Wed Jan 7, 2026 at 3:37 PM CET, Ke Sun wrote:
> >> >>> diff --git a/drivers/rtc/dev.c b/drivers/rtc/dev.c
> >> >>> index baf1a8ca8b2b1..0f62ba9342e3e 100644
> >> >>> --- a/drivers/rtc/dev.c
> >> >>> +++ b/drivers/rtc/dev.c
> >> >>> @@ -410,7 +410,7 @@ static long rtc_dev_ioctl(struct file *file,
> >> >>>   		}
> >> >>>   		default:
> >> >>>   			if (rtc->ops->param_get)
> >> >>> -				err = rtc->ops->param_get(rtc->dev.parent, &param);
> >> >>> +				err = rtc->ops->param_get(&rtc->dev, &param);
> >> >> It would make more sense to just pass a struct rtc_device than the embedded
> >> >> struct device in the RTC callbacks.
> >> > I considered passing struct rtc_device directly, but chose &rtc->dev
> >> > to minimize changes to existing drivers, since most callbacks use
> >> > dev_get_drvdata() on the device parameter.
> >> 
> >> No, you should not expose the embedded base device. For accessing the private
> >> data you should add helpers like rtc_get_drvdata(). This is what other
> >> subsystems do as well, e.g. [1].
> >> 
> >> [1] https://elixir.bootlin.com/linux/v6.18.3/source/include/linux/i2c.h#L371
> >
> > This is not a correct example as i2c is a bus, just like amba is...
> 
> Yes, struct i2c_client is indeed a bus device. However, the core struct device
> is what holds the device private data commonly in the same way, regardless of
> whether it is embedded in a bus or class device.
> 
> If you look for a class device example, here's PWM [2] and input [3].
> 
> [2] https://elixir.bootlin.com/linux/v6.18.3/source/include/linux/pwm.h#L382
> [3] https://elixir.bootlin.com/linux/v6.18.3/source/include/linux/input.h#L388
> 
> > Actually, I don't think the rework is necessary at all or this would
> > mean we need to rewor most of our existing subsystems.
> 
> That's not true, subsystems do not pass the parent device (i.e. the bus device)
> through their class device callbacks exclusively.

Like explained on the other thread, while it would be conceptually
better to pass a struct rtc_device to the callbacks, it doesn't solve
your issue. Let me take a random input drivers as an example:

https://elixir.bootlin.com/linux/v6.18.3/source/drivers/input/keyboard/pinephone-keyboard.c#L373
This sets its own private data on the parent device, it needs it later
on in the interrupt handler

https://elixir.bootlin.com/linux/v6.18.3/source/drivers/input/joystick/as5011.c#L313
It needs it later on in the remove callback

https://elixir.bootlin.com/linux/v6.18.3/source/drivers/input/misc/da7280.c#L1197
Needed later on for suspend/resume

So the input subsystem is not different from RTC

For PWM:

https://elixir.bootlin.com/linux/v6.18.6/source/drivers/pwm/pwm-pca9685.c#L450
Needed for suspend/resume and .remove()

https://elixir.bootlin.com/linux/v6.18.6/source/drivers/pwm/pwm-rockchip.c#L348
Needed for .remove()

Any other subsystem is going to have similar examples. I don't think
there is a pressing need to rewrite the rtc_class_ops callbacks.

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