| Message ID | 20230510065819.3987-3-wsa+renesas@sang-engineering.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Krzysztof Wilczyński |
| Headers | show |
| Series | KingFisher: support regulators for PCIe | expand |
Hi Wolfram, On Wed, May 10, 2023 at 8:59 AM Wolfram Sang <wsa+renesas@sang-engineering.com> wrote: > The KingFisher board has regulators. They just need to be en-/disabled, > so we can leave the handling to devm. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > --- > > Changes since RFC: > * add 12v regulator > * add comment about the order of enabling the regulators > * use a for-loop to iterate over the regulators Thanks for the update! > --- a/drivers/pci/controller/pcie-rcar-host.c > +++ b/drivers/pci/controller/pcie-rcar-host.c > @@ -29,6 +29,7 @@ > #include <linux/phy/phy.h> > #include <linux/platform_device.h> > #include <linux/pm_runtime.h> > +#include <linux/regulator/consumer.h> > > #include "pcie-rcar.h" > > @@ -974,13 +975,18 @@ static const struct of_device_id rcar_pcie_of_match[] = { > {}, > }; > > +/* Design note 346 from Linear Technology says order is not important */ > +static const char * const rcar_pcie_supplies[] = { > + "vpcie12v", "vpcie3v3", "vpcie1v5" > +}; > + > static int rcar_pcie_probe(struct platform_device *pdev) > { > struct device *dev = &pdev->dev; > struct rcar_pcie_host *host; > struct rcar_pcie *pcie; > u32 data; > - int err; > + int i, err; unsigned int i? > struct pci_host_bridge *bridge; The (lack of) reverse-Xmas-tree ordering is hurting my OCD, but that's not your fault... > @@ -992,6 +998,13 @@ static int rcar_pcie_probe(struct platform_device *pdev) > pcie->dev = dev; > platform_set_drvdata(pdev, host); > > + for (i = 0; i < ARRAY_SIZE(rcar_pcie_supplies); i++) { > + err = devm_regulator_get_enable_optional(dev, rcar_pcie_supplies[i]); > + if (err < 0 && err != -ENODEV) > + dev_err_probe(dev, err, "error enabling regulator %s\n", > + rcar_pcie_supplies[i]); Shouldn't this return, and propagate the error code upstream? > + } > + > pm_runtime_enable(pcie->dev); > err = pm_runtime_get_sync(pcie->dev); > if (err < 0) { Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
> > + int i, err; > > unsigned int i? OK. > > > struct pci_host_bridge *bridge; > > The (lack of) reverse-Xmas-tree ordering is hurting my OCD, but that's > not your fault... Ack :) I can change it, though. > > + dev_err_probe(dev, err, "error enabling regulator %s\n", > > + rcar_pcie_supplies[i]); > > Shouldn't this return, and propagate the error code upstream? Ouch, brown paper bag, please.
On Wed, May 10, 2023 at 09:27:46AM +0200, Geert Uytterhoeven wrote: > On Wed, May 10, 2023 at 8:59 AM Wolfram Sang > <wsa+renesas@sang-engineering.com> wrote: > ... > > static int rcar_pcie_probe(struct platform_device *pdev) > > { > > struct device *dev = &pdev->dev; > > struct rcar_pcie_host *host; > > struct rcar_pcie *pcie; > > u32 data; > > - int err; > > + int i, err; > > unsigned int i? > > > struct pci_host_bridge *bridge; > > The (lack of) reverse-Xmas-tree ordering is hurting my OCD, but that's > not your fault... I usually put things in order of use, with initializations from parameters first. Happily, that is often a pretty good approximation of reverse-Xmas-tree, as it is here, so I'm all in favor of moving "struct pci_host_bridge" up there :) Bjorn
diff --git a/drivers/pci/controller/pcie-rcar-host.c b/drivers/pci/controller/pcie-rcar-host.c index e80e56b2a842..e86bf0f7729b 100644 --- a/drivers/pci/controller/pcie-rcar-host.c +++ b/drivers/pci/controller/pcie-rcar-host.c @@ -29,6 +29,7 @@ #include <linux/phy/phy.h> #include <linux/platform_device.h> #include <linux/pm_runtime.h> +#include <linux/regulator/consumer.h> #include "pcie-rcar.h" @@ -974,13 +975,18 @@ static const struct of_device_id rcar_pcie_of_match[] = { {}, }; +/* Design note 346 from Linear Technology says order is not important */ +static const char * const rcar_pcie_supplies[] = { + "vpcie12v", "vpcie3v3", "vpcie1v5" +}; + static int rcar_pcie_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; struct rcar_pcie_host *host; struct rcar_pcie *pcie; u32 data; - int err; + int i, err; struct pci_host_bridge *bridge; bridge = devm_pci_alloc_host_bridge(dev, sizeof(*host)); @@ -992,6 +998,13 @@ static int rcar_pcie_probe(struct platform_device *pdev) pcie->dev = dev; platform_set_drvdata(pdev, host); + for (i = 0; i < ARRAY_SIZE(rcar_pcie_supplies); i++) { + err = devm_regulator_get_enable_optional(dev, rcar_pcie_supplies[i]); + if (err < 0 && err != -ENODEV) + dev_err_probe(dev, err, "error enabling regulator %s\n", + rcar_pcie_supplies[i]); + } + pm_runtime_enable(pcie->dev); err = pm_runtime_get_sync(pcie->dev); if (err < 0) {
The KingFisher board has regulators. They just need to be en-/disabled, so we can leave the handling to devm. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> --- Changes since RFC: * add 12v regulator * add comment about the order of enabling the regulators * use a for-loop to iterate over the regulators Sidenote: I tried to introduce 'devm_regulator_bulk_get_enable_optional' to avoid the for-loop but that was a too intrusive change because all of the regulator_bulk logic is designed to fail if something bad happens somewhere. drivers/pci/controller/pcie-rcar-host.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)