From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKNEe-0002q8-Hz for qemu-devel@nongnu.org; Wed, 29 Jul 2015 05:01:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKNEZ-0005Dt-Fz for qemu-devel@nongnu.org; Wed, 29 Jul 2015 05:01:12 -0400 Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]:38333) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKNEZ-0005Cq-1e for qemu-devel@nongnu.org; Wed, 29 Jul 2015 05:01:07 -0400 Received: by wibxm9 with SMTP id xm9so16373984wib.1 for ; Wed, 29 Jul 2015 02:01:06 -0700 (PDT) Date: Wed, 29 Jul 2015 10:01:03 +0100 From: Stefan Hajnoczi Message-ID: <20150729090103.GC10617@stefanha-thinkpad.redhat.com> References: <1438100563-14453-1-git-send-email-kevin@koconnor.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y5rl02BVI9TCfPar" Content-Disposition: inline In-Reply-To: <1438100563-14453-1-git-send-email-kevin@koconnor.net> Subject: Re: [Qemu-devel] [PATCH] sdhci: Pass drive parameter to sdhci-pci via qdev property List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: Paolo Bonzini , qemu-devel@nongnu.org, Markus Armbruster --Y5rl02BVI9TCfPar Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=3Ddrive0 -drive id=3Ddrive0,if=3Dsd,file=3Dmyima= ge >=20 > Signed-off-by: Kevin O'Connor > --- >=20 > This patch only changes the SDHCI PCI code - the sysbus code continues > to use drive_get_next(). >=20 > 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 =3D=3D 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() =66rom 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. --Y5rl02BVI9TCfPar Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVuJZPAAoJEJykq7OBq3PIkCQIALj1CORRHPWDwJ43H7rdBpk+ z7atvxgKaWOY2S0UvmOjFlKfS+qd4HVxRq73Mtnm/8//l8tNeTjbVcPVn/gKnt5i RL2o3uKjMf2dlgfoYJqQJQsWsqDey4HAY+l2640ktpCH+PR75+KZoi2POgybrg9V q5xIxpZX9/pxI8vMlDd/o7d7mHgrJJYCXOelICl22kRQJRfHHTl3H2Ys1Gi5kDJD LJQBRZndEVQsBa8OpDrcELiWROpezC6v7IxXTsaAzFjmaZxHEO2ULa2WRjVcLlBD sCUNihMKhZBlWS8iGOu6iyrrvSpGiVZ+J8D0YSgNMJ9cinmUfYhrAAwmlYSqacU= =nKii -----END PGP SIGNATURE----- --Y5rl02BVI9TCfPar--