On Sun, Feb 25, 2018 at 05:44:42PM +0000, Alex Kiernan wrote: > On Sun, Feb 25, 2018 at 1:23 PM, Tom Rini <[email protected]> wrote: > > On Sun, Feb 25, 2018 at 11:29:30AM +0100, Lukasz Majewski wrote: > >> Hi Tom, > >> > >> > Migrate the users of CONFIG_SYS_BOOTCOUNT_ADDR to Kconfig. We can > >> > provide a default for BOOTCOUNT_AM33XX as that's a specific part of > >> > the RTC in use. We can also provide a default for ARCH_LS1043A and > >> > ARCH_LS1021A as they had been previously calculated and their symbols > >> > are in Kconfig. In the case of other QE-enabled platforms, they are > >> > not so we must update the relevant defconfig files. The previous > >> > default only applied in some cases, even on a specific SoC family. > >> > >> Thanks for your patch. > >> > >> I suppose, that it is a last puzzle to convert BOOTCOUNT to Kconfig. > >> > >> Please correct me if I'm wrong, but it shall be applied on top of > >> Alex's series: > >> > >> http://patchwork.ozlabs.org/cover/874539/ > > > > Correct. I tested that and the only part I wasn't 100% confident in > > after transition was the addresses. > > > > Having looked at it both ways (migrate CONFIG_SYS_BOOTCOUNT_ADDR into > Kconfig, migrate everything out of the CONFIG_ namespace) they both > seem to have downsides... either you have magic numbers in Kconfig or > you have configuration littered through include files. It feels like > it wants some piece of machinery we don't really have today.
Long term, I think cases like this should be handled either way default 0xF00 if BAR or yes, we re-work things so it's out of the CONFIG namespace. In the case of bootcount_davinci.c we could easily key that off of CONFIG_AM33XX #elif CONFIG_SOC_DA8XX as we're talking about an on-chip RTC and that's not going to vary much in location. But for the generic driver that really is harder to say. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
