Re: [PATCH v3 19/26] coresight: etm4x: Detect access early on the target CPU

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 19/26] coresight: etm4x: Detect access early on the target CPU
Date: Mon, 9 Nov 2020 10:48:47 -0700	[thread overview]
Message-ID: <20201109174847.GC3395222@xps15> (raw)
In-Reply-To: <f66695c0-e436-0d5c-2e12-5383159e72d6@arm.com>

On Mon, Nov 09, 2020 at 09:48:07AM +0000, Suzuki K Poulose wrote:
> On 11/6/20 8:34 PM, Mathieu Poirier wrote:
> > On Wed, Oct 28, 2020 at 10:09:38PM +0000, Suzuki K Poulose wrote:
> > > In preparation to detect the support for system instruction
> > > support, move the detection of the device access to the target
> > > CPU.
> > > 
> > > Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> > > ---
> > >   .../coresight/coresight-etm4x-core.c          | 45 ++++++++++++++++---
> > >   1 file changed, 40 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > > index f038bb10bc78..308674ab746c 100644
> > > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > > @@ -56,6 +56,11 @@ static u64 etm4_get_access_type(struct etmv4_config *config);
> > >   static enum cpuhp_state hp_online;
> > > +struct etm_init_arg {
> > 
> > s/etm_init_arg/etm4_init_arg
> 
> Part of the reason was to add a future IP support where it is not all
> ETM4. Again it doesn't really matter. I could change it.
>

I thought about that too but the inclusion of etmv4_drvdata cancels any attempts
at making things generic.

> > 
> > > +	struct etmv4_drvdata	*drvdata;
> > > +	struct csdev_access	*csa;
> > > +};
> > > +
> > >   u64 etm4x_sysreg_read(struct csdev_access *csa,
> > >   		      u32 offset,
> > >   		      bool _relaxed,
> > > @@ -669,6 +674,22 @@ static const struct coresight_ops etm4_cs_ops = {
> > >   	.source_ops	= &etm4_source_ops,
> > >   };
> > > +static bool etm_init_iomem_access(struct etmv4_drvdata *drvdata,
> > > +				  struct csdev_access *csa)
> > > +{
> > > +	*csa = CSDEV_ACCESS_IOMEM(drvdata->base);
> > > +	return true;
> > > +}
> > > +
> > > +static bool etm_init_csdev_access(struct etmv4_drvdata *drvdata,
> > > +				  struct csdev_access *csa)
> > > +{
> > > +	if (drvdata->base)
> > > +		return etm_init_iomem_access(drvdata, csa);
> > > +
> > > +	return false;
> > > +}
> > 
> > Returning a boolean rather than an int for the above two functions seems odd to
> > me.
> > 
> 
> We don't return an error from the caller of these functions. So, all we

And this is done from smp_call_function_single() where returning a meaningful
error value would mandate changes to struct etm_init_arg, which is needlessly
messy for this set.  Void my comment. 

> need to know is, if the operation was success or failure. Having bool
> makes it explicit for the checkings, rather than documenting the
> expected return values. Hence the choice. But I am open to changing them
> if you prefer it that way.
> 
> 
> 
> Cheers
> Suzuki