From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751270AbaKUR5k (ORCPT ); Fri, 21 Nov 2014 12:57:40 -0500 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:21079 "EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750755AbaKUR5j (ORCPT ); Fri, 21 Nov 2014 12:57:39 -0500 X-IronPort-AV: E=Sophos;i="5.07,432,1413237600"; d="scan'208";a="89924497" Date: Fri, 21 Nov 2014 18:59:00 +0100 (CET) From: Julia Lawall X-X-Sender: jll@hadrien To: SF Markus Elfring cc: Julia Lawall , Greg Kroah-Hartman , Johan Hovold , linux-usb@vger.kernel.org, LKML , kernel-janitors@vger.kernel.org Subject: Re: USB: serial: Deletion of an unnecessary check before the function call "release_firmware" In-Reply-To: <546F5ED7.1000206@users.sourceforge.net> Message-ID: References: <5307CAA2.8060406@users.sourceforge.net> <530A086E.8010901@users.sourceforge.net> <530A72AA.3000601@users.sourceforge.net> <530B5FB6.6010207@users.sourceforge.net> <530C5E18.1020800@users.sourceforge.net> <530CD2C4.4050903@users.sourceforge.net> <530CF8FF.8080600@users.sourceforge.net> <530DD06F.4090703@users.sourceforge.net> <5317A59D.4@users.sourceforge.net> <546F5831.5060404@users.sourceforge.net> <546F5ED7.1000206@users.sourceforge.net> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 21 Nov 2014, SF Markus Elfring wrote: > >> diff --git a/drivers/usb/serial/mxuport.c b/drivers/usb/serial/mxuport.c > >> index ab1d690..3653ec1 100644 > >> --- a/drivers/usb/serial/mxuport.c > >> +++ b/drivers/usb/serial/mxuport.c > >> @@ -1101,8 +1101,7 @@ static int mxuport_probe(struct usb_serial *serial, > >> */ > >> usb_set_serial_data(serial, (void *)id->driver_info); > >> out: > >> - if (fw_p) > >> - release_firmware(fw_p); > >> + release_firmware(fw_p); > > > > I think that the if should stay. > > I have got an other opinion. > > > > There were two cases on the allocation, so there should be two cases > > on the release. > > I find that this implementation detail does not really matter for the > necessity of a null pointer check directly before such a function call. Conceptually, if it is clear 10 lines above that nothing was allocated, and there is a fallback to existing data (according to the comment above) it is strange to be releasing something. julia From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julia Lawall Date: Fri, 21 Nov 2014 17:59:00 +0000 Subject: Re: USB: serial: Deletion of an unnecessary check before the function call "release_firmware" Message-Id: List-Id: References: <5307CAA2.8060406@users.sourceforge.net> <530A086E.8010901@users.sourceforge.net> <530A72AA.3000601@users.sourceforge.net> <530B5FB6.6010207@users.sourceforge.net> <530C5E18.1020800@users.sourceforge.net> <530CD2C4.4050903@users.sourceforge.net> <530CF8FF.8080600@users.sourceforge.net> <530DD06F.4090703@users.sourceforge.net> <5317A59D.4@users.sourceforge.net> <546F5831.5060404@users.sourceforge.net> <546F5ED7.1000206@users.sourceforge.net> In-Reply-To: <546F5ED7.1000206@users.sourceforge.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: SF Markus Elfring Cc: Julia Lawall , Greg Kroah-Hartman , Johan Hovold , linux-usb@vger.kernel.org, LKML , kernel-janitors@vger.kernel.org On Fri, 21 Nov 2014, SF Markus Elfring wrote: > >> diff --git a/drivers/usb/serial/mxuport.c b/drivers/usb/serial/mxuport.c > >> index ab1d690..3653ec1 100644 > >> --- a/drivers/usb/serial/mxuport.c > >> +++ b/drivers/usb/serial/mxuport.c > >> @@ -1101,8 +1101,7 @@ static int mxuport_probe(struct usb_serial *serial, > >> */ > >> usb_set_serial_data(serial, (void *)id->driver_info); > >> out: > >> - if (fw_p) > >> - release_firmware(fw_p); > >> + release_firmware(fw_p); > > > > I think that the if should stay. > > I have got an other opinion. > > > > There were two cases on the allocation, so there should be two cases > > on the release. > > I find that this implementation detail does not really matter for the > necessity of a null pointer check directly before such a function call. Conceptually, if it is clear 10 lines above that nothing was allocated, and there is a fallback to existing data (according to the comment above) it is strange to be releasing something. julia