On Fri, 1 Feb 2019 06:26:58 +0000 Will Deacon <will.deacon@xxxxxxx> wrote: Hi, > On Thu, Jan 31, 2019 at 02:57:11PM +0000, Andre Przywara wrote: > > On Wed, 30 Jan 2019 18:20:19 +0000 > > Will Deacon <will.deacon@xxxxxxx> wrote: > > > On Fri, Jan 25, 2019 at 06:07:57PM +0000, Andre Przywara wrote: > > > > The DT spec describes the stdout-path property in the /chosen > > > > node to contain the DT path for a default device usable for > > > > outputting characters. The Linux kernel uses this for earlycon > > > > (without further parameters), other DT users might rely on this > > > > as well. > > > > > > > > Add a property containing the path to our emulated 8250 serial > > > > device. > > > > > > > > Even when we use the virtio console, the serial console is still > > > > there and works, so we can expose this unconditionally. Putting > > > > the virtio console path in there will not work anyway. > > > > > > > > Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx> > > > > --- > > > > arm/fdt.c | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/arm/fdt.c b/arm/fdt.c > > > > index 28ba1c2c..8cda3ded 100644 > > > > --- a/arm/fdt.c > > > > +++ b/arm/fdt.c > > > > @@ -143,6 +143,7 @@ static int setup_fdt(struct kvm *kvm) > > > > _FDT(fdt_property_cell(fdt, "linux,pci-probe-only", > > > > 1)); _FDT(fdt_property_string(fdt, "bootargs", > > > > kvm->cfg.real_cmdline)); _FDT(fdt_property_u64(fdt, > > > > "kaslr-seed", kvm->cfg.arch.kaslr_seed)); > > > > + _FDT(fdt_property_string(fdt, "stdout-path", > > > > "/U6_16550A@3f8")); > > > > > > Since the last string here has to match the one in hw/serial.c, I > > > think we should be retrieving it from there rather than > > > hardcoding it here. > > > > Are you thinking about something like setting a "char > > *primary_console_path" in > > hw/serial.c:serial8250_generate_fdt_node(), then using this here in > > arm/fdt.c? Or shall the generate function directly set the > > stdout-path? > > It's probably a bit dodgy doing it from the generate function, > because I think we'd then be relying on the the /chosen node being > created before the serial node (which is true, but I wouldn't like to > rely on it). Agreed. > So I think either have a way to register the primary console device, > or a way to squirrel the string away somewhere. Is there a variant of > stdout-path which uses a phandle instead of a string? That might end > up being cleaner to implement. stdout-path must be a string, so a phandle will not work. However that string can be an alias, so I now let stdout-path always be "serial0", then add an aliases node at the end of the FDT generation, assigning serial0 to the path of the first instantiated serial device. I will post a v2 with that. Cheers, Andre.
