Message-ID: <AANLkTi=JDPy4SCL_wW1A8xjnr9xs=XhPe3dsLX_9rLUH@mail.gmail.com>
Date:	Sat, 7 Aug 2010 00:53:01 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Patrick Pannuto <ppannuto@...eaurora.org>
Cc:	Kevin Hilman <khilman@...prootsystems.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"damm@...nsource.se" <damm@...nsource.se>,
	"lethal@...ux-sh.org" <lethal@...ux-sh.org>,
	"rjw@...k.pl" <rjw@...k.pl>,
	"eric.y.miao@...il.com" <eric.y.miao@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...e.de>, alan@...rguk.ukuu.org.uk,
	zt.tmzt@...il.com, magnus.damm@...il.com
Subject: Re: [PATCH] platform: Facilitate the creation of pseduo-platform 
	busses

On Thu, Aug 5, 2010 at 7:25 PM, Patrick Pannuto <ppannuto@...eaurora.org> wrote:
> On 08/05/2010 04:16 PM, Grant Likely wrote:
>> The relevant question before going down this path is, "Is the
>> omap/sh/other-soc behaviour something fundamentally different from the
>> platform bus?  Or is it something complementary that would be better
>> handled with a notifier or some orthogonal method of adding new
>> behaviour?"
>>
>> I don't have a problem with multiple platform_bus instances using the
>> same code (I did suggest it after all), but I do worry about muddying
>> the Linux device model or making it overly complex.  Binding single
>> drivers to multiple device types could be messy.
>>
>> Cheers,
>> g.
>
> From your other email, the distinction of /bus_types/ versus /physical
> or logical buses/ was very valuable (thanks). I am becoming less
> convinced that I need this infrastructure or the ability to create
> pseudo-platform buses. Let me outline some thoughts below, which I
> think at least solves my problems ( ;) ), and if some of the OMAP folks
> and Alan could chime in as to whether they can apply something similar,
> or if they still have need of creating actual new bus types?
>
>
> As we are exploring all of this, let me put a concrete (ish) scenario
> out there to discuss:
>
>        SUB_BUS1---DEVICE1
>       /
> CPU ---
>       \
>        SUB_BUS2---DEVICE2
>
> DEVICE1 and DEVICE2 are the same device (say, usb host controller, or
> whatever), and they should be driven by the same driver. However,
> physically they are attached to different buses.
>
> SUB_BUS1 and SUB_BUS2 are *different* and let's say require a different
> suspend method. If I understand correctly, the right way to build the
> topology would be:
>
> struct device_type SUB_BUS1_type = {
>        .name = "sub-bus1-type",
>        .pm   = &sub_bus1_pm_ops;
> };
>
> struct platform_device SUB_BUS1 = {
>        .init_name = "sub-bus1",
>        .dev.type  = &sub_bus1_type,
> };
>
> struct platform_device DEVICE1 = {
>        .name       = "device1",
>        .dev.parent = &SUB_BUS1.dev,
> };
>
> platform_device_register(&SUB_BUS1);
> platform_device_register(&DEVICE1);
>
> [analogous for *2]

Not quite.  The device_type is intended to collect similar, but
different things (ie, all keyboards, regardless of how they are
attached to the system).  Trying to capture the device-specific
behavour really belongs in the specific device driver attached to the
SUB_BUS* device.  In fact, the way you've constructed your example,
SUB_BUS1 and SUB_BUS2 don't really need to be platform_devices at all;
you could have used a plain struct device because in this example you
aren't binding them to a device driver).

That being said, because each bus *does* have custom behaviour, it
probably does make sense to either bind each to a device driver, or to
do something to each child device that changes the PM behaviour.  I
haven't dug into the problem domain deep enough to give you absolute
answers, but the devres approach looks promising, as does creating a
derived platform_bus_type (although I'm not fond of sharing device
drivers between multiple bus_types).  Another option might be giving
the parent struct device some runtime PM operations that it performs
per-child.  I'm just throwing out ideas here though.

> which would yield:
>
> /sys/bus/platform/devices/
>  |
>  |-SUB_BUS1
>  |  |
>  |  |-DEVICE1
>  |
>  |-SUB_BUS2
>  |  |
>  |  |-DEVICE2

You're looking in the wrong place.  Look in /sys/devices instead of
/sys/bus... (see comments below)

> Which is the correct topology, and logically provides all the correct
> interfaces.  The only thing that becomes confusing now, is that SUB_BUS*
> is *actually* a physically different bus, yet it's not in /sys/bus;
> although I suppose this is actually how the world works presently (you
> don't see an individual entry in /sys/bus for each usb host controller,
> which is technically defining a sub-bus...)

/sys/bus is for bus_types, not bus instances.  All USB devices will be
listed in /sys/bus/usb/devices regardless of the bus instance that
they attached to.

However, look carefully at the files in /sys/bus/*/devices.  Notice
that they are all symlinks?  Notice that the all of them point to
directories in /sys/devices?  /sys/bus tells you which devices are
registered against each bus type, but /sys/devices is the actual
structure.  Always look in /sys/devices when you want to know the
topology of the system.

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