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:	Mon, 11 Aug 2014 13:38:40 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Alexandre Courbot <gnurou@...il.com>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linaro-kernel@...ts.linaro.org
Subject: Re: [PATCH] gpiolib: Don't allow drivers to specify a base with DT

On Mon, Aug 04, 2014 at 01:21:57PM +0900, Alexandre Courbot wrote:
> On Thu, Jul 31, 2014 at 9:07 PM, Mark Brown <broonie@...nel.org> wrote:

> > DT based systems should have no reason to use fixed GPIO numbers but some
> > drivers that work on both DT and non-DT platforms specify them anyway. In
> > order to improve robustness in cases where drivers use gpio_is_valid() to
> > check for a valid GPIO on data initialized to zero as a default and avoid
> > bugs due to assuptions about fixed numbers creeping in ignore any specified
> > base when DT is in use.

> I agree that DT users should not use the base number at all - but the
> fact is some of them are doing it. Aren't we going to break some
> user-space users that will expect to find a GPIO under a given number?

Is this actually a realistic thing that people do with mainline - I'm
not convinced that it's going to be robust in general (a lot of DT
conversions will have broken things for entire architectures) and hard
coded numbers aren't the sort of things that make it into distros.

> Also, how is this going to help with gpio_is_valid() against
> zero-initialized data?

I should have said check for zero instead, sorry - though making 0 not
be a valid GPIO would help overall.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ