From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4F980346E7B for ; Mon, 13 Apr 2026 17:21:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776100868; cv=none; b=oFzmGK2V7ShbkSP7e+htz0OvH5FwEw4JPc25HR6ZJiaSwgMKCTouP6AQTYhObQdN/kO/Cr2pNkVeQDggZh4yaYMA4R2xZPwNV4YuuBF/PP7kuRtFSslcG8zKDByab/5ZTOk7u8vXUVO6Y23WZWEuRc6tCxYehfVZ/UuiMjQFZCc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776100868; c=relaxed/simple; bh=HKlmNvL3lsaWXRhMoep2GQ31CkZ+NBkaZrWabpLkiGE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Y9Y9sELPDMqdOrSJg5PUE+Ah75rS67/wj+ifhcYYA3b2XvvPhAGQsCwFJgAmI3P53rrR0Dmd2cszq19UyShYbBpGLz0zr85zUEp+617cshgnhMRumTgH9zDmRCbWRqzuJeCkNhGji7hMDGaqNoAo0oA5Cacl88TSCA+6j4TDVJU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=MqYrMuqO; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="MqYrMuqO" 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 145E4357A; Mon, 13 Apr 2026 10:21:01 -0700 (PDT) Received: from localhost (e132581.arm.com [10.1.196.87]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 63C993F86F; Mon, 13 Apr 2026 10:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1776100866; bh=HKlmNvL3lsaWXRhMoep2GQ31CkZ+NBkaZrWabpLkiGE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MqYrMuqO58GTp8l0L5xBn8paZZHj0xMNeoG6TzcwQFYJj/pu6QNp2XHvMgKepO9yT G5O7IQNZQKGs0WzWVroF+cdB5qhEX1hOAyBqXAbSi/V0W4w3eUBzYQtauX0XLcyhnF gURerw3HsEA2Io75DnW+0VMaCM/6/pKLlM4+PDKU= Date: Mon, 13 Apr 2026 18:21:04 +0100 From: Leo Yan To: Yeoreum Yun Cc: coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, suzuki.poulose@arm.com, mike.leach@arm.com, james.clark@linaro.org, alexander.shishkin@linux.intel.com, jie.gan@oss.qualcomm.com Subject: Re: [PATCH v4 1/9] coresight: etm4x: introduce struct etm4_caps Message-ID: <20260413172104.GD356832@e132581.arm.com> References: <20260413142003.3549310-1-yeoreum.yun@arm.com> <20260413142003.3549310-2-yeoreum.yun@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260413142003.3549310-2-yeoreum.yun@arm.com> On Mon, Apr 13, 2026 at 03:19:54PM +0100, Yeoreum Yun wrote: > Introduce struct etm4_caps to describe ETMv4 capabilities > and move capabilities information into it. > > Signed-off-by: Yeoreum Yun LGTM: Reviewed-by: Leo Yan FWIW, two comments from Sashiko are valuable for me, please see below. > --- > .../coresight/coresight-etm4x-core.c | 234 +++++++++--------- > .../coresight/coresight-etm4x-sysfs.c | 190 ++++++++------ > drivers/hwtracing/coresight/coresight-etm4x.h | 176 ++++++------- > 3 files changed, 328 insertions(+), 272 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c > index d565a73f0042..6443f3717b37 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > @@ -88,8 +88,9 @@ static int etm4_probe_cpu(unsigned int cpu); > */ > static bool etm4x_sspcicrn_present(struct etmv4_drvdata *drvdata, int n) > { > - return (n < drvdata->nr_ss_cmp) && > - drvdata->nr_pe && > + const struct etmv4_caps *caps = &drvdata->caps; > + > + return (n < caps->nr_ss_cmp) && caps->nr_pe && > (drvdata->config.ss_status[n] & TRCSSCSRn_PC); As Sashiko suggests: "This isn't a regression introduced by this patch, but should this be checking caps->nr_pe_cmp instead of caps->nr_pe?" I confirmed the ETMv4 specification (ARM IHI0064H.b), the comment above is valid as the we should check caps->nr_pe_cmp instead. Could you first use a patch to fix the typo and then apply capabilities afterwards? This is helpful for porting to stable kernels. [...] > @@ -525,14 +530,14 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata) > if (etm4x_wait_status(csa, TRCSTATR_IDLE_BIT, 1)) > dev_err(etm_dev, > "timeout while waiting for Idle Trace Status\n"); > - if (drvdata->nr_pe) > + if (caps->nr_pe) > etm4x_relaxed_write32(csa, config->pe_sel, TRCPROCSELR); > etm4x_relaxed_write32(csa, config->cfg, TRCCONFIGR); > /* nothing specific implemented */ > etm4x_relaxed_write32(csa, 0x0, TRCAUXCTLR); > etm4x_relaxed_write32(csa, config->eventctrl0, TRCEVENTCTL0R); > etm4x_relaxed_write32(csa, config->eventctrl1, TRCEVENTCTL1R); > - if (drvdata->stallctl) > + if (caps->stallctl) > etm4x_relaxed_write32(csa, config->stall_ctrl, TRCSTALLCTLR); > etm4x_relaxed_write32(csa, config->ts_ctrl, TRCTSCTLR); > etm4x_relaxed_write32(csa, config->syncfreq, TRCSYNCPR); > @@ -542,17 +547,17 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata) > etm4x_relaxed_write32(csa, config->vinst_ctrl, TRCVICTLR); > etm4x_relaxed_write32(csa, config->viiectlr, TRCVIIECTLR); > etm4x_relaxed_write32(csa, config->vissctlr, TRCVISSCTLR); > - if (drvdata->nr_pe_cmp) > + if (caps->nr_pe_cmp) > etm4x_relaxed_write32(csa, config->vipcssctlr, TRCVIPCSSCTLR); > - for (i = 0; i < drvdata->nrseqstate - 1; i++) > + for (i = 0; i < caps->nrseqstate - 1; i++) > etm4x_relaxed_write32(csa, config->seq_ctrl[i], TRCSEQEVRn(i)); Sashiko's comment: "If the hardware does not implement a sequencer, caps->nrseqstate (a u8) will be 0. Does 0 - 1 evaluate to -1 as an int, which then gets promoted to ULONG_MAX against val (an unsigned long)?" This is a good catch. The condition check should be: for (i = 0; i < caps->nrseqstate; i++) ...; The issue is irrelevant to your patch, but could you use a patch to fix "nrseqstate - 1" first and then apply the cap refactoring on it? This would be friendly for porting to stable kernel. Thanks, Leo