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 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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux