On Thu, Mar 06, 2025 at 04:39:27PM +0800, Yuanfang Zhang wrote:
[...]
> >> +static ssize_t flush_req_store(struct device *dev,
> >> + struct device_attribute *attr,
> >> + const char *buf,
> >> + size_t size)
> >> +{
...
> >> + reg = readl_relaxed(drvdata->base + TRACE_NOC_CTRL);
> >> + reg = reg | TRACE_NOC_CTRL_FLUSHREQ;
> >> + writel_relaxed(reg, drvdata->base + TRACE_NOC_CTRL);
> >
> > How can userspace determine when to trigger a flush?
> It can be triggered under any circumstances.
> >
> > Generally, a driver kicks off a flush operation for a hardware before
> > reading data from buffer or when disable a link path. I don't know the
> > hardware mechanism of TNOC, but seems to me, it does not make sense to
> > let the userspace to trigger a hardware flush, given the userspace has
> > no knowledge for device's state.
>
> TNOC supports the aforementioned flush operation, and it also adds this
> flush functionality, allowing users to set the flush themselves.
I am still not convinced for providing knobs to allow userspace to
directly control hardware.
A low level driver should have sufficient information to know when and
how it triggers a flush. E.g., CoreSight ETF (coresight-tmc-etf.c) can
act as a link, in this case, it calls the tmc_flush_and_stop() function
to flush its buffer when it is stopped. A flushing is triggered when a
session is terminated (either is a perf session or a Sysfs session).
Why not TNOC driver do the flushing same as other drivers? It can flush
the data before a hardware link is to be disabled. I don't think flush
operations are required at any time.
Seems to me, exposing APIs to userspace for flushing operations also
will introduce potential security risk. A malicious software might
attack system with triggering tons of flushing in short time.
> > Furthermore, based on my understanding for patch 02 and 03, the working
> > flow is also concerned me. IIUC, you want to use the driver to create
> > a linkage and then use userspace program to poll state and trigger
> > flushing. Could you explain why use this way for managing the device?
> >
> TNOC support flush just like other links. This interface simply provides
> customers with an additional option to trigger the flush.
This is not true for Arm CoreSight components. My understanding is Arm
CoreSight drivers never provides an API to userspace to manually trigger
flush operations.
Thanks,
Leo
On Mon, 10 Mar 2025 18:27:24 +0800, Jie Gan wrote:
> The coresight_etm_get_trace_id function is a global function. The
> verification process for 'csdev' is required prior to its usage.
>
>
Applied, thanks!
[1/1] coresight: add verification process for coresight_etm_get_trace_id
https://git.kernel.org/coresight/c/ab37128a
Best regards,
--
Suzuki K Poulose <suzuki.poulose(a)arm.com>
On Thu, 06 Mar 2025 12:11:01 +0000, Yeoreum Yun wrote:
> In some coresight drivers, drvdata->spinlock can be held during __schedule()
> by perf_event_task_sched_out()/in().
>
> Since drvdata->spinlock type is spinlock_t and
> perf_event_task_sched_out()/in() is called after acquiring rq_lock,
> which is raw_spinlock_t (an unsleepable lock),
> this poses an issue in PREEMPT_RT kernel where spinlock_t is sleepable.
>
> [...]
Applied, thanks!
[1/9] coresight: change coresight_device lock type to raw_spinlock_t
https://git.kernel.org/coresight/c/26f060c1
[2/9] coresight-etm4x: change etmv4_drvdata spinlock type to raw_spinlock_t
https://git.kernel.org/coresight/c/743c5a97
[3/9] coresight: change coresight_trace_id_map's lock type to raw_spinlock_t
https://git.kernel.org/coresight/c/4cf364ca
[4/9] coresight-cti: change cti_drvdata spinlock's type to raw_spinlock_t
https://git.kernel.org/coresight/c/e3044065
[5/9] coresight-etb10: change etb_drvdata spinlock's type to raw_spinlock_t
https://git.kernel.org/coresight/c/6b80c0ab
[6/9] coresight-funnel: change funnel_drvdata spinlock's type to raw_spinlock_t
https://git.kernel.org/coresight/c/56eb02f0
[7/9] coresight-replicator: change replicator_drvdata spinlock's type to raw_spinlock_t
https://git.kernel.org/coresight/c/982d0a0e
[8/9] coresight-tmc: change tmc_drvdata spinlock's type to raw_spinlock_t
https://git.kernel.org/coresight/c/db11f75b
[9/9] coresight/ultrasoc: change smb_drv_data spinlock's type to raw_spinlock_t
https://git.kernel.org/coresight/c/d11eb31d
Best regards,
--
Suzuki K Poulose <suzuki.poulose(a)arm.com>
On Thu, Mar 06, 2025 at 04:22:20PM +0800, Yuanfang Zhang wrote:
[...]
> >> +static int trace_noc_init_default_data(struct trace_noc_drvdata *drvdata)
> >> +{
> >> + int atid;
> >> +
> >> + atid = coresight_trace_id_get_system_id();
> >> + if (atid < 0)
> >> + return atid;
> >> +
> >> + drvdata->atid = atid;
> >> +
> >> + drvdata->freq_type = FREQ_TS;
> >
> > I don't see anywhere uses FREQ. Please remove the unused definitions
> > and related code.
>
> it is used in trace_noc_enable_hw().
I understood some macros and definitions are used by seqential patches.
A good practice is code should be added only when they are used. This
can allow every patch in neat way and easier for review.
Thanks,
Leo
> >
> >> + drvdata->flag_type = FLAG;
> >
> > FLAG_TS is not used in the driver as well. Remove it.
> it is used in trace_noc_enable_hw().
On 10/03/2025 02:23, Jie Gan wrote:
> The coresight_etm_get_trace_id function is a global function. The
> verification process for 'csdev' is required prior to its usage.
>
> Fixes: c367a89dec26 ("Coresight: Add trace_id function to retrieving the trace ID")
> Signed-off-by: Jie Gan <quic_jiegan(a)quicinc.com>
> ---
> drivers/hwtracing/coresight/coresight-core.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
> index bd0a7edd38c9..5a7cd2376e2d 100644
> --- a/drivers/hwtracing/coresight/coresight-core.c
> +++ b/drivers/hwtracing/coresight/coresight-core.c
> @@ -1616,9 +1616,12 @@ EXPORT_SYMBOL_GPL(coresight_remove_driver);
> int coresight_etm_get_trace_id(struct coresight_device *csdev, enum cs_mode mode,
> struct coresight_device *sink)
> {
> - int trace_id;
> - int cpu = source_ops(csdev)->cpu_id(csdev);
> + int cpu, trace_id;
> +
> + if (csdev->type != CORESIGHT_DEV_TYPE_SOURCE && !source_ops(csdev)->cpu_id)
That must be :
csdev->type != CORESIGHT_DEV_TYPE_SOURCE || !source_ops(csdev)->cpu_id)
Suzuki
> + return -EINVAL;
>
> + cpu = source_ops(csdev)->cpu_id(csdev);
> switch (mode) {
> case CS_MODE_SYSFS:
> trace_id = coresight_trace_id_get_cpu_id(cpu);