qemu-trivial
[Top][All Lists]
Advanced

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

Re: [PATCH 5/5] m48t59: remove legacy m48t59_init() function


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH 5/5] m48t59: remove legacy m48t59_init() function
Date: Sat, 17 Oct 2020 15:57:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1

On 10/17/20 1:19 PM, Mark Cave-Ayland wrote:
On 17/10/2020 10:53, Philippe Mathieu-Daudé wrote:

On 10/16/20 8:27 PM, Mark Cave-Ayland wrote:
Now that all of the callers of this function have been switched to use qdev
properties, this legacy init function can now be removed.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
---
  hw/rtc/m48t59.c         | 35 -----------------------------------
  include/hw/rtc/m48t59.h |  4 ----
  2 files changed, 39 deletions(-)
...

static void m48t59_class_init(ObjectClass *oc, void *data)
{
     M48txxISADeviceClass *midc = M48TXX_ISA_CLASS(oc);

     midc->model = 59;
     midc->size = 8 * KiB;
};

static const TypeInfo m48t59_isa_register_types[] = {
     {
         .name           = TYPE_M48T59_SRAM,
         .parent         = TYPE_M48TXX_ISA,
         .class_init     = m48t59_class_init,
     }, {
         .name           = TYPE_M48TXX_ISA,
         .parent         = TYPE_ISA_DEVICE,
         .instance_size  = sizeof(M48txxISAState),
         .class_size     = sizeof(M48txxISADeviceClass),
         .class_init     = m48txx_isa_class_init,
         .abstract       = true,
         .interfaces = (InterfaceInfo[]) {
             { TYPE_NVRAM },
             { }
         }
     }
};

I guess I didn't pursue because I wondered what was the
best way to have the same model usable by sysbus/isa.

IIRC I wanted to proceed as having TYPE_M48T59_SRAM being
an abstract qdev parent, and then TYPE_M48TXX_SYSBUS /
TYPE_M48TXX_ISA implementing the SYSBUS/ISA interfaces.

As it need some thinking I postponed that for after 5.2.

Anyhow back to this patch:

Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>

Ha indeed, I think you also came to the same conclusion that I did in my previous email :)

I'm also not convinced by the dynamic generation of various M48TXX types using class_data - this seems overly complex, and there's nothing there I can see that can't be just as easily handled using qdev properties using an abstract parent as you suggest above.

Yeah, no advantage except having uniform code style that serves
as example.



ATB,

Mark.




reply via email to

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