[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
    On Fri, Aug 20, 2010 at 12:51 PM, Kevin Hilman
    <> wrote:
    > Grant Likely <> writes:
    > [...]
    >>> One of the primary goals of this (at least for me and it seems Magnus also)
    >>> is to keep drivers ignorant of their bus type, and any bus-type-specific
    >>> code should be done in the bus_type implementation.
    >> Heh; which just screams to me that bus_type is the wrong level to be
    >> abstracting the behaviour
    > Heh, now I feel like we're going around in circles.  Remember, I never
    > wanted to create add a new bus_type.  Someone else [ahem] suggested
    > doing the abstraction at the bus_type level.  ;)

    Hey! I didn't suggest it either! I believe that was Greg at ELC. I
    just... um... kind of took it and ran with it. :-)

    >> (but I also understand your need for the
    >> "omap_device" wrapper around platform_device which also requires some
    >> method to sort out when a platform_device really is an omap_device
    >> without an unsafe dereference).
    > Yes, I'm working on the devres approach to that now, as is Magnus for
    > the sh-mobile version (proposed for .36-rc1[1])
    >>> Both for SH and OMAP, we've been using the (admiteddly broken)
    >>> weak-symbol-override approach to getting a custom bus-type based on the
    >>> platform_bus.  We've been using that in OMAP for a while now and have
    >>> not seen any need to for the drivers to know if they are on the vanilla
    >>> platform_bus or the customized one.
    >>> I'm very curious to hear what type of impact you expect to the drivers.
    >> 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.


    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.
    If the override (even when fixed to work at runtime) applies to every
    device on the platform_bus_type, then I'll nack it. My concern here
    is that the SoC or platform support code doesn't get to "own" the
    platform_bus_type. Other drivers/code can register their own set of
    platform_devices, which may also need to perform their own dev_pm_ops
    override. If the override is global to the platform_bus_type, then
    the model will not scale.

    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-20 22:11    [W:0.025 / U:14.008 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site