On Thu, Aug 29, 2019 at 02:43:46PM +0100, Andrew Murray wrote: > Where they are not specified, because there is really no reason for them to > be described in the DT - then these drivers should use regulator_get and > be happy with a dummy regulator. This gives a benefit as if another hardware > version uses the same driver but does have a regulator that needs software > control then we can be confident it will work. The common use case for this is that some boards have flexible power control which allows them save energy by powering off chips that are not in use, the driver doesn't super care if it actually gets powered off or not but it's nice to be able to do so. > Where regulators are really optional, then regulator_get_optional is used > and -ENODEV can be used by the caller to perform a different course of action > if required. (Does this use-case actually exist?) Yes. There are two main use cases. One is for things like MMC where there's optional supplies that can be used for some more advanced use cases but their use needs to be negotiated between the host and device, these typically enable lower power or higher performance modes at the cost of complexity. The other is for devices which have the option of using an internal regulator but can use an external one. This is typically used either for performance reasons (the external regulator might perform better but will increase board cost) or if some systems need multiple devices to be operating with the same reference voltage. > I guess I interpreted _optional as 'it's OK if you can't provide a regulator', > whereas the meaning is really 'get me a regulator that may not exist'. > Is my understanding correct? If so I guess another course of action would Yes. > be to clean-up users of _optional and convert them to regulator_get where > appropriate? Yes, I keep doing that intermittently (hence my frustration with more usages continually popping up in graphics drivers).
Attachment:
signature.asc
Description: PGP signature
