On Sat, Jul 2, 2016 at 5:17 PM, Chen-Yu Tsai <w...@csie.org> wrote: > On Fri, Jul 1, 2016 at 6:39 PM, Hongbo Zhang <macro.wav...@gmail.com> wrote: >> On Sun, Jun 19, 2016 at 12:38 PM, Chen-Yu Tsai <w...@csie.org> wrote: >>> The original PSCI implementation assumed CONFIG_ARMV7_PSCI_NR_CPUS=4. >>> Add this as a fallback value in case platforms have not defined it. >>> >>> Signed-off-by: Chen-Yu Tsai <w...@csie.org> >>> --- >>> arch/arm/include/asm/config.h | 5 +++++ >>> 1 file changed, 5 insertions(+) >>> >>> diff --git a/arch/arm/include/asm/config.h b/arch/arm/include/asm/config.h >>> index 435fc4521c2e..f70302dfc4f1 100644 >>> --- a/arch/arm/include/asm/config.h >>> +++ b/arch/arm/include/asm/config.h >>> @@ -23,4 +23,9 @@ >>> #include <asm/arch/config.h> >>> #endif >>> >>> +/* Original code assumed 4 CPUs */ >>> +#ifndef CONFIG_ARMV7_PSCI_NR_CPUS >>> +#define CONFIG_ARMV7_PSCI_NR_CPUS 4 >> >> This makes platforms which have there own macro definition embarrassed >> somehow. >> we should add >> #define CONFIG_ARMV7_PSCI_NR_CPUS CONFIG_MAX_CPUS >> if this patch merged. >> some of our platform even has 16 cores. > > I'm not sure how CONFIG_MAX_CPUS is used though. > > Thinking about this, my first approach is probably wrong. > I should add missing PSCI_NR_CPUS for the existing platforms. > New platforms should define it themselves when enabling PSCI.
Yes, this is better. > Failure to do so will result in a compile error, rather than > having a fallback value that subtly breaks later on. > > Regards > ChenYu > >> >>> +#endif >>> + >>> #endif >>> -- >>> 2.8.1 >>> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
