qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/6] hw/char: QOM'ify pl011 model


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 1/6] hw/char: QOM'ify pl011 model
Date: Fri, 27 May 2016 10:01:29 +0100

On 27 May 2016 at 03:06, xiaoqiang zhao <address@hidden> wrote:
> 在 2016年05月25日 21:08, Peter Maydell 写道:
>>>
>>> -
>>> >      /* AUX / UART1 */
>>> >-    /* TODO: don't call qemu_char_get_next_serial() here, instead set
>>> >-     * chardev properties for each uart at the board level, once pl011
>>> >-     * (uart0) has been updated to avoid qemu_char_get_next_serial()
>>> >-     */
>>
>> This comment says this should be fixed by having board-level
>> properties; you've removed it but this patch isn't adding
>> the properties to this (SoC-level) device. I think the board
>> level should be looking at serial_hds[], not this code.
>>
> Hi, Peter:
>
> I found bcm2835-peripherals is only used by bcm2836 code, you mean
> this(bcm2836) is the 'board level' and I should set chardev properties here?

Device models subclass DeviceClass (possibly indirectly).
Boards subclass MachineClass. Only boards should be looking
at serial_hds[]. Sometimes you have a device which is just
a "container" which encapsulates several other devices
(typically this is a model of an SoC). For that kind of
container device, it should expose chardev properties for
its UARTs, which will usually be alias properties for
the properties on the actual UART devices which the
container has.

bcm2835-peripherals is a device, not a board, so it shouldn't
be using serial_hds[].

If it's clearer, you can use a separate patch to push the
serial_hds[] usage out another layer, rather than folding
it into this one.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]