linux-kernel - Re: [GIT PULL] GPIO changes for v3.6

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]

Date:	Sun, 5 Aug 2012 00:03:59 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	NeilBrown <neilb@...e.de>
Cc:	linux-kernel@...r.kernel.org,
	Grant Likely <grant.likely@...retlab.ca>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Roland Stigge <stigge@...com.de>
Subject: Re: [GIT PULL] GPIO changes for v3.6

On Mon, Jul 30, 2012 at 8:57 AM, NeilBrown <neilb@...e.de> wrote:

> it means that if !gpio_is_valid(gpio), the error returned is EPROBE_DEFER
> which isn't right (an invalid gpio number will never become valid).
> If a driver happened to use gpio_request to check the validity of the gpio
> rather than doing it itself, it would defer the probe, rather than assume
> that the GPIO doesn't exist.
>
> I would suggest the following.  Reasonable?

Unless there is a firm regression solved by this we can very well
discuss this until the next merge window.

The solution from Mark looks very much like the method used in
regulators, clocks etc. I bet if we look at the error paths of the
driver doing gpio_is_valid() the majority will be something in the
probe() path just bailing out if that was not supplied, alternatively
shunting in some non-GPIO code.

The more typical problem for
deferring driver to solve will be something like commit
2805b9ab7c836cfbe01e86129983e36205078cb2
where we have to check for -EPROBE_DEFER explicitly
and bail out before doing any gpio_is_valid() checks.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/