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@xxxxxxxxxx>
> > > > ---
> > > > 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.
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. 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.
Thierry
Attachment:
signature.asc
Description: PGP signature
