On Tue, Nov 20, 2018 at 11:05:41AM +0000, Marc Zyngier wrote:

On 20/11/2018 08:56, Linus Walleij wrote:

quoted

On Tue, Nov 20, 2018 at 9:17 AM Marc Zyngier [off-list ref] wrote:

quoted

How does this change anything with the fact that the above code is
broken? 56 or 64 bit, you cannot read this counter with a single
access, or two. The canonical way of reading such a counter is
something like this:

        do {
                lo = readl_relaxed(LO);
                hi = readl_relaxed(HI);
        } while (hi != read_relaxed(HI));

To be fair, I have seen hardware that employ a logic latch
such that when a read access is done to the LO register,
the value of the whole counter is latched, also for the HI
register, so when you read the HI register in the second
step, it is never subject to wrapping. (Conversely reading
the HI before the LO will always give you insane values
:D)

I've seen such HW indeed, and I've also seen it being broken... ;-)

It this timer is built around such a (non-broken) logic, I'd really like
to see it spelled out. It will otherwise be a real pain to debug...

There is no information about HW latch in datasheet and vendor code. But the
vendor driver doesn't use any logic to prevent wrapping. However, this doesn't
mean that we can assume that the hardware is capable of preventing overrun.
So I guess it is best to go with Marc's suggestion here.

Thanks,
Mani

quoted

However the above code should be fine unless you know
for sure the hardware was constructed with a clever latch.

Let's find out!

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...