From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50086) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9WTM-0000UH-Uq for qemu-devel@nongnu.org; Thu, 17 Dec 2015 06:11:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9WTL-0001I6-Vw for qemu-devel@nongnu.org; Thu, 17 Dec 2015 06:11:48 -0500 Received: from mail-vk0-x236.google.com ([2607:f8b0:400c:c05::236]:34745) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9WTL-0001I1-RZ for qemu-devel@nongnu.org; Thu, 17 Dec 2015 06:11:47 -0500 Received: by mail-vk0-x236.google.com with SMTP id j66so44230313vkg.1 for ; Thu, 17 Dec 2015 03:11:47 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <56728E36.7010807@redhat.com> References: <0209faa3788f57deeb3ce4a197019b095bc2c05f.1450300479.git.alistair.francis@xilinx.com> <5671F2A1.6060005@redhat.com> <56728E36.7010807@redhat.com> From: Peter Maydell Date: Thu, 17 Dec 2015 11:11:28 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v5 5/6] xlnx-zynqmp: Connect the SPI devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Crosthwaite , QEMU Developers , Alistair Francis On 17 December 2015 at 10:28, Paolo Bonzini wrote: > > > On 17/12/2015 09:26, Peter Maydell wrote: >>> > In any case, I would prefer qdev_bus_rename to stay in xlnx-zynqmp.c. >> I disagree that it should be in xlnx-zynqmp.c. Either >> (a) qdev already provides some reasonable mechanism for >> SoC container like this to allow their users to get at >> buses provided by their child objects, in which case we >> should use it >> (b) qdev doesn't provide such a mechanism, in which case >> we need to provide one (either qdev_bus_rename or something >> else if you have a better idea) >> >> But we definitely shouldn't have the SoC container code >> messing around with the internals of the qdev objects. > > It's a hack and I don't want it to become a sanctioned way to do it. > It's already messing around pretty heavily with qdev internals, see the > line right after QLIST_INSERT_HEAD: > > QLIST_INSERT_HEAD(&dev->child_bus, spi_bus, sibling); Well, that doesn't look good either. I think my point still stands -- we should be providing proper infrastructure at the qdev level to allow SoC container devices to do the things they need to do, not just letting the containers mess with the qdev internals. thanks -- PMM