On Monday 25 January 2010, Greg KH wrote: > On Mon, Jan 25, 2010 at 12:46:48PM +0000, Mark Brown wrote: > > On Fri, Jan 22, 2010 at 12:50:21PM -0800, Greg KH wrote: > > > > > Isn't the Device Tree stuff supposed to help solve this type of problem? > > > > It's not really a viable solution for anything outside of PowerPC and > > SPARC at the minute and it won't be an overnight rollout if other > > platforms pick it up either. > > Sure, but that is what this is supposed to solve. Otherwise you are > stuck with the horrid arm config file nightmare. ARM uses the same .config files as all other Linux kernels. If that is "horrid", so is every other architecture... Do you maybe mean the arch/arm/mach-xxx/board-yyy.c *setup* files? Those are really easy to use and evolve. And you really *need* hooks where board-specific code can fixup whatever the boot loader does wrong, including coping with version-specific glitches and the reality that system functionality changes between software releases. (One can only wish that ACPI made such stuff practical. BIOS tables in PC are very notoriously buggy. Anything assuming the boot code is 100% correct is going to cause problems; boot code, like hardware, is always on a very different development timetable than the OS.) The only actual issue I've ever seen with the ARM boot scheme is that having a unique board ID can be a bit awkward ... early revisions of boot loaders sometimes use the wrong IDs (say, cloned from a development board not the actual production one). But that's easy enough to cope with. Some versions of U-Boot have acknowledged that, to the extent of having commands to change the board ID. (Early boards often need to be manufactured before the ID is known.) Yes, board bringup is error prone when assigned to junior coders who don't know what they're doing, and don't understand that cut/paste of hardware setup from entirely different boards creates problems. But so is everything else assigned to junior coders. :) - 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
