[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] RISC-V: virt: This is a "sifive,test1" test finisher
From: |
Peter Maydell |
Subject: |
Re: [PATCH] RISC-V: virt: This is a "sifive,test1" test finisher |
Date: |
Fri, 8 Nov 2019 18:04:47 +0000 |
On Fri, 8 Nov 2019 at 17:15, Alistair Francis <address@hidden> wrote:
>
> On Fri, Nov 8, 2019 at 9:05 AM Palmer Dabbelt <address@hidden> wrote:
> >
> > The test finisher implements the reset command, which means it's a
> > "sifive,test1" device. This is a backwards compatible change, so it's
> > also a "sifive,test0" device. I copied the odd idiom for adding a
> > two-string compatible field from the ARM virt board.
> >
> > Fixes: 9a2551ed6f ("riscv: sifive_test: Add reset functionality")
> > Signed-off-by: Palmer Dabbelt <address@hidden>
> > Signed-off-by: Palmer Dabbelt <address@hidden>
> > ---
> > hw/riscv/virt.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> > index 23f340df19..74f2dce81c 100644
> > --- a/hw/riscv/virt.c
> > +++ b/hw/riscv/virt.c
> > @@ -359,7 +359,10 @@ static void create_fdt(RISCVVirtState *s, const struct
> > MemmapEntry *memmap,
> > nodename = g_strdup_printf("/test@%lx",
> > (long)memmap[VIRT_TEST].base);
> > qemu_fdt_add_subnode(fdt, nodename);
> > - qemu_fdt_setprop_string(fdt, nodename, "compatible", "sifive,test0");
> > + {
> > + const char compat[] = "sifive,test1\0sifive,test0";
>
> Does this really work? Why not use qemu_fdt_setprop_cells()?
>
> Alistair
>
> > + qemu_fdt_setprop(fdt, nodename, "compatible", compat,
> > sizeof(compat));
> > + }
qemu_fdt_setprop_cells() is for "set this property to
contain this list of 32-bit integers" (and it does a byteswap
of each 32-bit value from host to BE). That's not what
you want for a string (or a string list, which is what
we have here).
Cc'ing David Gibson who's our device tree expert to see if there's
a nicer way to write this. Oddly, given that it's used in the
ubiquitous 'compatible' prop, the dtc Documentation/manual.txt
doesn't say anything about properties being able to be
'string lists', only 'strings', '32 bit numbers', 'lists of
32-bit numbers' and 'byte sequences'. You have to dig through
the header file comments to deduce that a string list is
represented by a string with embedded NULs separating
each list item.
thanks
-- PMM
- [PATCH] RISC-V: virt: This is a "sifive,test1" test finisher, Palmer Dabbelt, 2019/11/08
- Re: [PATCH] RISC-V: virt: This is a "sifive,test1" test finisher, Alistair Francis, 2019/11/08
- Re: [PATCH] RISC-V: virt: This is a "sifive,test1" test finisher,
Peter Maydell <=
- Re: [PATCH] RISC-V: virt: This is a "sifive,test1" test finisher, Palmer Dabbelt, 2019/11/08
- Re: [PATCH] RISC-V: virt: This is a "sifive,test1" test finisher, David Gibson, 2019/11/10
- Re: [PATCH] RISC-V: virt: This is a "sifive,test1" test finisher, Palmer Dabbelt, 2019/11/21
- Re: [PATCH] RISC-V: virt: This is a "sifive,test1" test finisher, Alistair Francis, 2019/11/21
- Re: [PATCH] RISC-V: virt: This is a "sifive,test1" test finisher, Palmer Dabbelt, 2019/11/21
- Re: [PATCH] RISC-V: virt: This is a "sifive,test1" test finisher, David Gibson, 2019/11/10