[PATCH] DRM: Armada: fixup wait_event_timeout being ignored

[PATCH] DRM: Armada: fixup wait_event_timeout being ignored

[Nicholas Mc Guire]

event API conformance testing with coccinelle spatches are being
used to locate API usage inconsistencies this triggert with:
./drivers/gpu/drm/armada/armada_overlay.c:153
        incorrect check for negative return

Return type of wait_event_timeout is signed long not int and the
return type is >=0 always thus the negative check was effectively
ignoring the timeout event - this looks like a bug.
An appropriately named variable of type long is inserted and the
call fixed up as well as the negative return check changed to detect
the timeout event.

Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
---

The calling side seems to assume 0 as success and <0 as error so 
returning -ETIME should be fine here.

Patch was compile tested with imx_v6_v7_defconfig + CONFIG_DRM_ARMADA=m

Patch is against 4.1-rc7 (localversion-next is -next-20150609)

 drivers/gpu/drm/armada/armada_overlay.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_overlay.c b/drivers/gpu/drm/armada/armada_overlay.c
index c5b06fd..f308949 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -107,7 +107,7 @@ armada_plane_update(struct drm_plane *plane, struct drm_crtc *crtc,
 	struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
 	uint32_t val, ctrl0;
 	unsigned idx = 0;
-	int ret;
+	long time_left;
 
 	crtc_w = armada_limit(crtc_x, crtc_w, dcrtc->crtc.mode.hdisplay);
 	crtc_h = armada_limit(crtc_y, crtc_h, dcrtc->crtc.mode.vdisplay);
@@ -150,11 +150,11 @@ armada_plane_update(struct drm_plane *plane, struct drm_crtc *crtc,
 			       dcrtc->base + LCD_SPU_SRAM_PARA1);
 	}
 
-	ret = wait_event_timeout(dplane->vbl.wait,
-				 list_empty(&dplane->vbl.update.node),
-				 HZ/25);
-	if (ret < 0)
-		return ret;
+	time_left = wait_event_timeout(dplane->vbl.wait,
+				       list_empty(&dplane->vbl.update.node),
+				       HZ / 25);
+	if (time_left == 0)
+		return -ETIME;
 
 	if (plane->fb != fb) {
 		struct armada_gem_object *obj = drm_fb_obj(fb);
-- 
1.7.10.4

Re: [PATCH] DRM: Armada: fixup wait_event_timeout being ignored

[Russell King - ARM Linux]

On Wed, Jun 10, 2015 at 01:07:08PM +0200, Nicholas Mc Guire wrote:
> The calling side seems to assume 0 as success and <0 as error so 
> returning -ETIME should be fine here.

The idea here is to allow the remainder of the code to execute when
the condition succeeds _or_ times out.  If it times out, that is
not a failure - it merely means that the display has been blanked
and we're not seeing frame done interrupts anymore.

The code should not be checking the returned value at all - in fact
I have updates to this code which (in part) remove this, and fix a
glaring problem that the wait queue is never woken.

I wonder how many places you've made this same mistake... please
ensure that you review the code you're changing carefully.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH] DRM: Armada: fixup wait_event_timeout being ignored

[Nicholas Mc Guire]

On Wed, 10 Jun 2015, Russell King - ARM Linux wrote:

> On Wed, Jun 10, 2015 at 01:07:08PM +0200, Nicholas Mc Guire wrote:
> > The calling side seems to assume 0 as success and <0 as error so 
> > returning -ETIME should be fine here.
> 
> The idea here is to allow the remainder of the code to execute when
> the condition succeeds _or_ times out.  If it times out, that is
> not a failure - it merely means that the display has been blanked
> and we're not seeing frame done interrupts anymore.
> 
> The code should not be checking the returned value at all - in fact
> I have updates to this code which (in part) remove this, and fix a
> glaring problem that the wait queue is never woken.
> 
> I wonder how many places you've made this same mistake... please
> ensure that you review the code you're changing carefully.
>

Sorry for that - I do try my best to understand the code - my obviously
wrong understanding of the code was that a negative return was being 
expected as being possible and then handed back to the caller so I 
assumed that would be the timeout case - but as this can never happen it 
was basically ignoring the timeout - that the execution should continue 
in the case of timeout being reached was not clear to me (it might be 
worth a comment ?)

I did find similar cases in other drivers 
./drivers/media/platform/s5p-tv/mixer_reg.c:364
        incorrect check for negative return
checking for < 0 and returning (so unreachable return statement with no 
effect but no side-effect in that condition ither) or 
./drivers/media/pci/ddbridge/ddbridge-core.c:89
        incorrect check for negative return
which checked for <= 0 and was fixed up to == 0 which is correct as the < 0
case simply is unreachable - so no change of error handling logic.

but those two other cases I think are correctly fixed up.

thx!
hofrat