Hi Julia,

W dniu 17.09.2015 o 10:57, Julia Lawall pisze:
Coccinelle suggests the following patch.  But the code is curious.  Is the
function expected to always return a failure value?


Thank you for catching this. The function is not expected to always
return a failure value. Fortunately it does not matter anyway because
the return value of the drop_link() operation is silently ignored by
its caller in fs/configfs/symlink.c, functions configfs_symlink()
and configfs_unlink(). For my comments see inline.

thanks,
julia

On Thu, 17 Sep 2015, kbuild test robot wrote:

TO: Andrzej Pietrasiewicz <andrze...@samsung.com>
CC: kbuild-...@01.org
CC: Felipe Balbi <ba...@ti.com>
CC: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
CC: "Greg Kroah-Hartman" <gre...@linuxfoundation.org>
CC: linux-...@vger.kernel.org
CC: linux-kernel@vger.kernel.org

drivers/usb/gadget/function/uvc_configfs.c:866:5-8: Unneeded variable: "ret". Return 
"- EINVAL" on line 891


  Remove unneeded variable used to store return value.

Generated by: scripts/coccinelle/misc/returnvar.cocci

CC: Andrzej Pietrasiewicz <andrze...@samsung.com>
Signed-off-by: Fengguang Wu <fengguang...@intel.com>
---

Please take the patch only if it's a positive warning. Thanks!

  uvc_configfs.c |    3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -863,7 +863,6 @@ static int uvcg_streaming_header_drop_li
        struct uvcg_streaming_header *src_hdr;
        struct uvcg_format *target_fmt = NULL;
        struct uvcg_format_ptr *format_ptr, *tmp;
-       int ret = -EINVAL;

        src_hdr = to_uvcg_streaming_header(src);
        mutex_lock(su_mutex); /* for navigating configfs hierarchy */
@@ -888,7 +887,7 @@ static int uvcg_streaming_header_drop_li
  out:
        mutex_unlock(&opts->lock);
        mutex_unlock(su_mutex);
-       return ret;
+       return -EINVAL;

return 0;


Thanks,

AP
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to