On Mon, May 12, 2014 at 1:10 AM, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 2014-05-12 at 16:00 +1000, David Gibson wrote: >> I'm not all that impressed by this translation code - in particular >> the per-bus-type hooks don't make sense to me. AFAIK the >> interpretation of ranges is not bus specific. I think it will also >> fail in some cases with #address-cells > 2, which is unfortunate. >> >> I'm about to post my own implementation of address translation. > > Well, I came up with the original code which did per-bus type hooks. > There are cases where it is needed. > > Take PCI. The top word can contain completely unrelated stuff such > as the "prefetchable" attribute. > > It's perfectly legal to put a prefetchable BAR under a non-prefetchable > bridge window. > > However a translation scheme that doesn't know to know that bit > will fail. > > It's not far fetched, it happens on our machines today. > > And that's just one of the problems I had back then... But what you wrote was for unflattened tree. For early FDT uses, do we really need to worry about PCI or other special cases? The current FDT address translation code in arch/powerpc/boot/devtree.c (yes, now we have 3 implementations) does not for example. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
