From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933848AbcKWIhY (ORCPT ); Wed, 23 Nov 2016 03:37:24 -0500 Received: from mailout1.w1.samsung.com ([210.118.77.11]:24679 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933283AbcKWIfm (ORCPT ); Wed, 23 Nov 2016 03:35:42 -0500 X-AuditID: cbfec7f1-f79f46d0000008eb-cb-583554da5118 Subject: Re: [PATCH] usb: gadget: uvc: fix returnvar.cocci warnings To: Laurent Pinchart Cc: Julia Lawall , kbuild-all@01.org, Felipe Balbi , Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, target-devel , Joel Becker , linux-nvme@lists.infradead.org, Christoph Hellwig , "Nicholas A. Bellinger" From: Andrzej Pietrasiewicz Message-id: <3504c280-fe7f-9ec2-0f92-2b6aea290080@samsung.com> Date: Wed, 23 Nov 2016 09:35:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-version: 1.0 In-reply-to: <2122146.rzc0RNY0pB@avalon> Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02SaUhUURTHue/N8pycfI2mJ02FITOCrMypl5UkRr6gDyJGgwQ26XO03Jjn TuCUjo2ClU41aZlLariENopL7pIbipgKaZROkguWpRlZhpLOm8Bvv8P53XPu/3IJXNLBtyfC o2IZVZQiQioQ8ep7/gwdeh8gkx9pXfKkOqdSqNTn1QKqvLIbo/qHfvGoMuMAonreZeNURnaJ kBp9/VRAFZTNCKniMg1OpVcOIkpTuoidtaSnWoX0zFt/+ok2l09PNbzB6Pb8KiHdWnedri1J oZsn1AK6d7wBo1cMTn6iQNHpECYiPJ5RHfa6Kgob7tbjMQZxYvuzO5garYgyEUEA6QGPK+SZ yGITbWF4slqQiUSEhCxFkPtxDXHFCoLZnIc8zvIA3USNkGuUITAWrGNcMY+g/8eccMuyJn2g Iquav8U2JAVZxXrTKJzMwOFnWqVJEpDHoLVTi7ZYTHqB7l6jiXmkC3zKVpt4NymHzleVZmcX /NZNmq5hQR6AFt2CaQ5OeoOxuInPsTPUVi3iW8uAnBaC8cUynwvqCIYOnItwDtq03Wa2hoXe OiHHeyFD24lxZ/UIih7cMg9qRjCoz8c46xQYxhcwbttOyKnX49wCMWjTJZxCw1J5rVn3htLp LvNDriEoXM3k30fOedsC5W0LkbctRCHCK5ANE8dGKhnW3Y1VRLJxUUq34OhIA9r8VwMbvcuN 6HufZxciCSS1FJMBHnIJXxHPJkV2ISBwqY3Yzl8ml4hDFEnJjCo6SBUXwbBdyIHgSe3ELYVj lyWkUhHL3GCYGEb1v4sRFvZqlFjkyX5LONkXVjXhcqVtwzVhjQrZt+GS6isuCfLT+MuaomP3 yNwlAXj2CSuZfWhh/Bffa5q0uXW5U9pn9djfxBHj+ZwLOzQ2oeFnZl19jldf7Pk6vz/YKq/l bqnupjb5doito23opNL/UTTfNviSpfLlh9GpnMAatKobiRnrdfCQ8tgwxdGDuIpV/AN5nutU UwMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsVy+t/xK7pPQ0wjDLZNMrI4eL/eonnxejaL lauPMlmcPPeNxWLZg9OMFseuT2S26Jy4hN3i8q45bBbzlz1lt1i0rJXZom31GUaL1qVvmRx4 PO7vZfd4ejHIY3bHTFaP+9uPMHnsn7uG3WPvliyPzUvqPXbfbGDzOH5jO5PH501yAVxRbjYZ qYkpqUUKqXnJ+SmZeem2SqEhbroWSgp5ibmptkoRur4hQUoKZYk5pUCekQEacHAOcA9W0rdL cMu4cHQ6c8Em3or989qZGhg/c3UxcnJICJhITL65gR3CFpO4cG89WxcjF4eQwBJGieZp15gh nBeMEg13Z4BVCQs4S6zqXc8KYosIWEj0LprOCFH0i1HiQPs1MIdZoJNZYunKB2BVbALGEnsP djCC2LwCdhKT+3eA2SwCqhIPJzaA2aICERKbvs5hgagRlPgx+R6YzSmgIbFn8iuwzcwCthIL 3q9jgbDlJTavecs8gVFgFpKWWUjKZiEpW8DIvIpRJLW0ODc9t9hQrzgxt7g0L10vOT93EyMw drcd+7l5B+OljcGHGAU4GJV4eDPCTCKEWBPLiitzDzFKcDArifCKB5lGCPGmJFZWpRblxxeV 5qQWH2I0BXpiIrOUaHI+MK3klcQbmhiaWxoaGVtYmBsZKYnzlny4Ei4kkJ5YkpqdmlqQWgTT x8TBKdXAaCUY2PFn/Tz+yUES6g51840ZZE69WBq/XmrqIv3ZaxvSxJcY5U37mHFeTXlBuFzg t2VNR0RMxBTeK127GP987sbfTx/ETpZInnuQ95XP/eK1zmav/V8ZB31yM8rT8Tm0KS/9joJb 1+mee8a3GQ6urjnPa+DTzOFmFJyYOXnqBu+vS/TDxcsWK7EUZyQaajEXFScCAN5qXrTzAgAA X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20161123083538eucas1p133b3d08ead981905bfa3a0b963e6ac64 X-Msg-Generator: CA X-Sender-IP: 182.198.249.179 X-Local-Sender: =?UTF-8?B?QW5kcnplaiBQaWV0cmFzaWV3aWN6G1NSUE9MLVNlY3VyZSBP?= =?UTF-8?B?UyAoVFApG+yCvOyEseyghOyekBtTZW5pb3IgU29mdHdhcmUgRW5naW5lZXI=?= X-Global-Sender: =?UTF-8?B?QW5kcnplaiBUb21hc3ogUGlldHJhc2lld2ljehtTUlBPTC1T?= =?UTF-8?B?ZWN1cmUgT1MgKFRQKRtTYW1zdW5nIEVsZWN0cm9uaWNzG1NlbmlvciBTb2Z0?= =?UTF-8?B?d2FyZSBFbmdpbmVlcg==?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDAyQ0QwMjczOTQ=?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20161122172658epcas4p43c58fc9861747068b50cc7af9337f692 X-RootMTR: 20161122172658epcas4p43c58fc9861747068b50cc7af9337f692 References: <201509170828.xv0cYNA5%fengguang.wu@intel.com> <55FAA16C.5070601@samsung.com> <2122146.rzc0RNY0pB@avalon> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: andrzej.p@samsung.com (Andrzej Pietrasiewicz) Date: Wed, 23 Nov 2016 09:35:36 +0100 Subject: [PATCH] usb: gadget: uvc: fix returnvar.cocci warnings In-Reply-To: <2122146.rzc0RNY0pB@avalon> References: <201509170828.xv0cYNA5%fengguang.wu@intel.com> <55FAA16C.5070601@samsung.com> <2122146.rzc0RNY0pB@avalon> Message-ID: <3504c280-fe7f-9ec2-0f92-2b6aea290080@samsung.com> 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