On Fri, Nov 21, 2025 at 12:23:50AM +0000, Kuan-Wei Chiu wrote:
[...]
I noticed this issue while browsing the coresight code after attending a technical talk on the subject. This code dates back to the initial driver submission over 10 years ago, so I was surprised it hadn't been caught earlier. Although I cannot perform runtime testing, the logic error seems obvious to me, so I still decided to submit this patch.
I have a question for maintainers.
The ETMv4 architecture specification shows that ETMv4 was released as a non-confidential module in May 2013 (with the confidential release even a year earlier). So ETMv4 has been a public IP for more than 12+ years, and ETMv3 has been gradually retired since then.
This fix can still be applied to older kernels, but seems to me that now might be an appropriate time to consider removing the ETMv3 driver from the mainline kernel?
Thanks, Leo
On 26/11/2025 12:09 pm, Leo Yan wrote:
On Fri, Nov 21, 2025 at 12:23:50AM +0000, Kuan-Wei Chiu wrote:
[...]
I noticed this issue while browsing the coresight code after attending a technical talk on the subject. This code dates back to the initial driver submission over 10 years ago, so I was surprised it hadn't been caught earlier. Although I cannot perform runtime testing, the logic error seems obvious to me, so I still decided to submit this patch.
I have a question for maintainers.
The ETMv4 architecture specification shows that ETMv4 was released as a non-confidential module in May 2013 (with the confidential release even a year earlier). So ETMv4 has been a public IP for more than 12+ years, and ETMv3 has been gradually retired since then.
This fix can still be applied to older kernels, but seems to me that now might be an appropriate time to consider removing the ETMv3 driver from the mainline kernel?
Thanks, Leo
Yeah, if anyone is using it it would be on an old kernel surely?
On Wed, Nov 26, 2025 at 12:11:05PM +0000, James Clark wrote:
[...]
This fix can still be applied to older kernels, but seems to me that now might be an appropriate time to consider removing the ETMv3 driver from the mainline kernel?
Yeah, if anyone is using it it would be on an old kernel surely?
We can confirm this in another way: if I don't miss anything, over the past several years (since 2017), we have not received any questions or bug reports based on hands-on practice regarding ETMv3 on the Coresight or perf mailing lists.
Thanks, Leo
Hi,
On Wed, 26 Nov 2025 at 12:31, Leo Yan leo.yan@arm.com wrote:
On Wed, Nov 26, 2025 at 12:11:05PM +0000, James Clark wrote:
[...]
This fix can still be applied to older kernels, but seems to me that now might be an appropriate time to consider removing the ETMv3 driver from the mainline kernel?
Yeah, if anyone is using it it would be on an old kernel surely?
We can confirm this in another way: if I don't miss anything, over the past several years (since 2017), we have not received any questions or bug reports based on hands-on practice regarding ETMv3 on the Coresight or perf mailing lists.
Thanks, Leo
The key to this is not the questions we are asked, but which platforms are still supported by the linux kernel.
The ETMv3 driver supports both ETMv3 and PTM trace (the programming model is the same, even if the trace decode is vastly different).
So as long as there are platforms supported that use either of those, we need to keep the driver in.
Mike
On 26/11/2025 1:42 pm, Mike Leach wrote:
Hi,
On Wed, 26 Nov 2025 at 12:31, Leo Yan leo.yan@arm.com wrote:
On Wed, Nov 26, 2025 at 12:11:05PM +0000, James Clark wrote:
[...]
This fix can still be applied to older kernels, but seems to me that now might be an appropriate time to consider removing the ETMv3 driver from the mainline kernel?
Yeah, if anyone is using it it would be on an old kernel surely?
We can confirm this in another way: if I don't miss anything, over the past several years (since 2017), we have not received any questions or bug reports based on hands-on practice regarding ETMv3 on the Coresight or perf mailing lists.
Thanks, Leo
The key to this is not the questions we are asked, but which platforms are still supported by the linux kernel.
The ETMv3 driver supports both ETMv3 and PTM trace (the programming model is the same, even if the trace decode is vastly different).
So as long as there are platforms supported that use either of those, we need to keep the driver in.
Mike
We're not running tests though, so if we find out it's fundamentally broken somehow it could be another justification to remove it, even if the kernel supports the devices. Do you have a board that you can test on Mike?
Maintenance hasn't been zero cost either, even build testing for arm32 is annoying enough.
On Wed, 26 Nov 2025 at 15:33, James Clark james.clark@linaro.org wrote:
On 26/11/2025 1:42 pm, Mike Leach wrote:
Hi,
On Wed, 26 Nov 2025 at 12:31, Leo Yan leo.yan@arm.com wrote:
On Wed, Nov 26, 2025 at 12:11:05PM +0000, James Clark wrote:
[...]
This fix can still be applied to older kernels, but seems to me that now might be an appropriate time to consider removing the ETMv3 driver from the mainline kernel?
Yeah, if anyone is using it it would be on an old kernel surely?
We can confirm this in another way: if I don't miss anything, over the past several years (since 2017), we have not received any questions or bug reports based on hands-on practice regarding ETMv3 on the Coresight or perf mailing lists.
Thanks, Leo
The key to this is not the questions we are asked, but which platforms are still supported by the linux kernel.
The ETMv3 driver supports both ETMv3 and PTM trace (the programming model is the same, even if the trace decode is vastly different).
So as long as there are platforms supported that use either of those, we need to keep the driver in.
Mike
We're not running tests though, so if we find out it's fundamentally broken somehow it could be another justification to remove it, even if the kernel supports the devices. Do you have a board that you can test on Mike?
Don't have one myself, but I believe the TC2 was used in development, (that's the A15/A7 32 bit part - not total compute!) which somewhat conveniently had both etmv3 and ptm trace.
Maintenance hasn't been zero cost either, even build testing for arm32 is annoying enough.
Pretty much the seem for any of the arm32 drivers I guess.
Until arm32 kernels are no longer supported, not sure it is safe to drop the etm3 driver as we do not know who out there might be using it.
Mike
-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK
On Wed, Nov 26, 2025 at 04:14:19PM +0000, Mike Leach wrote:
[...]
The key to this is not the questions we are asked, but which platforms are still supported by the linux kernel.
The ETMv3 driver supports both ETMv3 and PTM trace (the programming model is the same, even if the trace decode is vastly different).
So as long as there are platforms supported that use either of those, we need to keep the driver in.
We're not running tests though, so if we find out it's fundamentally broken somehow it could be another justification to remove it, even if the kernel supports the devices. Do you have a board that you can test on Mike?
Don't have one myself, but I believe the TC2 was used in development, (that's the A15/A7 32 bit part - not total compute!) which somewhat conveniently had both etmv3 and ptm trace.
If ETMv4 can be used by Armv7 (arm32) CPUs, and nowdays if Armv7 + ETMv4 is a popular design, it makes sense for me to remove ETMv3 driver.
If Armv7 CPUs are always bound to ETMv3 / PTM, then we should keep the driver.
Thanks, Leo
On 27/11/2025 9:29 am, Leo Yan wrote:
On Wed, Nov 26, 2025 at 04:14:19PM +0000, Mike Leach wrote:
[...]
The key to this is not the questions we are asked, but which platforms are still supported by the linux kernel.
The ETMv3 driver supports both ETMv3 and PTM trace (the programming model is the same, even if the trace decode is vastly different).
So as long as there are platforms supported that use either of those, we need to keep the driver in.
We're not running tests though, so if we find out it's fundamentally broken somehow it could be another justification to remove it, even if the kernel supports the devices. Do you have a board that you can test on Mike?
Don't have one myself, but I believe the TC2 was used in development, (that's the A15/A7 32 bit part - not total compute!) which somewhat conveniently had both etmv3 and ptm trace.
If ETMv4 can be used by Armv7 (arm32) CPUs, and nowdays if Armv7 + ETMv4 is a popular design, it makes sense for me to remove ETMv3 driver.
If Armv7 CPUs are always bound to ETMv3 / PTM, then we should keep the driver.
Thanks, Leo
Based on the the build system I don't think what the hardware supports matters that much. We've always only built the ETM4 driver on Arm64 and only build the ETM3 driver on Arm32.
I just found another bug which I think makes sense to log here. We've pretty much always turned on timestamps automatically in Perf, but for some reason the option validator in Perf thinks they're not supported in ETM3. The driver has always accepted it as an option so I'm not sure why. The end result is that the command will always fail, and you couldn't even undo it with "timestamp=0" until more recently when I fixed that.
Sysfs or per-thread Perf mode would be working, but it's one more bit of evidence to take in.
Based on the the build system I don't think what the hardware supports matters that much. We've always only built the ETM4 driver on Arm64 and only build the ETM3 driver on Arm32.
ETMv3/PTM don't support Arm64, so a trace driver in an Arm64 kernel will only need to drive ETMv4 (or ETE). There's no need to build ETMv3/PTM in 64-bit kernels.
But a 32-bit kernel could be running on a CPU with ETMv4 - this could be a legacy 32-bit kernel on a 64-bit-capable CPU, but there are pure 32-bit CPUs with ETMv4: Cortex-A32 is a 32-bit-only Armv8-A CPU with ETMv4 and all kernels on this CPU will be 32-bit. If the 32-bit kernel only builds the ETMv3/PTM driver, then it won't support trace on this CPU.
Al
I just found another bug which I think makes sense to log here. We've pretty much always turned on timestamps automatically in Perf, but for some reason the option validator in Perf thinks they're not supported in ETM3. The driver has always accepted it as an option so I'm not sure why. The end result is that the command will always fail, and you couldn't even undo it with "timestamp=0" until more recently when I fixed that.
Sysfs or per-thread Perf mode would be working, but it's one more bit of evidence to take in.
CoreSight mailing list -- coresight@lists.linaro.org To unsubscribe send an email to coresight-leave@lists.linaro.org
-
Al Grant -
James Clark -
Leo Yan -
Mike Leach