Re: [PATCH] RFC: let gpiod_get_optional et all return NULL when GPIOLIB is not enabled

[Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>]

Hello,

On Tue, Apr 28, 2015 at 12:31:37PM +0900, Alexandre Courbot wrote:
> On Tue, Apr 28, 2015 at 12:21 AM, Uwe Kleine-König
> <u.kleine-koenig@xxxxxxxxxxxxxx> wrote:
> > On Thu, Apr 09, 2015 at 11:20:55AM +0900, Alexandre Courbot wrote:
> >> Having GPIO disabled means there is no GPIO support, including the
> >> ability to look for GPIOs. -ENOSYS is a well-documented error-code
> >> which meaning also applies to the gpio_*_optional functions (we don't
> >> have support for the operation you requested). If a driver or
> >> architecture really, really needs GPIO support they can require or
> >> depend on CONFIG_GPIOLIB, and the problem goes away. If they can work
> >> with and without gpiolib, then they should check for -ENOSYS when they
> >> request GPIOs and behave accordingly.
> > What whould be the right behaviour in your eyes? I hope it's not
> >
> >         if (ret != -ENOSYS)
> >                 return ret;
> >
> >         /* continue and ignore error */
> 
> If a consumer absolutely needs a GPIO (most of the drivers out there I
> believe), then -ENOSYS can be handled like any other error. If it
> doesn't, and the driver is fine without GPIO support as well (meaning
> that it can somehow work even if a GPIO is declared, but GPIO support
> is not compiled in), then it will need to explicitly handle that
> particular error. That case should be rare though - most drivers will
> want to propagate -ENOSYS.
Ack.

Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html