* Re: [PATCH] usb: gadget: uvc: fix returnvar.cocci warnings [not found] ` <20150917000130.GA25134@lkp-ib04> @ 2015-09-17 8:57 ` Julia Lawall 2015-09-17 11:18 ` Andrzej Pietrasiewicz 0 siblings, 1 reply; 8+ messages in thread From: Julia Lawall @ 2015-09-17 8:57 UTC (permalink / raw) To: Andrzej Pietrasiewicz Cc: kbuild-all, Felipe Balbi, Laurent Pinchart, Greg Kroah-Hartman, linux-usb, linux-kernel Coccinelle suggests the following patch. But the code is curious. Is the function expected to always return a failure value? thanks, julia On Thu, 17 Sep 2015, kbuild test robot wrote: > TO: Andrzej Pietrasiewicz <andrzej.p@samsung.com> > CC: kbuild-all@01.org > CC: Felipe Balbi <balbi@ti.com> > CC: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > CC: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org> > CC: linux-usb@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 <andrzej.p@samsung.com> > Signed-off-by: Fengguang Wu <fengguang.wu@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; > > } > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] usb: gadget: uvc: fix returnvar.cocci warnings 2015-09-17 8:57 ` [PATCH] usb: gadget: uvc: fix returnvar.cocci warnings Julia Lawall @ 2015-09-17 11:18 ` Andrzej Pietrasiewicz 2015-09-17 11:30 ` SF Markus Elfring 2016-11-22 17:27 ` Laurent Pinchart 0 siblings, 2 replies; 8+ messages in thread From: Andrzej Pietrasiewicz @ 2015-09-17 11:18 UTC (permalink / raw) To: Julia Lawall Cc: kbuild-all, Felipe Balbi, Laurent Pinchart, Greg Kroah-Hartman, linux-usb, linux-kernel 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 <andrzej.p@samsung.com> >> CC: kbuild-all@01.org >> CC: Felipe Balbi <balbi@ti.com> >> CC: Laurent Pinchart <laurent.pinchart@ideasonboard.com> >> CC: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org> >> CC: linux-usb@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 <andrzej.p@samsung.com> >> Signed-off-by: Fengguang Wu <fengguang.wu@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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] usb: gadget: uvc: fix returnvar.cocci warnings 2015-09-17 11:18 ` Andrzej Pietrasiewicz @ 2015-09-17 11:30 ` SF Markus Elfring 2016-11-22 17:27 ` Laurent Pinchart 1 sibling, 0 replies; 8+ messages in thread From: SF Markus Elfring @ 2015-09-17 11:30 UTC (permalink / raw) To: Andrzej Pietrasiewicz Cc: Julia Lawall, kbuild-all, Felipe Balbi, Laurent Pinchart, Greg Kroah-Hartman, linux-usb, linux-kernel > 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(). Should such an implementation detail be also reconsidered once more? Regards, Markus ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] usb: gadget: uvc: fix returnvar.cocci warnings 2015-09-17 11:18 ` Andrzej Pietrasiewicz 2015-09-17 11:30 ` SF Markus Elfring @ 2016-11-22 17:27 ` Laurent Pinchart 2016-11-23 8:35 ` Andrzej Pietrasiewicz 1 sibling, 1 reply; 8+ messages in thread From: Laurent Pinchart @ 2016-11-22 17:27 UTC (permalink / raw) To: Andrzej Pietrasiewicz Cc: Julia Lawall, kbuild-all, Felipe Balbi, Greg Kroah-Hartman, linux-usb, linux-kernel Hi Andrzej and Julia, Could one of you please submit a patch to fix this ? On Thursday 17 Sep 2015 13:18:04 Andrzej Pietrasiewicz wrote: > 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 <andrzej.p@samsung.com> > >> CC: kbuild-all@01.org > >> CC: Felipe Balbi <balbi@ti.com> > >> CC: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > >> CC: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org> > >> CC: linux-usb@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 <andrzej.p@samsung.com> > >> Signed-off-by: Fengguang Wu <fengguang.wu@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; -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] usb: gadget: uvc: fix returnvar.cocci warnings 2016-11-22 17:27 ` Laurent Pinchart @ 2016-11-23 8:35 ` Andrzej Pietrasiewicz 0 siblings, 0 replies; 8+ messages in thread From: Andrzej Pietrasiewicz @ 2016-11-23 8:35 UTC (permalink / raw) To: Laurent Pinchart Cc: Julia Lawall, kbuild-all, Felipe Balbi, Greg Kroah-Hartman, linux-usb, linux-kernel, target-devel, Joel Becker, linux-nvme, Christoph Hellwig, Nicholas A. Bellinger Hi Laurent, Thanks for a reminder. Please see inline. W dniu 22.11.2016 o 18:27, Laurent Pinchart pisze: > Hi Andrzej and Julia, > > Could one of you please submit a patch to fix this ? > > On Thursday 17 Sep 2015 13:18:04 Andrzej Pietrasiewicz wrote: >> 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? As a matter of fact it seems it should not return anything at all, because... >> >> Thank you for catching this. The function is not expected to always >> return a failure value. Fortunately it does not matter anyway because ...because >> the return value of the drop_link() operation is silently ignored by And the Documentation/filesystems/configfs/configfs.txt says here: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/configfs/configfs.txt#n397 "When unlink(2) is called on the symbolic link, the source item is notified via the ->drop_link() method. Like the ->drop_item() method, this is a void function and cannot return failure." The ->drop_item() is indeed a void function, the ->drop_link() is actually not. This, together with the fact that the value of ->drop_link() is silently ignored suggests, that it is the ->drop_link() return type that should be corrected and changed to void. @Joel: What is your opinion? Should return type be changed to void? Is there any reason why it should still be declared int? I'm sending a copy of this mail to target-devel and linux-nvme, because other potentially affected users of configfs live there. AP ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] usb: gadget: uvc: fix returnvar.cocci warnings @ 2016-11-23 8:35 ` Andrzej Pietrasiewicz 0 siblings, 0 replies; 8+ messages in thread From: Andrzej Pietrasiewicz @ 2016-11-23 8:35 UTC (permalink / raw) Hi Laurent, Thanks for a reminder. Please see inline. W dniu 22.11.2016 o 18:27, Laurent Pinchart pisze: > Hi Andrzej and Julia, > > Could one of you please submit a patch to fix this ? > > On Thursday 17 Sep 2015 13:18:04 Andrzej Pietrasiewicz wrote: >> 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? As a matter of fact it seems it should not return anything at all, because... >> >> Thank you for catching this. The function is not expected to always >> return a failure value. Fortunately it does not matter anyway because ...because >> the return value of the drop_link() operation is silently ignored by And the Documentation/filesystems/configfs/configfs.txt says here: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/configfs/configfs.txt#n397 "When unlink(2) is called on the symbolic link, the source item is notified via the ->drop_link() method. Like the ->drop_item() method, this is a void function and cannot return failure." The ->drop_item() is indeed a void function, the ->drop_link() is actually not. This, together with the fact that the value of ->drop_link() is silently ignored suggests, that it is the ->drop_link() return type that should be corrected and changed to void. @Joel: What is your opinion? Should return type be changed to void? Is there any reason why it should still be declared int? I'm sending a copy of this mail to target-devel and linux-nvme, because other potentially affected users of configfs live there. AP ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] usb: gadget: uvc: fix returnvar.cocci warnings 2016-11-23 8:35 ` Andrzej Pietrasiewicz @ 2016-11-28 8:28 ` Christoph Hellwig -1 siblings, 0 replies; 8+ messages in thread From: Christoph Hellwig @ 2016-11-28 8:28 UTC (permalink / raw) To: Andrzej Pietrasiewicz Cc: Laurent Pinchart, Julia Lawall, kbuild-all, Felipe Balbi, Greg Kroah-Hartman, linux-usb, linux-kernel, target-devel, Joel Becker, linux-nvme, Christoph Hellwig, Nicholas A. Bellinger On Wed, Nov 23, 2016 at 09:35:36AM +0100, Andrzej Pietrasiewicz wrote: > The ->drop_item() is indeed a void function, the ->drop_link() is > actually not. This, together with the fact that the value of ->drop_link() > is silently ignored suggests, that it is the ->drop_link() return > type that should be corrected and changed to void. Please send a patch to change it. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] usb: gadget: uvc: fix returnvar.cocci warnings @ 2016-11-28 8:28 ` Christoph Hellwig 0 siblings, 0 replies; 8+ messages in thread From: Christoph Hellwig @ 2016-11-28 8:28 UTC (permalink / raw) On Wed, Nov 23, 2016@09:35:36AM +0100, Andrzej Pietrasiewicz wrote: > The ->drop_item() is indeed a void function, the ->drop_link() is > actually not. This, together with the fact that the value of ->drop_link() > is silently ignored suggests, that it is the ->drop_link() return > type that should be corrected and changed to void. Please send a patch to change it. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-11-28 8:28 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <201509170828.xv0cYNA5%fengguang.wu@intel.com> [not found] ` <20150917000130.GA25134@lkp-ib04> 2015-09-17 8:57 ` [PATCH] usb: gadget: uvc: fix returnvar.cocci warnings Julia Lawall 2015-09-17 11:18 ` Andrzej Pietrasiewicz 2015-09-17 11:30 ` SF Markus Elfring 2016-11-22 17:27 ` Laurent Pinchart 2016-11-23 8:35 ` Andrzej Pietrasiewicz 2016-11-23 8:35 ` Andrzej Pietrasiewicz 2016-11-28 8:28 ` Christoph Hellwig 2016-11-28 8:28 ` Christoph Hellwig
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.