[PATCH] drm/etnaviv: correct timeout calculation

[Russell King - ARM Linux]

On Fri, Mar 09, 2018 at 12:52:40PM +0100, Lucas Stach wrote:
> Hi Russell,
> 
> Am Freitag, den 09.03.2018, 11:44 +0000 schrieb Russell King - ARM Linux:
> > Hi Lucas,
> > 
> > Please retain my authorship of my patch, which was sent on 23 Oct 2017.
> > The patch you have below is 100% identical to that which I sent.
> 
> I'll gladly do so if you provide me a proper Signed-off-by for this
> patch, which was missing from your 23 Oct 2017 submission.

It wasn't a submission, but was for discussion and I provided two
variants.

However, by doing what you've done, you're effectively claiming
authorship of my work, and as works are copyrighted, that's really
not nice.  Unfortunately, the Linux community has tied itself in
knots over the "author must sign-off on the patch" despite DCO (b)
existing, and DCO (b) specifically allows for patches that are not
authored by the submitter to be incorporated into the kernel.

If you take the authorship and the manufactured sign-off requirements
together, then effectively no one has the ability to submit code
that they did not author.

Nevertheless, for this patch,

Signed-off-by: Russell King <rmk+kernel at armlinux.org.uk>

> 
> > You should also point out, as per the follow-on discussion, that using
> > clock_gettime() on 32-bit systems will not work once the time it
> > reports wraps - so something like the comment I suggested in a follow
> > up patch:
> > 
> > + * Etnaviv timeouts are specified wrt CLOCK_MONOTONIC, not jiffies.
> > + * We need to calculate the timeout in terms of number of jiffies
> > + * between the specified timeout and the current CLOCK_MONOTONIC time.
> > + * Note: clock_gettime() is 32-bit on 32-bit arch.  Using 64-bit
> > + * timespec math here just means that when a wrap occurs, the
> > + * specified timeout goes into the past and we can't request a
> > + * timeout in the future: IOW, the code breaks.
> > 
> > would be sensible either in the commit message or the code.
> 
> I'll add it to the commit message, as I think the discussion with Arnd
> established that this is a very theoretical risk, not likely to be hit
> in practice.

True, it's only likely to be hit if a system is up for 68 years, but
it's still worth documenting.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up