wt., 22 paź 2019 o 17:03 Mark Brown <broonie@xxxxxxxxxx> napisał(a): > > On Tue, Oct 22, 2019 at 02:13:29PM +0200, Bartosz Golaszewski wrote: > > wt., 22 paź 2019 o 13:19 Mark Brown <broonie@xxxxxxxxxx> napisał(a): > > > > The ambiguously named regulator_get_optional(). This should *only* be > > > used for regulators that may be physically absent in the system, other > > > regulators should use normal regulator_get(). It is vanishingly > > > unlikely that all the supplies for a device will be optional. > > > I take it that this driver should also use regular regulator_bulk_get() then? > > It's really up to whoever maintains the driver but I'd recommend it > since it tends to be easier. > > > I think the question about the return value of > > regulator_resolve_supply() still stands though: is it normal that it > > returns EPROBE_DEFER if it can't resolve the supply on systems without > > full_constraints? This will cause the driver to loop on probe > > deferral, right? > > Yes, that's right. The idea is that anything using regulators will call > that once it's finished setting up constraints, if you're not using > regulators at all you should compile out the API entirely. Ok, makes sense. Thanks Mark! I'm just wondering if all boardfile-based systems actually do call it. I recently had to sent a fix for old DaVinci boards where the lack of this call caused one of the GPIO expanders to fail to probe. Bibby: in that case please remove the entire has_supplies checking and just rely on dummy regulators. Bartosz
