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:

quoted

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