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

David Brownell
2007-06-22T18:46:01Z

On Friday 22 June 2007, Alessandro Zummo wrote:
> On Tue, 19 Jun 2007 19:24:29 +0200
> Tino Keitel <tino.keitel@gmx.de> 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.
>
>
> --
>