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]
Date:   Thu, 9 Jan 2020 09:42:28 +0100
From:   Jean Delvare <jdelvare@...e.de>
To:     Wolfram Sang <wsa+renesas@...g-engineering.com>
Cc:     <linux-i2c@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 06/12] i2c: taos-evm: convert to use
 i2c_new_client_device()

Hi again Wolfram,

On Wed, 8 Jan 2020 11:58:22 +0100, Jean Delvare wrote:
> On Tue, 7 Jan 2020 18:47:40 +0100, Wolfram Sang wrote:
> > Move away from the deprecated API and return the shiny new ERRPTR where
> > useful.
> > 
> > Signed-off-by: Wolfram Sang <wsa+renesas@...g-engineering.com>
> > ---
> > Build tested only.
> > 
> >  drivers/i2c/busses/i2c-taos-evm.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/i2c/busses/i2c-taos-evm.c b/drivers/i2c/busses/i2c-taos-evm.c
> > index 0bff3f3a8779..b4050f5b6746 100644
> > --- a/drivers/i2c/busses/i2c-taos-evm.c
> > +++ b/drivers/i2c/busses/i2c-taos-evm.c
> > @@ -49,10 +49,10 @@ static struct i2c_client *taos_instantiate_device(struct i2c_adapter *adapter)
> >  	if (!strncmp(adapter->name, "TAOS TSL2550 EVM", 16)) {
> >  		dev_info(&adapter->dev, "Instantiating device %s at 0x%02x\n",
> >  			tsl2550_info.type, tsl2550_info.addr);
> > -		return i2c_new_device(adapter, &tsl2550_info);
> > +		return i2c_new_client_device(adapter, &tsl2550_info);
> >  	}
> >  
> > -	return NULL;
> > +	return ERR_PTR(-ENODEV);
> >  }
> >  
> >  static int taos_smbus_xfer(struct i2c_adapter *adapter, u16 addr,  
> 
> Looks good to me, although ideally the caller should handle the error
> instead of ignoring it. But that's out of scope for this conversion
> patch, I'll look into submitting an update on top.

I take that back. taos_instantiate_device() is instantiating an
optional slave device on the bus. If that fails, the bus is still
usable, therefore failing the whole registration would be inappropriate.

Makes me wonder if return ERR_PTR(-ENODEV) is the right thing to do in
the fallback case. The i2c-taos-evm driver was designed to support
multiple TAOS evaluation module types, even though the only one fully
supported right now is the only one I own (TSL2550). The driver can
still be used with other modules, just no slave device will be
instantiated. It can still be done later from user-space.

In my opinion -ENODEV should only be used for "I expected a device but
could not find it". For the case where we simply don't know what slave
device to instantiate, NULL seems more appropriate, as it's not an
error.

What do you think? Either way I agree it doesn't make much practical
difference in the end as i2c_unregister_device() will deal gracefully
with both.

> So:
> 
> Reviewed-by: Jean Delvare <jdelvare@...e.de>
> 
> I'll also try to revive my evaluation module to give it some testing.

That I did, and it works fine, as expected :-)

Tested-by: Jean Delvare <jdelvare@...e.de>

-- 
Jean Delvare
SUSE L3 Support

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ