linux-kernel - Re: [PATCH] gpiolib: Don't return -EPROBE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20121027213744.GF4564@opensource.wolfsonmicro.com>
Date:	Sat, 27 Oct 2012 22:37:45 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	linus.walleij@...ricsson.com, grant.likely@...retlab.ca,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] gpiolib: Don't return -EPROBE_DEFER to sysfs, or for
 invalid gpios

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.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)