Date: Mon, 13 Nov 2017 06:04:44 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 223642] ds3231 iic driver can't initialise a new device Message-ID: <bug-223642-7@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223642 Bug ID: 223642 Summary: ds3231 iic driver can't initialise a new device Product: Base System Version: 11.1-STABLE Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: bscott@bunyatech.com.au Created attachment 187954 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=187954&action=edit Patch to change failures to start the oscillator and acknowledge interrupts to be warnings During initialisation of the ds3231 rtc driver it attempts to enable the oscillator and acknowledge any alarm conditions. For a brand new, never powered device this is rejected until the time has been set, however because these calls fail the device isn't started and the time is never set. Writing a quick and dirty program based on the i2c utility I have initialised the device without using the driver. When loaded, the driver proceeds normally and uses the device as intended. I have patched the driver (sys/dev/iicbus/ds3231.c) to just warn on failures of the two calls mentioned earlier. I haven't found any way to return one of the chips back to pristine condition. Fortunately I had another device that I had purchased but never used that I could use to test the change with and had the device accepted properly (with a few extra warning messages on first boot). It's quite possible that other suppliers actually test these devices before selling them and that normally they have some time setting when first installed. Mine where $2 each from Malaysia with free shipping so I couldn't really expect much. I don't know if other people would experience the same problem. While debugging this, I have also noticed that the device is initialised with a zero based day of week (i.e. 0-6) but the specification for the device is for a value from 1 to 7. The value returned by the device is never used so this shouldn't matter unless some version of the chip in the future enforces the specification for some reason. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-223642-7>