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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 1 Sep 2014 11:15:13 +0100
From:	Mark Brown <>
To:	Dirk Behme <>
Cc:	Dmitry Eremin-Solenikov <>,, Liam Girdwood <>,
	Gokulkrishnan Nagarajan <>
Subject: Re: [PATCH] regulator: core: GPIO #0 is a valid GPIO

On Mon, Sep 01, 2014 at 09:46:54AM +0200, Dirk Behme wrote:
> On 29.08.2014 21:01, Mark Brown wrote:

> >No, read the archives

> Could you kindly give us a pointer to the relevant thread in the archive?

Not off the top of my head.

> >this will break boards using zero as default.
> >Any current boards should be using DT and so shouldn't be using fixed
> >GPIO numbers in the first place which will mean they'll not end up
> >getting zero as a valid GPIO.

> Hmm? What's wrong with a DT entry

> <&gpio1 0 0>;

> for ena_gpio resulting in zero as a valid GPIO?

If the platform has been converted to DT fully it's only going to happen
if there are exactly as many GPIOs in the system as there are slots in
the GPIO array which is unlikely to happen and trivial to deal with if
it does.  If the platform has been fully converted the GPIO numbers will
be dynamically allocated and the GPIO API starts from the top of the
GPIO range.

> >If you are using zero as a GPIO for some
> >reason provide a way to specify that the GPIO is a real GPIO and not
> >just the default value for the struct.

> Do you want to say that GPIO #0 (<&gpio1 0 0>;) isn't a valid GPIO for
> config->ena_gpio?

No, explicitly specifying GPIO 0 is a problem but that's really only
likely to happen if someone actually asks for it.

> I wonder how this fits to


> "GPIOs are identified by unsigned integers in the range 0..MAX_INT"

> "If you want to initialize a structure with an invalid GPIO number, use
> some negative number (perhaps "-EINVAL");"

> then?

There's no practical way to deploy that without breaking users - as soon
as you treat 0 as a valid GPIO you make all existing users relying on
the natural behaviour of treating 0 as default instantly buggy which is
not practical.  Really the GPIO API is badly specified here.

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

Powered by blists - more mailing lists