On Mon, Jan 25, 2010 at 10:12:25PM -0800, David Brownell wrote: > 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? It is being ported to ARM and all other Linux platforms at the moment by Grant. > That's basically for hardware configuration. The issues > Felipe asked about are more at the software level. This could also be specified in the device tree, as that is a configuration issue for how the system is to be defined. > Run a different kernel ... the same hardware should be > able to come up acting like a very different USB device. Exactly. > 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. True, that's what the device tree is for. > 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. Then I suggest you work with Grant to resolve the issues :) thanks, greg k-h -- 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
