Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 10 Nov 2020 10:33:03 -0700
From:   Mathieu Poirier <mathieu.poirier@linaro.org>
To:     Suzuki K Poulose <suzuki.poulose@arm.com>
Cc:     linux-arm-kernel@lists.infradead.org, mike.leach@linaro.org,
        coresight@lists.linaro.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 23/26] coresight: etm4x: Detect system instructions
 support
Message-ID: <20201110173303.GB3429138@xps15>
References: <20201028220945.3826358-1-suzuki.poulose@arm.com>
 <20201028220945.3826358-25-suzuki.poulose@arm.com>
 <20201109202205.GB3396611@xps15>
 <b4a4bd73-00c5-a921-3f01-7100d2a0edf8@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b4a4bd73-00c5-a921-3f01-7100d2a0edf8@arm.com>
Precedence: bulk

On Tue, Nov 10, 2020 at 09:31:42AM +0000, Suzuki K Poulose wrote:
> On 11/9/20 8:22 PM, Mathieu Poirier wrote:
> > On Wed, Oct 28, 2020 at 10:09:42PM +0000, Suzuki K Poulose wrote:
> > > ETM v4.4 onwards adds support for system instruction access
> > > to the ETM. Detect the support on an ETM and switch to using the
> > > mode when available.
> > > 
> > > Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> > > ---
> > >   .../coresight/coresight-etm4x-core.c          | 39 +++++++++++++++++++
> > >   1 file changed, 39 insertions(+)
> > > 
> > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > > index 4bc2f15b6332..dc537b5612eb 100644
> > > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > > @@ -675,6 +675,37 @@ static const struct coresight_ops etm4_cs_ops = {
> > >   	.source_ops	= &etm4_source_ops,
> > >   };
> > > +static inline bool cpu_supports_sysreg_trace(void)
> > > +{
> > > +	u64 dfr0 = read_sysreg_s(SYS_ID_AA64DFR0_EL1);
> > > +
> > > +	return ((dfr0 >> ID_AA64DFR0_TRACEVER_SHIFT) & 0xfUL) > 0;
> > 
> > I would do:
> > 
> >          return ((dfr0 >> ID_AA64DFR0_TRACEVER_SHIFT) & 0xfUL) == 1;
> > 
> > Because any other value than '1' are reserved.
> 
> Correct. However, this is something we follow for all ID features
> in the arm64 kernel and is clarified in the Arm ARM (ARM DDI 0487F.a) :
> 
> "D13.1.3 Principles of the ID scheme for fields in ID registers"
> 
> Which guarantees that a (field  > n) implies, everything that field == n
> is implied. (Well there are exceptions listed in the section, but
> TRACEVER is not one of those). So this should cover an old kernel
> running on a future CPU, using the features that it understands.
> (See feature_matches() in arch/arm64/kernel/cpufeature.c, which is
> the fundamental logic to detect a feature).
> 

While I haven't found anything conclusive in cpufeature.c, the documentation is
clear on the fact that versions are incremental and build on top of previous
ones.  We can proceed with the current implementation. 

> Please let me know if you're OK with the justification.
> 
> Thanks for the review.
> 
> Suzuki