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

[Alexandre Courbot <gnurou@xxxxxxxxx>]

On Tue, Apr 28, 2015 at 12:21 AM, Uwe Kleine-König
<u.kleine-koenig@xxxxxxxxxxxxxx> wrote:
> 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 */

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.
--
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