All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	linux-gpio@vger.kernel.org,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	George Cherian <george.cherian@ti.com>,
	Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Subject: Re: [PATCH 13/54] gpio: pcf857x: Be sure to clamp return value
Date: Sun, 27 Dec 2015 09:47:29 +0200	[thread overview]
Message-ID: <4184910.enE8aZKjEM@avalon> (raw)
In-Reply-To: <567F3258.7020003@mentor.com>

Hi Vladimir,

On Sunday 27 December 2015 02:35:36 Vladimir Zapolskiy wrote:
> On 27.12.2015 00:35, Laurent Pinchart wrote:
> > On Tuesday 22 December 2015 15:20:09 Linus Walleij wrote:
> >> As we want gpio_chip .get() calls to be able to return negative
> >> error codes and propagate to drivers, we need to go over all
> >> drivers and make sure their return values are clamped to [0,1].
> >> We do this by using the ret = !!(val) design pattern.
> > 
> > The patch itself looks good to me, but wouldn't it be easier to patch the
> > caller to clamp positive values to [0,1] and propagate negative values
> > untouched ?
> 
> this has been done in v4.3 e20538b82f1f ("gpio: Propagate errors from
> chip->get()"), but the change causes problems with GPIO line id 31 and
> the change is temporarily reverted by 45ad7db90b ("gpio: revert get() to
> non-errorprogating behaviour").
> 
> See also a recent discussion related to this problem
> http://www.spinics.net/lists/linux-gpio/msg10677.html
> 
> >> Also start returning the error code if something fails, as the
> >> end of the series augment the core to support this.
> >> 
> >> Cc: Grygorii Strashko <grygorii.strashko@ti.com>
> >> Cc: George Cherian <george.cherian@ti.com>
> >> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> >> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> >> ---
> >> 
> >>  drivers/gpio/gpio-pcf857x.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
> >> index bf511c0efa48..f64380a7d004 100644
> >> --- a/drivers/gpio/gpio-pcf857x.c
> >> +++ b/drivers/gpio/gpio-pcf857x.c
> >> @@ -154,7 +154,7 @@ static int pcf857x_get(struct gpio_chip *chip,
> >> unsigned
> >> offset) int		value;
> >> 
> >>  	value = gpio->read(gpio->client);
> >> 
> >> -	return (value < 0) ? 0 : (value & (1 << offset));
> >> +	return (value < 0) ? value : !!(value & (1 << offset));
> >> 
> >>  }
> 
> Back to your question, assume here in unmodified version the case of
> (offset == 31) [1], on upper level the returned value will be
> misapprehended as a negative number.
> 
> [1] (offset == 31) may be an invalid GPIO line id in this particular
> driver, but some other gpiochip drivers should support line id 31.

Would something like the following make sense ?

	value = chip->get ? chip->get(chip, offset) : -EIO;
	value = IS_ERR_VALUE(value) ? value : !!value;

Granted, GPIO drivers would still need to make sure that the value they return 
from register reads don't get considered as an error code, but any val & (1 << 
offset) would be fine, which is the most common case.

If you still think that patching all GPIO drivers is better I won't oppose to 
that.

> >>  static int pcf857x_output(struct gpio_chip *chip, unsigned offset, int
> >> 
> >> value)

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2015-12-27  7:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-22 14:20 [PATCH 13/54] gpio: pcf857x: Be sure to clamp return value Linus Walleij
2015-12-26 22:35 ` Laurent Pinchart
2015-12-27  0:35   ` Vladimir Zapolskiy
2015-12-27  7:47     ` Laurent Pinchart [this message]
2016-01-01 17:06       ` Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4184910.enE8aZKjEM@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=george.cherian@ti.com \
    --cc=grygorii.strashko@ti.com \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=vladimir_zapolskiy@mentor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.