[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d120d5000706140817o5ee1a047nb90c9f787811a832@mail.gmail.com>
Date: Thu, 14 Jun 2007 11:17:51 -0400
From: "Dmitry Torokhov" <dmitry.torokhov@...il.com>
To: "David Brownell" <david-b@...bell.net>
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 6/14/07, David Brownell <david-b@...bell.net> wrote:
> 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.
Yes, I did misunderstood you.
The reason I can't use class-wide resume support is that since we
can't have class hierarchy we have mess of different objects dumped
into single pool (input_dev, evdev. mousedev, joydev, tsdev all relate
to /sys/class/input). And so instead of having class define standard
interface for all objects in it we have to rely on something else
(struct device_type - not visible fom userspace) to separate them and
add tweaks to interface. Can you see that I am not a fan of the
design? ;)
As far as input concerned - I need to resume input_dev but not evdev,
mousedev, tsdev, etc. as they are all just different representations
of the same object.
> 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.
It could be done within the class_device infrastructure as well.
> 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?
>
No, it will stay.
--
Dmitry
-
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