On Tue, Jul 28, 2015 at 12:22:43PM -0400, Kevin O'Connor wrote: > Commit 19109131 disabled the sdhci-pci support because it used > drive_get_next(). This patch reenables sdhci-pci and changes it to > pass the drive via a qdev property - for example: > -device sdhci-pci,drive=drive0 -drive id=drive0,if=sd,file=myimage > > Signed-off-by: Kevin O'Connor <ke...@koconnor.net> > --- > > This patch only changes the SDHCI PCI code - the sysbus code continues > to use drive_get_next(). > > The call to blk_detach_dev() is suspicious - I added it because > sd.c:sd_init() calls blk_attach_dev_nofail() and that causes a crash > if the drive is already attached to the PCI device. It's not clear to > me how this should be wired up though.
Ugly bits: hw/core/qdev-properties-system.c:release_drive() will call blk_detach_dev(*ptr, dev) and assert(blk->dev == dev) will fail. The SD card (SDState) isn't a DeviceState, it's a plain old C struct. So it doesn't have the qdev machinery for its own drive property. There is no detach call paired with sd_init() attach, so that's ugly too. A solution: Add an sd_init() flag argument that skips the attach/set_dev_ops calls. Make sd_cardchange() externally visible and then call blk_set_dev_ops() from sdhci.c instead. That way, existing users can rely on the semi-broken but convenient sd_init() behavior. sdhci can forward the .change_media_cb() to sd_cardchange() keep itself as the blk->dev pointer.
pgpqzQShiZpqN.pgp
Description: PGP signature
