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:
> > Hi,
> >
> > 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.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
