public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alessandro Zummo <alessandro.zummo@towertech.it>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, dtor_core@ameritech.net
Subject: Re: [PATCH 00/11] RTC subsystem
Date: Mon, 20 Feb 2006 02:10:40 +0100	[thread overview]
Message-ID: <20060220021040.094284b6@inspiron> (raw)
In-Reply-To: <20060219165845.09eb4183.akpm@osdl.org>

On Sun, 19 Feb 2006 16:58:45 -0800
Andrew Morton <akpm@osdl.org> wrote:

> > 
> 
> This is nowhere near a sufficient explanation for such a patchset.
> 
> What does it all do, how does it do it and, importantly, _why_ does it do
> it?

 Sorry Andrew, it was meant as an update to my original email
 with full description. I've reported here as it is still valid.


 Hello,

  this is a proposal for the implementation of a kernel-wide
 RTC subsystem.

  The current state of RTCs under linux is that each one
 of the current drivers is actually self-contained and
 has a lot of redundant functions [1].
 
  The lack of a kernel-wide subsystem is particulary important
 on embedded devices, where the RTC is usually implemented
 on an I2C chip.

  Of the current I2C RTC drivers, no-one actually interfaces
 with the kernel [2]: the driver is actually useless
 without further patches that are probably provided as part
 of an external project.

  When new driver are to be implemented [3], I've noticed
 authors are often confused on how to do it, resulting
 in drivers that will not work on different architectures
 and that will probably never be merged in the kernel.

  They also happen to use ioctls over (struct i2c_client *)->command,
 which has recently been deprecated [4].

  The architecture is quite simple. Each RTC device should
 register to the RTC class, providing a set of pointers
 to functions. The class will provide access to the RTC
 to the whole kernel and userspace.

  For this purpose, the class supports multiple interfaces,
 like sysfs, proc and dev.

  The user has complete control over which interfaces
 gets added using the standard Kconfig mechanism.

  proc and dev, due to their nature, will only expose
 the first RTC that registers to the subsystem.

  The RTC code is derived from the one of the ARM subsystem.

  This patchset has been verify to properly work under Linux/ARM
 on several NSLU2s (http://www.linux-nslu2.org) and applies
 successfully on the 2.6.15-rc6 kernel . If this is the right
 way to go, I will port the x86 rtc driver in order to get
 broader testing.

  I'd appreciate receiving feedback on this proposal.

  Thanks in advance.

--

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it


[1]
	http://lkml.org/lkml/2005/11/17/180

[2]
	drivers/i2c/chips/m41t00.c
	drivers/i2c/chips/rtc8564.c
	drivers/i2c/chips/ds1337.c
	drivers/i2c/chips/ds1374.c

[3]
	http://lists.lm-sensors.org/pipermail/lm-sensors/2005-November/014428.html
	http://lists.lm-sensors.org/pipermail/lm-sensors/2005-November/014386.html

[4]
	http://lists.lm-sensors.org/pipermail/lm-sensors/2005-December/014688.html
	http://lists.lm-sensors.org/pipermail/lm-sensors/2005-November/014369.html

  reply	other threads:[~2006-02-20  1:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-19 23:22 [PATCH 00/11] RTC subsystem Alessandro Zummo
2006-02-19 23:22 ` [PATCH 01/11] RTC subsystem, class Alessandro Zummo
2006-02-22 22:15   ` Andrew Morton
2006-02-23  1:09     ` Alessandro Zummo
2006-02-23  1:31       ` Andrew Morton
2006-02-19 23:22 ` [PATCH 02/11] RTC subsystem, ARM cleanup Alessandro Zummo
2006-02-19 23:22 ` [PATCH 03/11] RTC subsystem, I2C cleanup Alessandro Zummo
2006-02-19 23:22 ` [PATCH 04/11] RTC subsystem, sysfs interface Alessandro Zummo
2006-02-19 23:22 ` [PATCH 05/11] RTC subsystem, proc interface Alessandro Zummo
2006-02-19 23:22 ` [PATCH 06/11] RTC subsystem, dev interface Alessandro Zummo
2006-02-19 23:22 ` [PATCH 07/11] RTC subsystem, X1205 driver Alessandro Zummo
2006-02-19 23:22 ` [PATCH 08/11] RTC subsystem, test device/driver Alessandro Zummo
2006-02-19 23:22 ` [PATCH 09/11] RTC subsystem, DS1672 driver Alessandro Zummo
2006-02-19 23:22 ` [PATCH 10/11] RTC subsystem, PCF8563 driver Alessandro Zummo
2006-02-19 23:22 ` [PATCH 11/11] RTC subsystem, RS5C372 driver Alessandro Zummo
2006-02-20  0:58 ` [PATCH 00/11] RTC subsystem Andrew Morton
2006-02-20  1:10   ` Alessandro Zummo [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-02-13 22:54 Alessandro Zummo
2006-02-14 10:30 ` Ben Dooks
2006-02-14 11:00   ` Alessandro Zummo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060220021040.094284b6@inspiron \
    --to=alessandro.zummo@towertech.it \
    --cc=akpm@osdl.org \
    --cc=dtor_core@ameritech.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox