linux-kernel - Re: RTC: add RTC class interface to m41t00 driver

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: <20060807.020919.15248103.anemo@mba.ocn.ne.jp>
Date:	Mon, 07 Aug 2006 02:09:19 +0900 (JST)
From:	Atsushi Nemoto <anemo@....ocn.ne.jp>
To:	david-b@...bell.net
Cc:	ab@...able.de, mgreer@...sta.com, a.zummo@...ertech.it,
	linux-kernel@...r.kernel.org
Subject: Re: RTC: add RTC class interface to m41t00 driver

On Sat, 5 Aug 2006 12:13:49 -0700, David Brownell <david-b@...bell.net> wrote:
> > 1. The driver contains ds_1340 (or st m41t00) definition, but it seems
> >    no way to select the ds_type.
> 
> Which is harmless, since the driver has no code that really needs to care.
> As I said, it's a least-common-denominator driver ... used in my case
> with a SOC that integrates a highly functional (primary) RTC, because
> only the external RTC provides its own battery-backed power domain.

Oh, I missed that point.  It should work for m41t00 indeed.

> This is a limitation of the I2C stack ... one that I observe is being
> worked around by m41t00.c platform_device tricks.  A side effect of those
> tricks is to prevent hooking up more than one of this type I2C chip
> to a system ... not pretty (especially given that it's not documented),
> but often OK.

Yes, some more works would be needed on m41t00 to support multiple
(different) M41Txx chips at same time.

> It would have made more sense to me to have the M41T81 and M41T85 be
> in a different driver, because of the incompatible register layout.
> That's the more traditional approach.

Now I'm thinking this way.  Still thinking...

> My approach was to go for "least common denominator", not "super generic".
> Also, I avoided trying to work around I2C stack issues like the omission
> of per-board tables/customization.  When I2C eventually has a nice clean
> solution for those issues, I expect that will mean adopting the better
> solution involves fewer changes.

OK, I see.  I think LCD approach is worth indeed.

> But I was mostly pointing out that if the goal was to support the m41t00
> RTC (the normal reading of $SUBJECT), that work has been done for some
> time and has already been pushed upstream.

My real target is M41T80, which seems a subset of M41T81.
(Sorry for not writing this before.)

I agree m41t00 can be supported by rtc-ds1307 driver already.

So the next theme would be how we support M41T8x chips.  I think
Alexander's rtc-m41txx is good candidate for them.

Then M41T00 users can choose rtc-ds1307 or rtc-m41t00.  Not so bad, I
think.

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