Re: [PATCH 6/6] PCI: tegra: Add support to enable slot regulators

[Andrew Murray <andrew.murray@arm.com>]

On Wed, Aug 28, 2019 at 11:07:57AM +0200, Thierry Reding wrote:
> On Tue, Aug 27, 2019 at 06:13:34PM +0100, Andrew Murray wrote:
> > On Tue, Aug 27, 2019 at 09:54:17PM +0530, Vidya Sagar wrote:
> > > On 8/27/2019 9:17 PM, Andrew Murray wrote:
> > > > On Mon, Aug 26, 2019 at 01:01:43PM +0530, Vidya Sagar wrote:
> > > > > Add support to get regulator information of 3.3V and 12V supplies of a PCIe
> > > > > slot from the respective controller's device-tree node and enable those
> > > > > supplies. This is required in platforms like p2972-0000 where the supplies
> > > > > to x16 slot owned by C5 controller need to be enabled before attempting to
> > > > > enumerate the devices.
> > > > > 
> > > > > Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> > > > > ---
> > > > >   drivers/pci/controller/dwc/pcie-tegra194.c | 65 ++++++++++++++++++++++
> > > > >   1 file changed, 65 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > > index 8a27b25893c9..97de2151a738 100644
> > > > > --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > > +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > > @@ -278,6 +278,8 @@ struct tegra_pcie_dw {
> > > > >   	u32 aspm_l0s_enter_lat;
> > > > >   	struct regulator *pex_ctl_supply;
> > > > > +	struct regulator *slot_ctl_3v3;
> > > > > +	struct regulator *slot_ctl_12v;
> > > > >   	unsigned int phy_count;
> > > > >   	struct phy **phys;
> > > > > @@ -1047,6 +1049,59 @@ static void tegra_pcie_downstream_dev_to_D0(struct tegra_pcie_dw *pcie)
> > > > >   	}
> > > > >   }
> > > > > +static void tegra_pcie_get_slot_regulators(struct tegra_pcie_dw *pcie)
> > > > > +{
> > > > > +	pcie->slot_ctl_3v3 = devm_regulator_get_optional(pcie->dev, "vpcie3v3");
> > > > > +	if (IS_ERR(pcie->slot_ctl_3v3))
> > > > > +		pcie->slot_ctl_3v3 = NULL;
> > > > > +
> > > > > +	pcie->slot_ctl_12v = devm_regulator_get_optional(pcie->dev, "vpcie12v");
> > > > > +	if (IS_ERR(pcie->slot_ctl_12v))
> > > > > +		pcie->slot_ctl_12v = NULL;
> > > > 
> > > > Do these need to take into consideration -EPROBE_DEFER?
> > > Since these are devm_* APIs, isn't it taken care of automatically?
> > 
> > devm_regulator_get_optional can still return -EPROBE_DEFER - for times when
> > "lookup could succeed in the future".
> > 
> > It's probably helpful here for your driver to distinguish between there not
> > being a regulator specified in the DT, and there being a regulator but there
> > is no device for it yet. For the latter case - your driver would probe but
> > nothing would enumerate.
> > 
> > See pcie-rockchip-host.c for an example of where this is handled.
> > 
> > Of course if, for whatever reason it is unlikely you'll ever get -EPROBE_DEFER
> > then maybe it's OK as it is.
> 
> Let's not assume that. We've just recently encountered a case where we
> did not handle -EPROBE_DEFER because we had assumed too much, and that
> turned into a bit of a hassle to fix.
> 
> Vidya, I think what Andrew is saying is that you need to propagate the
> -EPROBE_DEFER error to the caller (i.e. the ->probe() callback) so that
> the PCI controller driver can be properly added to the defer queue in
> case the regulator isn't ready yet.

Indeed.

> 
> I think what we want here is something like:
> 
> 	pcie->slot_ctl_3v3 = devm_regulator_get_optional(pcie->dev, "vpcie3v3");
> 	if (IS_ERR(pcie->slot_ctl_3v3)) {
> 		if (PTR_ERR(pcie->slot_ctl_3v3) != -ENODEV)
> 			return PTR_ERR(pcie->slot_ctl_3v3);
> 
> 		pcie->slot_ctl_3v3 = NULL;
> 	}
> 
> Andrew, I'm not sure the handling in rockchip_pcie_parse_host_dt() is
> correct. It singles out -EPROBE_DEFER, which I think is the wrong way
> around. We should be special-casing -ENODEV, because regulator_get()
> can return a wide array of error cases, not all of which we actually
> want to consider successes. For example we could be getting -ENOMEM,
> which, I would argue, is something that we should propagate.

Yes I completely agree, given that the regulator is optional: we only want
to proceed if we find the regulator or if a regulator wasn't specified in the
DT. We should fail upon any other error, in case a regulator was specified
but the error prevented it from being returned.

> I think
> it'd be very confusing to take that as meaning "optional regulator
> wasn't specified", because in that case the DTS file would've had the
> regulator hooked up (we have to assume that it is needed in that case)
> but we won't be enabling it, so it's unlikely that devices will
> enumerate.

Thanks,

Andrew Murray

> 
> Thierry