Hi Behn, Need your help in understanding the historical context for having two rtc interfaces in the kernel (CONFIG_GEN_RTC & CONFIG_RTC_CLASS) and which one should be enabled for pseries_defconfig. I have posted a patch (http://patchwork.ozlabs.org/patch/478899/) to enable CONFIG_RTC_CLASS in the defconfig so that opal rtc driver (/drivers/rtc/opal-rtc.c) is enabled.
Afaik CONFIG_RTC_CLASS is more generic and can emulate the older interface provided by gen_rtc. So imho it would make sense to enable rtc-class with pseries_defconfig as we already have an opal-rtc-driver. My limited testing with gen_rtc on a tulleta reveals issues with hwclock as it reports invalid rtc-time error which I suspect is due to a genrtc driver trying to read date time values from an rtc port that is not available on the tulleta. With RTC_CLASS enabled however hwclock seems to work fine. Requesting your inputs, Thanks, ~Vaibhav On Wed, 2015-06-17 at 15:43 +1000, Michael Ellerman wrote: > On Mon, 2015-01-06 at 10:48:55 UTC, Vaibhav Jain wrote: > > A working rtc kernel driver is needed so that hwclock can synchronize > > system clock to rtc during shutdown/boot. We already have a rtc platform > > driver for power arch located at drivers/rtc/rtc-opal.c However it > > depends on CONFIG_RTC_CLASS which is disabled by default. So this driver > > is not compiled with pseries defconfig as rtc class support is missing > > from the kernel. > > > > We fix this by enabling rtc class support in pseries defconfig so that > > this driver gets enabled and is compiled into the pseries kernel. > > So that seems fair enough. > > But, it disables CONFIG_GEN_RTC. Which *I think* means we won't get an RTC > driver at all on pseries machines. > There's some history between those two options but I don't know it off the top > of my head. Ben should know? > > cheers > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
