On 29/11/2019 09:45:39-0500, Jean-Francois Dagenais wrote: > > Or does that mean that your previous read of control returning bit 24 > > set is also bogus? > > https://www.xilinx.com/html_docs/registers/ug1087/rtc___control.html# > Bits 30:28 are reserved, and not 0x0 as this reference page suggests, so who knows > what the bits mean... well someone at Xilinx knows! > According to this link, bit 24 is Crystal Enable which I would think would also enable the RTC. > > > > I ask because the simpler solution would simply to return -EINVAL in > > xlnx_rtc_read_time when you detect a power on condition. > > That could also work, but how would we determine that? Oh, perhaps by looking at > the Battery_Enable (31) bit. But then we would need to keep it disabled during > probe so that the time_read could test the bit to see if current_time is valid, > and then after this, when would we enable it? Perhaps at the first call to > set_time_write? This is all interesting but for now we have run out of time to > investigate further. Unless someone comes up with a ready made alternative > solution, we here are actually going to go into production with our patch. It > works well. Yes, this is exactly what should be done. leave the RTC in PON state until userspace sets the time. Until then, -EINVAL must be returned by .read_time. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
