[PATCH] RFC: let gpiod_get_optional et all return NULL when GPIOLIB is not enabled
Uwe Kleine-König
u.kleine-koenig at pengutronix.de
Mon Apr 27 08:21:53 PDT 2015
Hello,
On Thu, Apr 09, 2015 at 11:20:55AM +0900, Alexandre Courbot wrote:
> I should have replied one month ago, but if gpiolib is disabled, how
> can we use gpiolib-like logic to check the existence of a GPIO?
>
> 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 */
> Moving the interpretation of what the absence of gpiolib means down to
> the GPIO functions themselves is actually what might lead consumers to
> not know the result of their request. For this reason I would say that
> -ENOSYS is appropriate here.
Yeah, I fully agree.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
More information about the linux-arm-kernel
mailing list