On Fri, 18 Oct 2019 at 16:42, Marc-André Lureau
<marcandre.lur...@redhat.com> wrote:
>
> etraxfs_dma_client are not Object, so can't be exposed to user with
> QOM path. Let's remove property usage and move the constructor to the
> .c unit, simplifying some code on the way.
>
> Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com>
> +/* Instantiate an ETRAXFS Ethernet MAC. */
> +DeviceState *
> +etraxfs_eth_init(NICInfo *nd, hwaddr base, int phyaddr,
> + struct etraxfs_dma_client *dma_out,
> + struct etraxfs_dma_client *dma_in)
> +{
> + DeviceState *dev;
> + qemu_check_nic_model(nd, "fseth");
> +
> + dev = qdev_create(NULL, "etraxfs-eth");
> + qdev_set_nic_properties(dev, nd);
> + qdev_prop_set_uint32(dev, "phyaddr", phyaddr);
> + ETRAX_FS_ETH(dev)->dma_out = dma_out;
> + ETRAX_FS_ETH(dev)->dma_in = dma_in;
> + qdev_init_nofail(dev);
> + sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, base);
> +
> + return dev;
> +}
I think the right way to do this in a QOM design would be
to define a QOM interface for "I am an etraxfs DMA client"
(which replaces the current 'struct etraxfs_dma_client'
ad-hoc interface), implement it on the ethernet device,
and then have QOM link properties on the DMA controller
device so that you can pass the interface implementations
to it.
If that seems like too much hassle right now, I guess we
can add a TODO comment here explaining what we ought to
be doing instead.
thanks
-- PMM
