All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Eddie James <eajames@linux.ibm.com>
Cc: linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, peda@axentia.se
Subject: Re: [PATCH v2 2/2] i2c: mux: pca954x: Support multiple devices on a single reset line
Date: Mon, 2 Aug 2021 14:46:02 -0600	[thread overview]
Message-ID: <YQhZimPDbNJk5nbR@robh.at.kernel.org> (raw)
In-Reply-To: <20210727160315.15575-3-eajames@linux.ibm.com>

On Tue, Jul 27, 2021 at 11:03:15AM -0500, Eddie James wrote:
> Some systems connect several PCA954x devices to a single reset GPIO. For
> these devices to get out of reset and probe successfully, each device must
> defer the probe until the GPIO has been hogged. Accomplish this by
> attempting to grab a new "reset-shared-hogged" devicetree property, but
> expect it to fail with EPROBE_DEFER or EBUSY.
> 
> Signed-off-by: Eddie James <eajames@linux.ibm.com>
> ---
>  drivers/i2c/muxes/i2c-mux-pca954x.c | 46 +++++++++++++++++++++++------
>  1 file changed, 37 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c b/drivers/i2c/muxes/i2c-mux-pca954x.c
> index 4ad665757dd8..376b54ffb590 100644
> --- a/drivers/i2c/muxes/i2c-mux-pca954x.c
> +++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
> @@ -434,15 +434,43 @@ static int pca954x_probe(struct i2c_client *client,
>  	i2c_set_clientdata(client, muxc);
>  	data->client = client;
>  
> -	/* Reset the mux if a reset GPIO is specified. */
> -	gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> -	if (IS_ERR(gpio))
> -		return PTR_ERR(gpio);
> -	if (gpio) {
> -		udelay(1);
> -		gpiod_set_value_cansleep(gpio, 0);
> -		/* Give the chip some time to recover. */
> -		udelay(1);
> +	/*
> +	 * Grab the shared, hogged gpio that controls the mux reset. We expect
> +	 * this to fail with either EPROBE_DEFER or EBUSY. The only purpose of
> +	 * trying to get it is to make sure the gpio controller has probed up
> +	 * and hogged the line to take the mux out of reset, meaning that the
> +	 * mux is ready to be probed up. Don't try and set the line any way; in
> +	 * the event we actually successfully get the line (if it wasn't
> +	 * hogged) then we immediately release it, since there is no way to
> +	 * sync up the line between muxes.
> +	 */
> +	gpio = gpiod_get_optional(dev, "reset-shared-hogged", 0);
> +	if (IS_ERR(gpio)) {
> +		ret = PTR_ERR(gpio);
> +		if (ret != -EBUSY)
> +			return ret;

Why can't you just do this with the existing 'reset-gpios' property? 
What's the usecase where you'd want to fail probe because EBUSY other 
than an error in your DT.

> +	} else {
> +		if (gpio) {
> +			/* This is really a problem since now we don't know the
> +			 * state of the gpio. Log a warning and keep trying to
> +			 * probe the mux just in case it works.
> +			 */
> +			dev_warn(dev, "got hogged reset line, expect error\n");
> +			gpiod_put(gpio);
> +		} else {
> +			/* Reset the mux if a reset GPIO is specified. */
> +			gpio = devm_gpiod_get_optional(dev, "reset",
> +						       GPIOD_OUT_HIGH);
> +			if (IS_ERR(gpio))
> +				return PTR_ERR(gpio);
> +
> +			if (gpio) {
> +				udelay(1);
> +				gpiod_set_value_cansleep(gpio, 0);
> +				/* Give the chip some time to recover. */
> +				udelay(1);
> +			}
> +		}
>  	}
>  
>  	data->chip = device_get_match_data(dev);
> -- 
> 2.27.0
> 
> 

  reply	other threads:[~2021-08-02 20:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-27 16:03 [PATCH v2 0/2] i2c: mux: pca954x: Support multiple devices on a single reset line Eddie James
2021-07-27 16:03 ` [PATCH v2 1/2] dt-bindings: i2c: i2c-mux-pca954x: Define the reset-shared-hogged gpio Eddie James
2021-07-27 16:03 ` [PATCH v2 2/2] i2c: mux: pca954x: Support multiple devices on a single reset line Eddie James
2021-08-02 20:46   ` Rob Herring [this message]
2021-08-02 21:51     ` Eddie James
2021-08-02 22:35       ` Rob Herring
2021-08-04  7:50       ` Peter Rosin
2021-08-04 13:28         ` Rob Herring
2021-08-04 15:12           ` Eddie James
2021-08-04 16:35             ` Rob Herring

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=YQhZimPDbNJk5nbR@robh.at.kernel.org \
    --to=robh@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=eajames@linux.ibm.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peda@axentia.se \
    /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.