On Fri, 25 Jul 2008 17:44:52 -0500 Ken.Fuchs@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