qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/3] hw/sd/pxa2xx_mmci: convert to SysBusDevice


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 1/3] hw/sd/pxa2xx_mmci: convert to SysBusDevice object
Date: Thu, 3 Dec 2015 21:20:39 +0000

On 7 September 2015 at 17:57, Markus Armbruster <address@hidden> wrote:
> Peter Maydell <address@hidden> writes:
>
>> On 7 September 2015 at 17:40, Markus Armbruster <address@hidden> wrote:
>>> Peter Maydell <address@hidden> writes:
>>>
>>>> Convert the pxa2xx_mmci device to be a sysbus device.
>>
>>>> +static Property pxa2xx_mmci_properties[] = {
>>>> +    /* Note: pointer property 'drive' may remain NULL, thus no need
>>>> +     * for dc->cannot_instantiate_with_device_add_yet = true;
>>>> +     * Unfortunately this can't be a DEFINE_PROP_DRIVE, because
>>>> +     * setting a 'drive' property results in a call to blk_attach_dev()
>>>> +     * attaching the BlockBackend to this device; that then means that
>>>> +     * the call in sd_init() to blk_attach_dev_nofail() which tries to
>>>> +     * attach the BlockBackend to the SD card object aborts.
>>>> +     */
>>>> +    DEFINE_PROP_PTR("drive", PXA2xxMMCIState, blk),
>>>> +    DEFINE_PROP_END_OF_LIST(),
>>>> +};
>>>
>>> As far as I can tell, this problem is an artifact of our interface to
>>> the common sd-card code, namely sd_init().  sd_init() was made for the
>>> pre-qdev world: it creates and completely initializes the common
>>> SDState.
>>>
>>> In qdev, we do this in three separate steps: create, set properties,
>>> realize.  Split up sd_init(), and the problem should go away.
>>
>> Yes, but I don't really want to gate QOMification of mmc
>> controller devices on the more complicated problem of
>> QOMifying sd.c itself, especially since we already have several
>> QOMified mmc controllers...
>
> Is serial.c QOMified?  I don't think so, it's merely structured in a
> QOM-friendly way: typedef SerialState, realize helper
> serial_realize_core(), unrealize helper serial_exit_core().  If
> SerialState had more properties, we'd also need a macro to define them.

It looks like since we had this conversation the problem has been
dealt with in commit 5ec911c30ff433 by simply turning the sd_init() call
to blk_attach_dev_nofail() into a call to blk_attach_dev() which ignores
its error return. So I should be able to do this with a DEFINE_PROP_DRIVE
now I think...

thanks
-- PMM



reply via email to

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