From: Heiner Kallweit <hkallweit1@gmail.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Wolfram Sang <wsa@the-dreams.de>, Peter Rosin <peda@axentia.se>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH resubmit 1/2] i2c: core: add device-managed version of i2c_new_dummy
Date: Wed, 6 Dec 2017 20:05:58 +0100 [thread overview]
Message-ID: <56f41f75-2589-e185-5076-1d062e5625c2@gmail.com> (raw)
In-Reply-To: <CAMRc=McxO1AZy_bNyuzof2=s8zuzjJ=TO-rxvdKSNhT8R_aNgQ@mail.gmail.com>
Am 06.12.2017 um 11:36 schrieb Bartosz Golaszewski:
> 2017-12-05 20:44 GMT+01:00 Heiner Kallweit <hkallweit1@gmail.com>:
>> i2c_new_dummy is typically called from the probe function of the
>> driver for the primary i2c client. It requires calls to
>> i2c_unregister_device in the error path of the probe function and
>> in the remove function.
>> This can be simplified by introducing a device-managed version.
>>
>> Note the changed error case return value type:
>> i2c_new_dummy returns NULL whilst devm_new_i2c_dummy returns an ERR_PTR.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> Reviewed-by: Peter Rosin <peda@axentia.se>
>> ---
>> Documentation/driver-model/devres.txt | 3 +++
>> drivers/i2c/i2c-core-base.c | 39 +++++++++++++++++++++++++++++++++++
>> include/linux/i2c.h | 3 +++
>> 3 files changed, 45 insertions(+)
>>
>> diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
>> index c180045eb..6e2bccf85 100644
>> --- a/Documentation/driver-model/devres.txt
>> +++ b/Documentation/driver-model/devres.txt
>> @@ -259,6 +259,9 @@ GPIO
>> devm_gpio_request_one()
>> devm_gpio_free()
>>
>> +I2C
>> + devm_i2c_new_dummy
>> +
>> IIO
>> devm_iio_device_alloc()
>> devm_iio_device_free()
>> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
>> index bf52cca87..c1db67f9a 100644
>> --- a/drivers/i2c/i2c-core-base.c
>> +++ b/drivers/i2c/i2c-core-base.c
>> @@ -820,6 +820,45 @@ struct i2c_client *i2c_new_dummy(struct i2c_adapter *adapter, u16 address)
>> }
>> EXPORT_SYMBOL_GPL(i2c_new_dummy);
>>
>> +static void devm_i2c_release_dummy(struct device *dev, void *res)
>> +{
>> + i2c_unregister_device(*(struct i2c_client **)res);
>> +}
>> +
>
> Wolfram will have the last word here, but I would really prefer that
> you wrap struct i2c_client in a separate devres (e.g. struct
> i2c_dummy_devres) structure and avoid the cast. I find it a lot more
> readable even if it only has a single member.
>
This cast is a very common pattern in such release callbacks, see e.g.
devm_spi_unregister.
>> +/**
>> + * devm_i2c_new_dummy - return a new i2c device bound to a dummy driver
>> + * @dev: device the managed resource is bound to
>> + * @adapter: the adapter managing the device
>> + * @address: seven bit address to be used
>> + * Context: can sleep
>> + *
>> + * This is the device-managed version of i2c_new_dummy.
>> + * Note the changed return value type: It returns the new i2c client
>> + * or an ERR_PTR in case of an error.
>> + */
>> +struct i2c_client *devm_i2c_new_dummy(struct device *dev,
>> + struct i2c_adapter *adapter,
>> + u16 address)
>> +{
>> + struct i2c_client *ret, **dr;
>> +
>> + dr = devres_alloc(devm_i2c_release_dummy, sizeof(*dr), GFP_KERNEL);
>> + if (!dr)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + ret = i2c_new_dummy(adapter, address);
>> + if (!ret) {
>> + devres_free(dr);
>> + return ERR_PTR(-EBUSY);
>
> This is misleading as EBUSY is not necessarily the error that cased
> i2c_new_device() to fail. Return NULL here and document that users
> need to use IS_ERR_OR_NULL() to check for errors.
>
Indeed returning a fixed error code -EBUSY may not be the best choice.
I have another alternative in mind:
i2c_new_device brings everything to return a detailed error code.
I think of splitting this function into a main function returning
a detailed error code and a compatibility wrapper which returns NULL
in error case, thus keeping the API stable.
I will submit a proposal.
>> + }
>> +
>> + *dr = ret;
>> + devres_add(dev, dr);
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(devm_i2c_new_dummy);
>> +
>> /**
>> * i2c_new_secondary_device - Helper to get the instantiated secondary address
>> * and create the associated device
>> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
>> index a556db976..c27eac1e1 100644
>> --- a/include/linux/i2c.h
>> +++ b/include/linux/i2c.h
>> @@ -383,6 +383,9 @@ extern int i2c_probe_func_quick_read(struct i2c_adapter *, unsigned short addr);
>> extern struct i2c_client *
>> i2c_new_dummy(struct i2c_adapter *adap, u16 address);
>>
>> +extern struct i2c_client *
>> +devm_i2c_new_dummy(struct device *dev, struct i2c_adapter *adap, u16 address);
>> +
>> extern struct i2c_client *
>> i2c_new_secondary_device(struct i2c_client *client,
>> const char *name,
>> --
>> 2.15.1
>>
>>
>
> Thanks,
> Bartosz
>
next prev parent reply other threads:[~2017-12-06 19:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-05 19:40 [PATCH 0/2] i2c: introduce devm_i2c_new_dummy and use it in at24 driver Heiner Kallweit
2017-12-05 19:44 ` [PATCH resubmit 1/2] i2c: core: add device-managed version of i2c_new_dummy Heiner Kallweit
2017-12-06 10:36 ` Bartosz Golaszewski
2017-12-06 19:05 ` Heiner Kallweit [this message]
2017-12-05 19:45 ` [PATCH resubmit 2/2] eeprom: at24: switch to " Heiner Kallweit
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=56f41f75-2589-e185-5076-1d062e5625c2@gmail.com \
--to=hkallweit1@gmail.com \
--cc=brgl@bgdev.pl \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peda@axentia.se \
--cc=wsa@the-dreams.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).