Messages in this thread | | | Date | Thu, 14 Jun 2007 11:17:51 -0400 | From | "Dmitry Torokhov" <> | Subject | Re: [PATCH -mm 4/7] PM: Remove suspend and resume support from struct device_type |
| |
On 6/14/07, David Brownell <david-b@pacbell.net> wrote: > On Thursday 14 June 2007, Dmitry Torokhov wrote: > > On 6/14/07, David Brownell <david-b@pacbell.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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |