[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5474B564.9080902@roeck-us.net>
Date: Tue, 25 Nov 2014 08:59:16 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Bartosz Golaszewski <bgolaszewski@...libre.com>
CC: LKML <linux-kernel@...r.kernel.org>,
Benoit Cousson <bcousson@...libre.com>,
Patrick Titiano <ptitiano@...libre.com>
Subject: Re: [PATCH 1/5] hwmon: ina2xx: bail-out from ina2xx_probe() in case
of configuration errors
On 11/25/2014 08:25 AM, Bartosz Golaszewski wrote:
> 2014-11-25 16:58 GMT+01:00 Guenter Roeck <linux@...ck-us.net>:
>> You are introducing those two functions with the same code just to display
>> a different error message. That does not provide enough value to have extra
>> functions and just increases code size.
>>
>> Just check the return code from ina2xx_write_register directly in the probe
>> function and bail out there.
>
> With all six patches from this set applied, each of the two functions
> is called twice in the code. Together with the return value checks and
> repeated error messages it bloats the code even more. What about a
> single function taking the name of the register (in our case
> "configuration" or "calibration") as argument in order to print a nice
> error message? If this is still too dirty, than we can just print the
> hex value of the register.
>
> Bart
>
static int ina2xx_write_register(const struct i2c_client *client,
+ u8 reg, u16 value)
+{
+ return i2c_smbus_write_word_swapped(client, reg, value);
+}
Don't tell me that makes any sense. We don't introduce new functions
just to introduce new functions.
The new functions _might_ make a bit more sense if you would
implement the necessary calculations in the functions, but you are
not doing that. Instead, in the next patch, you introduce yet
another function to do the calibration calculation, just to add it
as parameter to the actual calibration function whenever you call it.
To me that is just adding unnecessary code, and I won't accept it.
The following applies to the entire series.
- I don't accept unnecessary ( ).
- I don't accept unnecessary typecasts.
- If you don't accept negative values, use kstrtoul().
- kstrtol can at least in theory return other errors besides -EINVAL.
- Locking should be done in the calling code. It is not needed during
probe and more appropriate in set functions.
- Any reason for selecting "rshunt" as sysfs attribute name instead
of, say, shunt-resistor or maybe shunt_resistor ?
- Returning -ENODEV from a set function doesn't make much sense.
- We don't overwrite error codes except in probe functions.
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists