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

Mathieu Poirier
2020-11-09T17:48:52Z

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