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 3:45 PM, Uwe Kleine-König
<u.kleine-koenig@xxxxxxxxxxxxxx> wrote:
> 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.

Of course if you can think of a more elegant way to handle this, by
all means, please let us know. :)
--
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