From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHYNe-0005US-83 for qemu-devel@nongnu.org; Fri, 08 Jan 2016 09:51:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHYNd-0004Pd-9R for qemu-devel@nongnu.org; Fri, 08 Jan 2016 09:51:06 -0500 MIME-Version: 1.0 In-Reply-To: References: <1449851831-4966-1-git-send-email-peter.maydell@linaro.org> <1449851831-4966-5-git-send-email-peter.maydell@linaro.org> <20151219213830.GE4164@pcrost-box> Date: Fri, 8 Jan 2016 06:51:03 -0800 Message-ID: From: Peter Crosthwaite Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 04/10] hw/sd: Add QOM bus which SD cards plug in to List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Max Reitz Cc: Kevin O'Connor , Qemu-block , Peter Crosthwaite , Markus Armbruster , Patch Tracking , QEMU Developers , Alistair Francis , qemu-arm , Paolo Bonzini , "Edgar E. Iglesias" On Thu, Jan 7, 2016 at 10:09 AM, Peter Maydell wrote: > On 20 December 2015 at 20:51, Peter Crosthwaite > wrote: >> On Sun, Dec 20, 2015 at 9:10 AM, Peter Maydell wrote: >>> For user-level back compat I think we need to retain "might have >>> an sdcard object with no block backend, and that means >>> 'no-card-present'". This is both for the user facing >>> monitor commands to manipulate the sd card, and also >> >> What are the user-facing monitor commands? I tried using "change" and >> "eject", but they don't seem to work for SD, due to the tray being >> closed. Has this ever worked in a way that is user manipulatable for >> SD or is it just to handle the case of unconditional SD card creation >> (with the card never hotplugging over the system lifetime)? > > I investigated this, and it looks like we accidentally broke > 'change' for SD cards in 2.5 (specifically in commit de2c6c05). > I think we should fix that regression, which in turn implies that > we still want to support the "sd card object with no block backend" case. > Yes, saw the patches on list. I guess we are stuck with it. It would be good to do this in a way that supports use of the hotplug API alongside though, so SDIO device could all be ejected and inserted with the same way. Regards, Peter > thanks > -- PMM