On Thu, 2008-07-17 at 00:58 +0200, Arnd Bergmann wrote: > On Wednesday 16 July 2008, Grant Likely wrote: > > > > > Shouldn't it be enough to have a common compatible value in each > > > of these boards, e.g. "amcc,generic-ppc44x" and then just ignore the > > > specific type unless you need to do something special? > > > > This is bad for the same reason that "amcc,44x-<blah>" compatible values > > are bad in device nodes. The definition of '*-44x-*' changes over time as > > new parts are added. Compatible values should always reflect an exact > > part number. > > I agree in general, but I also think that all 44x boards should be > regarded as the same machine time, in the same way that all powermacs > are detected as compatible with "Power Macintosh" or "MacRISC", or > how all sorts of serial ports claim compatibility with i8250. > > For classic SOCs like 4xx or 52xx, the SOC familiy more or less defines > the platform, and all the details about peripherals can be expressed > in the device tree elsewhere.
This is what Grant has done for 52xx and what I was talking about with "4xx_board.c", though 4xx_soc.c is probably a better name. My hesitation is that while it's true today that 440<chip name> defines the SoC, it might not always be. And the Virtex boards are craziness with the core and FPGA setup. So we need to be careful a bit when chosing what do "bind" to for generics. > If one board is so different that you need a separate board setup > in the kernel, it should simply not claim compatibility with the > SOC platform. Right. Today we only have a few "overrides" in 4xx. Namely Canyonlands/Glacier, and Bamboo/Yosemite (Sequoia/Rainier should also really be that way, but they aren't). So if we decide to go to a different scheme, it shouldn't be a big deal to switch. josh _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev