On Apr 22, 2009, at 4:57 PM, Timur Tabi wrote:

Kumar Gala wrote:

New nodes.  For example I've proposed a "local access window" node.
Once I add it I plan on changing code to use it.  This will break an
old device tree booting with the new kernel and I'm completely ok with
that.

Are we having two different conversations?  I was talking about this
block from your email:

arch/powerpc/include/asm/cpm2.h:#define CPM_MAP_ADDR (get_immrbase() +
0x80000)
arch/powerpc/sysdev/cpm2.c:     cpm2_immr = ioremap(get_immrbase(),
CPM_MAP_SIZE);
these two are related and seem like we could look for "fsl,cpm2"

That's okay, as long as you don't break compatibility with older
device trees that don't have that property, unless you can demonstrate
that these trees would never work with the current kernel anyway.

Specifically, I was referring to this comment:
        
        these two are related and seem like we could look for "fsl,cpm2"

And my point was that not all device trees have "fsl,cpm2" in their CPM
nodes.

Yes -- we are having two different conversations. I've moved on from the specific issue of "fsl,cpm2" not existing in old device trees. I've moved to a more general statement about how I can solve some of the CPM2 related uses of cpm2_immr. For example we assign cpmp based on cpm2_immr. I could stop using cpm2_immr and solve this problem by adding a new device node for the comm-proc registers in the device trees at which point I'd break older .dts working with the kernel.

- k
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Reply via email to