Re: [PATCH v2] riscv/virt: Add optional UART1

On 14/7/26 10:52, Peter Maydell wrote:
> On Sun, 5 Jul 2026 at 23:05, Philippe Mathieu-Daudé
> <[email protected]> wrote:
>>
>> On 4/7/26 03:41, Yanfeng Liu wrote:
>>>
>>> Philippe,
>>>
>>> The v1 always creates UART1 carelessly, then Peter suggested following
>>> 5d8a250f9068 (openrisc) and e7100972f2 (arm) to reduce guest breakage.
>>
>> Oh I missed that. I'm confused because I thought not checking for
>> backend use of a chardev (in particular calling serial_hd) was part
>> of Peter's recommendations, since he did that cleanup years ago.
> 
> Where we're modelling a real piece of hardware that always has,
> say, two UARTs, we want to always create both UARTs (because they're
> always there in the real hardware, whether there's a serial cable
> plugged into them or not). Having the chardev code handle "backend
> is NULL" as equivalent to "this is the do-nothing backend" lets us
> avoid unnecessary conditionals in the board code.
> 
> For "virtual" board types where it's QEMU defining what they are,
> the situation is a little different. Ideally we'd do the simple
> thing, i.e. "just create all the devices", but where there's
> existing guest software that makes assumptions about how older
> versions of QEMU used to behave and the number of users of the
> board type is big enough that we care about not breaking that,
> we sometimes need to do something else. The "only create the
> second UART if the user puts another -serial option on the
> command line" was the best idea I could come up with for letting
> the user opt into the extra functionality if they needed it.
> 
> (If we have another future architecture that creates a "virt"
> board type we should make sure we have it create at least two
> UARTs right from the beginning, because we've now made this
> mistake twice :-))

Thanks for the clarification, I missed this is a built up
virt board where QEMU itself announces the hw available,
not some real world model.

Regards,

Phil.