Robert, On 25/02/15 17:06, Robert Abel wrote: > Hi Roger, > > On 25 Feb 2015 13:02, Roger Quadros wrote: >> This creates platform devices for the children of child, but what about >> platform device for the child itself? > It seems my first try in the other patch set wasn't so wrong after all. Maybe > unconditionally call > > of_platform_device_create(child,...) and > of_platform_populate(child, ...)? > >> Shouldn't the bus driver for that bus be responsible for spawning children >> of its bus? > Well, a bus driver doesn't actually do much work here. The standard buses are > just there for offset and so on. > And that's my use case. Have one CS region with fixed settings and multiple > devices in it. > > Creating code that in effect replicates what simple-bus does isn't > worthwhile. Basically, it would replicate half the code that > of_platform_populate goes through anyway without good reason. > > If complex bus-behavior is needed -- more than single-bus offset shifts --, a > complex bus driver can always be written. > Since it wouldn't match of_default_match_table, it itself would be > responsible for creating children. > > I think I'll go with my first patch for this one, maybe call > of_platform_decide_create unconditionally to check whether buses are > available.
OK. Would be interesting to see how unconditional call to of_platform_decide_create() behaves for your case. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
