Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2997018pxb; Mon, 1 Nov 2021 06:05:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyMRjZbR4CfgYKDUtELx9wgQHDdtr8e7bvk8BAe85JY+N5EdFEa6lYLM73emXU9nWyryJQb X-Received: by 2002:a17:906:dc93:: with SMTP id cs19mr15082531ejc.21.1635771908591; Mon, 01 Nov 2021 06:05:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635771908; cv=none; d=google.com; s=arc-20160816; b=J5r6AaMRPxFrlV1n5nWym7RZwQ5B+7I4sEtnJzjdu/grUuEnqvMS3vEbHAoIzEvX5g X4jsu0Xv5ayEjkhtdiWSfPppT4/Aj4SnSAeWYMtL7Z7FSUXywA5RrBj/HM6QGAbbz0zY k9MGu4bB/zC8bQatLhSZko5XYcjgQfsH+fyruARRbw3NHKNa1KpC1yXFRNIvfC8yd79B yddCPYQmNoSp9FhyYQ+tPanGzQxUG0kKDHLFJLKrGym2y82uV63lbWgE6pILEqxgw+Vq in4FsjEZ3iKtWP9f2qOJso2g2j45b/wT/BxaFE7pjovKZ5gZYv+hTouKDJEjVm0ca7Vi ZFGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=a9yENrZa/sQVHsTLyaB4HKO2z3Q34LoBFqx8QmgOv6I=; b=DZXfbLeE7XiTc3oUAWzdTx0O7yecX8W91N93jxozLEllPgj18Qrt/TkuDDvuWvxmHH yTqlmRDKQLttbnYEDrsRnIBoLA26SW0szUykXaoSgq1bD7ksEPhYkO17TKDoOxB55tmV zvg14C44CKm9Zv8GtisdOisXH7l5wXhMBh9gvI8ylsnuorZpKZRZHTf6DvzH15q3uxFu Za6DNEuRgZeFNiERtrVyYGuXaseybRQ0YmceZjMDPcv3dasFjkNHAsh0gjV/rc1c6fSs cDb0shXUaIzAVstq1K+KUFGUW9zsVX1k0jYmfgkZh/D5FBK8jvMCRa3vEC9NaTyGcy+M meBQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=kCAbVo1f; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id sg11si27354775ejc.279.2021.11.01.06.04.43; Mon, 01 Nov 2021 06:05:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=kCAbVo1f; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232527AbhKANEB (ORCPT + 99 others); Mon, 1 Nov 2021 09:04:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:41352 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231493AbhKANEB (ORCPT ); Mon, 1 Nov 2021 09:04:01 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 22ED6610CB; Mon, 1 Nov 2021 13:01:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1635771687; bh=BnvAlu2La+WcsQ9YbWNSwcRtBUFoQ6NF91J/WMIhk2w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kCAbVo1fhBICtG4Fxnkyt8PmWvLNDqCjDK53PhBY6myVuI7c+F5UzQm/vB5T3KPMi f/CxPaMsVwuIpFeuxQbRmrN3THACcxmuZAg7vObL8+ipDyOtIoVCJqJVsDifiPIBQr 75zqS/WMNXczB4MLtB4R9hLa1PHCZMpyOrxxeNto= Date: Mon, 1 Nov 2021 14:01:24 +0100 From: Greg KH To: Saurav Girepunje Cc: Larry.Finger@lwfinger.net, phil@philpotter.co.uk, straube.linux@gmail.com, martin@kaiser.cx, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org, saurav.girepunje@hotmail.com Subject: Re: [PATCH] staging: r8188eu: os_dep: remove the goto statement Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Oct 31, 2021 at 11:40:18PM +0530, Saurav Girepunje wrote: > Remove the goto statement from rtw_init_drv_sw(). In this function goto > can be replace by return statement. As on goto label exit, function > only return it is not performing any cleanup. Avoiding goto will > improve the function readability. > > Signed-off-by: Saurav Girepunje > --- > drivers/staging/r8188eu/os_dep/os_intfs.c | 39 +++++++---------------- > 1 file changed, 12 insertions(+), 27 deletions(-) > > diff --git a/drivers/staging/r8188eu/os_dep/os_intfs.c b/drivers/staging/r8188eu/os_dep/os_intfs.c > index 1418c9c4916c..4b409479108e 100644 > --- a/drivers/staging/r8188eu/os_dep/os_intfs.c > +++ b/drivers/staging/r8188eu/os_dep/os_intfs.c > @@ -480,48 +480,34 @@ u8 rtw_init_drv_sw(struct adapter *padapter) > { > u8 ret8 = _SUCCESS; > > - if ((rtw_init_cmd_priv(&padapter->cmdpriv)) == _FAIL) { > - ret8 = _FAIL; > - goto exit; > - } > + if (!rtw_init_cmd_priv(&padapter->cmdpriv)) > + return _FAIL; > > padapter->cmdpriv.padapter = padapter; > > - if ((rtw_init_evt_priv(&padapter->evtpriv)) == _FAIL) { > - ret8 = _FAIL; > - goto exit; > - } > - > - if (rtw_init_mlme_priv(padapter) == _FAIL) { > - ret8 = _FAIL; > - goto exit; > - } > + if (!rtw_init_evt_priv(&padapter->evtpriv) || !rtw_init_mlme_priv(padapter)) > + return _FAIL; These are functions that are being called so keeping them separate as the code you removed did makes it "obvious" what is happening here. So can you keep it that way please? But my larger question is do these functions create state or allocate memory that needs to be unwound properly if an error does happen? Right now the function seems to not be doing that at all, but that does not mean it is correct as-is... thanks, greg k-h