Re: [PATCH] Hotplug for device power state changes

[Greg KH]

On Fri, Apr 30, 2004 at 06:16:22PM -0700, Todd Poynor wrote:
> Greg KH wrote:
> >On Fri, Apr 30, 2004 at 12:59:40PM -0700, Todd Poynor wrote:
> >
> >>* Changes to kobject to allow kobject hotplug to optionally be 
> >>synchronous if desired.  I'd assume this is a new hotplug_ops field.
> >
> >
> >Ick.
> 
> Is the objection to using kobject for synchronous hotplug events, or to 
> using a hotplug_ops flag to indicate which kind is needed?  Would the 
> addition of a kobject_hotplug_sync function be better?  Or a 
> handshake-like interface as with firmware downloads?

To add an option to the kobject_hotplug() function for a sync call is
one thing.  To make the option for the main kobject add and remove call
to be sync is a horribly misguided thought (the reason why is left as an
exercise for the reader...like go read the udev code for many reasons
why...)

I don't have an objection to add such a new paramater (or even a new
function call like you suggested), just don't go messing with the main
kobject hotplug call without thinking everything through :)

> >>* Synchronous hotplug events for system suspend and resume (without 
> >>individual device notifications).  These events can probably be 
> >>generated by the kobject hotplug methods by the existing power subsys 
> >>(once the above enhancement is in place).
> >
> >
> >But why?  Do you really need this?  Have you actually tested a system to
> >see if it is needed?
> 
> This is something that was requested of me by others who build Linux 
> into consumer electronics devices.  Perhaps some of the interested 
> parties may speak up here to add more insight.

Please encourage them to speak up.  I hear _nothing_ from any embedded
developers, and I am really interested in how the driver model and
hotplug works (or doesn't) for them.  Without that feedback, we are in
the dark as to what their needs/hates are.

thanks,

greg k-h
-
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/