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

[jgunthorpe@obsidianresearch.com (Jason Gunthorpe)]

On Thu, Mar 07, 2013 at 07:20:05PM -0300, Ezequiel Garcia wrote:
> Now that the Device Bus driver is posted I think we have a nice example
> on how address decoding windows would be allocated through the mbus
> driver, *without* touching the child driver (i.e. NOR driver).

No, that isn't the case. Your device bus driver *is* the child driver,
and you have touched it by adding mbus window code :)

In fact, looking at what you've done - with the DTs you've proposed
your driver does *nothing* but make a call to the mbus driver to setup
the windows for its children. Without timing parameters from the DT the
driver does nothing else!

So what is the point of that? Get rid of your driver, have the mbus
driver set up its own windows and put cfi-flash directly under
mbus. Smaller, simpler, clearer, better.

What you've done is *exactly* the sort of thing I was warning against
:)

BTW, I've made the same basic choice on our Kirkwood systems. The NAND
timing pameters are set by the bootloader and the kernel doesn't touch
them. The bootloader knows which flash chip is placed on the board so
only it knows the correct timing parameters. There is not any reason
to communicate them to the kernel.

I do see a fine use for your driver for non-boot devices, but the
window stuff needs to be removed so it isn't mandatory to use your
driver in the NOP case.

> In conclusion: there is absolutely no need to change the NOR driver,
> and there is no need to explictly add an explicit description of the
> NOR window in the device tree.

As I've said, a DT that has child nodes without an associated address
map is broken.

Jason