Re: [PATCH] gpio: pisosr: Use devm_gpiod_get_optional for gpio->load_gpio

["Andrew F. Davis" <afd@ti.com>]

On 02/22/2016 06:16 AM, Axel Lin wrote:
> gpio->load_gpio is optional, so use devm_gpiod_get_optional instead.
>
> Signed-off-by: Axel Lin <axel.lin@ingics.com>
> ---
>   drivers/gpio/gpio-pisosr.c | 11 ++++-------
>   1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpio/gpio-pisosr.c b/drivers/gpio/gpio-pisosr.c
> index f9f1074..8b8bf8f 100644
> --- a/drivers/gpio/gpio-pisosr.c
> +++ b/drivers/gpio/gpio-pisosr.c
> @@ -125,15 +125,12 @@ static int pisosr_gpio_probe(struct spi_device *spi)
>   	if (!gpio->buffer)
>   		return -ENOMEM;
>
> -	gpio->load_gpio = devm_gpiod_get(dev, "load", GPIOD_OUT_LOW);
> +	gpio->load_gpio = devm_gpiod_get_optional(dev, "load", GPIOD_OUT_LOW);
>   	if (IS_ERR(gpio->load_gpio)) {
>   		ret = PTR_ERR(gpio->load_gpio);
> -		if (ret != -ENOENT && ret != -ENOSYS) {
> -			if (ret != -EPROBE_DEFER)
> -				dev_err(dev, "Unable to allocate load GPIO\n");
> -			return ret;
> -		}
> -		gpio->load_gpio = NULL;
> +		if (ret != -EPROBE_DEFER)
> +			dev_err(dev, "Unable to allocate load GPIO\n");
> +		return ret;
>   	}
>
>   	mutex_init(&gpio->lock);
>

How does this work when the GPIO subsystem is disabled? It looks like
we get will get -ENOSYS and fail probe. The issue is then that
devm_gpiod_get_optional returns an error when it cant get the optional
GPIO in that case, when it should probably just return NULL, I would
think all the optional functions should.