Re: [PATCH v4] misc: eeprom: at24: support pm_runtime control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux