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.
Attachment:
signature.asc
Description: PGP signature
