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 X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48531C433E1 for ; Tue, 18 Aug 2020 17:40:43 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 182B32054F for ; Tue, 18 Aug 2020 17:40:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="OwysvEhA"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="F2EfZQK+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 182B32054F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=xuQWjGaxbWctjCu5EPmdmNuzb0yX/bij1jaiGI5tQnQ=; b=OwysvEhAkuZygV7hufHwubsYW TJ6O+JXrbWEeP2NnNbnCzsgBeLt+7P/R1/rajnbzlT4CG45CSfgf4Hsi9DCzvqxHXZaHt7QfLKolt qQxIvqTLebvVzTh+8rbT05pvARwZKdjWSMMTJGiN7LbAYFTj1UCKELD4vlAz0ay7BsWKu0UEALnmr crplqT3Fw8H0zB7+6tXZfRYMcmcbWwNTvALe4SCkdFXzwJrXXaiQhB8GmQ64kV7Nfjd3wMbACYPWI CfzZX6DBdmiQBa1dAEK45YWOpf4c3lQIMIReUM/QRuCGq9RoSXNcMNTKrxnf9blMldmnGiPLP2i0S r2QrKH91w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k85Zv-0001XN-1n; Tue, 18 Aug 2020 17:39:19 +0000 Received: from mail-pf1-x444.google.com ([2607:f8b0:4864:20::444]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k85Zr-0001WK-U7 for linux-arm-kernel@lists.infradead.org; Tue, 18 Aug 2020 17:39:17 +0000 Received: by mail-pf1-x444.google.com with SMTP id r11so10304533pfl.11 for ; Tue, 18 Aug 2020 10:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Nl2zHIST8ueEPQbCKPiQ0hw74U6tDw0+XQH8llOYaMI=; b=F2EfZQK+1asLdnQEutBmo7DbVuUWVQataKIC8u6tKWP4xabbGfX2Wiyw9NSSZU3jJy oRekIAnPq/imp68gX4HakfNdX07sFLaMHTU/dN58A6E8TKWzxl/q9xXBNqMKn+RfI6Ie +VedK956Cj5SEVnYp5nwfRh7bWVWpqAedkIBsBe/PT85IQNvEGBk28+oCOnTmp6Yx14v kbb5ybSOnlicJWbBEydSdwT3FrCIS1qvZXE7uRyn5IfXwq9vReVj2BdeTtLVrwbGNXih xIbDOMZgWgO/F94jXMKo8ehqQgIoAP02giqVrrCX/Ms78jDDzTCSBE4k4dwJJfBrgNdA gWQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Nl2zHIST8ueEPQbCKPiQ0hw74U6tDw0+XQH8llOYaMI=; b=AaXVXc7Tfl44sHXQa4WEgbRqgGBWTlM6+06gJd1h66MVuH3GoFP5rUveCIFeF3Z4wQ UpH2BVJDwtrFdtZ9BZIRXiRdWnnQ4E7LodDonrP7hfjhJ+rtqTTZPxRUG2PovkuIFJz/ Kiz9wwWA0aTwXqUsg50Iwx+ZLr/wT5iRadlwB+3tL3r8FFKeL6M+Fp5WiLXdIB3vw2FC i7/BXqabsndXhWpVa1TEOR20t20eZuq6LD31Ak6vw03jhxoLgTU+s5EtKGvJGXZLrGGT zdqfTbS44sKwN+XKWoYbSL0aFNAhsfme7DydxbSwa8gYmYu8MUFhlrUgqA04tArF393/ 4jxA== X-Gm-Message-State: AOAM530aIwPt5doeLHHk+HbpnNeVETmvKHPJjJdXHU8dz8fs9aAbsYfx Bk2nliUHdBBo2ANy7glztjde1g== X-Google-Smtp-Source: ABdhPJwIYiIHx4ofE/SsXpfRoBzp5virT+A2FS+yTXJsQT+NSXZoWSFLimmB3nqMkpAp2fDJ9neXQg== X-Received: by 2002:a63:151c:: with SMTP id v28mr13759517pgl.357.1597772352572; Tue, 18 Aug 2020 10:39:12 -0700 (PDT) Received: from xps15 (S0106002369de4dac.cg.shawcable.net. [68.147.8.254]) by smtp.gmail.com with ESMTPSA id g17sm475854pjl.37.2020.08.18.10.39.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2020 10:39:11 -0700 (PDT) Date: Tue, 18 Aug 2020 11:39:09 -0600 From: Mathieu Poirier To: Mike Leach Subject: Re: [PATCH v8 19/24] coresight: cti: don't disable ect device if it's not enabled Message-ID: <20200818173909.GB3801581@xps15> References: <20200807111153.7784-1-tingwei@codeaurora.org> <20200807111153.7784-20-tingwei@codeaurora.org> <20200817163843.GD3614061@xps15> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200818_133916_026411_27D34FDF X-CRM114-Status: GOOD ( 40.49 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tsoni@codeaurora.org, Sai Prakash Ranjan , Kim Phillips , Mao Jinlong , Suzuki K Poulose , Alexander Shishkin , Greg Kroah-Hartman , Coresight ML , Randy Dunlap , Mian Yousaf Kaukab , Russell King , Tingwei Zhang , Leo Yan , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Aug 17, 2020 at 08:04:06PM +0100, Mike Leach wrote: > Hi Mathieu, > > On Mon, 17 Aug 2020 at 17:38, Mathieu Poirier > wrote: > > > > On Fri, Aug 07, 2020 at 07:11:48PM +0800, Tingwei Zhang wrote: > > > If associated ect device is not enabled at first place, disable > > > routine should not be called. Add ect_enabled flag to check whether > > > ect device is enabled. Fix the issue in below case. Ect device is > > > not available when associated coresight device enabled and the > > > association is established after coresight device is enabled. > > > > > > Signed-off-by: Mike Leach > > > Signed-off-by: Tingwei Zhang > > > --- > > > drivers/hwtracing/coresight/coresight.c | 11 ++++++++--- > > > include/linux/coresight.h | 1 + > > > 2 files changed, 9 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c > > > index d066411aa794..27ad8317e3cf 100644 > > > --- a/drivers/hwtracing/coresight/coresight.c > > > +++ b/drivers/hwtracing/coresight/coresight.c > > > @@ -245,13 +245,18 @@ coresight_control_assoc_ectdev(struct coresight_device *csdev, bool enable) > > > > > > if (!ect_csdev) > > > return 0; > > > + if ((!ect_ops(ect_csdev)->enable) || (!ect_ops(ect_csdev)->disable)) > > > + return 0; > > > > > > if (enable) { > > > - if (ect_ops(ect_csdev)->enable) > > > - ect_ret = ect_ops(ect_csdev)->enable(ect_csdev); > > > + ect_ret = ect_ops(ect_csdev)->enable(ect_csdev); > > > + if (!ect_ret) > > > + csdev->ect_enabled = true; > > > } else { > > > - if (ect_ops(ect_csdev)->disable) > > > + if (csdev->ect_enabled) { > > > ect_ret = ect_ops(ect_csdev)->disable(ect_csdev); > > > + csdev->ect_enabled = false; > > > + } > > > } > > > > > > /* output warning if ECT enable is preventing trace operation */ > > > diff --git a/include/linux/coresight.h b/include/linux/coresight.h > > > index 3bb738f9a326..7d3c87e5b97c 100644 > > > --- a/include/linux/coresight.h > > > +++ b/include/linux/coresight.h > > > @@ -208,6 +208,7 @@ struct coresight_device { > > > /* sysfs links between components */ > > > int nr_links; > > > bool has_conns_grp; > > > + bool ect_enabled; /* true only if associated ect device is enabled */ > > > > We have cti_config::enable_req_count and cti_config::hw_enabled, both used in > > cti_enable_hw() and cti_disable_hw(). I would have thought they'd be sufficient > > to address the counting problems. If they are not I would much rather see a > > solution confined to the cti driver than in the core itself. > > > > This is related to the fact that under sysfs it is possible under > sysfs to enable an etm e.g. etm1 without the cti module present, then > insert the CTI module, then enable another ETM e.g etm2. > This is an issue that is caused by the possibility of module load and > unload, and though inadvisable from a system usage point of view - > Tingwei correctly points out that it could happen. > > At the point that the first ETM is enabled, the associated ect pointer > would be NULL, and thus no attempt to enable the ect/CTI is made. The > CTI module on load will set the ect pointers on all registered csdev > devices, including ones that are already enabled - etm1. > So when we come to disable etm1, it will try to disable a CTI that it > did not enable - a fact that cannot be counted in the CTI driver as it > was not there when the etm was enabled. So we have a flag in csdev to > record if this csdev did in fact enable the associated device, so it > is clear to disable it on shutdown. In the above example the csdev structures associated with ETM1 and ETM2 will have different csdev->ect_dev pointers, one for each CTI it is assocated with. And I would think the reference count for CTI1 would not have been incremented since it was never enabled. What am I missing? > > Regards > > Mike > > > > > Thanks, > > Mathieu > > > > > }; > > > > > > /* > > > -- > > > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > > > a Linux Foundation Collaborative Project > > > > > > > -- > Mike Leach > Principal Engineer, ARM Ltd. > Manchester Design Centre. UK _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel