From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Akhil R <akhilrajeev@nvidia.com>
Cc: andy.shevchenko@gmail.com, 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,
p.zabel@pengutronix.de, robh@kernel.org,
thierry.reding@gmail.com
Subject: Re: [PATCH v4 2/3] i2c: tegra: make reset an optional property
Date: Fri, 13 Jun 2025 10:00:36 +0300 [thread overview]
Message-ID: <aEvMlKIfcccD_s-O@smile.fi.intel.com> (raw)
In-Reply-To: <20250613060032.14927-1-akhilrajeev@nvidia.com>
On Fri, Jun 13, 2025 at 11:30:32AM +0530, Akhil R wrote:
> On Thu, 12 Jun 2025 21:43:56 +0300, Andy Shevchenko wrote:
> >> >> > if (handle)
> >> >> > err = acpi_evaluate_object(handle, "_RST", NULL, NULL);
> >> >> > - else
> >> >> > + else if (i2c_dev->rst)
> >> >> > err = reset_control_reset(i2c_dev->rst);
> >> >> > + else
> >> >> > + err = tegra_i2c_master_reset(i2c_dev);
> >> >>
> >> >> Can you please take a look here? Should the reset happen in ACPI?
> >> >
> >> > This is a good question. Without seeing all the implementations of _RST method
> >> > for the platforms based on this SoC it's hard to say. Ideally the _RST (which
> >> > is called above) must handle it properly, but firmwares have bugs...
> >> >
> >> > TL;DR: I think the approach is correct, and if any bug in ACPI will be found,
> >> > the workaround (quirk) needs to be added here later on.
> >>
> >> As in Thierry's comment, I was in thought of updating the code as below.
> >> Does it make sense or would it be better keep what it is there now?
> >>
> >> if (handle && acpi_has_method(handle, "_RST"))
> >> err = acpi_evaluate_object(handle, "_RST", NULL, NULL);
> >> else if (i2c_dev->rst)
> >> err = reset_control_reset(i2c_dev->rst);
> >> else
> >> err = tegra_i2c_master_reset(i2c_dev);
> >
> > This will change current behaviour for the ACPI based platforms that do not
> > have an _RST method. At bare minumum this has to be elaborated in the commit
> > message with an explanation why it's not a probnlem.
>
> This sequence is hit only at boot and on any error. It should be good to reset
> the controller internally at least for those cases. We are reconfiguring the I2C
> anyway after this and hence should not cause any problem.
> Will add these in the commit message as well.
This is not enough. You should explain the ACPI case. The above is just generic
wording as I read it. It does not explain 1) if there are ACPI firmwares that
have no _RST method for this device; 2) why it's not a problem for them to do
like this and why it was not supported before (with the current code this
platform will return an error on the method evaluation. Moreover the current
code is buggy. The acpi_evaluate_object() returns an ACPI error code and not
Linux one. so, for the such platforms (which I think do not exist, but still)
the err will have positive code which may be interpreted incorrectly.
So, fix the bug first, then rebase your code based on that change and
extend the commit message to really elaborate on all of the aspects.
W/o this done it's no go change.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2025-06-13 7:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-03 15:30 [PATCH v4 1/3] dt-bindings: i2c: nvidia,tegra20-i2c: Specify the required properties Akhil R
2025-06-03 15:30 ` [PATCH v4 2/3] i2c: tegra: make reset an optional property Akhil R
2025-06-10 8:32 ` Thierry Reding
2025-06-10 9:51 ` Akhil R
2025-06-10 9:56 ` Thierry Reding
2025-06-12 0:57 ` Andi Shyti
2025-06-12 12:55 ` Andy Shevchenko
2025-06-12 15:33 ` Akhil R
2025-06-12 18:43 ` Andy Shevchenko
2025-06-13 6:00 ` Akhil R
2025-06-13 7:00 ` Andy Shevchenko [this message]
2025-06-03 15:30 ` [PATCH v4 3/3] i2c: tegra: Remove dma_sync_*() calls Akhil R
2025-06-10 8:03 ` Thierry Reding
2025-06-03 19:00 ` [PATCH v4 1/3] dt-bindings: i2c: nvidia,tegra20-i2c: Specify the required properties Krzysztof Kozlowski
2025-06-09 9:02 ` Akhil R
2025-06-10 8:09 ` Krzysztof Kozlowski
2025-06-12 0:59 ` Andi Shyti
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=aEvMlKIfcccD_s-O@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=akhilrajeev@nvidia.com \
--cc=andi.shyti@kernel.org \
--cc=andy.shevchenko@gmail.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=p.zabel@pengutronix.de \
--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