On Mon, Sep 7, 2015 at 9:42 AM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 7 September 2015 at 17:40, Markus Armbruster <arm...@redhat.com> wrote: >> Peter Maydell <peter.mayd...@linaro.org> 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... >
+1. We have QOMified SDHCI already and I would assume that the SD QOMification will be made easier if the attached controllers are QOMified in their own right. Regards, Peter > thanks > -- PMM >