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

[Dmitry Torokhov]

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/