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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3DC79C433F5 for ; Thu, 7 Oct 2021 09:20:37 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 EE20561175 for ; Thu, 7 Oct 2021 09:20:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org EE20561175 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=0DFY5WSF0xg2uDZ+NREcbifWEN1iQl7baIQUOkTuZik=; b=ptd2b5rPDP8lHPKANNfO3jSEVC mdtfU5OnzE06Jvoiu7YGj014YxzbtIQLw5UvteOMw4rBm8elTQXrezOoHwh4ckdjpdaa5Em1XUvra 6rnD613M4Zfiod0Wv3fwGKsSws02u1egcawWZnYbXEaCW61QlZkwmNe4Yznc4SFqzR1i9DKuJ04oD bQAGMdSdQvxJIgGd2LgXDbn58n4fDwSrNHYnXyECxAzdF4Dp/BJijcS5hV1YKlDiu9GbpnFI3byDg fdKkTPLrWpZ1WkoodM4rgYleXqwRx5YGonFk8pBP1Ni7hsXbORUE9P3O5UFp1sigLn9h2zXJUabpe zyfMQgew==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mYPYE-00GfTx-R5; Thu, 07 Oct 2021 09:18:54 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mYPYA-00GfSW-IB for linux-arm-kernel@lists.infradead.org; Thu, 07 Oct 2021 09:18:52 +0000 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 E249F1FB; Thu, 7 Oct 2021 02:18:45 -0700 (PDT) Received: from [10.57.72.173] (unknown [10.57.72.173]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 02C1E3F766; Thu, 7 Oct 2021 02:18:43 -0700 (PDT) Subject: Re: [PATCH v2 12/17] coresight: trbe: Add a helper to fetch cpudata from perf handle To: Mathieu Poirier Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, maz@kernel.org, catalin.marinas@arm.com, mark.rutland@arm.com, james.morse@arm.com, anshuman.khandual@arm.com, leo.yan@linaro.org, mike.leach@linaro.org, will@kernel.org, lcherian@marvell.com, coresight@lists.linaro.org References: <20210921134121.2423546-1-suzuki.poulose@arm.com> <20210921134121.2423546-13-suzuki.poulose@arm.com> <20211004174239.GB3263478@p14s> <0ff450f4-ab3e-b409-5278-35cdfb883284@arm.com> <20211006171536.GA3373323@p14s> From: Suzuki K Poulose Message-ID: <8cecf6d2-f1ff-5b9c-7969-24124a00944e@arm.com> Date: Thu, 7 Oct 2021 10:18:42 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211006171536.GA3373323@p14s> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211007_021850_751847_F0325BA5 X-CRM114-Status: GOOD ( 28.13 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 06/10/2021 18:15, Mathieu Poirier wrote: > On Tue, Oct 05, 2021 at 11:35:13PM +0100, Suzuki K Poulose wrote: >> Hi Mathieu >> >> On 04/10/2021 18:42, Mathieu Poirier wrote: >>> On Tue, Sep 21, 2021 at 02:41:16PM +0100, Suzuki K Poulose wrote: >>>> Add a helper to get the CPU specific data for TRBE instance, from >>>> a given perf handle. This also adds extra checks to make sure that >>>> the event associated with the handle is "bound" to the CPU and is >>>> active on the TRBE. >>>> >>>> Cc: Anshuman Khandual >>>> Cc: Mike Leach >>>> Cc: Mathieu Poirier >>>> Cc: Leo Yan >>>> Signed-off-by: Suzuki K Poulose >>>> --- >>>> drivers/hwtracing/coresight/coresight-trbe.c | 12 ++++++++++-- >>>> 1 file changed, 10 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c >>>> index 983dd5039e52..797d978f9fa7 100644 >>>> --- a/drivers/hwtracing/coresight/coresight-trbe.c >>>> +++ b/drivers/hwtracing/coresight/coresight-trbe.c >>>> @@ -268,6 +268,15 @@ static unsigned long trbe_snapshot_offset(struct perf_output_handle *handle) >>>> return buf->nr_pages * PAGE_SIZE; >>>> } >>>> +static inline struct trbe_cpudata * >>>> +trbe_handle_to_cpudata(struct perf_output_handle *handle) >>>> +{ >>>> + struct trbe_buf *buf = etm_perf_sink_config(handle); >>>> + >>>> + BUG_ON(!buf || !buf->cpudata); >>>> + return buf->cpudata; >>>> +} >>>> + >>>> /* >>>> * TRBE Limit Calculation >>>> * >>>> @@ -533,8 +542,7 @@ static enum trbe_fault_action trbe_get_fault_act(struct perf_output_handle *hand >>>> { >>>> int ec = get_trbe_ec(trbsr); >>>> int bsc = get_trbe_bsc(trbsr); >>>> - struct trbe_buf *buf = etm_perf_sink_config(handle); >>>> - struct trbe_cpudata *cpudata = buf->cpudata; >>>> + struct trbe_cpudata *cpudata = trbe_handle_to_cpudata(handle); >>> >>> There is two other places where this pattern is present: is_perf_trbe() and >>> __trbe_normal_offset(). >> >> I skipped them, as they have to get access to the "trbe_buf" anyways. >> So the step by step, made sense. But I could replace them too to make it >> transparent. >> >> What do you think ? > > Humm... I don't think there is a right way or a wrong way here. If we move > forward with this patchset we have two ways of getting to buf->cpudata. One > using trbe_handle_to_cpudata() and another one as laid out in is_perf_trbe() and > __trbe_normal_offset(), each with an equal number of occurences (2 for each). > > I am usually not fond of small functions like trbe_handle_to_cpudata() and to me > keeping the current heuristic in trbe_get_fault_act() would have been just fine. There is another user introduced in the work around patch. But, yes, I agree, we could open code it, rather than having it inconsistent across the driver. > I agree with the argument that trbe_handle_to_cpudata() provides more checks but > is it really worth it if they aren't done everywhere? > > In short I would get rid of trbe_handle_to_cpudata() entirely and live without > the extra checks... But I'm not strongly opinionated on this either. Ok, I will remove this then. Thanks for the feedback. Suzuki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel