[PATCH 04/10] bus: introduce an Marvell EBU MBus driver

[Jason Cooper]

On Wed, Mar 06, 2013 at 11:35:13PM -0700, Jason Gunthorpe wrote:
> On Thu, Mar 07, 2013 at 03:37:43AM +0000, Arnd Bergmann wrote:
> 
> > Yes. We can even use the index of the "ranges" property to refer directly
> > to the number of the window, so ranges replaces the kernel internal
> > struct mvebu_mbus_mapping.
> 
> I think we are thinking the same thing, but, s/index/bus address/ and
> s/number of the window/target id/ ?
> 
> > I would also suggest not making the mbus compatible with "simple_bus", but
> > instead probing /only/ the mbus device at bootup, which can then set
> > up the hardware based on the ranges property and then call
> > of_platform_populate on its children.
> 
> Yeah, something is needed to make startup ordering work. Things like
> the timer and main interrupt controller live behind the special
> internal regs window, so in a perfect world finding the timer would
> automatically setup the enclosing bus structures ...
> 
> > > I certainly agree with this. If it wasn't for the idea that the DT is
> > > a stable ABI and thus must be perfect from the start, I wouldn't have
> > > mentioned any of this right now, making fine tuning adjustments as a
> > > follow on seems better to me.
> > > 
> > > It is absolutely way too much work to try and fix everything in one
> > > go! I would be happy to see your patch go in as-is, but mildly unhappy
> > > to see us stuck with this DT layout forever...
> > > 
> > > Especially since I really want to see your PCI stuff go in ....
> > 
> > I basically agree with everything you write in this mail, Jason, and
> > I was about to make exactly the same comments myself.
> > 
> > Getting the binding right is certainly a priority here, but I also think
> > that we don't need to rush the code to use that binding (although having
> > the code work would make me more comfortable thinking that the binding
> > actually works).
> 
> Do you think Jason C's notion to take it as is and then be OK with
> altering the binding later pending agreement is acceptable for now? I
> agree with Thomas that this is too much to ask just to get
> the already huge Marvell PCI-E patchset into mainline.

Since these bindings are mvebu-specific, and since there are no DT
based boards on the market for mvebu, I think this is an acceptable
compromise.

Thanks to JasonG and Arnd for clearing up my misunderstandings.  The
only thing I would really like to see at this point is a clear,
thought-through migration path from Thomas' patches to JasonG's
proposal.  Obviously, it would be nice if the proposer took a crack at
this. ;-)

I'd really like to avoid a churn/spaghetti nightmare down the road if we
can avoid it with a simple tweak now.

thx,

Jason.