Re: [PATCH v4 2/4] dt-bindings: regulator: add bindings for output-supply

[Rob Herring]

+Zev

On Thu, Jul 14, 2022 at 9:54 AM Mark Brown <broonie@xxxxxxxxxx> wrote:
>
> On Thu, Jul 14, 2022 at 09:07:49AM -0600, Rob Herring wrote:
> > On Thu, Jul 14, 2022 at 8:43 AM Mark Brown <broonie@xxxxxxxxxx> wrote:
>
> > > Consider for example a BMC (IIRC that's what their specific product is),
> > > a bench supply or some automated test equipment.  Part of the function
> > > for these systems is to provide power to other systems which would be
> > > represented as a root or wall supply in the description of the system
> > > that actually uses the supply if it were described using DT.
>
> > Didn't someone else have a similar use recently? Controlling some
> > supply external to the system. I can't seem to find it now.
>
> IIRC that was an earlier iteration of the same thing - it's been round
> the houses a bit.  extcon seemed like it might be a home since these are
> external connections from the system but in the end people didn't think
> it looked like a good fit.

Found it:

v1: https://lore.kernel.org/all/20220504065252.6955-2-zev@xxxxxxxxxxxxxxxxx/
v2: https://lore.kernel.org/all/20220505232557.10936-1-zev@xxxxxxxxxxxxxxxxx/

v2 was the using extcon version. v1 looks pretty similar to this one
though anything that's just a compatible plus supplies would.

But AFAICT these 2 submissions are completely independent.

> > In any case, it's not for you to describe, but Naresh, and in the
> > binding and commit messages. But first we need to overcome proper
> > usage of get_maintainers.pl. In response, to my first reply on v4, I
> > have a second v4 sent privately today (and still only the vendor
> > prefix). Sigh. AFAICT, for v1-v3, the only thing that made it to the
> > list was the cover letters. Bottom line is this series has multiple
> > problems and shouldn't have been applied yet.
>
> I can drop it but I do think it's reasonable to be adding a vendor
> binding for this, we don't seem to have enough people engaged to scope
> out a generic binding confidently and TBH I've got a feeling we might
> want multiple application specific generic bindings when we do have one.

I don't mind the vendor prefix. I mind the vendor prefix without any
description of the vendor's h/w.

Rob