linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Philipp Zabel <p.zabel@pengutronix.de>
To: Akhil R <akhilrajeev@nvidia.com>, andriy.shevchenko@linux.intel.com
Cc: andi.shyti@kernel.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org,  digetx@gmail.com,
	jonathanh@nvidia.com, krzk+dt@kernel.org, ldewangan@nvidia.com,
	 linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
	 linux-tegra@vger.kernel.org, robh@kernel.org,
	thierry.reding@gmail.com
Subject: Re: [PATCH v5 1/3] i2c: tegra: Fix reset error handling with ACPI
Date: Thu, 03 Jul 2025 10:31:25 +0200	[thread overview]
Message-ID: <14af238d2106544147dfb1c7824787d6d54f1885.camel@pengutronix.de> (raw)
In-Reply-To: <20250702171036.1892-1-akhilrajeev@nvidia.com>

Hi Akhil,

On Mi, 2025-07-02 at 22:40 +0530, Akhil R wrote:
> On Wed, 2 Jul 2025 18:13:51 +0300, Andy Shevchenko wrote:
> > > > +static int tegra_i2c_reset(struct tegra_i2c_dev *i2c_dev)
> > > > +{
> > > > +	acpi_handle handle = ACPI_HANDLE(i2c_dev->dev);
> > > > +	int err;
> > > > +
> > > > +	if (handle) {
> > > > +		err = acpi_evaluate_object(handle, "_RST", NULL, NULL);
> > > > +		if (ACPI_FAILURE(err))
> > > > +			return -EIO;
> > > > +
> > > > +		return 0;
> > > > +	}
> > > > +
> > > > +	return reset_control_reset(i2c_dev->rst);
> > > 
> > > It's better to be written other way around:
> > > 
> > > 	acpi_handle handle;
> > > 	int err;
> > > 
> > > 	handle = ACPI_HANDLE(i2c_dev->dev);
> > > 	if (!handle)
> > > 		return reset_control_reset(i2c_dev->rst);
> > > 
> > > 	err = acpi_evaluate_object(handle, "_RST", NULL, NULL);
> > > 	if (ACPI_FAILURE(err))
> > > 		return -EIO;
> > > 
> > > 	return 0;
> > > 
> > > > +}
> > > 
> > > Other than that, LGTM,
> > > 
> > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > 
> > Actually I have to withdraw the tag. The above function is repetition of
> > the device_reset() / device_reset_optional(). Please use that instead.
> 
> I did check that. But device_reset_optional() returns '0' if reset is
> not available or when the reset succeeds. Then there is no option to
> conditionally trigger the internal reset when the reset is not available.
> 
> Other option was to do the internal reset unconditionally. But then the
> devices that do not have an internal reset will have to skip the reset
> silently if the reset property is absent in the device tree (or _RST
> method is absent in the ACPI table).
> 
> Though device_reset() returns error when reset is absent, it looks to
> be not so straight-forward to detect from the return value that if there
> is an actual error during reset or if the reset is absent.

device_reset() should return -ENOENT if the reset is absent (as opposed
to present but somehow broken). If there is any code path where this
isn't the case, we should probably fix this.

In the ACPI case, -ENOENT is returned by __device_reset() if the "_RST"
method is not found.

In the OF case, -ENOENT is returned by __of_reset_control_get() if the
requested id can't be found in a "reset-names" property, or if
of_parse_phandle_with_args() returns -ENOENT for the "resets" (or
"reset-gpios") property - that is, when this property doesn't exist or
the entry indicated by the reset id is empty.


regards
Philipp

  reply	other threads:[~2025-07-03  8:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-02 13:34 [PATCH v5 1/3] i2c: tegra: Fix reset error handling with ACPI Akhil R
2025-07-02 13:34 ` [PATCH v5 2/3] i2c: tegra: make reset an optional property Akhil R
2025-07-02 15:11   ` Andy Shevchenko
2025-07-03 16:02   ` kernel test robot
2025-07-02 13:34 ` [PATCH v5 3/3] i2c: tegra: Remove dma_sync_*() calls Akhil R
2025-07-02 15:24   ` Andy Shevchenko
2025-07-02 15:04 ` [PATCH v5 1/3] i2c: tegra: Fix reset error handling with ACPI Andy Shevchenko
2025-07-02 15:13   ` Andy Shevchenko
2025-07-02 17:10     ` Akhil R
2025-07-03  8:31       ` Philipp Zabel [this message]
2025-07-03 14:11         ` Andy Shevchenko
2025-07-04  6:47           ` Akhil R

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=14af238d2106544147dfb1c7824787d6d54f1885.camel@pengutronix.de \
    --to=p.zabel@pengutronix.de \
    --cc=akhilrajeev@nvidia.com \
    --cc=andi.shyti@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=digetx@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=krzk+dt@kernel.org \
    --cc=ldewangan@nvidia.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=thierry.reding@gmail.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).