On 11/19/2021 7:47 PM, Marc Zyngier wrote:
On Fri, 19 Nov 2021 14:07:09 +0000,
Sai Prakash Ranjan <quic_saipraka@xxxxxxxxxxx> wrote:
On 11/19/2021 7:13 PM, Marc Zyngier wrote:
On Mon, 15 Nov 2021 11:33:29 +0000,
Sai Prakash Ranjan <quic_saipraka@xxxxxxxxxxx> wrote:
From: Prasad Sodagudi <psodagud@xxxxxxxxxxxxxx>
[...]
Reason why we wouldn't need value along with mmio write log is
that value can be easily deduced from the caller_name+offset which is
printed already by the rwmmio trace events which gives the exact
location of mmio writes and the value is easily known from the driver.
That's a very narrow view of what can be written in an MMIO
registers. We write dynamic values at all times, and if we are able to
trace MMIO writes, then the value written out must be part of the trace.
I'd rather you try and get to the bottom of this issue rather than
paper over it.
Thanks,
M.
Sure, idea was to put it out in the open if anyone has any idea as
to what might be happening there since the version where directly
instrumenting the raw read/write accessors in arm64/asm/io.h was
working fine casting doubts if this has to do something with
inlining as Arnd mentioned before.
Yup. I wouldn't be surprised if MMIO accessors were getting directly
inlined at the wrong location and creating havoc. For example:
writel(readl(addr1) | 1, addr2);
If you're not careful about capturing the result of the read rather
than the read itself, you can end-up with something really funky. No
idea if that's what is happening, but a disassembly of the generated
code could tell you.
M.
I did that initially (compare the disassembly in working and non-working
case) but didn't find
anything noticeable, maybe I need to look some more. Thanks for the
suggestion.
Thanks,
Sai
