Re: [Qemu-devel] [PATCH] sdhci: Pass drive parameter to sdhci-pci via qdev property

[Stefan Hajnoczi <stefanha@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]

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 <kevin@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.

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]