On 27 May 2016 at 03:06, xiaoqiang zhao <zxq_yx_...@163.com> 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
