linux-kernel - Re: [patch 2.6.19-git] rts-rs5c372 updates: more chips, alarm, 12hr mode, etc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <42002.80.222.56.248.1165818454.squirrel@webmail.movial.fi>
Date:	Mon, 11 Dec 2006 08:27:34 +0200 (EET)
From:	"Voipio Riku" <Riku.Voipio@...ial.fi>
To:	"David Brownell" <david-b@...bell.net>
Cc:	rtc-linux@...glegroups.com,
	"Linux Kernel list" <linux-kernel@...r.kernel.org>,
	"Riku Voipio" <riku.voipio@...ial.fi>,
	"Alessandro Zummo" <alessandro.zummo@...ertech.it>
Subject: Re: [patch 2.6.19-git] rts-rs5c372 updates:  more chips, alarm,
      12hr mode, etc

> Update the rtc-rs5c372 driver:
> I suspect the
> issue wasn't that "mode 1" didn't work on that board; the original
> code to fetch the trim was broken.  If "mode 1" really won't work,
> that's almost certainly a bug in that board's I2C driver.

It was not related to trim fetching. Yes, it very likely that the boards
i2c controller (i2c-iop3xx) is has a bug, but I'm not competent enough to
find out what it is actually sending out to the wire.

With your patch, the rtc acts like the chip would completely ignore the
"address" transfer, and starts reading from the last (default) register
anyway. Thus all the regs look shifted by one in the driver. With current
git driver results look like:

# cat /proc/driver/rtc ; sleep 1 ; echo one sec gone; cat /proc/driver/rtc
rtc_time        : 06:16:55
rtc_date        : 2006-12-11
24hr            : yes
32.768 KHz
trim    : 1
one sec gone
rtc_time        : 06:16:56
rtc_date        : 2006-12-11
24hr            : yes
32.768 KHz
trim    : 1

And same after your patch:

rtc_time        : 16:23:28
rtc_date        : 2012-11-01
alrm_time       : **:01:00
alrm_date       : ****-**-**
alrm_wakeup     : no
alrm_pending    : no
24hr            : yes
crystal         : 32.768 KHz
trim            : 10
one sec gone
rtc_time        : 16:24:28
rtc_date        : 2012-11-01
alrm_time       : **:01:00
alrm_date       : ****-**-**
alrm_wakeup     : no
alrm_pending    : no
24hr            : yes
crystal         : 32.768 KHz
trim            : 10


> +	/* this implements the first (most portable) reading method
> +	 * specified in the datasheet.
>  	 */

Why is this method considered more portable? Howabout making the read
method a module parameter?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/