On 09/04/2019 12:46:20+0200, Mastro Gippo wrote: > Hi Alexandre, > thank you for your comments. > Since failure behaviour is not specified in the Maxim datasheet, the > gracious way to handle this would be a retry counter, as that would > also solve the problem of a DS1307 that for some reason doesn't set > the CH bit (maybe an internal oscillator failure?). A similar erratic > behavior happened to me once, due to an unstable power supply to the > RTC. Ok, I had a closer look at the tissue, the solution here is to not bother and simply not handle DS1307_BIT_CH, DS1338_BIT_OSF, DS1340_BIT_nEOSC, DS1340_BIT_OSF, MCP794XX_BIT_VBATEN or MCP794XX_BIT_ST. they should only be handled in the read_time and set_time callbacks, were they really matters. I'll send a patch for that. > IMHO, I think that a hardware failure and/or a problematic I2C driver > should not produce an infinite loop - be it fatal or not. This is correct and this has to be fixed. I must admit I was too quick and didn't see this was in the probe function. > I already solved my boot issue with this patch, and I will ship it > with the devices I sell, but may I ask you what approach would you > recommend instead of hctosys? I tried looking online for solutions but > couldn't find an "official" one. I will gladly investigate better > approaches if available. > Many distributions have initscripts that are using hwclock to set the system time at boot and save it at shutdown. The kernel is not doing a good job at setting the system time and saving it for technical and historical reasons. hctosys and systohc should not be used. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
