On Wed, Nov 03, 2021 at 04:34:34PM -0400, Jim Quinlan wrote:
> On Wed, Nov 3, 2021 at 4:25 PM Jim Quinlan <[email protected]> wrote:
> > I did it to squelch the "supply xxxxx not found, using dummy
> > regulator" output. I'll change it.
> Now I remember: if I know there are no vpciexxx-supplly props in the
> DT, I can skip executing all of the buik regulator calls entirely, as
> well as walking the PCI bus as in brcm_regulators_off().
> Do you consider this a valid reason?
No, the whole point in the core code providing dummy supplies is that it
removes the complexity introduced by client drivers trying to guess if
there's supplies available or not. If they do that then we end up with
a bunch of code duplication and issues if there's any changes or
extensions to the generic bindings.
On Wed, Nov 3, 2021 at 5:52 PM Mark Brown <[email protected]> wrote:
>
> On Wed, Nov 03, 2021 at 04:34:34PM -0400, Jim Quinlan wrote:
> > On Wed, Nov 3, 2021 at 4:25 PM Jim Quinlan <[email protected]> wrote:
>
> > > I did it to squelch the "supply xxxxx not found, using dummy
> > > regulator" output. I'll change it.
>
> > Now I remember: if I know there are no vpciexxx-supplly props in the
> > DT, I can skip executing all of the buik regulator calls entirely, as
> > well as walking the PCI bus as in brcm_regulators_off().
>
> > Do you consider this a valid reason?
>
> No, the whole point in the core code providing dummy supplies is that it
> removes the complexity introduced by client drivers trying to guess if
> there's supplies available or not. If they do that then we end up with
> a bunch of code duplication and issues if there's any changes or
> extensions to the generic bindings.
Ok, will change it.
Thanks, Jim