[PATCH] [FYI] etnaviv: use ktime_t for timeouts

[Arnd Bergmann]

On Mon, Nov 6, 2017 at 4:07 PM, Russell King - ARM Linux
<linux at armlinux.org.uk> wrote:
> On Mon, Nov 06, 2017 at 03:44:40PM +0100, Arnd Bergmann wrote:
>> This is what I ended up with after Lucas' email this morning,
>> it should result in exactly the same behavior as Russell's patch
>> but also remove all traces of 'timespec' from the kernel.
>
> What if userspace passes in a zero timeout?  Your patch appears to
> make that non-blocking.  I'd rather keep the semantics different
> as they are today, and pass the drm_etnaviv_timeout into the
> functions rather than a ktime.

Sure, makes sense. I thought about it only briefly and thought it
good enough that passing a zero timestamp would result in
-ETIMEDOUT before the patch, and -EBUSY after the patch,
which is not exactly the same but unlikely to make a difference
in practice.

If we stick with your tested timespec64 based patch and also
change the intermediate interfaces to pass around timespec64
pointers rather than timespec pointers, that will work out
automatically to not change the behavior.

> Remember that the specs for the monotonic clock_gettime() allow
> systems to define an arbitary starting value.  That starting value
> could be a negative number, which would mean a timestamp of all
> zeros is a legal timestamp in the future.

I'm pretty sure that Linux defines monotonic times as starting at
boot time to avoid that kind of problem. We certainly have countless
other drivers that rely on that already.

The timekeeping code defines the seconds portion of
CLOCK_MONOTONIC as an 'unsigned long', and the comment in
ktime_get_seconds() explains that it is expected to never wrap
because of that.

      Arnd