From: Thierry Reding <thierry.reding@gmail.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Vidya Sagar <vidyas@nvidia.com>,
robh+dt@kernel.org, bhelgaas@google.com, jonathanh@nvidia.com,
amanharitsh123@gmail.com, dinghao.liu@zju.edu.cn, kw@linux.com,
linux-pci@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org, kthota@nvidia.com,
mmaddireddy@nvidia.com, sagar.tv@gmail.com
Subject: Re: [PATCH V4 4/6] PCI: tegra: Continue unconfig sequence even if parts fail
Date: Tue, 1 Dec 2020 15:24:24 +0100 [thread overview]
Message-ID: <X8ZSGCdp3lqORsPh@ulmo> (raw)
In-Reply-To: <20201130121007.GC16758@e121166-lin.cambridge.arm.com>
[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]
On Mon, Nov 30, 2020 at 12:10:07PM +0000, Lorenzo Pieralisi wrote:
> On Mon, Nov 09, 2020 at 10:49:35PM +0530, Vidya Sagar wrote:
> > Currently the driver checks for error value of different APIs during the
> > uninitialization sequence. It just returns from there if there is any error
> > observed for one of those calls. Comparatively it is better to continue the
> > uninitialization sequence irrespective of whether some of them are
> > returning error. That way, it is more closer to complete uninitialization.
>
> Hi Vidya, Thierry,
>
> I can apply this series (dropping patches as suggested by Thierry),
> before though I wanted to ask you if this patch is really an
> improvement, it is hard to understand why skipping some error
> codes is OK for device correct operations to continue, maybe it
> is worth describing why some of those failures aren't really
> fatal.
>
> Please let me know, thanks.
As explained in the commit message, the idea is to continue tearing
down even if things fail somewhere in the middle, because that ensures
that the hardware gets as close to an "uninitialized" state as possible.
If for example the first reset assert were to fail, then none of the
PHYs get disabled, the regulator stays on and the clocks stays on, all
of which can continue draining power after the controller has already
been torn down.
So yes, I think this is an improvement. It's unclear to me what you're
asking for, though. Would you rather have a comment somewhere near the
tegra_pcie_unconfig_controller() function that states the same thing as
the commit message?
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-12-01 14:25 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-09 17:19 [PATCH V4 0/6] Enhancements to Tegra194 PCIe driver Vidya Sagar
2020-11-09 17:19 ` [PATCH V4 1/6] PCI: tegra: Fix ASPM-L1SS advertisement disable code Vidya Sagar
2020-11-26 11:33 ` Thierry Reding
2020-12-03 12:36 ` Vidya Sagar
2020-11-09 17:19 ` [PATCH V4 2/6] PCI: tegra: Map configuration space as nGnRnE Vidya Sagar
2020-11-26 11:33 ` Thierry Reding
2020-12-03 12:56 ` Vidya Sagar
2020-11-09 17:19 ` [PATCH V4 3/6] PCI: tegra: Set DesignWare IP version Vidya Sagar
2020-11-26 11:34 ` Thierry Reding
2020-11-09 17:19 ` [PATCH V4 4/6] PCI: tegra: Continue unconfig sequence even if parts fail Vidya Sagar
2020-11-26 11:34 ` Thierry Reding
2020-11-30 12:10 ` Lorenzo Pieralisi
2020-12-01 14:24 ` Thierry Reding [this message]
2020-12-01 14:44 ` Lorenzo Pieralisi
2020-11-09 17:19 ` [PATCH V4 5/6] PCI: tegra: Check return value of tegra_pcie_init_controller() Vidya Sagar
2020-11-26 11:34 ` Thierry Reding
2020-11-09 17:19 ` [PATCH V4 6/6] PCI: tegra: Disable LTSSM during L2 entry Vidya Sagar
2020-11-26 11:34 ` Thierry Reding
2020-11-25 17:57 ` [PATCH V4 0/6] Enhancements to Tegra194 PCIe driver Thierry Reding
2020-11-25 19:51 ` Vidya Sagar
2020-11-26 11:31 ` Thierry Reding
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=X8ZSGCdp3lqORsPh@ulmo \
--to=thierry.reding@gmail.com \
--cc=amanharitsh123@gmail.com \
--cc=bhelgaas@google.com \
--cc=dinghao.liu@zju.edu.cn \
--cc=jonathanh@nvidia.com \
--cc=kthota@nvidia.com \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mmaddireddy@nvidia.com \
--cc=robh+dt@kernel.org \
--cc=sagar.tv@gmail.com \
--cc=vidyas@nvidia.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).