linux-kernel - Re: [PATCH v7 30/34] i2c: tegra: Clean up variable names

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <633d8e6e-d50c-a7cb-5cdf-f0547b94a86d@gmail.com>
Date:   Mon, 21 Sep 2020 18:18:59 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Thierry Reding <thierry.reding@...il.com>
Cc:     Jonathan Hunter <jonathanh@...dia.com>,
        Laxman Dewangan <ldewangan@...dia.com>,
        Wolfram Sang <wsa@...-dreams.de>,
        Michał Mirosław <mirq-linux@...e.qmqm.pl>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        linux-i2c@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 30/34] i2c: tegra: Clean up variable names

21.09.2020 14:40, Thierry Reding пишет:
> On Thu, Sep 17, 2020 at 06:43:28PM +0300, Dmitry Osipenko wrote:
>> 17.09.2020 15:21, Thierry Reding пишет:
>>> On Wed, Sep 09, 2020 at 01:40:02AM +0300, Dmitry Osipenko wrote:
>>>> Rename "ret" variables to "err" in order to make code a bit more
>>>> expressive, emphasizing that the returned value is an error code.
>>>> Same vice versa, where appropriate.
>>>>
>>>> Rename variable "reg" to "val" in order to better reflect the actual
>>>> usage of the variable in the code and to make naming consistent with
>>>> the rest of the code.
>>>>
>>>> Use briefer names for a few members of the tegra_i2c_dev structure in
>>>> order to improve readability of the code.
>>>>
>>>> All dev/&pdev->dev are replaced with i2c_dev->dev in order to have uniform
>>>> code style across the driver.
>>>>
>>>> Signed-off-by: Dmitry Osipenko <digetx@...il.com>
>>>> ---
>>>>  drivers/i2c/busses/i2c-tegra.c | 173 ++++++++++++++++-----------------
>>>>  1 file changed, 86 insertions(+), 87 deletions(-)
>>>
>>> That's indeed a nice improvement. One thing did spring out at me,
>>> though.
>>>
>>>> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
>>> [...]
>>>> @@ -1831,20 +1830,20 @@ static int __maybe_unused tegra_i2c_runtime_suspend(struct device *dev)
>>>>  
>>>>  	clk_bulk_disable(i2c_dev->nclocks, i2c_dev->clocks);
>>>>  
>>>> -	return pinctrl_pm_select_idle_state(i2c_dev->dev);
>>>> +	return pinctrl_pm_select_idle_state(dev);
>>>>  }
>>>>  
>>>>  static int __maybe_unused tegra_i2c_suspend(struct device *dev)
>>>>  {
>>>>  	struct tegra_i2c_dev *i2c_dev = dev_get_drvdata(dev);
>>>> -	int err = 0;
>>>> +	int ret = 0;
>>>>  
>>>>  	i2c_mark_adapter_suspended(&i2c_dev->adapter);
>>>>  
>>>>  	if (!pm_runtime_status_suspended(dev))
>>>> -		err = tegra_i2c_runtime_suspend(dev);
>>>> +		ret = tegra_i2c_runtime_suspend(dev);
>>>>  
>>>> -	return err;
>>>> +	return ret;
>>>>  }
>>>
>>> Isn't this exactly the opposite of what the commit message says (and the
>>> rest of the patch does)?
>>
>> This change makes it to be consistent with the rest of the code. You may
>> notice that "Factor out hardware initialization into separate function"
>> made a similar change.
>>
>> The reason I'm doing this is that the "err" suggests that code returns a
>> error failure code, while it could be a success too and you don't know
>> for sure by looking only at the part of code. Hence it's cleaner to use
>> "err" when error code is returned.
> 
> I don't follow that reasoning. Every error code obviously also has a
> value for success. Otherwise, what's the point of even having a function
> if all it can do is fail. Success has to be an option for code to be any
> useful at all, right?
> 
> The "err" variable here transports the error code and if that error code
> happens to be 0 (meaning success), why does that no longer qualify as an
> error code?

If you're naming variable as "err", then this implies to me that it will
contain a error code if error variable is returned directly. Error
shouldn't relate to a success. In practice nobody pays much attention to
variable naming, so usually there is a need to check what code actually
does anyways. I don't care much about this and just wanting to make a
minor improvement while at it.