regulator: tps65219: fix Wextra warning

From: Arnd Bergmann <arnd@arndb.de>

gcc warns about an invalid pointer comparison when building with
-Wextra enabled:

drivers/regulator/tps65219-regulator.c: In function 'tps65219_regulator_probe':
drivers/regulator/tps65219-regulator.c:370:26: error: ordered comparison of pointer with integer zero [-Werror=extra]
  370 |                 if (rdev < 0) {
      |                          ^

It appears that the intention here was to check for an error code, rather
than the pointer, so adapt the code to propagate the error from the
called function instead.

Fixes: c12ac5fc3e0a ("regulator: drivers: Add TI TPS65219 PMIC regulators support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/regulator/tps65219-regulator.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

On Fri, Dec 16, 2022, at 11:18, Arnd Bergmann wrote:
> On Thu, Dec 15, 2022, at 17:48, Mark Brown wrote:
>> On Thu, Dec 15, 2022 at 05:41:28PM +0100, Arnd Bergmann wrote:
>>
>>> -		tps65219_get_rdev_by_name(irq_type->regulator_name, rdevtbl, rdev);
>>> -		if (rdev < 0) {
>>> +		error = tps65219_get_rdev_by_name(irq_type->regulator_name, rdevtbl, rdev);
>>> +		if (error) {
>>>  			dev_err(tps->dev, "Failed to get rdev for %s\n",
>>>  				irq_type->regulator_name);
>>> -			return -EINVAL;
>>> +			return error;
>>
>> This will shut up the warning but is leaving the use of the
>> uninitialised rdev (which I'm kind of disappointed the static checkers
>> didn't pick up on).  rdev needs to be passed by reference into the
>> function, or set from the return value.
>
> Right, I didn't look far enough to see what the function is
> actually trying to do here, and that it completely fails to
> do that.
>
> I see that the bug was introduced between the first [1] and
> second []2] version of the driver, but don't see why. I'll
> leave it up to Jerome to address the problem, he's still
> in the middle of posting the rest of the series that has
> not yet been merged, so it makes sense for him to test it
> all together.
>
>     Arnd
>
> [1] https://lore.kernel.org/lkml/20220719091742.3221-9-jneanne@baylibre.com/
> [2] https://lore.kernel.org/lkml/20220726103355.17684-10-jneanne@baylibre.com/

It looks like you merged another workaround from Randy Dunlap now as
commit 2bbba115c3c9 ("regulator: tps65219: use IS_ERR() to detect an error
pointer"), but I think that one is just as wrong as the one I submitted:
the 'rdev' variable still remains uninitialized, and checking its value
after it has already been used is not helpful.

      Arnd

On Thu, Jan 19, 2023 at 09:07:38AM +0100, Arnd Bergmann wrote:

> It looks like you merged another workaround from Randy Dunlap now as
> commit 2bbba115c3c9 ("regulator: tps65219: use IS_ERR() to detect an error
> pointer"), but I think that one is just as wrong as the one I submitted:
> the 'rdev' variable still remains uninitialized, and checking its value
> after it has already been used is not helpful.

Right, that's just changing the way the result is parsed, it's
nothing to do with making sure things are initialised.  It's just
a coccinelle style thing.