On Wed, Aug 28, 2019 at 10:26:55PM +0100, Andrew Murray wrote:

> I initially thought that you forgot to check for -ENODEV - though I can see
> that the implementation of devm_phy_optional_get very helpfully does this for
> us and returns NULL instead of an error.

> What is also confusing is that devm_regulator_get_optional, despite its
> _optional suffix doesn't do this and returns an error. I wonder if
> devm_phy_optional_get should be changed to return NULL instead of an error
> instead of -ENODEV. I've copied Liam/Mark for feedback.

The regulator API has an assumption that people will write bad DTs and
not describe all the regulators in the system, this is especially likely
in cases where consumer drivers initially don't have regulator support
and then get it added since people often only describe supplies actively
used by drivers.  In order to handle this gracefully the API will
substitute in a dummy regulator if it sees that the regulator just isn't
described in the system but a consumer requests it, this will ensure
that for most simple uses the consumer will function fine even if the DT
is not fully described.  Since most devices won't physically work if
some of their supplies are missing this is a good default assumption.  

If a consumer could genuinely have some missing supplies (some devices
do support this for various reasons) then this support would mean that
the consumer would have to have some extra property to say that the
regulator is intentionally missing which would be bad.  Instead what we
do is let the consumer say that real systems could actually be missing
the regulator and that the dummy shouldn't be used so that the consumer
can handle this.