From: Peter Delevoryas <pdel@fb.com>

This is a follow-up to a discussion in a previous series I sent:

https://lore.kernel.org/qemu-devel/20210827210417.4022054-1-pdel@fb.com/

I tried to add a new machine type called Fuji that required the ability
to specify the UART connected to the first serial device on the command
line (serial_hd(0)).

After some discussion, we concluded that we could add a serial_dev
option to the machine class and the SoC to support this:

https://lore.kernel.org/qemu-devel/a802ecb1-aa49-fd4c-5bd2-2bb19af56ac9@kaod.org/

I didn't follow Cedric's advice _exactly_, so let me know if you have
suggestions. I used "uint32_t serial_hd0", because I think it more
clearly indicates that this is the device to connect to the first serial
device, serial_hd(0).

Also, I didn't know how to transfer data from the machine class to the
device state, so I just added the attribute to the machine class and
used 'qdev_get_machine' to within aspeed_soc_realize() based on some
code I found in hw/ppc/spapr_cpu_core.c. I expect that I'm missing
something, I've just been having some trouble figuring out the QEMU
object model.

If this patch is accepted, I can follow-up with another patch adding the
fuji machine type with "serial_hd0 = ASPEED_DEV_UART1".

Thanks,
Peter

Peter Delevoryas (1):
  hw/arm/aspeed: Allow machine to set serial_hd(0)

 hw/arm/aspeed.c         |  1 +
 hw/arm/aspeed_ast2600.c | 11 +++++++----
 hw/arm/aspeed_soc.c     |  9 ++++++---
 include/hw/arm/aspeed.h |  1 +
 4 files changed, 15 insertions(+), 7 deletions(-)

-- 
2.30.2

On 9/1/21 1:31 AM, pdel@fb.com wrote:
> From: Peter Delevoryas <pdel@fb.com>
> 
> This is a follow-up to a discussion in a previous series I sent:
> 
> https://lore.kernel.org/qemu-devel/20210827210417.4022054-1-pdel@fb.com/
> 
> I tried to add a new machine type called Fuji that required the ability
> to specify the UART connected to the first serial device on the command
> line (serial_hd(0)).
> 
> After some discussion, we concluded that we could add a serial_dev
> option to the machine class and the SoC to support this:
> 
> https://lore.kernel.org/qemu-devel/a802ecb1-aa49-fd4c-5bd2-2bb19af56ac9@kaod.org/
> 
> I didn't follow Cedric's advice _exactly_, so let me know if you have
> suggestions. I used "uint32_t serial_hd0", because I think it more
> clearly indicates that this is the device to connect to the first serial
> device, serial_hd(0).

I don't have a strong opinion on the name but it is part of the user
API and can be set from the command line  : 

  -global driver=ast2600-a3,property=serial-hd0,value=5

I would prefer something like "uart-default" which makes more sense.

> Also, I didn't know how to transfer data from the machine class to the
> device state, so I just added the attribute to the machine class and
> used 'qdev_get_machine' to within aspeed_soc_realize() based on some
> code I found in hw/ppc/spapr_cpu_core.c. 

This is called from the reset execution path which is a bit special.
The use of qdev_get_machine() should be avoided when possible. 

> I expect that I'm missing
> something, I've just been having some trouble figuring out the QEMU
> object model.

Look at the "dram" property of the SoC.

Thanks,

C. 

> If this patch is accepted, I can follow-up with another patch adding the
> fuji machine type with "serial_hd0 = ASPEED_DEV_UART1".
> 
> Thanks,
> Peter
> 
> Peter Delevoryas (1):
>   hw/arm/aspeed: Allow machine to set serial_hd(0)
> 
>  hw/arm/aspeed.c         |  1 +
>  hw/arm/aspeed_ast2600.c | 11 +++++++----
>  hw/arm/aspeed_soc.c     |  9 ++++++---
>  include/hw/arm/aspeed.h |  1 +
>  4 files changed, 15 insertions(+), 7 deletions(-)
>