Michael Ellerman <m...@ellerman.id.au> writes: > Jack Miller <j...@codezen.org> writes: > >> On Wed, Aug 03, 2016 at 05:16:34PM +1000, Michael Ellerman wrote: >>> We could instead just search for all nodes that are compatible with >>> "ibm,opal-flash". We do that for i2c, see opal_i2c_create_devs(). >>> >>> Is there a particular reason not to do that? >> >> I'm actually surprised that this is preferred. Jeremy mentioned something >> similar, but I guess I just don't like the idea of finding devices in weird >> places in the tree. > > But where is "weird". Arguably "/opal/flash" is weird. What does it > mean? There's a bus called "opal" and a device on it called "flash"? No. > > Point being the structure is fairly arbitrary, or at least debatable, so > tying the code 100% to the structure is inflexible. As we have discovered. > > Our other option is to tell skiboot to get stuffed, and leave the flash > node where it was on P8. > >> Then again, if we can't trust the DT we're in bigger >> trouble than erroneous flash nodes =). > > Quite :) > >> If we really just want to find compatible nodes anywhere, let's simplify i2c >> and pdev_init into one function and make that behavior consistent with this >> new patch. > > That seems OK to me. > > We should get an ack from Stewart though for the other node types.
For finding nodes based on compatible no matter where they are in the tree, Acked-by: Stewart Smith <stew...@linux.vnet.ibm.com> (and yes, includes other nodes too) The exact location then isn't too important, and having a /flash that's ibm,opal-flash and allows for some other driver to bind to it I think is also something we shouldn't rule out. -- Stewart Smith OPAL Architect, IBM.