[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0703280931520.6730@woody.linux-foundation.org>
Date: Wed, 28 Mar 2007 09:38:48 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Maxim <maximlevitsky@...il.com>
cc: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
Jeff Chua <jeff.chua.linux@...il.com>,
Adrian Bunk <bunk@...sta.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"Rafael J. Wysocki" <rjw@...k.pl>, pavel@...e.cz,
linux-pm@...ts.osdl.org, gregkh@...e.de,
linux-pci@...ey.karlin.mff.cuni.cz,
Jens Axboe <jens.axboe@...cle.com>,
Len Brown <lenb@...nel.org>, linux-acpi@...r.kernel.org,
jgarzik@...ox.com, linux-ide@...r.kernel.org,
"Michael S. Tsirkin" <mst@...lanox.co.il>
Subject: Re: [3/6] 2.6.21-rc4: known regressions
On Wed, 28 Mar 2007, Maxim wrote:
>
> Now I don't have a clue how to set those bits if only HPET is used as clock source because now clocksources
> don't have _any_ resume hook.
One thing that drives me wild about that "clocksource resume" thing is
that it seems to think that clocksources are somehow different from any
other system devices..
Why isn't the HPET considered a "device", and has it's own *device*
"suspend" and "resume"? Why do we seem to think that only "set_mode()"
etc should wake up clock sources?
It's a *device*, dammit. It should save and resume like one (probably as a
system device). The "set_mode()" etc stuff is at a completely different
(higher) conceptual level.
Thomas? It does seem like Maxim has hit the nail on the head (at least
partly) on the HPET timer resume problems..
Linus
-
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/
Powered by blists - more mailing lists