ad9528 probe not bringing up vcc-supply on boot

This fixed it - Should I submit a patch?  This seems like a bug.

diff --git a/drivers/iio/frequency/ad9528.c b/drivers/iio/frequency/ad9528.c
index 5696cf191e35..e973f0f17452 100644
--- a/drivers/iio/frequency/ad9528.c
+++ b/drivers/iio/frequency/ad9528.c
@@ -1642,12 +1642,18 @@ static int ad9528_probe(struct spi_device *spi)
        struct gpio_desc *status0_gpio;
        struct gpio_desc *status1_gpio;
        struct clk *clk;
+       struct regulator *reg;
        int ret;

+       reg = devm_regulator_get(&spi->dev, "vcc");
+       if (PTR_ERR(reg) == -EPROBE_DEFER)
+               return -EPROBE_DEFER;
+
        clk = devm_clk_get(&spi->dev, NULL);
        if (PTR_ERR(clk) == -EPROBE_DEFER)
                return -EPROBE_DEFER;

+
        if (spi->dev.of_node)
                pdata = ad9528_parse_dt(&spi->dev);
        else
@@ -1670,7 +1676,7 @@ static int ad9528_probe(struct spi_device *spi)

        mutex_init(&st->lock);

-       st->reg = devm_regulator_get(&spi->dev, "vcc");
+       st->reg = reg;
        if (!IS_ERR(st->reg)) {
                ret = regulator_enable(st->reg);
                if (ret)

SamuelW said:

Should I submit a patch?

No - I'll fix this slightly different using devm_regulator_get_optional().

But thanks for pointing out!

-Michael

SamuelW said:

Should I submit a patch?

No - I'll fix this slightly different using devm_regulator_get_optional().

But thanks for pointing out!

-Michael

I am not sure we are talking about the same issue - perhaps there are multiple issues around the "vcc" supply.

The problem I had is that the "vcc" supply is not only required, but it must be enabled before the probe routine trying to communicate with the ad9528 as part of initialization. If the ad9528 is probed before the fixed-regulator then (I believe) all the regulator _get functions will return "EPROBE_DEFER" indicating that the fixed-regulator isn't available yet.  This means the ad9528 must defer until the regulator is available.

It is entirely possible I am missing something here because this isn't a part of the kernel I am very familiar with. I took a quick glance at the code and I don't think this would correct my issue.

Hi Samuel,

Can you try this: 

https://github.com/analogdevicesinc/linux/pull/2309/commits/2a530232de1a0d99331176aa82e5728ec1c776b1

https://github.com/analogdevicesinc/linux/pull/2309

-Michael

Ahh, ok. I see this handles the DEFER case. I will give it a try shortly.

This worked well - regulator came up before accessing the device.