All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <jdelvare@suse.de>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: <linux-i2c@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 06/12] i2c: taos-evm: convert to use i2c_new_client_device()
Date: Thu, 9 Jan 2020 09:42:28 +0100	[thread overview]
Message-ID: <20200109094228.2e058653@endymion> (raw)
In-Reply-To: <20200108115822.20871d77@endymion>

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@sang-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@suse.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@suse.de>

-- 
Jean Delvare
SUSE L3 Support

WARNING: multiple messages have this Message-ID (diff)
From: Jean Delvare <jdelvare@suse.de>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 06/12] i2c: taos-evm: convert to use i2c_new_client_device()
Date: Thu, 9 Jan 2020 09:42:28 +0100	[thread overview]
Message-ID: <20200109094228.2e058653@endymion> (raw)
In-Reply-To: <20200108115822.20871d77@endymion>

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@sang-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@suse.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@suse.de>

-- 
Jean Delvare
SUSE L3 Support

  reply	other threads:[~2020-01-09  9:57 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-07 17:47 [PATCH 00/12] i2c: convert subsystem to use i2c_new_client_device() Wolfram Sang
2020-01-07 17:47 ` Wolfram Sang
2020-01-07 17:47 ` Wolfram Sang
2020-01-07 17:47 ` [PATCH 01/12] i2c: cht-wc: convert " Wolfram Sang
2020-01-09 23:05   ` Hans de Goede
2020-01-07 17:47 ` [PATCH 02/12] i2c: i801: " Wolfram Sang
2020-01-09  8:54   ` Jean Delvare
2020-01-09  8:54     ` Jean Delvare
2020-01-07 17:47 ` [PATCH 03/12] i2c: nvidia-gpu: " Wolfram Sang
2020-01-07 17:47 ` [PATCH 04/12] i2c: ocores: " Wolfram Sang
2020-01-07 18:32   ` Peter Korsgaard
2020-01-07 19:31     ` Wolfram Sang
2020-01-07 19:58       ` Peter Korsgaard
2020-01-07 19:36     ` Andrew Lunn
2020-01-07 17:47 ` [PATCH 05/12] i2c: powermac: " Wolfram Sang
2020-01-07 17:47   ` Wolfram Sang
2020-01-07 17:47 ` [PATCH 06/12] i2c: taos-evm: " Wolfram Sang
2020-01-08 10:58   ` Jean Delvare
2020-01-08 10:58     ` Jean Delvare
2020-01-09  8:42     ` Jean Delvare [this message]
2020-01-09  8:42       ` Jean Delvare
2020-01-15 19:56       ` Wolfram Sang
2020-01-07 17:47 ` [PATCH 07/12] i2c: xiic: " Wolfram Sang
2020-01-07 17:47   ` Wolfram Sang
2020-01-08 11:39   ` Michal Simek
2020-01-08 11:39     ` Michal Simek
2020-01-08 11:39     ` Michal Simek
2020-01-07 17:47 ` [PATCH 08/12] i2c: i2c-core-acpi: " Wolfram Sang
2020-01-08 10:04   ` Mika Westerberg
2020-01-07 17:47 ` [PATCH 09/12] i2c: i2c-core-base: " Wolfram Sang
2020-01-07 17:47 ` [PATCH 10/12] i2c: i2c-core-of: " Wolfram Sang
2020-01-07 17:47 ` [PATCH 11/12] docs: i2c: use the new API in 'instantiating-devices.rst' Wolfram Sang
2020-01-07 17:47 ` [PATCH 12/12] docs: i2c: use the new API in 'writing-clients' Wolfram Sang
2020-01-15 19:57 ` [PATCH 00/12] i2c: convert subsystem to use i2c_new_client_device() Wolfram Sang
2020-01-15 19:57   ` Wolfram Sang
2020-01-15 19:57   ` Wolfram Sang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200109094228.2e058653@endymion \
    --to=jdelvare@suse.de \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wsa+renesas@sang-engineering.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.