[PATCH 4/5] sandbox: Audit config.h and common.h usage
Simon Glass
sjg at chromium.org
Sat Nov 18 18:58:50 CET 2023
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.
If you like you could create an issue for it.
>
> > For CFG_SYS_BAUDRATE_TABLE perhaps we could have a standard set that
> > most boards use, or turn it into a set of word flags with a bit for
> > each rate?
>
> We do, largely, use a default table. I forget which further rework I
> posted as an RFC a few years ago, but I believe it was largely seen as
> being uglier than what we have today.
I found these:
https://patchwork.ozlabs.org/project/uboot/list/?series=262148&state=*
http://patchwork.ozlabs.org/project/uboot/patch/20210925121958.26001-1-pali@kernel.org/
IMO the second one from Pali makes sense, but it was never followed
up. It doesn't look too difficult.
We should have a policy that if people complain about a patch but
don't follow up, we apply the patch we have.
I would like to drop configs/sandbox.h at some point and these two
points are all that is left.
Regards,
Simon
More information about the U-Boot
mailing list