On Tue, Jun 17, 2014 at 08:37:09AM -0400, Tom Rini wrote: > On 06/17/2014 05:09 AM, Russell King - ARM Linux wrote: > > A good way that this could have been done is to put an I2C EEPROM on > > each cape, and have that store the DT fragment. The boot loader could > > have then read that from each cape, and used that information to build > > up the final DT. Why this hasn't been thought of, considering that the > > kernel has been moving towards DT for years, is quite unbelievable. > > I had actually talked about this a long while back (face to face) with > people, but the problem was (and still kind of is) the bindings > changing, etc. And that's a strong argument for having stable bindings - or at the very least, ensuring that new bindings which are compatible with older versions. We all know how to deal with this, we've had these discussions frequently with the same outcomes. It's really not something that needs discussing yet again, just to reach the same conclusions. Look, go back to the x86 model. Why does the kernel run on virtually any x86 computer there (firmware bugs not withstanding)? It's not only because the platform is mostly standardised, but also because it's standardised at the firmware (BIOS) level as well. So there's standard ways to find out what hardware is fitted, standard ways to find out how it's wired up (eg, which interrupts) and such like. Like it or not, with ARM64 moving into the server space, and (I believe) we're saying that we want FDT inside ACPI - well, as soon as you go down that path on servers, FDT _has_ to be standardised and stable. Server space will /not/ stand having to update the FDT in firmware for each incremental kernel version change, just because we've decided to change the bindings. Exactly the same should start applying here. Yes, we may not want bindings to be entirely frozen, but when we /do/ change them, we must change them in a way that is compatible with the old bindings. Like, for instance, the iMX AHCI driver that I've had for the last five months patches to fix the incomplete DT bindings for: we have platforms using it which have hard-coded non-hardware default parameters into the driver. I need different hardware parameters for it to come close to working on my hardware, so when introducing new properties for these, I _must_ ensure that when these properties are not specified (as they aren't for the existing platforms using the driver) that their non-hardware default values are used. This even means providing negative options to _disable_ features on the interface, because providing positive "enable this feature" options would mean that their bindings break. This is not rocket science. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
