On Wed, 2 Mar 2016 00:07:45 +0100
Alexandre Belloni [off-list ref] wrote:

quoted

quoted

I wouldn't reset the VLOW1 and VLOW2 flags here. Just bail out if the
voltage is not sufficient. I don't think that condition will actually
get better simply by waiting.  

I do actually think so that we should clear them at least once (that is
retry once). According to the data sheet these bits will not reset
automatically and might be left over from machine start (brown out).
  

No, this should be handled differently. I have some pending patches to
handle those bits. The main issue is that if you reset those bits there,
there is now way to know whether the date has been set or is invalid.

I think the best way to handle this case is to call the function again
when the date/time are set and we have to reset VLOW1/2.

Yes, right. But as of now we do not have VLOW handling. So I don't see
an issue with clearing the bits here.
The clearing can be removed, if VLOW handling is added eventually.

The issue currently is: We need to check VLOW before accessing the
eeprom, because otherwise it would mean data corruption. This is
especially true for writing. And if we read VLOW, we need a way to
reset the bits from the probable initial brown out. Otherwise we can
never access the eeprom as this check would hit often.

So when are your VLOW patches going to be available?

-- 
Michael

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.