On Thursday 16 October 2008, Benjamin Herrenschmidt wrote: > On Thu, 2008-10-16 at 10:03 +0200, Stefan Roese wrote: > > Doing this unconditionally is not a good idea since we could have an old > > (buggy) firmware which didn't configure the PCIe controller correctly. > > But I really like your idea with the device-tree property to optionally > > skip this re-configuration. Now we only need to find some "volunteer" to > > do this job... ;) > > I don't have a problem adding support for testing that property and > skipping most of the initial HW setup, basically treating the endpoint > as pre-configured. > > What about using a value for "status" ?
No. "status" is already used to disable/skip the PCIe slot completely. For example on Canyonlands where PCIe#0 is multiplexed with the SATA port. > Or an empty "configured" > property ? Ideally, it should have been the other way around, ie > "unconfigured" for old/buggy stuff but I'm worried there may be existing > out-of-tree device-trees without it :-) Yeah. I could add this "configured" property to the current U-Boot version. Perhaps we should add some version information to it so that Linux could eventually decide to re-configure when the "configured" version is known to be buggy. What do you think? Best regards, Stefan _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
