On Fri, Aug 13, 2021 at 8:47 AM Robin Murphy <robin.murphy@xxxxxxx> wrote: > > On 2021-08-13 14:34, Rob Herring wrote: > > On Fri, Aug 13, 2021 at 7:55 AM Robin Murphy <robin.murphy@xxxxxxx> wrote: > >> > >> On 2021-08-13 12:33, Dan Carpenter wrote: > >>> If devm_regulator_get_optional() returns an error pointer, then we > >>> should return it to the user. The current code makes an exception > >>> for -ENODEV that will result in an error pointer dereference on the > >>> next line when it calls regulator_enable(). Remove the exception. > >> > >> Doesn't this break the apparent intent of the regulator being optional, > >> though? > > > > I'm pretty sure 'optional' means ENODEV is never returned. So there > > wasn't any real problem, but the check was unnecessary. > > In fact it's the other way round - "optional" in this case is for when > the supply may legitimately not exist so the driver may or may not need > to handle it, so it can return -ENODEV if a regulator isn't described by > firmware. A non-optional regulator is assumed to represent a necessary > supply, so if there's nothing described by firmware you get the (valid) > dummy regulator back. Ah yes, regulators is the oddball. Surely no one else will assume the same behavior of _optional() variants across subsystems... ;)
