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=-10.0 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=unavailable 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 99094C433E4 for ; Tue, 28 Jul 2020 20:27:18 +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 57B442065E for ; Tue, 28 Jul 2020 20:27:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="k2Tc347u"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="HBSVeOJJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 57B442065E 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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=WweBIMyC+sRL9wr635fiQG1q36wmnp3WwGbuyJFOzKw=; b=k2Tc347uPHshvTYMU2tthzU3h dmfa4vNHWwaOVIELHUauwun2dsoOsV0ahAUDj4sSCctTYv1gunm9io5EMkCQQlwytmd9EqgHcFADJ ionkV4D9Zv4khm05YRcIUdaaprWbR05QDG0mmk0VkVMuSHmv+0khsEBYiWtvU/hNsjn+eMvCXFCyw 72D2WSuF5CQsWyV620Jck4S6gsZrg2gVWsFeL+bV2fnEdJI1v9H57cIN2oO7QR1mvV0Td7rGWN8fm VOYosD66R8LjflA+RNpqqZXUzHKJ3NRNRy/1CjD3sZ3qg6DzEASYlqarZ0JrmnvDXWWZAw6Jj20BI LClA4opeg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k0WAV-00066U-Tj; Tue, 28 Jul 2020 20:25:48 +0000 Received: from mail-ej1-x642.google.com ([2a00:1450:4864:20::642]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k0WAO-00065Z-DS for linux-arm-kernel@lists.infradead.org; Tue, 28 Jul 2020 20:25:44 +0000 Received: by mail-ej1-x642.google.com with SMTP id kq25so9019075ejb.3 for ; Tue, 28 Jul 2020 13:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lts9OcKmsXGGdW696uhvjO+nvE7v+/aN8EKz0bSa3oI=; b=HBSVeOJJYcyuyZ86WFdcUjvLt/vFhzzAFEgQ8A3VVi62gk8ixJkUWzciBSHFTP6rPE Xs8FIhHWwtO+Pses2Fb0AxsAX8bv9i+J6GaLJ3Lq0jmZaUwirdAdIxTtT4LxvJi7UtgW bpiFmJllONtmvTUO81X6CEpNL8CFUkLcu66kHK6dXm8UOJfhWJkY2z1cBLFLXDo8e9rp OQ6kA71wMw4yh7D1tjVdf4Q9QQ1pylSdwBnho5m4LBhIFleUJ3Ohbf90/Su9qMpklwUO viNRtdfX9MAsXyMfDQbberuAlg2tNtC/mDK8Cww5NOFY9S3U0GXMORPjcr09hBZjaQXS ALGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lts9OcKmsXGGdW696uhvjO+nvE7v+/aN8EKz0bSa3oI=; b=na2Zrz0IfI6CW44ZuNtRSZ2Z1fB3+U5AVBlETzaZZtqP5jwvWDuX8HdBt5BRG8APmi PGApnhGq7by8L/SqUvDjoj4gxKqu16YSIBQy8offyQXtnZg83utBsFAc6u6g0ENRskNo raotjI/QtGI5ZiXX8UoOOvdx7xpZoLGEUccJguWIF857bWRm3AtwZtJqqsYGP9pZrgU/ csoN1l7za8q/6KhOk7F7/qbN5vlYG0DSPQ6MsgV+/oCVWZ6y+YF+DU5ZqYguAQOsKpeo P9cV91q+oZ8Sl9rll7Dj/qXeGr2G4BiHGP4lvve25LOA2JNiVnMpP6c2ve0/Io+5gxjD Je5w== X-Gm-Message-State: AOAM530eWCmXb+46kLb7upxNCA9DLG1nTCPbzJyIgu0V279bQZK0IURq 2aQsRUoy4UEdaNcD7y2qo3iG/CDRQIaFBsQkuR+Os93Z83ciUg== X-Google-Smtp-Source: ABdhPJyMd/0BeIlQ1XPKG7Xek/KEjhyRIwoo4ozlaBROEyUPP74nZov9ByRBMMRvaIw1m04tRrsUby9+FxxwMe1ZEXM= X-Received: by 2002:a17:907:36b:: with SMTP id rs11mr8198793ejb.544.1595967938806; Tue, 28 Jul 2020 13:25:38 -0700 (PDT) MIME-Version: 1.0 References: <20200723042802.22511-1-tingwei@codeaurora.org> <20200723042802.22511-7-tingwei@codeaurora.org> <20200725100516.GA18120@codeaurora.org> <20200726013205.GA23391@codeaurora.org> <20200728010711.GA12572@codeaurora.org> <20200728111703.GA19375@codeaurora.org> In-Reply-To: <20200728111703.GA19375@codeaurora.org> From: Mike Leach Date: Tue, 28 Jul 2020 21:25:27 +0100 Message-ID: Subject: Re: [PATCH v4 06/20] coresight: add try_get_module() in coresight_grab_device() To: Tingwei Zhang X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200728_162540_960398_29164658 X-CRM114-Status: GOOD ( 68.00 ) 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 , Mathieu Poirier , Suzuki K Poulose , Alexander Shishkin , Greg Kroah-Hartman , Coresight ML , Randy Dunlap , Mian Yousaf Kaukab , Russell King , Mao Jinlong , 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 Hi Tingwei, On Tue, 28 Jul 2020 at 12:17, Tingwei Zhang wrote: > > Hi Mike, > On Tue, Jul 28, 2020 at 06:08:37PM +0800, Mike Leach wrote: > > Hi Tingwei, > > > > On Tue, 28 Jul 2020 at 02:07, Tingwei Zhang wrote: > > > > > > Hi Mike, > > > > > > On Tue, Jul 28, 2020 at 01:04:21AM +0800, Mike Leach wrote: > > > > Hi Tingwei, > > > > > > > > On Sun, 26 Jul 2020 at 02:32, Tingwei Zhang > > > > wrote: > > > > > > > > > > Hi Mike, > > > > > On Sat, Jul 25, 2020 at 09:51:31PM +0800, Mike Leach wrote: > > > > > > Hi Tingwei, > > > > > > > > > > > > On Sat, 25 Jul 2020 at 11:05, Tingwei Zhang > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Hi Mike, > > > > > > > > > > > > > > Thu, Jul 23, 2020 at 06:55:47PM +0800, Mike Leach wrote: > > > > > > > > Hi Tingwei, > > > > > > > > > > > > > > > > On Thu, 23 Jul 2020 at 05:28, Tingwei Zhang > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > When coresight device is in an active session, driver module > > > > > > > > > of > > > > > > > > > that device should not be removed. Use try_get_module() in > > > > > > > > > coresight_grab_device() to prevent module to be unloaded. > > > > > > > > > > > > > > > > > > Signed-off-by: Tingwei Zhang > > > > > > > > > --- > > > > > > > > > drivers/hwtracing/coresight/coresight.c | 27 > > > > > > +++++++++++++++++++++---- > > > > > > > > > 1 file changed, 23 insertions(+), 4 deletions(-) > > > > > > > > > > > > > > > > > > diff --git a/drivers/hwtracing/coresight/coresight.c > > > > > > > > b/drivers/hwtracing/coresight/coresight.c > > > > > > > > > index b7151c5f81b1..17bc76ea86ae 100644 > > > > > > > > > --- a/drivers/hwtracing/coresight/coresight.c > > > > > > > > > +++ b/drivers/hwtracing/coresight/coresight.c > > > > > > > > > @@ -640,7 +640,7 @@ struct coresight_device > > > > > > > > *coresight_get_sink_by_id(u32 id) > > > > > > > > > * don't appear on the trace path, they should be handled > > > > > > > > > along > > > > > > with > > > > > > > > the > > > > > > > > > * the master device. > > > > > > > > > */ > > > > > > > > > -static void coresight_grab_device(struct coresight_device > > > > *csdev) > > > > > > > > > +static int coresight_grab_device(struct coresight_device > > > > *csdev) > > > > > > > > > { > > > > > > > > > int i; > > > > > > > > > > > > > > > > > > @@ -648,10 +648,25 @@ static void coresight_grab_device(struct > > > > > > > > coresight_device *csdev) > > > > > > > > > struct coresight_device *child; > > > > > > > > > > > > > > > > > > child = csdev->pdata->conns[i].child_dev; > > > > > > > > > - if (child && child->type == > > > > > > CORESIGHT_DEV_TYPE_HELPER) > > > > > > > > > + if (child && child->type == > > > > > > CORESIGHT_DEV_TYPE_HELPER) { > > > > > > > > > + if > > > > > > > > (!try_module_get(child->dev.parent->driver->owner)) > > > > > > > > > + goto err; > > > > > > > > > > > > > > > > > > pm_runtime_get_sync(child->dev.parent); > > > > > > > > > + } > > > > > > > > > } > > > > > > > > > + if (!try_module_get(csdev->dev.parent->driver->owner)) > > > > > > > > > + goto err; > > > > > > > > > pm_runtime_get_sync(csdev->dev.parent); > > > > > > > > > + return 0; > > > > > > > > > +err: > > > > > > > > > + for (i--; i >= 0; i--) { > > > > > > > > > + struct coresight_device *child; > > > > > > > > > + > > > > > > > > > + child = csdev->pdata->conns[i].child_dev; > > > > > > > > > + if (child && child->type == > > > > > > CORESIGHT_DEV_TYPE_HELPER) > > > > > > > > > + pm_runtime_put(child->dev.parent); > > > > > > > > > + } > > > > > > > > > + return -ENODEV; > > > > > > > > > } > > > > > > > > > > > > > > > > > > /* > > > > > > > > > @@ -663,12 +678,15 @@ static void coresight_drop_device(struct > > > > > > > > coresight_device *csdev) > > > > > > > > > int i; > > > > > > > > > > > > > > > > > > pm_runtime_put(csdev->dev.parent); > > > > > > > > > + module_put(csdev->dev.parent->driver->owner); > > > > > > > > > for (i = 0; i < csdev->pdata->nr_outport; i++) { > > > > > > > > > struct coresight_device *child; > > > > > > > > > > > > > > > > > > child = csdev->pdata->conns[i].child_dev; > > > > > > > > > - if (child && child->type == > > > > > > CORESIGHT_DEV_TYPE_HELPER) > > > > > > > > > + if (child && child->type == > > > > > > CORESIGHT_DEV_TYPE_HELPER) { > > > > > > > > > pm_runtime_put(child->dev.parent); > > > > > > > > > + > > > > > > module_put(child->dev.parent->driver->owner); > > > > > > > > > + } > > > > > > > > > } > > > > > > > > > } > > > > > > > > > > > > > > > > > > @@ -721,7 +739,8 @@ static int _coresight_build_path(struct > > > > > > > > coresight_device *csdev, > > > > > > > > > if (!node) > > > > > > > > > return -ENOMEM; > > > > > > > > > > > > > > > > > > - coresight_grab_device(csdev); > > > > > > > > > + if (coresight_grab_device(csdev)) > > > > > > > > > + return -ENODEV; > > > > > > > > > node->csdev = csdev; > > > > > > > > > list_add(&node->link, path); > > > > > > > > > > > > > > > > > > -- > > > > > > > > > The Qualcomm Innovation Center, Inc. is a member of the Code > > > > Aurora > > > > > > > > Forum, > > > > > > > > > a Linux Foundation Collaborative Project > > > > > > > > > > > > > > > > > > > > > > > > > The CTI devices are associated with other coresight components > > > > using > > > > > > > > csdev->ect_dev; These are not handled in the main linear trace > > > > path as > > > > > > > > these have a star topology interlinking all components. > > > > > > > > However, when a component has an associated ect_dev then is > > > > enabled at > > > > > > > > the same time as the other component is enabled. > > > > > > > > > > > > > > > > So a module_get/put will be needed for this association to > > > > > > > > prevent > > > > the > > > > > > > > CTI being removed while a trace session is active. > > > > > > > > I suggest in coresight.c : coresight_control_assoc_ectdev() > > > > > > > > > > > > > > > > > > > > > > In module unload process, devices of that module will be removed. > > > > > > > In > > > > > > > this case, cti_remove() is called on all cti device when unloading > > > > > > > cti module. All cti connections is cleaned at that time. > > > > > > > csdev->ect_dev is set to NULL. coresight_control_assoc_ectdev() > > > > > > > will return since since ect_csdev is NULL. > > > > > > > > > > > > > > I think we are safe without holding module reference since cti > > > > > > > driver has done a pretty good job on clean up. > > > > > > > > > > > > > > > > > > > The issue here is not about clean up. We need to keep all the > > > > > > programmed coresight modules loaded and operational while a > > > > > > coresight > > > > > > trace session is in progress. The CTI can be used to control the > > > > > > generation of trace, trigger trace related events etc. > > > > > > If the module is removed while a session is in progress then this > > > > > > programming is lost and the trace data collected may not be what is > > > > > > expected. > > > > > > > > > > > > > > > > Got your point now. In my opinion, CTI is kinda different to other > > > > > coresight components since it's optional. > > > > > > > > > > For other components, they have to been there when path is built or > > > > > the enablement fails. Use can either get a successfully return which > > > > > means it's good and all devices/modules are there until path is > > > > > released, or a failed return which means trace session can't be > > > > > setup. > > > > > > > > > > > > > The module get/put do more than ensure that the system can be enabled. > > > > They ensure that no components in the coresight path can be unloaded > > > > until all paths in use are released. This ensures that clients do not > > > > get the trace system pulled out from underneath - corrupting trace > > > > data, and possibly affecting the client program. > > > > > > > > > > I agree. > > > > > > > > In CTI case, there's no garrantee that CTI related to the trace > > > > > session is there even the enablement is successful. > > > > > > > > And there is no guarantee that it is not programmed to perform a key > > > > task in controlling the generation of trace. > > > > > > > > The entire programmed coresight system must be protected when in use. > > > > That includes CTI devices. Otherwise the integrity of the captured > > > > trace could be compromised, and indeed there may be no trace captured > > > > if this is relying on CTI triggers. > > > > > > > > > > That's correct. If CTI is not there, the trace may be wrong or no > > > trace as all. > > > > > > > >For example, > > > > > One cti is required for ETM tracing session. If cti module is > > > > > unloaded before enable that trace session. The enablement will > > > > > still be successfully done since there's no ect_dev connected > > > > > at all. > > > > > > > > > > My point is holding cti module reference in enable path won't > > > > > fix all the problem. Altenatively, user should be aware that > > > > > unload cti module leads to all cti functioniol failure. > > > > > With current design, the behavior is consistant on cti. User > > > > > can unload cti module whenever he wants but it will break > > > > > the function. > > > > > > > > Precisely - and this is what should never be allowed - why can the CTI > > > > be used to break the trace system but not other components? > > > > > > > > > > > Sorry - I may not have been clear here - I do not want to make having > > a CTI mandatory for enabling the trace session - this is an optional > > component. > > > > > We can't prevent user to unload CTI module when there's no active > > > trace session. > > > > Agreed - the same applies to all the other components. > > > > > If we don't allow CTI to be not available, we need to > > > check whether CTI is there in build_path routine or coresight enable > > > routine. We need return failure if CTI is not there when user enables > > > the trace session. Currently, coresight framework check associate CTI > > > device, but if CTI deivce is not probed due to probe failure or > > > module unload, coresight framework assume there's no assocaite CTI > > > device and just continue the enablement. It won't return failure. > > > > > > If we have plan to change CTI check to be mandatory, make the coresight > > > enablement fail if CTI is not there like other trace components. I'm > > > perfect fine to add module_get/module_put for CTI. > > > > > > > If the CTI is present at the time the trace path is created, then it > > must be enabled, and a failure to enable the CTI fails the entire path > > enable - this is the operation that is implemented by > > coresight_control_assoc_ectdev() at this time. > > If a CTI is not present at the time the trace path is created, then as > > you have said previously, the ect_dev pointer will be NULL and the > > check and enable of CTI will be skipped by > > coresight_control_assoc_ectdev() and have no effect on the trace path. > > > > For the module version, if CTI is present and enabled then the module > > must be locked so it cannot be removed while the trace is active - > > this is the only change that is required. So adding get / put module > > in coresight_control_assoc_ectdev() will lock the module in for the > > duration that trace is active. > > > > I've tested the code below to ensure that the cti module is correctly > > locked while trace is active, but can be removed as required when > > trace is inactive. > > > > Thanks a lot for coming up with the patch and testing it, Mike. > > > Regards > > > > Mike > > > > --------------------------------------------------------------------------------- > > static int > > coresight_control_assoc_ectdev(struct coresight_device *csdev, bool enable) > > { > > int ect_ret = 0; > > struct coresight_device *ect_csdev = csdev->ect_dev; > > struct module *mod; > > > > if (!ect_csdev) > > return 0; > > > > if ((!ect_ops(ect_csdev)->enable) || (!ect_ops(ect_csdev)->disable)) > > return 0; > > > > mod = ect_csdev->dev.parent->driver->owner; > > > > if (enable) { > > if (try_module_get(mod)) { > > ect_ret = ect_ops(ect_csdev)->enable(ect_csdev); > > if (ect_ret) > > module_put(mod); > > } else > > ect_ret = -ENODEV; > > } else { > > module_put(mod); > > ect_ret = ect_ops(ect_csdev)->disable(ect_csdev); > > } > > If CTI module is removed before enablement of ETM and installed after ETM > enablement and before ETM disablement. We have a unbalanced module > reference number here. I made one test to prove this with above code. > > We may need move module_put() after disable(). Return proper error from > disable() to indicate CTI was not enabled before so we can skip > module_put(). > > Tests: > db845c:/sys/bus/coresight/devices # echo 1 > tmc_etr0/enable_sink > db845c:/sys/bus/coresight/devices # echo 1 > etm1/enable_source > db845c:/sys/bus/coresight/devices # rmmod coresight_cti > rmmod: failed to unload coresight_cti: Try again > 1|db845c:/sys/bus/coresight/devices # echo 0 > etm1/enable_source > db845c:/sys/bus/coresight/devices # rmmod coresight_cti > db845c:/sys/bus/coresight/devices # echo 1 > etm1/enable_source > db845c:/sys/bus/coresight/devices # insmod /data/modules/coresight-cti.ko > db845c:/sys/bus/coresight/devices # echo 1 > etm2/enable_source > db845c:/sys/bus/coresight/devices # echo 0 > etm1/enable_source > db845c:/sys/bus/coresight/devices # rmmod coresight_cti > db845c:/sys/bus/coresight/devices # > > Above module removal should fail since etm2 is still active now. > Good point. Not sure this is sensible user operation, but it is something that needs to be handled. The issue goes beyond just the module count - the CTI driver has an internal enable/disable refcount that is affected by this too. I think the best way to handle this late CTI load is to flag which Coresight devices have actually enabled the CTI, and only disable for these. So given a new flag in coresight_device, the following is possible:- if (enable) { if (try_module_get(mod)) { ect_ret = ect_ops(ect_csdev)->enable(ect_csdev); if (ect_ret) module_put(mod); else csdev->ect_enable = true; } else ect_ret = -ENODEV; } else { if (csdev->ect_enable) { module_put(mod); ect_ret = ect_ops(ect_csdev)->disable(ect_csdev); csdev->ect_enable = false; } } During testing I have found that removing the etm4x module before the cti module results in a crash. This is due to a bug in the cti driver callback that removes sysfs links - and an issue in the coresight-core where that callback is called. I'll forward detail for all this tomorrow. Regards Mike > > > > /* output warning if ECT enable is preventing trace operation */ > > if (ect_ret) > > dev_info(&csdev->dev, "Associated ECT device (%s) %s failed\n", > > dev_name(&ect_csdev->dev), > > enable ? "enable" : "disable"); > > return ect_ret; > > } > > ----------------------------------------------------------------------------------------- > > Tests:- > > ----------------------- > > root@linaro-developer:/home/linaro/scripts# ./trace-sysfs-start.bash > > Tracing via sysfs > > enabling etf > > wait before enable etm > > enabling etm 0. > > enabling etm 1. > > enabling etm 2. > > enabling etm 3. > > waiting for trace > > root@linaro-developer:/home/linaro/scripts# rmmod > > ../cs-mods/coresight-etm4x.ko > > rmmod: ERROR: Module coresight_etm4x is in use > > root@linaro-developer:/home/linaro/scripts# rmmod > > ../cs-mods/coresight-cti.ko > > rmmod: ERROR: Module coresight_cti is in use > > root@linaro-developer:/home/linaro/scripts# ./trace-sysfs-end.bash > > ending trace > > disabling etm 0. > > disabling etm 1. > > disabling etm 2. > > disabling etm 3. > > disabling etf > > 16+0 records in > > 16+0 records out > > 8192 bytes (8.2 kB) copied, 0.000834116 s, 9.8 MB/s > > root@linaro-developer:/home/linaro/scripts# rmmod > > ../cs-mods/coresight-cti.ko > > root@linaro-developer:/home/linaro/scripts# rmmod > > ../cs-mods/coresight-etm4x.ko > > root@linaro-developer:/home/linaro/scripts# insmod > > ../cs-mods/coresight-etm4x.ko > > root@linaro-developer:/home/linaro/scripts# ./trace-sysfs-start.bash > > Tracing via sysfs > > enabling etf > > wait before enable etm > > enabling etm 0. > > enabling etm 1. > > enabling etm 2. > > enabling etm 3. > > waiting for trace > > root@linaro-developer:/home/linaro/scripts# rmmod > > ../cs-mods/coresight-etm4x.ko > > rmmod: ERROR: Module coresight_etm4x is in use > > root@linaro-developer:/home/linaro/scripts# rmmod > > ../cs-mods/coresight-cti.ko > > rmmod: ERROR: Module coresight_cti is not currently loaded > > root@linaro-developer:/home/linaro/scripts# ./trace-sysfs-end.bash > > ending trace > > disabling etm 0. > > disabling etm 1. > > disabling etm 2. > > disabling etm 3. > > disabling etf > > 16+0 records in > > 16+0 records out > > 8192 bytes (8.2 kB) copied, 0.000819117 s, 10.0 MB/s > > > > } > > > > > > > > > > Moving forwards we will see users who simply use pre-programmed > > > > settings from client programs such as perf. It may be that some users > > > > do not have the credentials to add and remove modules - this could be > > > > an admin function where larger systems with multiple sessions are in > > > > use. > > > > > > > > > > > > Regards > > > > > > > > Mike > > > > > > > > > > > > > > > > > > Thanks, Tingwei > > > > > > > > > > > Regards > > > > > > > > > > > > Mike > > > > > > > > > > > > > Let me know if you still think we need hold the module reference. > > > > > > > > > > > > > > Thanks, Tingwei > > > > > > > > Regards > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > 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 > > > > > > > > > > > > > > > > -- > > > > 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 > > > > > > > > -- > > Mike Leach > > Principal Engineer, ARM Ltd. > > Manchester Design Centre. UK -- 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