From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BD3D0C433F5 for ; Wed, 2 Mar 2022 10:27:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235243AbiCBK2P (ORCPT ); Wed, 2 Mar 2022 05:28:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235643AbiCBK2O (ORCPT ); Wed, 2 Mar 2022 05:28:14 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id F2C91FD1A; Wed, 2 Mar 2022 02:27:31 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BC850139F; Wed, 2 Mar 2022 02:27:31 -0800 (PST) Received: from [10.57.21.40] (unknown [10.57.21.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B488C3F70D; Wed, 2 Mar 2022 02:27:29 -0800 (PST) Message-ID: <5529d0f7-e81f-4def-0d34-eb3f1801cc45@arm.com> Date: Wed, 2 Mar 2022 10:27:28 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH] coresight: core: Fix coresight device probe failure issue To: Mao Jinlong , Mathieu Poirier , Mike Leach , Leo Yan , Alexander Shishkin Cc: coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, Tingwei Zhang , Yuanfang Zhang , Tao Zhang , Hao Zhang References: <20220302080132.20946-1-quic_jinlmao@quicinc.com> From: Suzuki K Poulose In-Reply-To: <20220302080132.20946-1-quic_jinlmao@quicinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On 02/03/2022 08:01, Mao Jinlong wrote: > It is possibe that probe failure issue happens when the device > and its child_device's probe happens at the same time. > In coresight_make_links, has_conns_grp is true for parent, but > has_conns_grp is false for child device as has_conns_grp is set > to true in coresight_create_conns_sysfs_group. The probe of parent > device will fail at this condition. Add has_conns_grp check for > child device before make the links and make the process from > device_register to connection_create be atomic to avoid this > probe failure issue. > > Suggested-by: Suzuki K Poulose > Suggested-by: Mike Leach > Signed-off-by: Mao Jinlong > --- > drivers/hwtracing/coresight/coresight-core.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c > index 88653d1c06a4..7ce78dddfe31 100644 > --- a/drivers/hwtracing/coresight/coresight-core.c > +++ b/drivers/hwtracing/coresight/coresight-core.c > @@ -1382,7 +1382,7 @@ static int coresight_fixup_device_conns(struct coresight_device *csdev) > continue; > conn->child_dev = > coresight_find_csdev_by_fwnode(conn->child_fwnode); > - if (conn->child_dev) { > + if (conn->child_dev && conn->child_dev->has_conns_grp) { > ret = coresight_make_links(csdev, conn, > conn->child_dev); > if (ret) > @@ -1619,6 +1619,7 @@ struct coresight_device *coresight_register(struct coresight_desc *desc) > csdev->dev.fwnode = fwnode_handle_get(dev_fwnode(desc->dev)); > dev_set_name(&csdev->dev, "%s", desc->name); > > + mutex_lock(&coresight_mutex); > ret = device_register(&csdev->dev); > if (ret) { > put_device(&csdev->dev); > @@ -1645,8 +1646,6 @@ struct coresight_device *coresight_register(struct coresight_desc *desc) > } > } > > - mutex_lock(&coresight_mutex); > - > ret = coresight_create_conns_sysfs_group(csdev); > if (!ret) > ret = coresight_fixup_device_conns(csdev); > @@ -1666,6 +1665,7 @@ struct coresight_device *coresight_register(struct coresight_desc *desc) > err_free_csdev: > kfree(csdev); > err_out: > + mutex_unlock(&coresight_mutex); This appears to be wrong. We may do an unlock when we didn't lock it in the first place. Please could you double check. Also, I think it may be neater to move the kfree(csdev) to the only user and return straight away from there. Cheers Suzuki > /* Cleanup the connection information */ > coresight_release_platform_data(NULL, desc->pdata); > return ERR_PTR(ret);