Re: [PATCH -mm 4/7] PM: Remove suspend and resume support from struct device_type

From: Dmitry Torokhov
Date: Thu Jun 14 2007 - 11:18:00 EST


On 6/14/07, David Brownell <david-b@xxxxxxxxxxx> wrote:
On Thursday 14 June 2007, Dmitry Torokhov wrote:
> On 6/14/07, David Brownell <david-b@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/