[U-Boot-Users] [PATCH 1/1] Add support for ATMELAT91SAM9G20EK board

[Haavard Skinnemoen]

On Fri, 25 Jul 2008 17:44:52 -0500
<Ken.Fuchs at bench.com> wrote:

> > But since we already have a CONFIG_AVR32 #define, we can clean
> > up the mess in macb.c by simply reversing the logic.  
> 
> If CONFIG_AVR32 can be used in macb.c without ofuscation, why is
> CONFIG_AT91 needed here?  However, "simply reversing the logic"
> may be too much ofuscation though; we want clear rather than
> clever code after all.

Reversing the logic wouldn't obfuscate anything. The code in question
is a simple matter of "AT91 needs to do it this way, AVR32 needs to do
it another way". Whether we check for AT91 or AVR32 is completely
arbitrary.

> An example of what I'd be opposed to is defining
> CONFIG_AT91SAM9260_OR_AT91SAM9263 where it is TRUE if either
> CONFIG_AT91SAM9260 or CONFIG_AT91SAM9263 are TRUE.

I completely agreee with this.

> Can you see where this might be used in the macb.c code?

Not really, no. The processors aren't _that_ different. It's a bit
unfortunate that the USRIO register ended up with different behaviour
on AT91 and AVR32, but fixing the silicon at this point would just make
things worse, and IMO it's not a huge deal. From a CPP abuse point of
view, the macb driver is IMO exceptionally clean compared to a lot of
other code in u-boot.

Haavard