All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@deeprootsystems.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: "Moffett, Kyle D" <Kyle.D.Moffett@boeing.com>,
	Patrick Pannuto <ppannuto@codeaurora.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"magnus.damm@gmail.com" <magnus.damm@gmail.com>,
	"gregkh@suse.de" <gregkh@suse.de>,
	Paul Mundt <lethal@linux-sh.org>,
	Magnus Damm <damm@opensource.se>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Eric Miao <eric.y.miao@gmail.com>, Dmitry Torokhov <dtor@mail.ru>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Kyle D Moffett <kyle@moffetthome.net>
Subject: Re: [PATCH 2/2] platform: Facilitate the creation of pseudo-platform buses
Date: Mon, 23 Aug 2010 07:53:40 -0700	[thread overview]
Message-ID: <87tyml1itn.fsf@deeprootsystems.com> (raw)
In-Reply-To: <AANLkTi=WKcb59jJQuLVfqJG07Et+cU75GOC5Lrr_dXR4@mail.gmail.com> (Grant Likely's message of "Sat, 21 Aug 2010 01:10:05 -0600")

Grant Likely <grant.likely@secretlab.ca> writes:

>>> If the override is global to the platform_bus_type, then the model
>>> will not scale.
>>
>> It will not scale any more (or less) than the current functionality of
>> the driver model which handles this globally.  Again, if scalabilty
>> becomes a problem down the road, lets fix it then.
>
> Alright, I can agree to that.  I do agree that the runtime override is
> far and away better than the weak symbol approach.  However, there
> needs to be some very clear rules in place for users of the override,
> namely that users must understand that they are stewards of the
> platform_bus_type, and must take care to preserve the default
> behaviour for "uninteresting" devices.

Completely agree here.

Any overrides of the dev_pm_ops functions that do not also call the
pm_generic_* functions (or their equivalents) should be suspect.

I'll post a proposal for a runtime override shortly.

> Also, the expectation should be that it is a temporary measure until a
> better abstraction is implemented.  It might be that a separate
> bus_type is the way to go (if the multiple driver registration problem
> can be solved) or it might be a way to differentiate pm_ops either
> per-device or per-parent.  I'm not sure, but I'm starting on an OMAP
> project soon, so I may very well end up working on this.

Yes, I'll be glad to work on this too, but first I need to get through
reviewing the backlog of all the OMAP drivers we're converting to
runtime PM.

Kevin

WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@deeprootsystems.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: "Moffett\, Kyle D" <Kyle.D.Moffett@boeing.com>,
	Patrick Pannuto <ppannuto@codeaurora.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-msm\@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"magnus.damm\@gmail.com" <magnus.damm@gmail.com>,
	"gregkh\@suse.de" <gregkh@suse.de>,
	Paul Mundt <lethal@linux-sh.org>,
	Magnus Damm <damm@opensource.se>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Eric Miao <eric.y.miao@gmail.com>, Dmitry Torokhov <dtor@mail.ru>,
	"netdev\@vger.kernel.org" <netdev@vger.kernel.org>,
	Kyle D Moffett <kyle@moffetthome.net>
Subject: Re: [PATCH 2/2] platform: Facilitate the creation of pseudo-platform buses
Date: Mon, 23 Aug 2010 07:53:40 -0700	[thread overview]
Message-ID: <87tyml1itn.fsf@deeprootsystems.com> (raw)
In-Reply-To: <AANLkTi=WKcb59jJQuLVfqJG07Et+cU75GOC5Lrr_dXR4@mail.gmail.com> (Grant Likely's message of "Sat, 21 Aug 2010 01:10:05 -0600")

Grant Likely <grant.likely@secretlab.ca> writes:

>>> If the override is global to the platform_bus_type, then the model
>>> will not scale.
>>
>> It will not scale any more (or less) than the current functionality of
>> the driver model which handles this globally.  Again, if scalabilty
>> becomes a problem down the road, lets fix it then.
>
> Alright, I can agree to that.  I do agree that the runtime override is
> far and away better than the weak symbol approach.  However, there
> needs to be some very clear rules in place for users of the override,
> namely that users must understand that they are stewards of the
> platform_bus_type, and must take care to preserve the default
> behaviour for "uninteresting" devices.

Completely agree here.

Any overrides of the dev_pm_ops functions that do not also call the
pm_generic_* functions (or their equivalents) should be suspect.

I'll post a proposal for a runtime override shortly.

> Also, the expectation should be that it is a temporary measure until a
> better abstraction is implemented.  It might be that a separate
> bus_type is the way to go (if the multiple driver registration problem
> can be solved) or it might be a way to differentiate pm_ops either
> per-device or per-parent.  I'm not sure, but I'm starting on an OMAP
> project soon, so I may very well end up working on this.

Yes, I'll be glad to work on this too, but first I need to get through
reviewing the backlog of all the OMAP drivers we're converting to
runtime PM.

Kevin

  reply	other threads:[~2010-08-23 14:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-10 23:49 [PATCHv2 0/2] platform: Facilitate the creation of pseudo-platform buses Patrick Pannuto
2010-08-10 23:49 ` [PATCH 1/2] platform: Use drv->driver.bus instead of assuming platform_bus_type Patrick Pannuto
2010-08-10 23:49 ` [PATCH 2/2] platform: Facilitate the creation of pseudo-platform buses Patrick Pannuto
2010-08-13  1:13   ` Patrick Pannuto
2010-08-14 21:04     ` Greg KH
2010-08-13 22:05   ` Grant Likely
2010-08-16 18:47     ` Patrick Pannuto
2010-08-16 20:25       ` Grant Likely
2010-08-16 23:58       ` Michał Mirosław
2010-08-16  1:38   ` Moffett, Kyle D
2010-08-16  6:43     ` Grant Likely
2010-08-19 19:20       ` Kevin Hilman
2010-08-19 19:20         ` Kevin Hilman
2010-08-19 22:22         ` Grant Likely
2010-08-20 18:51           ` Kevin Hilman
2010-08-20 18:51             ` Kevin Hilman
2010-08-20 20:08             ` Grant Likely
2010-08-21  0:10               ` Kevin Hilman
2010-08-21  0:10                 ` Kevin Hilman
2010-08-21  7:10                 ` Grant Likely
2010-08-23 14:53                   ` Kevin Hilman [this message]
2010-08-23 14:53                     ` Kevin Hilman

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=87tyml1itn.fsf@deeprootsystems.com \
    --to=khilman@deeprootsystems.com \
    --cc=Kyle.D.Moffett@boeing.com \
    --cc=damm@opensource.se \
    --cc=dtor@mail.ru \
    --cc=eric.y.miao@gmail.com \
    --cc=grant.likely@secretlab.ca \
    --cc=gregkh@suse.de \
    --cc=kyle@moffetthome.net \
    --cc=lethal@linux-sh.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=ppannuto@codeaurora.org \
    --cc=rjw@sisk.pl \
    /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.