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

Jason Gunthorpe jgunthorpe at obsidianresearch.com
Thu Mar 7 01:35:13 EST 2013

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.


More information about the linux-arm-kernel mailing list