qemu-discuss
[Top][All Lists]
Advanced

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

RE: When is SysBusDevice's num_mmios determined? and does SYS_BUS_DEVICE


From: ckim
Subject: RE: When is SysBusDevice's num_mmios determined? and does SYS_BUS_DEVICE macro allocate memory?
Date: Sun, 6 Jun 2021 11:20:08 +0900

Thanks! Now clearly understood.
Chan Kim

> -----Original Message-----
> From: Peter Maydell <peter.maydell@linaro.org>
> Sent: Sunday, June 6, 2021 4:58 AM
> To: Chan Kim <ckim@etri.re.kr>
> Cc: qemu-discuss <qemu-discuss@nongnu.org>
> Subject: Re: When is SysBusDevice's num_mmios determined? and does
> SYS_BUS_DEVICE macro allocate memory?
> 
> On Sat, 5 Jun 2021 at 16:09, <ckim@etri.re.kr> wrote:
> > I have a questions for my clarification.
> > In function sysbut_init_mmio, I see these two lines,
> >      assert(dev->num_mmio < QDEV_MAX_MMIO);
> >      n = dev->num_mmio++;
> > I gathered this QDEV_MAX_MMIO means (currently defined to 32): maximum
> number of instances a same device can be attached to the system bus. Is my
> understanding correct?
> 
> No. It means no device can have more than 32 different MMIO regions (ie
> its init or realize function mustn't call sysbus_init_mmio() more than
> that many times). Most devices have just one MMIO region ("my bank of
> registers"). A handful provide two or three, for example because they have
> several sets of registers that live at separated places in the system
> address space (eg a PCI controller might have one for its config registers,
> one for the PCI memory window and one for the PCI IO window).
> 
> There's no fixed limit on how many instances of any device you can create.
> 
> > And I have an opinion about the comment in code for OBJECT_CHECK :
> > By the way, when I see the comment on OBJECT_CHECK, it says
> > /**
> >  * OBJECT_CHECK:
> >  * @type: The C type to use for the return value.
> >  * @obj: A derivative of @type to cast.
> >  * @name: The QOM typename of @type
> >  *
> >   (...)
> > #define OBJECT_CHECK(type, obj, name) \
> >     ((type *)object_dynamic_cast_assert(OBJECT(obj), (name), \
> >                                         __FILE__, __LINE__, __func__))
> 
> > static void smc91c111_reset(DeviceState *dev) {
> >     smc91c111_state *s = SMC91C111(dev);
> >
> > Here in macro OBJECT_CHECK is used to cast DeviceState to its derivative
> smc91c111_state.
> > So in the comment above, shouldn't "@obj: A derivative of @type to cast".
> be modified to "@obj: A derivative or a base of @type to case"?
> > I understand this casting is possible from base to derivative, or from
> derivative to base.
> 
> It is, but I think what the comment is trying to say is that the
> underlying object must actually be of either type SMC91C111 or some type
> derived from SMC91C111, even if at the moment the pointer that you have to
> it is an Object* or a DeviceState*.
> If you pass it a DeviceState* which is really some other device like a
> PL011, then the attempt to cast to SMC91C111 will not work (it will
> assert).
> 
> -- PMM







reply via email to

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