All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Rosin <peda@axentia.se>
To: Robert Shearman <robertshearman@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>
Cc: "linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Robert Shearman <robert.shearman@att.com>
Subject: Re: [PATCH 1/2] i2c: mux: pca954x: change the default to deselect after each transfer
Date: Tue, 22 Jan 2019 08:41:52 +0000	[thread overview]
Message-ID: <9b484cde-c20c-2078-9a55-eab27b56ef36@axentia.se> (raw)
In-Reply-To: <20190121164742.35718-1-robertshearman@gmail.com>

Hi Robert,

Thanks, for your patches.

On 2019-01-21 17:47, Robert Shearman wrote:
> From: Robert Shearman <robert.shearman@att.com>
> 
> The behaviour, by default, to not deselect after each transfer is
> not safe/correct when there is a device with an address that conflicts
> with another device either on the parent bus, or on another pca954x
> mux on the same parent bus.

Right. The current way might not be the safest, but the way I see it,
this ship has sailed a long time ago. It might take quite a while
before someone reports a regression, but when that happens and we
need to revisit or even revert this, things will get ugly.

Also, doubling or even tripling the I2C traffic (most I2C xfers
are small) for unsuspecting users with more normal I2C setups
(w/o multiple muxes) just to accommodate the more complexes cases
is arguably not the correct balance.

> Therefore, default to the least surprising mode, where the mux
> channels are deselected after each transaction, which is safe in the
> face of one or more devices hanging off the mux with addresses that
> conflict with other devices on different muxes, or on the parent

Side note, and not that it matters since it's a NACK anyway, but
having an address conflict with the parent bus is not allowed and is
just bad hardware design that simply cannot work reliably, if at all.

Cheers,
Peter

> bus. On systems where it is guaranteed that this is not the case, then
> the i2c-mux-no-idle-disconnect devicetree or no_deselect_on_exit
> platform data options can be used to improve the performance.
> 
> Signed-off-by: Robert Shearman <robert.shearman@att.com>
> ---
>  drivers/i2c/muxes/i2c-mux-pca954x.c   | 16 +++++++++-------
>  include/linux/platform_data/pca954x.h |  6 +++---
>  2 files changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c b/drivers/i2c/muxes/i2c-mux-pca954x.c
> index bfabf985e830..c2b6cff4ba3c 100644
> --- a/drivers/i2c/muxes/i2c-mux-pca954x.c
> +++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
> @@ -351,7 +351,7 @@ static int pca954x_probe(struct i2c_client *client,
>  	struct pca954x_platform_data *pdata = dev_get_platdata(&client->dev);
>  	struct device *dev = &client->dev;
>  	struct device_node *np = dev->of_node;
> -	bool idle_disconnect_dt;
> +	bool no_idle_disconnect_dt;
>  	struct gpio_desc *gpio;
>  	int num, force, class;
>  	struct i2c_mux_core *muxc;
> @@ -412,9 +412,10 @@ static int pca954x_probe(struct i2c_client *client,
>  	}
>  
>  	data->last_chan = 0;		   /* force the first selection */
> +	data->deselect = GENMASK(data->chip->nchans, 0);
>  
> -	idle_disconnect_dt = np &&
> -		of_property_read_bool(np, "i2c-mux-idle-disconnect");
> +	no_idle_disconnect_dt = np &&
> +		of_property_read_bool(np, "i2c-mux-no-idle-disconnect");
>  
>  	ret = pca954x_irq_setup(muxc);
>  	if (ret)
> @@ -422,7 +423,7 @@ static int pca954x_probe(struct i2c_client *client,
>  
>  	/* Now create an adapter for each channel */
>  	for (num = 0; num < data->chip->nchans; num++) {
> -		bool idle_disconnect_pd = false;
> +		bool no_idle_disconnect_pd = false;
>  
>  		force = 0;			  /* dynamic adap number */
>  		class = 0;			  /* no class by default */
> @@ -434,10 +435,11 @@ static int pca954x_probe(struct i2c_client *client,
>  			} else
>  				/* discard unconfigured channels */
>  				break;
> -			idle_disconnect_pd = pdata->modes[num].deselect_on_exit;
> +			no_idle_disconnect_pd =
> +				pdata->modes[num].no_deselect_on_exit;
>  		}
> -		data->deselect |= (idle_disconnect_pd ||
> -				   idle_disconnect_dt) << num;
> +		data->deselect &= ~((no_idle_disconnect_pd ||
> +				     no_idle_disconnect_dt) << num);
>  
>  		ret = i2c_mux_add_adapter(muxc, force, num, class);
>  		if (ret)
> diff --git a/include/linux/platform_data/pca954x.h b/include/linux/platform_data/pca954x.h
> index 1712677d5904..cb5359797867 100644
> --- a/include/linux/platform_data/pca954x.h
> +++ b/include/linux/platform_data/pca954x.h
> @@ -29,13 +29,13 @@
>  
>  /* Per channel initialisation data:
>   * @adap_id: bus number for the adapter. 0 = don't care
> - * @deselect_on_exit: set this entry to 1, if your H/W needs deselection
> - *                    of this channel after transaction.
> + * @no_deselect_on_exit: set this entry to 1, if your H/W doesn't need
> + *                       deselection of this channel after transaction.
>   *
>   */
>  struct pca954x_platform_mode {
>  	int		adap_id;
> -	unsigned int	deselect_on_exit:1;
> +	unsigned int	no_deselect_on_exit:1;
>  	unsigned int	class;
>  };
>  
> 


  parent reply	other threads:[~2019-01-22  8:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-21 16:47 [PATCH 1/2] i2c: mux: pca954x: change the default to deselect after each transfer Robert Shearman
2019-01-21 16:47 ` [PATCH 2/2] dt-bindings: i2c-mux-pca954x: Invert i2c-mux-idle-disconnect property Robert Shearman
2019-01-22  8:41 ` Peter Rosin [this message]
2019-01-22 10:17   ` [PATCH 1/2] i2c: mux: pca954x: change the default to deselect after each transfer Robert Shearman

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=9b484cde-c20c-2078-9a55-eab27b56ef36@axentia.se \
    --to=peda@axentia.se \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robert.shearman@att.com \
    --cc=robertshearman@gmail.com \
    --cc=robh+dt@kernel.org \
    /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.