On 26/07/2019 11:27:11+0200, Oliver Hartkopp wrote: > 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? >
CONFIG_RTC_INTF_DEV_UIE_EMUL emulates it by polling the RTC. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com