linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
> 

  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).