Hi,

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

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.

If you return -EPROBE_DEFER from your driver's probe function, the
driver probe will fail. In opposit to other error codes it will be
marked for retry at a later point, though. You will get
EPROBE_DEFER, if you try to access a GPIO from a not-yet initialized
GPIO controller (e.g. if you load the charger driver before the
gpio driver).

Correct handling is simple: Just forward it, making sure, that all
non-devm probed resources are correctly free'd.

-- Sebastian