From patchwork Fri May 24 18:44:44 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Eduardo Habkost X-Patchwork-Id: 1105109 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 459bHG75bHz9s00 for ; Sat, 25 May 2019 04:58:18 +1000 (AEST) Received: from localhost ([127.0.0.1]:58949 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUFOT-0000WX-1G for incoming@patchwork.ozlabs.org; Fri, 24 May 2019 14:58:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUFCT-0007Kd-3k for qemu-devel@nongnu.org; Fri, 24 May 2019 14:45:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hUFCR-0006eV-LJ for qemu-devel@nongnu.org; Fri, 24 May 2019 14:45:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56618) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hUFCR-0006dO-Ch for qemu-devel@nongnu.org; Fri, 24 May 2019 14:45:51 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A39163060485; Fri, 24 May 2019 18:45:50 +0000 (UTC) Received: from localhost (ovpn-116-14.gru2.redhat.com [10.97.116.14]) by smtp.corp.redhat.com (Postfix) with ESMTP id DD4597D911; Fri, 24 May 2019 18:45:47 +0000 (UTC) From: Eduardo Habkost To: Peter Maydell , qemu-devel@nongnu.org, Marcel Apfelbaum Date: Fri, 24 May 2019 15:44:44 -0300 Message-Id: <20190524184447.16678-15-ehabkost@redhat.com> In-Reply-To: <20190524184447.16678-1-ehabkost@redhat.com> References: <20190524184447.16678-1-ehabkost@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Fri, 24 May 2019 18:45:50 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 14/17] hw/microblaze/zynqmp: Use object_initialize_child for correct ref. counting X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" From: Philippe Mathieu-Daudé As explained in commit aff39be0ed97: Both functions, object_initialize() and object_property_add_child() increase the reference counter of the new object, so one of the references has to be dropped afterwards to get the reference counting right. Otherwise the child object will not be properly cleaned up when the parent gets destroyed. Thus let's use now object_initialize_child() instead to get the reference counting here right. This patch was generated using the following Coccinelle script (then manually modified to use numbered IPI name) @use_sysbus_init_child_obj_missing_parent@ expression child_ptr; expression child_type; expression child_size; @@ - object_initialize(child_ptr, child_size, child_type); ... - qdev_set_parent_bus(DEVICE(child_ptr), sysbus_get_default()); ... ?- object_unref(OBJECT(child_ptr)); + sysbus_init_child_obj(OBJECT(PARENT_OBJ), "CHILD_NAME", child_ptr, + child_size, child_type); We let the SoC adopt the IPI children. While the object_initialize() function doesn't take an 'Error *errp' argument, the object_initialize_child() does. Since this code is used when a machine is created (and is not yet running), we deliberately choose to use the &error_abort argument instead of ignoring errors if an object creation failed. This choice also matches when using sysbus_init_child_obj(), since its code is: void sysbus_init_child_obj(Object *parent, const char *childname, void *child, size_t childsize, const char *childtype) { object_initialize_child(parent, childname, child, childsize, childtype, &error_abort, NULL); qdev_set_parent_bus(DEVICE(child), sysbus_get_default()); } Suggested-by: Eduardo Habkost Inspired-by: Thomas Huth Signed-off-by: Philippe Mathieu-Daudé Message-Id: <20190507163416.24647-14-philmd@redhat.com> Reviewed-by: Paolo Bonzini Reviewed-by: Alistair Francis Signed-off-by: Eduardo Habkost --- hw/microblaze/xlnx-zynqmp-pmu.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/hw/microblaze/xlnx-zynqmp-pmu.c b/hw/microblaze/xlnx-zynqmp-pmu.c index 20e973edf5..0948b1fd5f 100644 --- a/hw/microblaze/xlnx-zynqmp-pmu.c +++ b/hw/microblaze/xlnx-zynqmp-pmu.c @@ -71,9 +71,10 @@ static void xlnx_zynqmp_pmu_soc_init(Object *obj) /* Create the IPI device */ for (int i = 0; i < XLNX_ZYNQMP_PMU_NUM_IPIS; i++) { - object_initialize(&s->ipi[i], sizeof(XlnxZynqMPIPI), - TYPE_XLNX_ZYNQMP_IPI); - qdev_set_parent_bus(DEVICE(&s->ipi[i]), sysbus_get_default()); + char *name = g_strdup_printf("ipi%d", i); + sysbus_init_child_obj(obj, name, &s->ipi[i], + sizeof(XlnxZynqMPIPI), TYPE_XLNX_ZYNQMP_IPI); + g_free(name); } }