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 <[email protected]>
---
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
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.
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