All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Fabio Estevam <fabio.estevam@nxp.com>
Cc: linus.walleij@linaro.org, sergei.shtylyov@cogentembedded.com,
	andrew@lunn.ch, dmitry.torokhov@gmail.com,
	linux-gpio@vger.kernel.org, festevam@gmail.com
Subject: Re: [PATCH] gpio: consumer: Remove WARN_ON(1) when GPIOLIB is disabled
Date: Mon, 31 Jul 2017 13:17:49 +0200	[thread overview]
Message-ID: <20170731111749.GL26667@ulmo> (raw)
In-Reply-To: <1501258886-12376-1-git-send-email-fabio.estevam@nxp.com>

[-- Attachment #1: Type: text/plain, Size: 2141 bytes --]

On Fri, Jul 28, 2017 at 01:21:26PM -0300, Fabio Estevam wrote:
> gpiod_get_optional() returns NULL when GPIOLIB is disabled since
> commit 22c403676dbbb7c6 ("gpio: return NULL from gpiod_get_optional when
> GPIOLIB is disabled").
> 
> However, many gpiod functions still have WARN_ON(1) in their
> GPIOLIB=n stubs, which causes warnings in drivers even if the
> GPIO descriptor is requested via gpiod_get_optional().
> 
> Prior to commit 22c403676dbbb7c6 ("gpio: return NULL from
> gpiod_get_optional when GPIOLIB is disabled") it was indeed true
> the comment: "GPIO can never have been requested" as gpiod_get_optional()
> used to return an error.
> 
> After this commit the returned value is NULL, so the comment and
> WARN_ON(1) are no longer accurate.
> 
> An example of this kernel warning can be see in this report:
> https://www.spinics.net/lists/kernel/msg2563045.html
> 
> Remove the WARN_ON(1) so that drivers can silently work fine
> without kernel warnings when GPIOLIB is disabled.
> 
> Reported-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> Changes since RFC:
> - Expand a bit on the commit log
> - Include the kernel warning example
> 
>  include/linux/gpio/consumer.h | 59 -------------------------------------------
>  1 file changed, 59 deletions(-)

How about cases where the GPIO was not optional? Do we still want those
to be silently ignored? I guess in some way that makes sense as well,
but after this patch we're deviating from existing behaviour for non-
optional GPIOs.

Also, if we do decide that we want to silently ignore all GPIO calls if
GPIOLIB is disabled, maybe it would still be a good idea to warn users
about this at least once, so that they don't go chasing wild geese?

In either case, I think the commit message is still confusing because
you're arguing that gpiod_get_optional() now returns NULL and therefore
it is fine to remove WARN_ON(), whereas the WARN_ON() would still be
valid for non-NULL GPIO descriptors (such as requested via gpiod_get()
when GPIOLIB=n.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-07-31 11:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-28 16:21 [PATCH] gpio: consumer: Remove WARN_ON(1) when GPIOLIB is disabled Fabio Estevam
2017-07-31 11:17 ` Thierry Reding [this message]
2017-08-02 12:27 ` 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=20170731111749.GL26667@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=dmitry.torokhov@gmail.com \
    --cc=fabio.estevam@nxp.com \
    --cc=festevam@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=sergei.shtylyov@cogentembedded.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.