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;
Subject: Re: [PATCH 3/3] staging: r8188eu: Reorganize error handling in
 rtw_drv_init()
To:     "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Phillip Potter <phil@philpotter.co.uk>,
        Larry Finger <Larry.Finger@lwfinger.net>,
        Nick Desaulniers <ndesaulniers@google.com>,
        linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
        clang-built-linux@googlegroups.com
References: <20210812204027.338872-1-nathan@kernel.org>
 <20210812204027.338872-4-nathan@kernel.org>
 <1651213.ETx7SW4KbR@localhost.localdomain>
From:   Nathan Chancellor <nathan@kernel.org>
Message-ID: <24e15d45-40b8-b8a7-b633-9e538324a29b@kernel.org>
Date:   Thu, 12 Aug 2021 16:14:01 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <1651213.ETx7SW4KbR@localhost.localdomain>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 8/12/2021 4:11 PM, Fabio M. De Francesco wrote:
> On Thursday, August 12, 2021 10:40:27 PM CEST Nathan Chancellor wrote:
>> [...]
>> Looking at the error function as a whole, the error handling is odd
>> compared to the rest of the kernel, which prefers to set error codes on
>> goto paths, rather than a global "status" variable which determines the
>> error code at the end of the function and function calls in the case of
>> error.
>>
> "status" is not a global variable, instead it is a local variable with only
> in-function visibility and it has an automatic storage duration (i.e., it is
> allocated on the stack frame of the function and is destroyed when the stack
> is unwound at the return from the function).
> 
> According to the above definition there's no difference in storage classes
> between the old "status" and the new "ret" (the latter being a merely rename
> of the former). However, "ret" is a more appropriate name for that variable.
> Furthermore, your handling of errors and return value is more consistent with
> best practices.

Sorry, I meant "global" with regards to the function (as in "was there 
an error in the function"), rather than "global" as a storage class.

> Therefore, apart that minor misuse of the "global" class in your commit
> message, it's a nice work and so...

I am happy to redo the commit message if you and others so desire.

> Acked-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>

Thank you for the review and ack!

Cheers,
Nathan