On Fri, Aug 13, 2021 at 04:00:45PM +0100, Robin Murphy wrote: > On 2021-08-13 15:32, Mark Brown wrote: > > It also encourages *really* bad practice with error handling, and in > > general there are few use cases for optional regulators where there's > > not some other actions that need to be taken in the case where the > > supply isn't there (elimintating some operating points or features, > > reconfiguring power internally and so on). If we genuninely don't need > > to do anything special one wonders why we're trying to turn the power on > > in the first place. > Sure, once you get into it, regulators are arguably a rather deeper area > than GPIOs, so in terms of the NULL-safe aspect anything beyond > enable/disable - for the sake of keeping trivial usage simple - would be > pretty questionable for sure. enable and disable are among my biggest worries frankly, if the device was supposed to have power and that didn't work then there's probably some kind of issue. > A lot of the usage of regulator_get_optional() seems to be just making sure > some external thing is powered between probe() and remove() if it's not > hard-wired already, so maybe something like a > devm_regulator_get_optional_enabled() could be an answer to that argument > without even touching the underlying API. I'm fairly sure a lot of the regulator_get_optional() usage is just abuse of the API, every so often I get fed up enough to send patches converting users that look like you describe to normal regulator API calls. People really don't get the dummy regulator stuff and seem to think that _get_optional() is what you use to avoid writing any error handling code :(
Attachment:
signature.asc
Description: PGP signature
