Re: [PATCH] regulator: core: GPIO #0 is a valid GPIO

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]

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

> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/gpio/gpio-legacy.txt

> "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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]