Message-ID: <AANLkTi=WKcb59jJQuLVfqJG07Et+cU75GOC5Lrr_dXR4@mail.gmail.com>
Date:	Sat, 21 Aug 2010 01:10:05 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Kevin Hilman <khilman@...prootsystems.com>
Cc:	"Moffett, Kyle D" <Kyle.D.Moffett@...ing.com>,
	Patrick Pannuto <ppannuto@...eaurora.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"magnus.damm@...il.com" <magnus.damm@...il.com>,
	"gregkh@...e.de" <gregkh@...e.de>,
	Paul Mundt <lethal@...ux-sh.org>,
	Magnus Damm <damm@...nsource.se>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Eric Miao <eric.y.miao@...il.com>,
	Dmitry Torokhov <dtor@...l.ru>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Kyle D Moffett <kyle@...fetthome.net>
Subject: Re: [PATCH 2/2] platform: Facilitate the creation of pseudo-platform buses

On Fri, Aug 20, 2010 at 6:10 PM, Kevin Hilman
<khilman@...prootsystems.com> wrote:
> Grant Likely <grant.likely@...retlab.ca> writes:
>
> [...]
>
>>>>
>>>> My fears on this point may very well be unfounded.  This isn't the
>>>> hill I'm going to die on either.  Show me an implementation of driver
>>>> sharing that is clean and prove me wrong!  :-)
>>>
>>> IMHO, simply overriding the few dev_pm_ops methods was the cleanest and
>>> simplest.
>>>
>>> Since we seem to be in agreement now that the a new bus may not the
>>> right abstraction for this (since we want it to be completely
>>> transparent to the drivers), I'll go back to the original design.  No new
>>> bus types, keep the platform_bus as is, but simply override the few
>>> dev_pm_ops methods I care about.  This is what is done on SH,
>>> SH-Mobile[1] and my original version for OMAP that started this
>>> conversation.
>>>
>>> Yes, the weak-symbol method of overriding is not scalable, but that's a
>>> separate issue from whether or not to create a new bus.  I have a
>>> proposed fix for the weak which I'll post shortly.
>>
>> Okay.
>>
>> One constraint remains though:  If you can override the dev_pm_ops on
>> a per-device or per-device-parent basis, then you've got my support.
>
> hmm, a new requirement?, and one that would require some significant
> changes to the driver model.

Nope!  Not a new requirement; this is the issue that this entire
thread has been about.  Hijacking the entire platform_bus_type
behaviour for a particular bus is the wrong thing to do because there
are other users in the same system.

> Currently, dev_pm_ops for a bus applies globally to *all* devices on
> that bus (or class or type) and changing that would require changing the
> platform_bus code to start having per-device (or per-parent-device)
> checks.

I'm not opposed to modifying the platform_bus_type to support the use-case.

>> If the override (even when fixed to work at runtime) applies to every
>> device on the platform_bus_type, then I'll nack it.
>
> /me can't help but wonder why the OMAP implementation is getting all the
> negative attention while the other identical implementations are already
> upstream.

OMAP is not getting singled out.  This applies to all the implementations.

>> My concern here is that the SoC or platform support code doesn't get
>> to "own" the platform_bus_type.
>
> Well, I'm not proposing that here.  This "feature" already exists in
> mainline (albeit using the less-than-optimal weak symbol approach.)  All
> I'm proposing is fixing it to make it multi-arch friendly.

Oops, I didn't phrase that very well.  What I meant was that SoC or
platform support code must not be allowed to "own" or hijack the
platform_bus_type for it's own purposes.  What I wrote sounds like I
was suggesting that as a good thing.

> If you think this behavior should be changed to non global, that should
> be done a separate series since it is not directly related to runtime PM
> support for a given platform, IMO.
>
>> Other drivers/code can register their own set of
>> platform_devices, which may also need to perform their own dev_pm_ops
>> override.
>
> IMHO, we should deal with such hypothetical, future problems *if* they
> arise down the road.
>
>> 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.

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.

Cheers,
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists