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]

Date:	Tue, 12 Dec 2006 00:30:42 -0800
From:	David Brownell <david-b@...bell.net>
To:	"Voipio Riku" <Riku.Voipio@...ial.fi>
Cc:	rtc-linux@...glegroups.com,
	"Linux Kernel list" <linux-kernel@...r.kernel.org>,
	"Alessandro Zummo" <alessandro.zummo@...ertech.it>,
	dan.j.williams@...el.com, i2c@...sensors.org
Subject: Re: [patch 2.6.19-git] rts-rs5c372 updates:  more chips, alarm, 12hr mode, etc

On Monday 11 December 2006 2:23 pm, Voipio Riku wrote:

> from what I saw, the driver simply passes messages over to the i2c
> controller. It even specifically mentiones that it supports repeated start
> conditions, as needed for read method #1. Comparing to 80219 manual[1], I
> did not spot anything obviously wrong.

I skimmed i2c-ixp3xx too, but have never spent much time with I2C controller
drivers or Intel's fancier XScales.


> >> 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.
> 
> > That's quite strange.  The docs on the RTC are quite clear about what's
> > supposed to happen with what I2C messages.  And I'd expect them to be
> > right ... especially since they behaved for me, and the original author
> > of that code!  That makes me suspect that your particular I2C controller
> > driver must not be issuing the protocol requests it should be, at least
> > on your hardware and revision.
> 
> Well at least I'm happy that there is now someone more experienced working
> on this driver. When I tried to get it working I could not find anyone
> with another board to verify if the original and/or my patch works for
> them..

Unfortunately our patches collided.  The original code worked for me
(other than bugs in the trim register).


> > Plus, if I understand things correctly, using mode #3 would break when
> > writing
> 
> I should not. Writing isn't related to reading methods according the
> datasheet[2]. It provides one addressing method for writing, and writing
> works fine our Thecus/Allnet hardware.

I see ... reading more closely "the internal address pointer is set to Fh
when the stop condition is met", namely right after each transaction.  It's
not like other chips with such pointers that I've used (they never reset it).

I don't mind if the "read all the registers" operation uses mode 3.  I'll
have to see if your updated version behaves (albeit without handling 12 hour
time, the alarm, etc) for me.

But I'm still concerned that switching to mode 3 seems to be just working
around a bug in some other driver, and that _other_ bug should be fixed.

- Dave

-
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/