linux-renesas-soc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-i2c@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	Luca Ceresoli <luca@lucaceresoli.net>,
	Kieran Bingham <kieran@ksquared.org.uk>,
	Jacopo Mondi <jacopo@jmondi.org>,
	Vladimir Zapolskiy <vz@mleia.com>
Subject: Re: [RFC PATCH 3/5] i2c: core: add function to request an alias
Date: Wed, 1 Jan 2020 18:55:15 +0200	[thread overview]
Message-ID: <20200101165515.GC6226@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20191231161400.1688-4-wsa+renesas@sang-engineering.com>

Hi Wolfram,

Thank you for the patch.

On Tue, Dec 31, 2019 at 05:13:58PM +0100, Wolfram Sang wrote:
> Some devices are able to reprogram their I2C address at runtime. This
> can prevent address collisions when one is able to activate and
> reprogram these devices one by one. For that to work, they need to be
> assigned an unused address. This new functions allows drivers to request
> for such an address. It assumes all non-occupied addresses are free. It
> will then send a message to such a free address to make sure there is
> really nothing listening there.
> 
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>  drivers/i2c/i2c-core-base.c | 22 ++++++++++++++++++++++
>  include/linux/i2c.h         |  2 ++
>  2 files changed, 24 insertions(+)
> 
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index 51bd953ddfb2..5a010e7e698f 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -2241,6 +2241,28 @@ static int i2c_detect(struct i2c_adapter *adapter, struct i2c_driver *driver)
>  	return err;
>  }
>  

Missing kerneldoc, but you already know about this.

> +struct i2c_client *i2c_new_alias_device(struct i2c_adapter *adap)
> +{
> +	struct i2c_client *alias = ERR_PTR(-EBUSY);
> +	int ret;
> +	u16 addr;
> +
> +	i2c_lock_bus(adap, I2C_LOCK_SEGMENT);
> +
> +	for (addr = 0x08; addr < 0x78; addr++) {
> +		ret = i2c_scan_for_client(adap, addr, i2c_unlocked_read_byte_probe);
> +		if (ret == -ENODEV) {
> +			alias = i2c_new_dummy_device(adap, addr);
> +			dev_dbg(&adap->dev, "Found alias: 0x%x\n", addr);
> +			break;
> +		}
> +	}

This looks quite inefficient, especially if the beginning of the range
is populated with devices. Furthermore, I think there's a high risk of
false negatives, as acquiring a free address and reprogramming the
client to make use of it are separate operations. Another call to
i2c_new_alias_device() could occur in-between. There's also the issue
that I2C hasn't been designed for scanning, so some devices may not
appreciate this.

What happened to the idea of reporting busy address ranges in the
firmware (DT, ACPI, ...) ?

> +
> +	i2c_unlock_bus(adap, I2C_LOCK_SEGMENT);
> +	return alias;
> +}
> +EXPORT_SYMBOL_GPL(i2c_new_alias_device);
> +
>  int i2c_probe_func_quick_read(struct i2c_adapter *adap, unsigned short addr)
>  {
>  	return i2c_smbus_xfer(adap, addr, 0, I2C_SMBUS_READ, 0,
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index f834687989f7..583ca2aec022 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -441,6 +441,8 @@ i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info);
>  struct i2c_client *
>  i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info const *info);
>  
> +struct i2c_client *i2c_new_alias_device(struct i2c_adapter *adap);
> +
>  /* If you don't know the exact address of an I2C device, use this variant
>   * instead, which can probe for device presence in a list of possible
>   * addresses. The "probe" callback function is optional. If it is provided,

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2020-01-01 16:55 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-31 16:13 [RFC PATCH 0/5] i2c: implement mechanism to retrieve an alias device Wolfram Sang
2019-12-31 16:13 ` [RFC PATCH 1/5] i2c: core: refactor scanning for a client Wolfram Sang
2020-01-01 16:45   ` Laurent Pinchart
2020-01-07  9:26   ` Kieran Bingham
2020-01-07  9:53     ` Geert Uytterhoeven
2020-01-07  9:58       ` Kieran Bingham
2020-01-07 10:25       ` Wolfram Sang
2020-01-07 10:36         ` Geert Uytterhoeven
2020-01-07 11:23           ` Wolfram Sang
2020-01-07 15:03             ` Luca Ceresoli
2020-01-07 16:45               ` Wolfram Sang
2020-01-07 16:52                 ` Kieran Bingham
2019-12-31 16:13 ` [RFC PATCH 2/5] i2c: core: add new variant to check " Wolfram Sang
2020-01-01 16:49   ` Laurent Pinchart
2020-01-07  9:42   ` Kieran Bingham
2019-12-31 16:13 ` [RFC PATCH 3/5] i2c: core: add function to request an alias Wolfram Sang
2020-01-01 16:55   ` Laurent Pinchart [this message]
2020-01-02 18:58     ` Luca Ceresoli
2020-01-02 21:13       ` Wolfram Sang
2020-01-02 22:27         ` Luca Ceresoli
2020-01-03  0:10           ` Laurent Pinchart
2020-01-07 15:03             ` Luca Ceresoli
2020-01-07 17:13               ` Laurent Pinchart
2020-01-08 13:27                 ` Wolfram Sang
2020-01-08 13:31                   ` Laurent Pinchart
2020-01-08 13:38                     ` Wolfram Sang
2020-01-08 13:22               ` Wolfram Sang
2020-01-08 13:19             ` Wolfram Sang
2020-01-08 13:29               ` Geert Uytterhoeven
2020-01-08 13:34               ` Laurent Pinchart
2020-01-02 21:03     ` Wolfram Sang
2020-01-21  9:05     ` Peter Rosin
2020-01-07  9:40   ` Kieran Bingham
2020-01-07 17:11     ` Laurent Pinchart
2020-01-07 17:14       ` Kieran Bingham
2020-01-08 13:35         ` Wolfram Sang
2020-01-08 13:36           ` Laurent Pinchart
2019-12-31 16:13 ` [RFC PATCH 4/5] i2c: core: add simple caching to the 'alias' scanning Wolfram Sang
2020-01-07  9:59   ` Kieran Bingham
2020-01-21  9:22   ` Peter Rosin
2019-12-31 16:14 ` [RFC PATCH 5/5] simple test case for the I2C alias functionality Wolfram Sang
2019-12-31 16:27 ` [RFC PATCH 0/5] i2c: implement mechanism to retrieve an alias device 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=20200101165515.GC6226@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=jacopo@jmondi.org \
    --cc=kieran@ksquared.org.uk \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=luca@lucaceresoli.net \
    --cc=vz@mleia.com \
    --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 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).