[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200706140803.18603.david-b@pacbell.net>
Date: Thu, 14 Jun 2007 08:03:17 -0700
From: David Brownell <david-b@...bell.net>
To: "Dmitry Torokhov" <dmitry.torokhov@...il.com>
Cc: "Kay Sievers" <kay.sievers@...y.org>,
"Rafael J. Wysocki" <rjw@...k.pl>,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Alan Stern" <stern@...land.harvard.edu>,
"Greg KH" <greg@...ah.com>, LKML <linux-kernel@...r.kernel.org>,
"Pavel Machek" <pavel@....cz>
Subject: Re: [PATCH -mm 4/7] PM: Remove suspend and resume support from struct device_type
On Thursday 14 June 2007, Dmitry Torokhov wrote:
> On 6/14/07, David Brownell <david-b@...bell.net> wrote:
> > On Wednesday 13 June 2007, Dmitry Torokhov wrote:
> > > On Wednesday 13 June 2007 18:20, Kay Sievers wrote:
> > > > Dmitry, you added this recently, is this used in any code you plan to
> > > > merge soon?
> > > >
> > >
> > > Yes, I will need it to implement input device resume (mainly to restore LED
> > > state and repeat rate for keyboards).
> >
> > Why wouldn't that use the class device suspend/resume mechanism?
> >
>
> Because they are not class devices anymore.
Perhaps you mis-understood me: the class level device suspend/resume
hooks don't rely on class_device. I observe that /sys/class/input
still exists (2.6.22-rc4-git), so if all you mean is that it's no
longer using class_device, that's good. One part of the reason to
stop using class_device is specifically to let framework code (like
input, network, or rtc) receive class level suspend/resume calls.
ISTR the RTC framework was the first to do that, but there's some
work afoot to teach the network stack to use that mechanism too.
Or are you referring to some input patches which I've not yet seen,
which cause /sys/class/input to vanish?
- Dave
-
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