On Friday 22 January 2010, Greg KH wrote: > > > The problem I'm trying to solve is when building a kernel for several > > different devices, then we have to keep on adding if > > (machine_is_xxxx()), and that only works on ARM-based kernel images > > afaict. > > Isn't the Device Tree stuff supposed to help solve this type of problem? You mean the OpenFirmware-derived thing, which is not really an option except on SPARC and PowerPC? That's basically for hardware configuration. The issues Felipe asked about are more at the software level. Run a different kernel ... the same hardware should be able to come up acting like a very different USB device. But the hardware would be unchanged. Same codecs hooked up in the same quirky ways; same GPIO wiring, same external chips on non-hotpluggable busses, same SoC peripherals hooked up (or not) ... no hardware changes. FWIW, I'm no big fan of that tree thing either. When it's used in the "flattened tree combined with kernel image" mode it's just an overly simplified -- and much less flexible!! -- version of a board-specific startup file, like an arch/arm/mach-xxx/board-yyy.c file; no real run-this-code hooks. (OpenFirmware at least had FORTH code associated with each device node ... in the same way that ACPI has AML bytecode. But that's not C code from the operating system.) If it's part of boot code in flash or ROM, it's fragile and hard to fix. In both cases it has all the drawbacks of ACPI's device trees, in terms of needing to evolve and maintain data apart from the drivers manipulating it. Combined with a fair amount of requirement for committee design (faugh!) to come up with details of those data tables. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
