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

Will Deacon will.deacon at arm.com
Tue Aug 6 21:52:14 EDT 2013


On Sat, Aug 03, 2013 at 06:16:57AM +0100, Olof Johansson wrote:
> On Fri, Aug 2, 2013 at 3:32 PM, Greg KH <greg at kroah.com> wrote:
> > 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.

Right, but being more forward-looking, we will need to know this kind of
topological information to do simple things like (coherent) DMA or even
just to generate/route an interrupt.

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

I take your point, but at the same time we don't want to find ourselves
suddenly landed with having to convert a bunch of drivers to sit on
different buses as an afterthought. There's likely some middle-ground that
is difficult to envisage up-front.

Will



More information about the linux-arm-kernel mailing list