[v4,33/47] hw/m68k/q800: use qemu_find_nic_info()

From: David Woodhouse <dwmw@amazon.co.uk>

If a corresponding NIC configuration was found, it will have a MAC address
already assigned, so use that. Else, generate and assign a default one.

Using qemu_find_nic_info() is simpler than the alternative of using
qemu_configure_nic_device() and then having to fetch the "mac" property
as a string and convert it.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 hw/m68k/q800.c | 29 ++++++++++++++++-------------
 1 file changed, 16 insertions(+), 13 deletions(-)

On 26/01/2024 18.25, David Woodhouse wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> If a corresponding NIC configuration was found, it will have a MAC address
> already assigned, so use that. Else, generate and assign a default one.
> 
> Using qemu_find_nic_info() is simpler than the alternative of using
> qemu_configure_nic_device() and then having to fetch the "mac" property
> as a string and convert it.
> 
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
>   hw/m68k/q800.c | 29 ++++++++++++++++-------------
>   1 file changed, 16 insertions(+), 13 deletions(-)
> 
> diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c
> index b80a3b6d5f..fa7683bf76 100644
> --- a/hw/m68k/q800.c
> +++ b/hw/m68k/q800.c
> @@ -48,6 +48,7 @@
>   #include "hw/display/macfb.h"
>   #include "hw/block/swim.h"
>   #include "net/net.h"
> +#include "net/util.h"
>   #include "qapi/error.h"
>   #include "qemu/error-report.h"
>   #include "sysemu/qtest.h"
> @@ -270,6 +271,8 @@ static void q800_machine_init(MachineState *machine)
>       BusState *adb_bus;
>       NubusBus *nubus;
>       DriveInfo *dinfo;
> +    NICInfo *nd;
> +    MACAddr mac;
>       uint8_t rng_seed[32];
>   
>       linux_boot = (kernel_filename != NULL);
> @@ -370,13 +373,6 @@ static void q800_machine_init(MachineState *machine)
>   
>       /* MACSONIC */
>   
> -    if (nb_nics > 1) {
> -        error_report("q800 can only have one ethernet interface");
> -        exit(1);
> -    }
> -
> -    qemu_check_nic_model(&nd_table[0], "dp83932");
> -
>       /*
>        * MacSonic driver needs an Apple MAC address
>        * Valid prefix are:
> @@ -386,14 +382,21 @@ static void q800_machine_init(MachineState *machine)
>        * 08:00:07 Apple
>        * (Q800 use the last one)
>        */
> -    nd_table[0].macaddr.a[0] = 0x08;
> -    nd_table[0].macaddr.a[1] = 0x00;
> -    nd_table[0].macaddr.a[2] = 0x07;
> -
>       object_initialize_child(OBJECT(machine), "dp8393x", &m->dp8393x,
>                               TYPE_DP8393X);
>       dev = DEVICE(&m->dp8393x);
> -    qdev_set_nic_properties(dev, &nd_table[0]);
> +    nd = qemu_find_nic_info(TYPE_DP8393X, true, "dp83932");
> +    if (nd) {
> +        qdev_set_nic_properties(dev, nd);
> +        memcpy(mac.a, nd->macaddr.a, sizeof(mac.a));
> +    } else {
> +        qemu_macaddr_default_if_unset(&mac);
> +    }
> +    mac.a[0] = 0x08;
> +    mac.a[1] = 0x00;
> +    mac.a[2] = 0x07;

Don't we have to change nd->macaddr.a[0 to 2] with this hard-coded 
MAC-prefix, too?

  Thomas

> +    qdev_prop_set_macaddr(dev, "mac", mac.a);
> +
>       qdev_prop_set_uint8(dev, "it_shift", 2);
>       qdev_prop_set_bit(dev, "big_endian", true);
>       object_property_set_link(OBJECT(dev), "dma_mr",
> @@ -414,7 +417,7 @@ static void q800_machine_init(MachineState *machine)
>       prom = memory_region_get_ram_ptr(&m->dp8393x_prom);
>       checksum = 0;
>       for (i = 0; i < 6; i++) {
> -        prom[i] = revbit8(nd_table[0].macaddr.a[i]);
> +        prom[i] = revbit8(mac.a[i]);
>           checksum ^= prom[i];
>       }
>       prom[7] = 0xff - checksum;

On Wed, 2024-01-31 at 13:18 +0100, Thomas Huth wrote:
> 
> > @@ -386,14 +382,21 @@ static void q800_machine_init(MachineState
> > *machine)
> >         * 08:00:07 Apple
> >         * (Q800 use the last one)
> >         */
> > -    nd_table[0].macaddr.a[0] = 0x08;
> > -    nd_table[0].macaddr.a[1] = 0x00;
> > -    nd_table[0].macaddr.a[2] = 0x07;
> > -
> >        object_initialize_child(OBJECT(machine), "dp8393x", &m-
> > >dp8393x,
> >                                TYPE_DP8393X);
> >        dev = DEVICE(&m->dp8393x);
> > -    qdev_set_nic_properties(dev, &nd_table[0]);
> > +    nd = qemu_find_nic_info(TYPE_DP8393X, true, "dp83932");
> > +    if (nd) {
> > +        qdev_set_nic_properties(dev, nd);
> > +        memcpy(mac.a, nd->macaddr.a, sizeof(mac.a));
> > +    } else {
> > +        qemu_macaddr_default_if_unset(&mac);
> > +    }
> > +    mac.a[0] = 0x08;
> > +    mac.a[1] = 0x00;
> > +    mac.a[2] = 0x07;
> 
> Don't we have to change nd->macaddr.a[0 to 2] with this hard-coded 
> MAC-prefix, too?

I don't think so.

We either get the MAC address from 'nd' if that exists, or generate a
new MAC address with qemu_macaddr_default_if_unset().

Then we override the OUI in the actual device. We don't care about 'nd'
any more at that point.

On 31/01/2024 15.18, David Woodhouse wrote:
> On Wed, 2024-01-31 at 13:18 +0100, Thomas Huth wrote:
>>
>>> @@ -386,14 +382,21 @@ static void q800_machine_init(MachineState
>>> *machine)
>>>          * 08:00:07 Apple
>>>          * (Q800 use the last one)
>>>          */
>>> -    nd_table[0].macaddr.a[0] = 0x08;
>>> -    nd_table[0].macaddr.a[1] = 0x00;
>>> -    nd_table[0].macaddr.a[2] = 0x07;
>>> -
>>>         object_initialize_child(OBJECT(machine), "dp8393x", &m-
>>>> dp8393x,
>>>                                 TYPE_DP8393X);
>>>         dev = DEVICE(&m->dp8393x);
>>> -    qdev_set_nic_properties(dev, &nd_table[0]);
>>> +    nd = qemu_find_nic_info(TYPE_DP8393X, true, "dp83932");
>>> +    if (nd) {
>>> +        qdev_set_nic_properties(dev, nd);
>>> +        memcpy(mac.a, nd->macaddr.a, sizeof(mac.a));
>>> +    } else {
>>> +        qemu_macaddr_default_if_unset(&mac);
>>> +    }
>>> +    mac.a[0] = 0x08;
>>> +    mac.a[1] = 0x00;
>>> +    mac.a[2] = 0x07;
>>
>> Don't we have to change nd->macaddr.a[0 to 2] with this hard-coded
>> MAC-prefix, too?
> 
> I don't think so.
> 
> We either get the MAC address from 'nd' if that exists, or generate a
> new MAC address with qemu_macaddr_default_if_unset().
> 
> Then we override the OUI in the actual device. We don't care about 'nd'
> any more at that point.

I just double-checked, and yes, you're right, so:

Reviewed-by: Thomas Huth <thuth@redhat.com>

On Thu, 2024-02-01 at 11:30 +0100, Thomas Huth wrote:
> On 31/01/2024 15.18, David Woodhouse wrote:
> > On Wed, 2024-01-31 at 13:18 +0100, Thomas Huth wrote:
> > > Don't we have to change nd->macaddr.a[0 to 2] with this hard-coded
> > > MAC-prefix, too?
> > 
> > I don't think so.
> > 
> > We either get the MAC address from 'nd' if that exists, or generate a
> > new MAC address with qemu_macaddr_default_if_unset().
> > 
> > Then we override the OUI in the actual device. We don't care about 'nd'
> > any more at that point.
> 
> I just double-checked, and yes, you're right, so:
> 
> Reviewed-by: Thomas Huth <thuth@redhat.com>

Thank you, just just about completes my set. Every patch now has a
Reviewed-by: except two of them (hw/s390x/s390-virtio-ccw and
hw/arm/aspeed) which only have an Acked-by: 

I think according to The Rules I just need a maintainer to *tell* me to
send a pull request and then I'm allowed to do so?

On Thu, 1 Feb 2024 at 16:07, David Woodhouse <dwmw2@infradead.org> wrote:
>
> On Thu, 2024-02-01 at 11:30 +0100, Thomas Huth wrote:
> > On 31/01/2024 15.18, David Woodhouse wrote:
> > > On Wed, 2024-01-31 at 13:18 +0100, Thomas Huth wrote:
> > > > Don't we have to change nd->macaddr.a[0 to 2] with this hard-coded
> > > > MAC-prefix, too?
> > >
> > > I don't think so.
> > >
> > > We either get the MAC address from 'nd' if that exists, or generate a
> > > new MAC address with qemu_macaddr_default_if_unset().
> > >
> > > Then we override the OUI in the actual device. We don't care about 'nd'
> > > any more at that point.
> >
> > I just double-checked, and yes, you're right, so:
> >
> > Reviewed-by: Thomas Huth <thuth@redhat.com>
>
> Thank you, just just about completes my set. Every patch now has a
> Reviewed-by: except two of them (hw/s390x/s390-virtio-ccw and
> hw/arm/aspeed) which only have an Acked-by:
>
> I think according to The Rules I just need a maintainer to *tell* me to
> send a pull request and then I'm allowed to do so?

Yeah, go ahead and send a pullreq for this.

(I have a new board model brewing so it would be handy for me
to have the new functions upstream so I can create the ethernet
device in the right way :-))

thanks
-- PMM