On Fri, Feb 04, 2005 at 05:04:09PM -0700, Mark A. Greer wrote:
> Greg KH wrote:
>
> >Can you resend it with a proper Changelog description in the top of the
> >email and the signed-off-by line? thanks,
> >
> >greg k-h
> >
> >
> >
> Certainly.
> --
>
> This patch adds support for the ST M41T00
On Fri, Feb 04, 2005 at 05:04:09PM -0700, Mark A. Greer wrote:
Greg KH wrote:
Can you resend it with a proper Changelog description in the top of the
email and the signed-off-by line? thanks,
greg k-h
Certainly.
--
This patch adds support for the ST M41T00 I2C RTC chip.
Greg KH wrote:
Can you resend it with a proper Changelog description in the top of the
email and the signed-off-by line? thanks,
greg k-h
Certainly.
--
This patch adds support for the ST M41T00 I2C RTC chip.
This rtc chip has no mechanism to freeze it's registers while being
read; however, it
On Fri, Feb 04, 2005 at 04:14:51PM -0700, Mark A. Greer wrote:
> From http://archives.andrew.net.au/lm-sensors/msg29319.html:
>
> Mark A. Greer wrote:
>
> >
> >
> >Here is a replacement patch that should address Jean Delvare and Dick
> >Johnson's issues. Please let me know if there are any
From http://archives.andrew.net.au/lm-sensors/msg29319.html:
Mark A. Greer wrote:
Here is a replacement patch that should address Jean Delvare and Dick
Johnson's issues. Please let me know if there are any more issues.
Thanks,
Mark
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
--
I haven't
From http://archives.andrew.net.au/lm-sensors/msg29319.html:
Mark A. Greer wrote:
snip
Here is a replacement patch that should address Jean Delvare and Dick
Johnson's issues. Please let me know if there are any more issues.
Thanks,
Mark
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
--
I
On Fri, Feb 04, 2005 at 04:14:51PM -0700, Mark A. Greer wrote:
From http://archives.andrew.net.au/lm-sensors/msg29319.html:
Mark A. Greer wrote:
snip
Here is a replacement patch that should address Jean Delvare and Dick
Johnson's issues. Please let me know if there are any more
Greg KH wrote:
Can you resend it with a proper Changelog description in the top of the
email and the signed-off-by line? thanks,
greg k-h
Certainly.
--
This patch adds support for the ST M41T00 I2C RTC chip.
This rtc chip has no mechanism to freeze it's registers while being
read; however, it
Thank you for your comments, Jean.
Jean Delvare wrote:
Hi Mark,
+ This driver can also be built as a module. If so, the module
+ will be called i2c-m41t00.
It'll actually be called m41t00, according to the Makefile.
Good catch.
+struct m41t00_data {
+ struct i2c_client client;
+};
Thank you for your comments, Jean.
Jean Delvare wrote:
Hi Mark,
+ This driver can also be built as a module. If so, the module
+ will be called i2c-m41t00.
It'll actually be called m41t00, according to the Makefile.
Good catch.
+struct m41t00_data {
+ struct i2c_client client;
+};
linux-os wrote:
On ix86 machines, it is appropriate to read the RTC clock
several times in a row until nothing changes. This protects
against getting bad readings when some values wrap (like
seconds). You can't stop the clock when you read it
or you will lose time. I don't see anything like this
Hi Mark,
> This patch adds support for the ST M41T00 RTC chip.
As for your other driver, I lack the device-specific knowledge to
comment on the functionality, but still have some technical comments on
the code itself:
> + This driver can also be built as a module. If so, the module
> +
On ix86 machines, it is appropriate to read the RTC clock
several times in a row until nothing changes. This protects
against getting bad readings when some values wrap (like
seconds). You can't stop the clock when you read it
or you will lose time. I don't see anything like
this in your code.
On ix86 machines, it is appropriate to read the RTC clock
several times in a row until nothing changes. This protects
against getting bad readings when some values wrap (like
seconds). You can't stop the clock when you read it
or you will lose time. I don't see anything like
this in your code.
Hi Mark,
This patch adds support for the ST M41T00 RTC chip.
As for your other driver, I lack the device-specific knowledge to
comment on the functionality, but still have some technical comments on
the code itself:
+ This driver can also be built as a module. If so, the module
+
linux-os wrote:
On ix86 machines, it is appropriate to read the RTC clock
several times in a row until nothing changes. This protects
against getting bad readings when some values wrap (like
seconds). You can't stop the clock when you read it
or you will lose time. I don't see anything like this
16 matches
Mail list logo