[PATCH 4/5] sandbox: Audit config.h and common.h usage

[Simon Glass]

Hi Tom,

On Sat, 18 Nov 2023 at 11:04, Tom Rini <trini at konsulko.com> wrote:
>
> Splitting this in to two different threads..
>
> On Sat, Nov 18, 2023 at 10:58:50AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sat, 18 Nov 2023 at 10:45, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Sat, Nov 18, 2023 at 10:09:55AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 17 Nov 2023 at 15:54, Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > Remove and replace common.h and config.h in sandbox when it's not needed
> > > > > and add some explicit includes where needed.
> > > > >
> > > > > Signed-off-by: Tom Rini <trini at konsulko.com>
> > > > > ---
> > > > >  arch/sandbox/cpu/cache.c         | 1 -
> > > > >  arch/sandbox/cpu/cpu.c           | 1 -
> > > > >  arch/sandbox/cpu/sdl.c           | 2 +-
> > > > >  arch/sandbox/cpu/spl.c           | 1 -
> > > > >  arch/sandbox/cpu/start.c         | 2 +-
> > > > >  arch/sandbox/cpu/state.c         | 2 +-
> > > > >  arch/sandbox/include/asm/io.h    | 2 ++
> > > > >  arch/sandbox/include/asm/state.h | 1 -
> > > > >  arch/sandbox/lib/bootm.c         | 1 -
> > > > >  arch/sandbox/lib/fdt_fixup.c     | 1 -
> > > > >  arch/sandbox/lib/interrupts.c    | 1 -
> > > > >  arch/sandbox/lib/pci_io.c        | 1 -
> > > > >  board/sandbox/sandbox.c          | 2 +-
> > > > >  13 files changed, 6 insertions(+), 12 deletions(-)
> > > >
> > > > Reviewed-by: Simon Glass <sjg at chromium.org>
> > > >
> > > > Is it possible to move CFG_SYS_SDRAM_BASE/SIZE to Kconfig?
> > >
> > > Possible? Sure. But I think it would end up being fairly horrible. What
> > > would be nice I think is some Zephyr-style "convert
> > > CONFIG_DEFAULT_DEVICE_TREE to some defines" because we could parse out
> > > /memory to CFG_SYS_SDRAM_BASE/SIZE and that's something we _need_ at
> > > build time.
> >
> > That would be pretty easy to do. But I would prefer to have it create
> > CONFIG_SYS_SDRAM_BASE/SIZE so that it fits in with Kconfig, just that
> > the value is set for you.
>
> I _think_ we need it to be non-CONFIG namespace or we'll run in to other
> problems? We could get the new autogenerated header to be included along
> with generated/autoconf.h but since we couldn't use it within Kconfig
> logic it would be confusing.
>
> > If you like you could create an issue for it.
>
> Please, thanks.

https://source.denx.de/u-boot/u-boot/-/issues/27

Regards,
Simon