Re: [PATCH v2] gpio: return NULL from gpiod_get_optional when GPIOLIB is disabled

[Mark Brown]

On Wed, Feb 22, 2017 at 05:06:35PM +0100, Linus Walleij wrote:

> For optional regulators, if I understand correctly, these are
> *electrically optional* as in: a voltage input pin on a chip that
> the chip can very well live without. The regulator may be there,
> it may not, it may affect the function of the chip but it's still OK
> without it.

> For this reason regulators will return an error if an optional regulator
> is not present, and the code is expected to deal with it.

Yes.

> It is a common misconception that the "optional" part of the
> regulator API call means "software optional". It is not the semantic
> of this call.

> It is also tagged __must_check and return an error when compiled
> out. They return -ENODEV, see <linux/regulator/consumer.h>

Right.  Dmitry actually sent a patch a few weeks ago proposing a change
in this behaviour for the regulator API which I didn't apply.  I'm
mainly worried that this would the already encourage common broken
patterns with people just not writing error handling code properly and
the incorrect software optional assumption you mention above.  The
expectation is that the majority of drivers with optional regulators
will need to do some explicit handling whenever they would interact with
the regulator.

Attachment: signature.asc
Description: PGP signature