Le 16/04/2011 09:26, Albert ARIBAUD a écrit : > Le 03/04/2011 18:35, Eric Bénard a écrit : > >> diff --git a/board/eukrea/cpu9260/cpu9260.c b/board/eukrea/cpu9260/cpu9260.c >> index 61b6c33..9ec48a0 100644 >> --- a/board/eukrea/cpu9260/cpu9260.c >> +++ b/board/eukrea/cpu9260/cpu9260.c > >> @@ -188,26 +175,16 @@ int board_init(void) >> >> int dram_init(void) >> { >> - gd->bd->bi_dram[0].start = PHYS_SDRAM; >> - if (get_ram_size((long *) PHYS_SDRAM, PHYS_SDRAM_SIZE) != >> - PHYS_SDRAM_SIZE) >> - return -1; >> - >> - gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE; >> + gd->ram_size = get_ram_size((volatile long *)CONFIG_SYS_SDRAM_BASE, >> + CONFIG_SYS_SDRAM_SIZE); > > Checkpatch warns about the volatile here. > > I know the get_ram_size() prototype calls for the volatile attribute, > but what is the rationale here for this? get_ram_size() just needs the > RAM base address *value*; if it requires volatile accesses to it, it can > arrange for these inside its definition. Besides, throughout the code > base there are 19 instances of get_ram_size() callw where the argument > is cast to volatile, against 130 where it is not. > > Wolfgang et al.: how about removing the 'volatile' qualifier from the > get_ram_size() prototype? > > Eric: if your patch does not cause a warning without the volatile in the > call, can you update and repost it as V2? > >> diff --git a/include/configs/cpu9260.h b/include/configs/cpu9260.h >> index d239423..a8ada2d 100644 >> --- a/include/configs/cpu9260.h >> +++ b/include/configs/cpu9260.h > >> -#define CONFIG_SYS_NAND_READY_PIN AT91_PIN_PC13 >> -#define CONFIG_SYS_NAND_ENABLE_PIN AT91_PIN_PC14 >> +#define CONFIG_SYS_NAND_READY_PIN AT91_PIO_PORTC, 13 >> +#define CONFIG_SYS_NAND_ENABLE_PIN AT91_PIO_PORTC, 14 > >> -#define CONFIG_RED_LED AT91_PIN_PC11 >> -#define CONFIG_GREEN_LED AT91_PIN_PC12 >> -#define CONFIG_YELLOW_LED AT91_PIN_PC7 >> -#define CONFIG_BLUE_LED AT91_PIN_PC9 >> +#define CONFIG_RED_LED AT91_PIO_PORTC, 11 >> +#define CONFIG_GREEN_LED AT91_PIO_PORTC, 12 >> +#define CONFIG_YELLOW_LED AT91_PIO_PORTC, 7 >> +#define CONFIG_BLUE_LED AT91_PIO_PORTC, 9 > > Checkpatch considers these errors. This is again a case where we'd want > it to ignore it... or reconsider this type of macro, which intends to > expand to several function arguments. > > For now I'll ignore these 6 checkpatch errors. > > Amicalement,
Applied to u-boot-arm/master, thanks. Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot