Re: [PATCH] RISC-V: virt: This is a "sifive,test1" test finisher

[Peter Maydell]

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