From: Thierry Reding <thierry.reding@gmail.com>
To: Andrew Murray <andrew.murray@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Heiko Stuebner <heiko@sntech.de>,
linux-pci@vger.kernel.org, Shawn Lin <shawn.lin@rock-chips.com>,
Vidya Sagar <vidyas@nvidia.com>,
linux-rockchip@lists.infradead.org,
Bjorn Helgaas <bhelgaas@google.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] PCI: rockchip: Properly handle optional regulators
Date: Wed, 28 Aug 2019 17:41:03 +0200 [thread overview]
Message-ID: <20190828154103.GA10422@ulmo> (raw)
In-Reply-To: <20190828153243.GZ14582@e119886-lin.cambridge.arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 3973 bytes --]
On Wed, Aug 28, 2019 at 04:32:44PM +0100, Andrew Murray wrote:
> On Wed, Aug 28, 2019 at 05:07:37PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > regulator_get_optional() can fail for a number of reasons besides probe
> > deferral. It can for example return -ENOMEM if it runs out of memory as
> > it tries to allocate data structures. Propagating only -EPROBE_DEFER is
> > problematic because it results in these legitimately fatal errors being
> > treated as "regulator not specified in DT".
> >
> > What we really want is to ignore the optional regulators only if they
> > have not been specified in DT. regulator_get_optional() returns -ENODEV
> > in this case, so that's the special case that we need to handle. So we
> > propagate all errors, except -ENODEV, so that real failures will still
> > cause the driver to fail probe.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > drivers/pci/controller/pcie-rockchip-host.c | 16 ++++++++--------
> > 1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
> > index 8d20f1793a61..ef8e677ce9d1 100644
> > --- a/drivers/pci/controller/pcie-rockchip-host.c
> > +++ b/drivers/pci/controller/pcie-rockchip-host.c
> > @@ -608,29 +608,29 @@ static int rockchip_pcie_parse_host_dt(struct rockchip_pcie *rockchip)
> >
> > rockchip->vpcie12v = devm_regulator_get_optional(dev, "vpcie12v");
> > if (IS_ERR(rockchip->vpcie12v)) {
> > - if (PTR_ERR(rockchip->vpcie12v) == -EPROBE_DEFER)
> > - return -EPROBE_DEFER;
> > + if (PTR_ERR(rockchip->vpcie12v) != -ENODEV)
> > + return PTR_ERR(rockchip->vpcie12v);
> > dev_info(dev, "no vpcie12v regulator found\n");
>
> In the event that -ENODEV is returned - we don't set vpcie12v to NULL, however
> it seems that this is OK as vpcie12v is tested with IS_ERR before use everywhere
> else in this file.
Yeah, I was trying to keep the diff small here. There doesn't seem to be
any canonical way to mark regulators as "not available". This driver
leaves it set as an error pointer, the Tegra PCI driver sets it to NULL.
They're both valid ways to do it as long as they use the proper checks
before using them. So I wasn't trying to force one way or another, just
kept it the way it was and only fixed the problematic checks.
> By the way it looks like this patch pattern could be applied right across the
> kernel, there are also others in PCI: pci-imx6 and pcie-histb.c - not sure if
> you wanted to fix those up too.
I hadn't checked any other drivers, but I can take another look and
prepare patches for them.
> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Thanks,
Thierry
> > }
> >
> > rockchip->vpcie3v3 = devm_regulator_get_optional(dev, "vpcie3v3");
> > if (IS_ERR(rockchip->vpcie3v3)) {
> > - if (PTR_ERR(rockchip->vpcie3v3) == -EPROBE_DEFER)
> > - return -EPROBE_DEFER;
> > + if (PTR_ERR(rockchip->vpcie3v3) != -ENODEV)
> > + return PTR_ERR(rockchip->vpcie3v3);
> > dev_info(dev, "no vpcie3v3 regulator found\n");
> > }
> >
> > rockchip->vpcie1v8 = devm_regulator_get_optional(dev, "vpcie1v8");
> > if (IS_ERR(rockchip->vpcie1v8)) {
> > - if (PTR_ERR(rockchip->vpcie1v8) == -EPROBE_DEFER)
> > - return -EPROBE_DEFER;
> > + if (PTR_ERR(rockchip->vpcie1v8) != -ENODEV)
> > + return PTR_ERR(rockchip->vpcie1v8);
> > dev_info(dev, "no vpcie1v8 regulator found\n");
> > }
> >
> > rockchip->vpcie0v9 = devm_regulator_get_optional(dev, "vpcie0v9");
> > if (IS_ERR(rockchip->vpcie0v9)) {
> > - if (PTR_ERR(rockchip->vpcie0v9) == -EPROBE_DEFER)
> > - return -EPROBE_DEFER;
> > + if (PTR_ERR(rockchip->vpcie0v9) != -ENODEV)
> > + return PTR_ERR(rockchip->vpcie0v9);
> > dev_info(dev, "no vpcie0v9 regulator found\n");
> > }
> >
> > --
> > 2.22.0
> >
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-08-28 15:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-28 15:07 [PATCH] PCI: rockchip: Properly handle optional regulators Thierry Reding
2019-08-28 15:32 ` Andrew Murray
2019-08-28 15:41 ` Thierry Reding [this message]
2019-08-28 18:15 ` Heiko Stuebner
2019-08-29 2:31 ` [PATCH] PCI: rockchip: Properly handle optional regulators【请注意,邮件由linux-rockchip-bounces+shawn.lin=rock-chips.com@lists.infradead.org代发】 Shawn Lin
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=20190828154103.GA10422@ulmo \
--to=thierry.reding@gmail.com \
--cc=andrew.murray@arm.com \
--cc=bhelgaas@google.com \
--cc=heiko@sntech.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=shawn.lin@rock-chips.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).