[lkml]   [2010]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/2] platform: Facilitate the creation of pseudo-platform buses
Grant Likely <> 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.

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)

> 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

> 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.

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2010-08-21 02:13    [W:0.038 / U:5.068 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site