On 03/02/2022 10:40, James Clark wrote:
On 02/02/2022 17:05, Suzuki K Poulose wrote:
Hi James
Thanks for taking this tedious task of cleaning the code and making this robust and readable.
One minor comment below.
On 02/02/2022 16:02, James Clark wrote:
This is a no-op change for style and consistency and has no effect on the binary produced by gcc-11.
Signed-off-by: James Clark james.clark@arm.com
.../coresight/coresight-etm4x-core.c | 37 +++++-------------- drivers/hwtracing/coresight/coresight-etm4x.h | 17 +++++++++ drivers/hwtracing/coresight/coresight-priv.h | 1 + 3 files changed, 27 insertions(+), 28 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c index bf18128cf5de..8aefee4e72fd 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -1091,41 +1091,22 @@ static void etm4_init_arch_data(void *info) etmidr0 = etm4x_relaxed_read32(csa, TRCIDR0); /* INSTP0, bits[2:1] P0 tracing support field */ - if (BMVAL(etmidr0, 1, 1) && BMVAL(etmidr0, 2, 2)) - drvdata->instrp0 = true; - else - drvdata->instrp0 = false;
+ drvdata->instrp0 = !!((REG_VAL(etmidr0, TRCIDR0_INSTP0) & 0b01) && + (REG_VAL(etmidr0, TRCIDR0_INSTP0) & 0b10));
I don't understand this check. For ETMv4, here is what I find in the spec (ARM IHI 0064C)
P0 tracing support field. The permitted values are: 0b00 Tracing of load and store instructions as P0 elements is not supported. 0b11 Tracing of load and store instructions as P0 elements is supported, so TRCCONFIGR.INSTP0 is supported.
All other values are reserved.
So the check could simply be :
drvdata->instrp0 = (REG_VAL(emtidr0, TRCIDR0_INSTP0) == 0b11;
Yes I can make this change, but it does make the compiler emit a slightly different binary so we can't rely on that to check the refactor is ok.
Should I change it in this commit or stick it on the very end? Probably the end is best in case I have to do any rebases and I still need to validate there are no mistakes.
I would say, fix the existing check first and then convert to use the updated symbols.
That way we could queue the fix separately and you may be able to rebase your next version on the updated tree ?
Cheers Suzuki