Received-SPF: pass (google.com: domain of linux-kernel+bounces-201260-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Tue, 4 Jun 2024 15:55:43 -0300
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Besar Wicaksono <bwicaksono@nvidia.com>, Will Deacon <will@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Ian Rogers <irogers@google.com>, Jiri Olsa <jolsa@kernel.org>,
	Kan Liang <kan.liang@linux.intel.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-perf-users@vger.kernel.org
Subject: Re: [RFC/PATCH 1/1] tools headers arm64: Sync arm64's cputype.h with
 the kernel sources
Message-ID: <Zl9jL1wCn3A5s8m3@x1>
References: <Zl4MYzhP0NB-Z1DW@x1>
 <Zl7aOk2h4_73JmUu@J2N7QTR9R3>
 <Zl8cYk0Tai2fs7aM@x1>
 <Zl8l_NdVEmcrsuSx@J2N7QTR9R3>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Zl8l_NdVEmcrsuSx@J2N7QTR9R3>

On Tue, Jun 04, 2024 at 03:34:36PM +0100, Mark Rutland wrote:
> On Tue, Jun 04, 2024 at 10:53:38AM -0300, Arnaldo Carvalho de Melo wrote:
> > On Tue, Jun 04, 2024 at 10:11:22AM +0100, Mark Rutland wrote:
> > > On Mon, Jun 03, 2024 at 03:33:07PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > The changes in the above patch add MIDR_NEOVERSE_V[23] and
> > > > MIDR_NEOVERSE_V1 is used in arm-spe.c, so probably we need to add those
> > > > and perhaps MIDR_CORTEX_X4 to that array? Or maybe we need to leave this
> > > > for later when this is all tested on those machines?
> > > 
> > > Hmm... looking at where that was added this is somewhat misnamed, this
> > > is really saying that these cores use the same IMPLEMENTATION DEFINED
> > > encoding of the source field. That's not really a property of Neoverse
> > > specifically, and I'm not sure what Arm's policy is here going forwards.
> > > 
> > > We should probably rename that to something like
> > > common_data_source_encoding, with a big comment about exactly what it
> > > implies.
> > > 
> > > I would not touch this for now -- someone would have to go audit the
> > 
> > Ok, you mean not touch tools/perf/util/arm-spe.c, right, can I just go
> > ahead and update the copy of that header so that we have a clean (of
> > build warnings) build?
> 
> Yes: update the header, but leave arm-spe.c unchanged. Sorry for not
> being clear!

np
 
> It'd be nice if we could update the commit message to note that we're
> deliberately leaving that as-is.

There is a link tag to this thread and I'll update the message removing
my questions and adding your recommendation.

> Either way:
> 
> Acked-by: Mark Rutland <mark.rutland@arm.com>

Thanks!

- Arnaldo