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 BAE5CC433DF for ; Wed, 19 Aug 2020 19:51:57 +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 718E3207DE for ; Wed, 19 Aug 2020 19:51:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="jVoslP37"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="pkA96dxR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 718E3207DE 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=WsjAPDWmENEnqfq5gTeklLAyGsvVW+ARsDgYV3dF9Es=; b=jVoslP37/ySrgaPcjYkRe+MRW PnmQfh1SJSKSgdZ4kuYUtG7R4jgToL91zA8e0Fm3X5M8I1cw8uB0CYVVukGZA2VhA1WecEgufitM+ j2v4y4CPpnibSHKvAHQdJxmVTByNnLnUrVS9QoMtdXTB5HKXChfCQo7DmUMmXMXIC+8mrpWHFmBnD 2v6nBBvwi2fShFdch5vn7hkpktEhxzvg+Lfb5j7EX7gEFKdra8915GgAqSRJ1/t928Xb66yVz2zld NlMV2FvN2J3UWtM4wsZ6eT54O/snHG00btLK7r7oWktOvUsyZDtyJ0f/RUHiXs6/j0PKBx7Y+ajpe G3959BobQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8U6g-0001nS-69; Wed, 19 Aug 2020 19:50:46 +0000 Received: from mail-pg1-x543.google.com ([2607:f8b0:4864:20::543]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8U6c-0001m7-M4 for linux-arm-kernel@lists.infradead.org; Wed, 19 Aug 2020 19:50:44 +0000 Received: by mail-pg1-x543.google.com with SMTP id v15so11905909pgh.6 for ; Wed, 19 Aug 2020 12:50:42 -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=vvi6fy8+0qrAwU9LE1mr1IUd02bbed5tFjIPCE9AEc4=; b=pkA96dxRACJOI2N6VKPDxsi8rHf2MI/lwv9KtQZcgHLAYpwIwxRfIEdpKqvgaXbrwE yShPJvH1YJ2p/ph0ZStDust0n3RPtEM+OwQ5pZ92qiiZ4GVI+ybkX/bwaoGsKnSDc+eu 3YNTgOcOu2oBmMjy86JWHsQotw4lGnDrUzKJ3OGAPpJmbJ/6HzRJ7Q6/+Dlt9OModt8O k81XdqFdckaZMJE9q8Fl3x+OcOGdv5mffxSwxLtup+iOkhnhehTcC8BdH8xhEeSgYxR4 x5a8CfUnRqLR0Dz570HaS6oFqlQZ0MoGljQP/XNZZwLSNANtPAk0I1DlBnxFEPBsAk46 Yttw== 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=vvi6fy8+0qrAwU9LE1mr1IUd02bbed5tFjIPCE9AEc4=; b=A74mxE9x6XkAoE/+WSJowG09oERAgG66Aw9t58wm6VGT8EXgjozoRPuw8VnOv/3kvP srt67CAfqsmMKU15cCzbfYcCS0dVIvUPra7KYAPoS8m32IidW1yvVLqO3XFm2RbdafyK ODcuT09q2Fb4OLHZEMXBUACH88T58+ytVR4ejTziOxM1oCv1Kl0Sc5d59NbRjDzw9qWA rLgSy6WcvZ9s07zwVeapOgTy/ZNW5P5MCYaYYSKtzFni7kLEAyOvOBg2v1gqhu3N641O 8DnwiXYJ0fqXP/52K85fs7ccFMNJ0SJLRTQZK1w8Y6r7Oa088TYciLmA/knaflGb5lze dPmw== X-Gm-Message-State: AOAM532Hmko+NsBUIVel7ylKKUtf5FUGcPn/yaYsVXY2mni0/RbyOYlr NCBTOBCsUankshY1AWhzdYnNrg== X-Google-Smtp-Source: ABdhPJznXvZRcNoHwGmEzlBGg+6YTVBhW2WKJOSOXDkUPWsvAHJqGAeuLPTDLHYDPr1ym9rwQMJ+8Q== X-Received: by 2002:a63:fc4b:: with SMTP id r11mr16233pgk.342.1597866639768; Wed, 19 Aug 2020 12:50:39 -0700 (PDT) Received: from xps15 (S0106002369de4dac.cg.shawcable.net. [68.147.8.254]) by smtp.gmail.com with ESMTPSA id r186sm3492pfr.162.2020.08.19.12.50.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Aug 2020 12:50:39 -0700 (PDT) Date: Wed, 19 Aug 2020 13:50:36 -0600 From: Mathieu Poirier To: Tingwei Zhang Subject: Re: [PATCH v8 19/24] coresight: cti: don't disable ect device if it's not enabled Message-ID: <20200819195036.GC3845366@xps15> References: <20200807111153.7784-1-tingwei@codeaurora.org> <20200807111153.7784-20-tingwei@codeaurora.org> <20200817163843.GD3614061@xps15> <20200818173909.GB3801581@xps15> <20200819015533.GA19500@codeaurora.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200819015533.GA19500@codeaurora.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200819_155042_867774_D0B5156E X-CRM114-Status: GOOD ( 52.25 ) 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 , Suzuki K Poulose , Alexander Shishkin , Greg Kroah-Hartman , Coresight ML , Mao Jinlong , Mian Yousaf Kaukab , Russell King , Randy Dunlap , Tingwei Zhang , Leo Yan , linux-arm-kernel , Mike Leach 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 Wed, Aug 19, 2020 at 09:55:33AM +0800, Tingwei Zhang wrote: > On Wed, Aug 19, 2020 at 01:39:09AM +0800, Mathieu Poirier wrote: > > 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? > > > > The issue here is we could have two or more coresght devices associated > to single CTI device, especially for sys cti case. For example, we have > coresight devcie A and B. They are assocaited to CTI device C. CTI module > is not loaded at first. Device A is enabled. CTI C is not enabled. Then > CTI module is loaded. Device B is enabled. CTI C is enabled with > enable_req_count = 1. Device A is disabled. It decrease enable_req_count > to 0, so CTI C is disabled. It's kinda weird to me that CTI C is enabled > with device B and disabled by device A. Thanks for taking the time to write this out, I now have a better understanding of the problem. On the flip side I hope to find a better solution, something I will have to think about. No need to wait on me though, resubmit a new revision when ready and I'll see then. > > The point is we need some flag in coresight device structure to save the > status of associated CTI enablement when CTI module is not loaded yet. > > Thanks, > Tingwei > > > > > > > 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel