On Mon, Sep 28, 2015 at 07:04:12AM -0500, Andreas Dannenberg wrote:

On Sun, Sep 27, 2015 at 10:20:26PM +0200, Sebastian Reichel wrote:

quoted

Hi,

On Fri, Sep 25, 2015 at 10:54:14AM -0500, Andreas Dannenberg wrote:

quoted

@@ -651,15 +670,18 @@ static int bq24257_power_supply_init(struct bq24257_device *bq)
 	return PTR_ERR_OR_ZERO(bq->charger);
 }
 
-static int bq24257_pg_gpio_probe(struct bq24257_device *bq)
+static void bq24257_pg_gpio_probe(struct bq24257_device *bq)
 {
-	bq->pg = devm_gpiod_get_index(bq->dev, BQ24257_PG_GPIO, 0, GPIOD_IN);
+	bq->pg = devm_gpiod_get_optional(bq->dev, BQ24257_PG_GPIO, GPIOD_IN);
+
 	if (IS_ERR(bq->pg)) {
-		dev_err(bq->dev, "could not probe PG pin\n");
-		return PTR_ERR(bq->pg);
+		dev_err(bq->dev, "error probing PG pin\n");
+		bq->pg = NULL;
+		return;
 	}

You should handle -EPROBE_DEFER here.

Hi Sebastian. From having a quick look at the Kernel tree it seems like
this error shouldn't get exposed to the user (which it doesn't since it
would get zeroe'd out) and the error itself suggests that I should
"retry" which none of the things I looked at in the Kernel through "git
grep" seemed to do. So before making any assumptions I wanted to see if
I'm missing something or you could give me any pointers how to proceed.

Ok after checking drivers/base/dd.c it seems like what I should be doing
here is to simply exit the probe function and pass on -EPROBE_DEFER as
the return value of the probe function, and the system would then
automatically take care of re-trying the probe later, correct? Please
let know, I want to make sure this patch series is converging into an
acceptable state.

Regards,

--
Andreas Dannenberg
Texas Instruments Inc