Comment # 13 on bug 1202206 from Michal Kube������ek

(In reply to Claudio Fontana from comment #12)
> "- use value from master if the option exists there", but in master it was
> enabled, so something might have gone wrong in the process.

The commit message also says "for each option, use first rule which applies"
and in this case it's "use value from SLE15-SP1 if the option exists there".
In other words, the value was inherited from SLE15-SP1 (the previous SP).

Digging deeper, SLE15 inherited the value from SLE12 and in SLE12, the config
option was disabled by kernel-source commit 253e6b166dd4 ("Update config
files."). I doubt Borislav does still remember, after 8 years, why he did
disable it back then so I guess this serves mostly as a memento emphasizing
the importance of useful commit messages. But let's ask him anyway in case
he does actually remember.

I suppose right now the key question is not really who disabled the config
option and why but if enabling it in a released product would either break
kABI or change user visible behaviour in a way that could be seen as a bug
by some of our customers/users. The answer to the first part seems to be
negative (I did not test it and only checked quickly for the most obvious
problems), for the second part, I'm afraid I'm not the right person to answer
that. I always lived under the impression that userspace is responsible for
the synchronization between RTC and system time.

Boris, do you happen to know what was the reason for disabling
CONFIG_RTC_HCTOSYS config option in kernel-source commit 253e6b166dd4
("Update config files.") in SLE12 branch?