[Ksummit-2013-discuss] [ARM ATTEND] Describing complex, non-probable system topologies

[tony@atomide.com (Tony Lindgren)]

* Olof Johansson <olof@lixom.net> [130802 22:23]:
> On Fri, Aug 2, 2013 at 3:32 PM, Greg KH <greg@kroah.com> wrote:
> > On Fri, Aug 02, 2013 at 05:09:32PM +0100, Will Deacon wrote:
> >> On Fri, Aug 02, 2013 at 03:20:10PM +0100, Greg KH wrote:
> >> > On Fri, Aug 02, 2013 at 12:53:34PM +0100, Will Deacon wrote:
> >> > > We can change the mindset by yelling, but if you're writing a new
> >> > > driver for a peripheral on an ARM SoC, platform_bus is mighty tempting
> >> > > because you get a bunch of device-tree parsing code for free (see
> >> > > drivers/of/platform.c).
> >> >
> >> > I know :(
> >> >
> >> > So, who do I "yell at", and what do I do to make things easier for you
> >> > from the driver-core perspective?
> >>
> >> I would anticipate most of these drivers going through the arm-soc tree, so
> >> Olof and Kevin would be doing the yelling. You could join in the chorus too!
> >>
> >> We basically need reviewers to adopt the position that a new bus should be
> >> considered and dismissed before using the platform_bus, then you can yell
> >> transitively through them.
> >
> > I don't scale if I'm forced to review every driver to ensure that they
> > shouldn't be using platform device and should be creating their own bus
> > type.  You can do that, along with the other ARM developers reviewing
> > these new subsystems and code being added.
> 
> For most new platforms, using basic platform_bus devices makes sense
> when the setup is simple and just has a few devices. It's only when
> they need to add support for {S,IO}MMUs and get the more advanced
> functionality going that things get messy and platform_bus stops
> working.

Yes, and I think we could get some more mileage out of platform bus
by adding some hooks for things like bus specific reset. That's something
that the device drivers don't need to know about.
 
> So, we have the option of having someone care about the {S,IO}MMU
> pieces, and when they spot the attempts to make that work, push them
> towards a proper bus architecture. Until then, the simpler solution is
> probably a reasonable idea compared to having newcomers worry about
> defining new bus architectures and raising the bar for what it takes
> to sort out the initial contributions and getting engaged upstream.

Yes I'd like to avoid having multiple versions of the same driver
to bind to various SoC specific busses that only differ at the bus
level.

Regards,

Tony