From: "Songwei.Chai" <songwei.chai@oss.qualcomm.com>
To: sashiko-reviews@lists.linux.dev
Cc: devicetree@vger.kernel.org, conor+dt@kernel.org, robh@kernel.org
Subject: Re: [PATCH v16 6/7] qcom-tgu: Add timer/counter functionality for TGU
Date: Thu, 30 Jul 2026 16:46:11 +0800 [thread overview]
Message-ID: <bb8ce65f-755f-4f47-9f0e-5421d6856b76@oss.qualcomm.com> (raw)
In-Reply-To: <20260730081830.43D6F1F000E9@smtp.kernel.org>
On 7/30/2026 4:18 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Incorrect mapping of missing hardware timer and counter registers causes out-of-order register writes.
> --
>
> --- Patch [6]: [PATCH v16 6/7] qcom-tgu: Add timer/counter functionality for TGU ---
> commit db9df0865ab2140ab0eb7823166108ce956f637e
> Author: Songwei Chai <songwei.chai@oss.qualcomm.com>
>
> qcom-tgu: Add timer/counter functionality for TGU
>
> This commit adds timer and counter functionality for each step in the TGU
> driver. It determines the number of timers and counters by reading the DEVID2
> register, allocates necessary memory, and exposes sysfs attributes for user
> configuration.
>
>> diff --git a/drivers/hwtracing/qcom/tgu.c b/drivers/hwtracing/qcom/tgu.c
>> index 7f0a74514e40f..ea83273a628c5 100644
>> --- a/drivers/hwtracing/qcom/tgu.c
>> +++ b/drivers/hwtracing/qcom/tgu.c
> [ ... ]
>> @@ -236,6 +266,30 @@ static ssize_t tgu_write_all_hw_regs(struct tgu_drvdata *drvdata)
>> drvdata->base + CONDITION_SELECT_STEP(i, j));
>> }
>> }
>> +
>> + for (i = 0; i < drvdata->num_step; i++) {
>> + for (j = 0; j < drvdata->num_timer; j++) {
>> + index = check_array_location(drvdata, i, TGU_TIMER, j);
>> +
>> + if (index == -EINVAL)
>> + goto exit;
>> +
>> + writel(drvdata->value_table->timer[index],
>> + drvdata->base + TIMER_COMPARE_STEP(i, j));
> [Severity: High]
> Does this code handle sparse timers correctly? If the hardware implements a
> non-contiguous set of timers (e.g. TIMER1 is present but TIMER0 is absent),
> tgu_set_timer_counter() will set num_timers to 1.
>
> Since num_timers is 1, j will be 0 here. This writes to TIMER_COMPARE_STEP(i, 0)
> instead of TIMER_COMPARE_STEP(i, 1). Could writing to an unimplemented
> or unclocked register cause an asynchronous external abort?
Clarification:
All three comments point to the same underlying concern: that sparse
timer/counter allocation (e.g. TIMER1 present but TIMER0 absent) could
cause the count-based index to map to the wrong hardware register.
However, according to the hardware specification, timers and counters
are allocated contiguously — TIMER1 cannot be present without TIMER0.
The same applies to counters. Therefore the sparse case cannot occur,
and the count-based approach is correct.
>
>> + }
>> + }
>> +
>> + for (i = 0; i < drvdata->num_step; i++) {
>> + for (j = 0; j < drvdata->num_counter; j++) {
>> + index = check_array_location(drvdata, i, TGU_COUNTER, j);
>> +
>> + if (index == -EINVAL)
>> + goto exit;
>> +
>> + writel(drvdata->value_table->counter[index],
>> + drvdata->base + COUNTER_COMPARE_STEP(i, j));
> [Severity: High]
> Can the same issue happen for sparse counters, where we map to the wrong
> hardware register if COUNTER1 is present but COUNTER0 is absent?
>
>> + }
>> + }
>> /* Enable TGU to program the triggers */
>> writel(1, drvdata->base + TGU_CONTROL);
>> exit:
> [ ... ]
>> @@ -316,6 +370,27 @@ static void tgu_set_conditions(struct tgu_drvdata *drvdata)
>> drvdata->num_condition_select = TGU_MAX_CONDITION_SELECT;
>> }
>>
>> +static void tgu_set_timer_counter(struct tgu_drvdata *drvdata)
>> +{
>> + int num_timers = 0, num_counters = 0;
>> + u32 devid2;
>> +
>> + devid2 = readl(drvdata->base + CORESIGHT_DEVID2);
>> +
>> + if (TGU_DEVID2_TIMER0(devid2))
>> + num_timers++;
>> + if (TGU_DEVID2_TIMER1(devid2))
>> + num_timers++;
> [Severity: High]
> If TIMER0 is absent but TIMER1 is present, this collapses the presence bits
> into a single count of 1, losing the index mapping used when writing to the
> hardware registers above.
>
>> +
>> + if (TGU_DEVID2_COUNTER0(devid2))
>> + num_counters++;
>> + if (TGU_DEVID2_COUNTER1(devid2))
>> + num_counters++;
>> +
>> + drvdata->num_timer = num_timers;
>> + drvdata->num_counter = num_counters;
>> +}
next prev parent reply other threads:[~2026-07-30 8:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 8:06 [PATCH v16 0/7] Provide support for Trigger Generation Unit Songwei Chai
2026-07-30 8:06 ` [PATCH v16 1/7] dt-bindings: arm: Add support for Qualcomm TGU trace Songwei Chai
2026-07-30 8:15 ` sashiko-bot
2026-07-31 2:48 ` Songwei.Chai
2026-07-30 8:06 ` [PATCH v16 2/7] qcom-tgu: Add TGU driver Songwei Chai
2026-07-30 8:07 ` [PATCH v16 3/7] qcom-tgu: Add signal priority support Songwei Chai
2026-07-30 8:17 ` sashiko-bot
2026-07-30 10:07 ` Songwei.Chai
2026-07-30 8:07 ` [PATCH v16 4/7] qcom-tgu: Add TGU decode support Songwei Chai
2026-07-30 8:07 ` [PATCH v16 5/7] qcom-tgu: Add support to configure next action Songwei Chai
2026-07-30 8:07 ` [PATCH v16 6/7] qcom-tgu: Add timer/counter functionality for TGU Songwei Chai
2026-07-30 8:18 ` sashiko-bot
2026-07-30 8:46 ` Songwei.Chai [this message]
2026-07-30 8:07 ` [PATCH v16 7/7] qcom-tgu: Add reset node to initialize Songwei Chai
2026-08-06 5:30 ` [PATCH v16 0/7] Provide support for Trigger Generation Unit Songwei.Chai
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=bb8ce65f-755f-4f47-9f0e-5421d6856b76@oss.qualcomm.com \
--to=songwei.chai@oss.qualcomm.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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