From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Mathias Nyman <mathias.nyman@linux.intel.com>,
linus.walleij@stericsson.com, grant.likely@secretlab.ca,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] gpiolib: Don't return -EPROBE_DEFER to sysfs, or for invalid gpios
Date: Sat, 27 Oct 2012 22:37:45 +0100 [thread overview]
Message-ID: <20121027213744.GF4564@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CACRpkdYPbs34Ob+MN9tjevXPTwGnEYsyJG0LMjCqsfxP=S_FJA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 831 bytes --]
On Fri, Oct 26, 2012 at 09:26:33AM +0200, Linus Walleij wrote:
> On Thu, Oct 25, 2012 at 1:03 PM, Mathias Nyman
> > gpios requested with invalid numbers, or gpios requested from userspace via sysfs
> > should not try to be deferred on failure.
> Very good catch. I applied this to my fixes branch and also
> put the stable tag on this thing, it goes way back to the introduction
> of deffered probe.
> Mark: OK with this?
The invalid numbers thing I'm a bit meh on. It came up before and I
personally wasn't sure if the issue wasn't with gpio_is_valid() only
checking for "this number could possibly ever be a GPIO" and not doing
any checking against the GPIOs that have actually been registered. If
it's the former then ideally at some point in the future we'll remove
the big table and gpio_is_valid() will always be true.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2012-10-27 21:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-25 11:03 [PATCH] gpiolib: Don't return -EPROBE_DEFER to sysfs, or for invalid gpios Mathias Nyman
2012-10-26 7:26 ` Linus Walleij
2012-10-27 21:37 ` Mark Brown [this message]
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=20121027213744.GF4564@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=grant.likely@secretlab.ca \
--cc=linus.walleij@linaro.org \
--cc=linus.walleij@stericsson.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathias.nyman@linux.intel.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.