| Message ID | 1433934428-21980-1-git-send-email-hofrat@osadl.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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
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);
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(-)