Bug#932845: TS-219 RTC issue with Debian Buster

[Oliver Hartkopp <socketcan@hartkopp.net>]

Hello Uwe,

On 26.07.19 09:27, Uwe Kleine-König wrote:
> Hello Alexandre,
>
> On Thu, Jul 25, 2019 at 04:31:49PM +0200, Oliver Hartkopp wrote:
> > On 24.07.19 09:07, Uwe Kleine-König wrote:
> > > On Tue, Jul 23, 2019 at 10:28:18PM +0200, Oliver Hartkopp wrote:
> > > > I'm running a TS-119P+ and a TS-219P II Qnap NAS with Debian Buster.
> > > > Both are now running a linux-image-4.19.0-5-marvell kernel.
> > > >
> > > > But since my update from Linux 4.9 (Stretch) to Linux 4.19 (Buster) the
> > > > hardware clock of both boxes refuse to work.
> > > >
> > > > After some digging in kernel sources and re-installing Linux 4.9 on my
> > > > Buster setup it turns out, that a change in the kernel config causes the
> > > > problem:
> > > >
> > > > 4.19.0-5-marvell -> CONFIG_RTC_DRV_S35390A=m   (fails)
> > > >
> > > > 4.9.0-4-marvell -> CONFIG_RTC_DRV_S35390A=y    (works)
> > > >
> > > > See details and solving process at:
> > > >
> > > > https://marc.info/?l=linux-arm-kernel&m=156390875629259&w=2
> > > >
> > > > Can you please revert the Kernel config parts for the RTC in a way that the
> > > > RTC drivers are built into the marvell-arch kernel again instead of building
> > > > them as modules?
> > >
> > > They were switched to modules because the kernel image got too big to
> > > fit into the flash storage of some machines. I assume when we switch to
> > > built-in again the resulting problem is the bigger one.
> >
> > I don't know which is the bigger problem here.
> >
> > When the rtc driver is built as module it can not be operated with the
> > hwclock tool from the util-linux package due to the missing rtc UIE support.
> >
> > You finally have no hardware clock on these machines and must wait for ntp
> > to shift time and date (my system always starts in February until ntp fixes
> > the time).
>
> For me it's obvious what is the bigger problem. Either you don't have
> the correct time until ntp fixes it up for you, or others cannot install
> a kernel update and so run a vulnerable OS.

That what I've written, NTP fixes the time for me. I have no problem 
with updating my kernels - in fact I was even able to flash an older 
kernel to figure out this rtc issue :-)

> > Maybe this problem is only relevant for the S35390A and PCF8563 chip which
> > both lack the UIE support needed by hwclock. Both have only alarm triggers
> > in a minute accuracy according to the driver source code.
>
> AFAIK the rtc framework should then emulate this event somehow.

I don't think so. When the rtc chip is not able to trigger an event with 
a one second resolution - how can you emulate that?

> > So CONFIG_RTC_DRV_S35390A=y and CONFIG_RTC_DRV_PCF8563=y should bring back
> > the hw clocks on these machines.
> >
> > I assume using hwclock without UIE trigger code will impact the accuracy.
> >
> > > > As described in the referenced description the hwclock tool does not work on
> > > > the machines.
> > >
> > > I'm not sure yet if this is a problem in hwclock() or the s35390a
> > > driver.
> >
> > In detail it is hwclock together with rtc drivers not supporting UIE trigger
> > with a 1 second resolution.
>
> @abelloni: Do you can shed some light here, how it is supposed to work?
> Is hwclock just doing it wrong with non-PC clocks, or is there a kernel
> bug to fix?
>
> Best regards
> Uwe

Best regards,
Oliver