Re: [rtc-linux] Re: rtc_cmos: error after first write to wakealarm

[David Brownell]

On Friday 22 June 2007, Alessandro Zummo wrote:
> On Tue, 19 Jun 2007 19:24:29 +0200
> Tino Keitel <tino.keitel@xxxxxx> wrote:
> 
> > > > Where is the documentation that describes that I have to disable it
> > > > first, and how to do this? A migration document for
> > > > /proc/acpi/alarm users would be nice, too.
> > > 
> > >  Well, I guess there is no documentation. Maybe we could add
> > >  a dev_warn with an explicit message.
> > 
> > Isn't it somewhat ridiculous to plan the removal of a feature for
> > several months, and then replace it with something that behaves
> > differently without any documentation?

It's got as much documentation in the kernel tree as that
old /proc/acpi/alarm thing.  More, in fact, since the GIT
comment for the putback creating /sys/rtc/.../wakealarm
files has lots of info about how to use it.

But sure, having documentation for the rtc sysfs interface
would be a Fine Thing.  It should cover the other values
too, not just that one attribute.


> > I still wonder how 'cat /sys/class/rtc/rtcX/wakealarm' is expected to
> > behave. With 2.6.22-rc5, I get this:
> > 
> > $ echo 1182351177 > /sys/class/rtc/rtc0/wakealarm 
> > $ cat /sys/class/rtc/rtc0/wakealarm
> > 2051644873
> > 
> > There seems to be a constant difference of 869984896 seconds. Is this a
> > bug?

What RTC driver is that using?

One theory:  it's an RTC that doesn't support all the fields,
so its driver is returning "-1" in fields like "year" or "month".

Right now there's no code forcing rtc_read_alarm() to return
values for which rtc_valid_tm(&alarm->time), and bogus values
in wakealarm would be a symptom.  I suspect most of the systems
I tested the "wakealarm" attribute with have RTC alarms that
don't have those particular deficiencies.

- Dave

> 
>  I'll have to check that. Sorry for the delay, i've been a bit busy.
> 
> 
> -- 
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/