[PATCH] ARM: Include Makefile.boot only when it exists

Brian Swetland swetland at google.com
Sat Apr 30 04:44:15 EDT 2011

On Fri, Apr 29, 2011 at 12:43 PM, Nicolas Pitre <nico at fluxnic.net> wrote:
> On Fri, 29 Apr 2011, Russell King - ARM Linux wrote:
>> Even the OMAP4 clock data which is supposedly generated from TIs
>> internal hardware database changes on a fairly regular basis.  You'll
>> find that the per-clk flags get changed, the operations get changed,
>> etc.
>> It doesn't _matter_ how it is represented, it will continue to be patched
>> whether it's structures in a .c file (as it currently is) or whether it's
>> a device tree description for each clock.
> If that is the case, the associated drivers have to change as well to be
> in sync with the new flags, etc.  And to me it is way better to have
> both the data and the drivers maintained in a single place compared to
> the unavoidable bugs that will crop up due to version skews.

This is a one reason why I'm skeptical of the "device tree" approach
and somewhat concerned about a potential future where board files
would vanish, to be replaced by device trees which may well come from
some place disconnected from the kernel that will depend on them being
correct to work.

I live in a world where the bootloader is often a black box and rarely
updated. Mobile device OEMs usually have their own bootloader
(nothing standard nor open source) which is closely tied to their
factory process and testing, etc.  Having to trust the bootloader to
get anything right beyond passing me a machine type, system revision,
and a commandline is pretty scary.  Add to that the fact that
bootloaders often aren't updated in the field (it's the riskiest piece
of the system to update).

The other reason is that I've rarely seen a board spin that didn't
involve some quirky change that would be hard to represent in a static
configuration format.  Oh, you need to power up this level shifter
before you can talk to the back half of that i2c bus, by way of this
gpio over here?  Eventually you end up with something like a byte-code
or forth runtime to handle these cases and then things really get fun
from the "where's the code that does what?!" standpoint.


More information about the linux-arm-kernel mailing list