[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e1a2ee99-07bc-40f3-8742-a0cb1c273350@oss.qualcomm.com>
Date: Fri, 19 Sep 2025 09:20:55 +0800
From: Jie Gan <jie.gan@....qualcomm.com>
To: Carl Worth <carl@...amperecomputing.com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Mike Leach
<mike.leach@...aro.org>,
James Clark <james.clark@...aro.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Sabrina Dubroca <sd@...asysnail.net>
Cc: coresight@...ts.linaro.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] coresight: Fix data argument to coresight_enable_helpers
On 9/19/2025 6:18 AM, Carl Worth wrote:
> Jie Gan <jie.gan@....qualcomm.com> writes:
>> I dont think we can change back to sink_data since we introduced
>> coresight_path to wrap 'data' which is needed by the path.
>>
>> I suggest you to add the struct perf_output_handle to the
>> coresight_path, then retrieving it with data->perf_handle in
>> tmc_etr_get_buffer.
> ...
>> We can assign the perf_output_handle to the coresight_path after we
>> constructed the coresight_path in perf mode.
>
> Thanks. That much makes sense to me, and I'll put together a patch along
> those lines.
>
> But, further: with core coresight code assembling into the path all the
> data that is necessary, is there any reason to be using void* in these
> enable/disable functions?
In my opinion, yes, we can change void * to coresight_path * for
helper's enable/disable functions since we have everything in path so
the cast is not necessary now.
>
> Could we also change these functions to accept a coresight_path* and
> actually get some compiler help at finding mistakes like the one we're
> fixing here?
That's the only benefit in my mind so far.
Thanks,
Jie
>
> -Carl
Powered by blists - more mailing lists