Re: [PATCH 06/12] i2c: taos-evm: convert to use i2c_new_client_device()

[Jean Delvare]

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@xxxxxxxxxxxxxxxxxxxx>
> > ---
> > 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@xxxxxxx>
> 
> 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@xxxxxxx>

-- 
Jean Delvare
SUSE L3 Support