linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Leach <mike.leach@linaro.org>
To: James Clark <James.Clark@arm.com>
Cc: mathieu.poirier@linaro.org, coresight@lists.linaro.org,
	suzuki.poulose@arm.com, Leo Yan <leo.yan@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] coresight: Fix TRCCONFIGR.QE sysfs interface
Date: Fri, 21 Jan 2022 12:40:56 +0000	[thread overview]
Message-ID: <CAJ9a7VhA0YLaamjddvsmiiY-6fdzjobobtxj++Bphi1wt6EPsg@mail.gmail.com> (raw)
In-Reply-To: <139e5fb6-b917-163e-751c-1ef745852529@arm.com>

Hi James,

On Thu, 20 Jan 2022 at 11:37, James Clark <james.clark@arm.com> wrote:
>
>
>
> On 19/01/2022 15:22, Mike Leach wrote:
> > Hi James
> >
> > On Fri, 14 Jan 2022 at 17:33, James Clark <james.clark@arm.com> 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 doesn't go any further to validate if the user supplied value
> >> is valid, because none of the other parts this function do, but it does fix
> >> the case where it was impossible to ever set a valid value.
> >>
> >
> > I concur that the input is not checked as valid, However all the other
> > fields are single bit - with no invalid values - other than the cond
> > field, which controls tracing of non-branch conditionals -
> > architecturally unsupported for A profile in ETMv4/.
> >
> >
> >> Signed-off-by: James Clark <james.clark@arm.com>
> >> ---
> >>  drivers/hwtracing/coresight/coresight-etm4x-sysfs.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> >> index a0640fa5c55b..a99bb537ea23 100644
> >> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> >> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> >> @@ -368,7 +368,7 @@ static ssize_t mode_store(struct device *dev,
> >>         /* 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 ((mode & BIT(0)) && drvdata->q_support)
> >>                 config->cfg |= BIT(13);
> >
> > This can be trivially changed to
> >
> > if ((mode)  && drvdata->q_support)
> >          config->cfg |= BIT(13);
> >
> > to ensure that any input mode 2'b01, 2'b10, 2'b11 results in output
> > settings of 2'b01, 2'b11, 2'b11 respectively
> >
> > With that
> >
> > Reviewed-by: Mike Leach <mike.leach@linaro.org>
> >
>
> Thanks for the review. Can I also get your opinion about this one? At the very least
> I think the comment is not detailed enough, but I also think that case 0 should set
> BIT(0) rather than BIT(1). Or is there some edge case and it's correct?
>

Agreed - case 0 should be BIT(0)

However, now you mention it there is a corner case too...
On an ETM4.3 or later, if TRCIDR4.NUMRSPAIR == 0, then
drvdata->nr_event == 0 means zero events, otherwise drvdata->nr_event
== 0 means 1 event as implemented in the code below.

So a check on drvdata->nr_resource (which is the processed NUMRSPAIR
value wrt etm arch ) to skip setting eventctrl1 if this is 0 could be
added.

Regards

Mike

Mike
>
>         /* start by clearing all instruction event enable bits */
>         config->eventctrl1 &= ~(BIT(0) | BIT(1) | BIT(2) | BIT(3));
>         switch (drvdata->nr_event) {
>         case 0x0:
>                 /* generate Event element for event 1 */
>                 config->eventctrl1 |= val & BIT(1);
>                 break;
>         case 0x1:
>                 /* generate Event element for event 1 and 2 */
>                 config->eventctrl1 |= val & (BIT(0) | BIT(1));
>                 break;
>         case 0x2:
>                 /* generate Event element for event 1, 2 and 3 */
>                 config->eventctrl1 |= val & (BIT(0) | BIT(1) | BIT(2));
>                 break;
>         case 0x3:
>                 /* generate Event element for all 4 events */
>                 config->eventctrl1 |= val & 0xF;
>                 break;
>         default:
>                 break;
>         }
>
>
> >>         /*
> >>          * if supported, Q elements with and without instruction
> >> --
> >> 2.17.1
> >>
> >
> >



-- 
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK

      reply	other threads:[~2022-01-21 12:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-14 17:32 [PATCH 0/1] coresight: Fix TRCCONFIGR.QE sysfs interface James Clark
2022-01-14 17:32 ` [PATCH 1/1] " James Clark
2022-01-19 15:22   ` Mike Leach
2022-01-20 11:37     ` James Clark
2022-01-21 12:40       ` Mike Leach [this message]

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=CAJ9a7VhA0YLaamjddvsmiiY-6fdzjobobtxj++Bphi1wt6EPsg@mail.gmail.com \
    --to=mike.leach@linaro.org \
    --cc=James.Clark@arm.com \
    --cc=coresight@lists.linaro.org \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.poirier@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).