Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp3834397pxy; Tue, 4 May 2021 10:57:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJym5Y1kSQeWLokZaXJ0X7ELWeFMFJk3w+mXlGVjnUhoyRJ4OOx7u0LRs0rfVSZVebJLLFsO X-Received: by 2002:a17:902:9307:b029:ea:e588:10a with SMTP id bc7-20020a1709029307b02900eae588010amr27436906plb.7.1620151051424; Tue, 04 May 2021 10:57:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620151051; cv=none; d=google.com; s=arc-20160816; b=rdQ31jzm8YS8kuTwJFSfiHthk7eHEI9jE3Zc29S3F9KW5qTvx8egSAtKvjQ0SlUpXz mWHMJDHUkeOa8A5rkojrK7QGM2YCAky6QR+JwZ8quua/6Q1Z7zRJRttHkabQirRws4Fs uiia1mjOKFYOYb7n8Vm2xuaUvkJzZd2wzAmwyQs0ZthEzCcj6cjQQXD8nYuaxQQi2HK9 TNtH8RgzSaoBhVIc7MtrKgYdq9lSgn6fz6m8X+SZVUkDeGODZC1hjauc3hr00tdjAkT0 PwfNJlzbScUPuvNDRgHDfM/xLSGh4eHO3T7sWJ32S7chK9bEt7LTe54Vk8ml/bLQYthW ehjQ== 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-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=oeFUFhQr/tjWO5NE83v6z1pOEQtnZuGs+sQEycy94tU=; b=USmiKHk2h0430RZwJcAb1u/3KxhkTBC43G02/Tp3d2SBcf/OZqD5o5V9DX5e65pffD reT72zWYP/Xnn7iiRPjKkkyPNzubjtFQwOGg1t3ix5gjwGXNsrlb2BnzxlDngiF2+J7N E/mIu9LPqD4bN94w20PUZFRHx7jyP0zbRCfi56bmx+T6kU9x7q3ypmA8boTTfU5MlhGq aETSuDMFmhsRT2ydnUwSorlHKZ5hB5qzn4kgIX4IvXqHaE0AU0AIGMJ5kSPAPnwADK3b ovBv6Hba1c53/tbyH2G4Aa0Yt2B9A0vEGzL0eZljgXcGO0ACBhnf9i0H4GgnQFoi+tA3 KRIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=QmKwdX9C; 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 l19si2385300pgb.434.2021.05.04.10.57.13; Tue, 04 May 2021 10:57:31 -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=QmKwdX9C; 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 S232037AbhEDR5g (ORCPT + 99 others); Tue, 4 May 2021 13:57:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:49760 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230285AbhEDR5e (ORCPT ); Tue, 4 May 2021 13:57:34 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7416F61076; Tue, 4 May 2021 17:56:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1620150997; bh=GEHj4bfA2qK0agu2/aTvuXZ4ztOXSkpgNUkIjTGXWgo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QmKwdX9CwO7xEZAkyD+O7KS465kxbRonWmYRid7adAVThMcZCeTBVe3CKFawBh7jm MNXOsAvYfqd2AjeE/iyHv7iQl8Yp+dt8uz7DBnOnQBeMht5mjmQWTmj1JKeg4Ozd88 3NLzAFWlVMqbAtKzE12tVQCFsa889KATgUlA14Yc= Date: Tue, 4 May 2021 19:56:35 +0200 From: Greg Kroah-Hartman To: Bryan Brattlof Cc: linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] staging: rtl8723bs: use generic kernel error codes Message-ID: References: <20210504174530.3kog7zq6tuk3wnlk@bryanbrattlof.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210504174530.3kog7zq6tuk3wnlk@bryanbrattlof.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 04, 2021 at 05:45:37PM +0000, Bryan Brattlof wrote: > Sorry for the spam Greg I dropped the mailing lists from the first > email. :( > > On Tue, May 04, 2021 at 06:17:15PM +0200, Greg Kroah-Hartman wrote: > >On Tue, May 04, 2021 at 04:07:48PM +0000, Bryan Brattlof wrote: > > > > >> @@ -139,12 +139,11 @@ static u32 sdio_init(struct dvobj_priv *dvobj) > >> psdio_data->tx_block_mode = 1; > >> psdio_data->rx_block_mode = 1; > >> > >> + return err; > >> + > >> release: > >> sdio_release_host(func); > >> - > >> - if (err) > >> - return _FAIL; > >> - return _SUCCESS; > >> + return err; > >> } > > > >You just changed the logic here, are you SURE that was ok to do? > > > > I can't say my brain didn't bleed a little trying to keep this straight > in my head while walking through this. (For what ever reason my brain > sees negative integers as False) ¯\_(ツ)_/¯ > > Both the sdio_enable_func() and sdio_set_block_size() will return a > negative integer if they fail, which we evaluate as True, allowing us to > jump to release, free the card and propagate the error backwards. > > If everything worked, we'll skip all the jumps until we get to the first > 'return err;' statement, returning our 0 for success. > > Inside sdio_dvobj_init() if we see 'anything below 0' (This probably > should be changed to 'anything True') we jump to free_dvobj where we > free the dvobj and return NULL > > If I've looked at this long enough I don't thing I changed the logic. > > Hopefully. :) So you need to document this really well, showing that the function whose error you changed, is being evaluated here now differently too. > >> static void sdio_deinit(struct dvobj_priv *dvobj) > >> @@ -186,7 +185,7 @@ static struct dvobj_priv *sdio_dvobj_init(struct sdio_func *func) > >> psdio = &dvobj->intf_data; > >> psdio->func = func; > >> > >> - if (sdio_init(dvobj) != _SUCCESS) > >> + if (sdio_init(dvobj) < 0) > >> goto free_dvobj; > >> > >> rtw_reset_continual_io_error(dvobj); > >> > >> base-commit: 9ccce092fc64d19504fa54de4fd659e279cc92e7 > >> -- > >> git-series 0.9.1 > >> > >> > > > >And that's all to remove the need for these crazy error values? If so, > >why not also remove the #defines for them as well? > > > > I might have over sold this patch. :) > > There are quite a few functions like this still here that need to be > converted before we can get rid of the _SUCCESS and _FAIL definitions. > > Would it be better if I bundled these up in a series? Do it one function "call-chain" at a time, and yes, a series would be great. thanks, greg k-h