All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: James Clark <james.clark@arm.com>
Cc: coresight@lists.linaro.org, mike.leach@linaro.org,
	suzuki.poulose@arm.com, leo.yan@linaro.com,
	Leo Yan <leo.yan@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/1] coresight: Fix TRCCONFIGR.QE sysfs interface
Date: Tue, 1 Feb 2022 10:00:23 -0700	[thread overview]
Message-ID: <20220201170023.GA2490199@p14s> (raw)
In-Reply-To: <20220120113047.2839622-2-james.clark@arm.com>

On Thu, Jan 20, 2022 at 11:30:47AM +0000, James Clark wrote:
> It's impossible to program a valid value for TRCCONFIGR.QE
> when TRCIDR0.QSUPP==0b10. In that case the following is true:
> 
>   Q element support is implemented, and only supports Q elements without
>   instruction counts. TRCCONFIGR.QE can only take the values 0b00 or 0b11.
> 
> Currently the low bit of QSUPP is checked to see if the low bit of QE can
> be written to, but as you can see when QSUPP==0b10 the low bit is cleared
> making it impossible to ever write the only valid value of 0b11 to QE.
> 0b10 would be written instead, which is a reserved QE value even for all
> values of QSUPP.
> 
> The fix is to allow writing the low bit of QE for any non zero value of
> QSUPP.
> 
> This change also ensures that the low bit is always set, even when the
> user attempts to only set the high bit.
> 
> Signed-off-by: James Clark <james.clark@arm.com>
> Reviewed-by: Mike Leach <mike.leach@linaro.org>
> ---
>  drivers/hwtracing/coresight/coresight-etm4x-sysfs.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> index a0640fa5c55b..57e94424a8d6 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> @@ -367,8 +367,12 @@ static ssize_t mode_store(struct device *dev,
>  	mode = ETM_MODE_QELEM(config->mode);
>  	/* start by clearing QE bits */
>  	config->cfg &= ~(BIT(13) | BIT(14));
> -	/* if supported, Q elements with instruction counts are enabled */
> -	if ((mode & BIT(0)) && (drvdata->q_support & BIT(0)))
> +	/*
> +	 * if supported, Q elements with instruction counts are enabled.
> +	 * Always set the low bit for any requested mode. Valid combos are
> +	 * 0b00, 0b01 and 0b11.
> +	 */
> +	if (mode && drvdata->q_support)
>  		config->cfg |= BIT(13);

Interesting brain gymnastic - applied.

Thanks,
Mathieu

>  	/*
>  	 * if supported, Q elements with and without instruction
> -- 
> 2.28.0
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: James Clark <james.clark@arm.com>
Cc: coresight@lists.linaro.org, mike.leach@linaro.org,
	suzuki.poulose@arm.com, leo.yan@linaro.com,
	Leo Yan <leo.yan@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/1] coresight: Fix TRCCONFIGR.QE sysfs interface
Date: Tue, 1 Feb 2022 10:00:23 -0700	[thread overview]
Message-ID: <20220201170023.GA2490199@p14s> (raw)
In-Reply-To: <20220120113047.2839622-2-james.clark@arm.com>

On Thu, Jan 20, 2022 at 11:30:47AM +0000, James Clark wrote:
> It's impossible to program a valid value for TRCCONFIGR.QE
> when TRCIDR0.QSUPP==0b10. In that case the following is true:
> 
>   Q element support is implemented, and only supports Q elements without
>   instruction counts. TRCCONFIGR.QE can only take the values 0b00 or 0b11.
> 
> Currently the low bit of QSUPP is checked to see if the low bit of QE can
> be written to, but as you can see when QSUPP==0b10 the low bit is cleared
> making it impossible to ever write the only valid value of 0b11 to QE.
> 0b10 would be written instead, which is a reserved QE value even for all
> values of QSUPP.
> 
> The fix is to allow writing the low bit of QE for any non zero value of
> QSUPP.
> 
> This change also ensures that the low bit is always set, even when the
> user attempts to only set the high bit.
> 
> Signed-off-by: James Clark <james.clark@arm.com>
> Reviewed-by: Mike Leach <mike.leach@linaro.org>
> ---
>  drivers/hwtracing/coresight/coresight-etm4x-sysfs.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> index a0640fa5c55b..57e94424a8d6 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> @@ -367,8 +367,12 @@ static ssize_t mode_store(struct device *dev,
>  	mode = ETM_MODE_QELEM(config->mode);
>  	/* start by clearing QE bits */
>  	config->cfg &= ~(BIT(13) | BIT(14));
> -	/* if supported, Q elements with instruction counts are enabled */
> -	if ((mode & BIT(0)) && (drvdata->q_support & BIT(0)))
> +	/*
> +	 * if supported, Q elements with instruction counts are enabled.
> +	 * Always set the low bit for any requested mode. Valid combos are
> +	 * 0b00, 0b01 and 0b11.
> +	 */
> +	if (mode && drvdata->q_support)
>  		config->cfg |= BIT(13);

Interesting brain gymnastic - applied.

Thanks,
Mathieu

>  	/*
>  	 * if supported, Q elements with and without instruction
> -- 
> 2.28.0
> 

  reply	other threads:[~2022-02-01 17:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-20 11:30 [PATCH v2 0/1] coresight: Fix TRCCONFIGR.QE sysfs interface James Clark
2022-01-20 11:30 ` James Clark
2022-01-20 11:30 ` [PATCH v2 1/1] " James Clark
2022-01-20 11:30   ` James Clark
2022-02-01 17:00   ` Mathieu Poirier [this message]
2022-02-01 17:00     ` Mathieu Poirier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220201170023.GA2490199@p14s \
    --to=mathieu.poirier@linaro.org \
    --cc=coresight@lists.linaro.org \
    --cc=james.clark@arm.com \
    --cc=leo.yan@linaro.com \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.leach@linaro.org \
    --cc=suzuki.poulose@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.