All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Todd Poynor <tpoynor@mvista.com>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Patrick Mochel <mochel@digitalimplant.org>,
	linux-hotplug-devel@lists.sourceforge.net,
	Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Hotplug for device power state changes
Date: Sat, 01 May 2004 01:48:27 +0000	[thread overview]
Message-ID: <20040501014827.GA16006@kroah.com> (raw)
In-Reply-To: <4092FA66.20704@mvista.com>

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


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id149&alloc_idÅ66&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: Todd Poynor <tpoynor@mvista.com>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Patrick Mochel <mochel@digitalimplant.org>,
	linux-hotplug-devel@lists.sourceforge.net,
	Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Hotplug for device power state changes
Date: Fri, 30 Apr 2004 18:48:27 -0700	[thread overview]
Message-ID: <20040501014827.GA16006@kroah.com> (raw)
In-Reply-To: <4092FA66.20704@mvista.com>

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

  reply	other threads:[~2004-05-01  1:48 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-29 20:26 [PATCH] Hotplug for device power state changes Todd Poynor
2004-04-29 21:42 ` Russell King
2004-04-29 21:42   ` Russell King
2004-04-29 22:36   ` Todd Poynor
2004-04-29 22:36     ` Todd Poynor
2004-04-30  0:50     ` Benjamin Herrenschmidt
2004-04-30  0:50       ` Benjamin Herrenschmidt
2004-04-30  8:30       ` Russell King
2004-04-30  8:30         ` Russell King
2004-04-30 19:59         ` Todd Poynor
2004-04-30 19:59           ` Todd Poynor
2004-04-30 21:56           ` Greg KH
2004-04-30 21:56             ` Greg KH
2004-05-01  1:16             ` Todd Poynor
2004-05-01  1:16               ` Todd Poynor
2004-05-01  1:48               ` Greg KH [this message]
2004-05-01  1:48                 ` Greg KH
2004-05-03 21:33                 ` Todd Poynor
2004-05-03 21:33                   ` Todd Poynor
2004-05-01  0:03           ` Nigel Cunningham
2004-05-01  0:03             ` Nigel Cunningham
2004-05-03 22:04             ` Todd Poynor
2004-05-03 22:04               ` Todd Poynor
2004-04-30 19:07       ` Todd Poynor
2004-04-30 19:07         ` Todd Poynor
2004-05-15  1:40   ` Nicolas Pitre
2004-05-15  1:40     ` Nicolas Pitre
2004-05-15 23:34     ` Pavel Machek
2004-05-15 23:34       ` Pavel Machek
2004-05-04 15:26 ` Patrick Mochel
2004-05-04 20:36   ` Todd Poynor
2004-05-04 20:36     ` Todd Poynor
2004-05-05  4:19     ` Patrick Mochel
2004-05-06  1:08       ` Todd Poynor
2004-05-06  1:08         ` Todd Poynor
2004-05-14  2:50         ` Pavel Machek
2004-05-14  2:50           ` Pavel Machek
2004-05-15  2:08           ` Todd Poynor
2004-05-15  2:08             ` Todd Poynor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040501014827.GA16006@kroah.com \
    --to=greg@kroah.com \
    --cc=benh@kernel.crashing.org \
    --cc=linux-hotplug-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@digitalimplant.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=tpoynor@mvista.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.