wt., 22 paź 2019 o 13:19 Mark Brown <broonie@xxxxxxxxxx> napisał(a): > > On Tue, Oct 22, 2019 at 07:33:54PM +0900, Tomasz Figa wrote: > > On Tue, Oct 22, 2019 at 6:00 PM Bartosz Golaszewski > > > > > I can see that the core returns the dummy regulator if > > > > have_full_constraints() [1]. That is always true for DT systems, but > > > > for others it's false by default, unless someone explicitly calls > > > > regulator_has_full_constraints() [2]. > > ACPI systems are also always marked as having full constraints, only > systems with board files will see this. > > > > Not tested yet, but from the code it looks like it will then keep > > > returning EPROBE_DEFER which doesn't sound right really, especially > > > since we're printing an error message too. Shouldn't it be -ENODEV? > > > That's an interesting finding. Liam, Mark, what's the proper way to > > bulk get optional regulators? > > 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? 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? Bart
