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
next prev parent 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: linkBe 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.