On Sat, 2015-05-02 at 09:29 +1000, Benjamin Herrenschmidt wrote: > Looking a bit more at it, I don't quite see how I can attach a subtree > using that stuff. > > Instead, each node in the overlay seems to need extra nodes and > properties to refer to the original. > > So the FW would essentially have to create something a lot more complex > than just reflattening a bit of its internal tree. For each internal > node, it will need to add all those __overlay__ nodes and properties. > > That is not going to fly for me at all. It's order of magnitudes more > complex than the solution we are pursuing. > > So I think for our use case, we should continue in the direction of > having a helper to unflatten a piece of FDT underneath an existing > node. I don't like the "HYBRID" stuff though, we should not refer to > the original FDT, we should just make them normal dynamic nodes. A bit more thought... if we were to use the overlay stuff, Gavin, what we *could* do is add to OPAL FW internal representation a generation count to every node and property. That way we could essentially know whenever something's changed from what we flattened originally for the kernel. We can then create a generic (not PCI specific) call that generates an overlay tree for every node and property that has a generation count that is newer than what was flattened (or passed by the OS). It's still a LOT more complex than what we need though... Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
