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
