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:
> > On Fri, Sep 25, 2015 at 10:54:14AM -0500, Andreas Dannenberg wrote:
> > > @@ -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
Attachment:
signature.asc
Description: PGP signature
