All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Zev Weiss <zev@bewilderbeest.net>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	openbmc@lists.ozlabs.org
Subject: Re: [PATCH 2/6] dt-bindings: regulator: Add reg-external-output binding
Date: Wed, 4 May 2022 21:49:12 +0100	[thread overview]
Message-ID: <YnLmyHwMGnRL18LD@sirena.org.uk> (raw)
In-Reply-To: <YnLjNn9WVhvd4izZ@hatter.bewilderbeest.net>

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]

On Wed, May 04, 2022 at 01:33:58PM -0700, Zev Weiss wrote:
> On Wed, May 04, 2022 at 05:55:53AM PDT, Mark Brown wrote:

> > I think at a minimum anything like this would need some sort of
> > representation of how the output physically appears so that people can
> > work out how outputs are mapped to the hardware they see.

> I don't quite understand what you're describing here -- could you elaborate
> on what you mean by "how the output physically appears", and what that might
> look like in a DT binding?

For example if the output comes out on a socket then that socket should
be described.

> > However we
> > already have a subsystem for external connectors - extcon.  Perhaps this
> > should be a regulator client in the extcon API?  It's common for
> > connectors to include some sort of power provision so it seems like this
> > would fit right in.

> Interesting -- I wasn't previously aware of the extcon subsystem, thanks for
> the pointer.  However, after looking at it a bit, I'm not sure I see how
> it'd be applicable here, since it looks like it's built to handle hardware
> that's at least sophisticated enough for software to tell whether or not
> something's plugged in, which isn't the case here.  The connector is just a
> ground pin and +12VDC pin, no presence-detection mechanism or anything else.
> Outside of the regulator itself there's really no "device" there for
> software to talk to or otherwise interact with at all.

Sure, but there's no reason why it can't scale down to something
simpler.  It's easier to support something simpler than have to extend
to support something more complicated.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Zev Weiss <zev@bewilderbeest.net>
Cc: devicetree@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	openbmc@lists.ozlabs.org, Liam Girdwood <lgirdwood@gmail.com>,
	linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Subject: Re: [PATCH 2/6] dt-bindings: regulator: Add reg-external-output binding
Date: Wed, 4 May 2022 21:49:12 +0100	[thread overview]
Message-ID: <YnLmyHwMGnRL18LD@sirena.org.uk> (raw)
In-Reply-To: <YnLjNn9WVhvd4izZ@hatter.bewilderbeest.net>

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]

On Wed, May 04, 2022 at 01:33:58PM -0700, Zev Weiss wrote:
> On Wed, May 04, 2022 at 05:55:53AM PDT, Mark Brown wrote:

> > I think at a minimum anything like this would need some sort of
> > representation of how the output physically appears so that people can
> > work out how outputs are mapped to the hardware they see.

> I don't quite understand what you're describing here -- could you elaborate
> on what you mean by "how the output physically appears", and what that might
> look like in a DT binding?

For example if the output comes out on a socket then that socket should
be described.

> > However we
> > already have a subsystem for external connectors - extcon.  Perhaps this
> > should be a regulator client in the extcon API?  It's common for
> > connectors to include some sort of power provision so it seems like this
> > would fit right in.

> Interesting -- I wasn't previously aware of the extcon subsystem, thanks for
> the pointer.  However, after looking at it a bit, I'm not sure I see how
> it'd be applicable here, since it looks like it's built to handle hardware
> that's at least sophisticated enough for software to tell whether or not
> something's plugged in, which isn't the case here.  The connector is just a
> ground pin and +12VDC pin, no presence-detection mechanism or anything else.
> Outside of the regulator itself there's really no "device" there for
> software to talk to or otherwise interact with at all.

Sure, but there's no reason why it can't scale down to something
simpler.  It's easier to support something simpler than have to extend
to support something more complicated.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2022-05-04 20:49 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-04  6:52 [PATCH 1/6] dt-bindings: regulator: Add regulator-external-output property Zev Weiss
2022-05-04  6:52 ` Zev Weiss
2022-05-04  6:52 ` [PATCH 2/6] dt-bindings: regulator: Add reg-external-output binding Zev Weiss
2022-05-04  6:52   ` Zev Weiss
2022-05-04 12:55   ` Mark Brown
2022-05-04 12:55     ` Mark Brown
2022-05-04 20:33     ` Zev Weiss
2022-05-04 20:33       ` Zev Weiss
2022-05-04 20:49       ` Mark Brown [this message]
2022-05-04 20:49         ` Mark Brown
2022-05-04 21:35         ` Zev Weiss
2022-05-04 21:35           ` Zev Weiss
2022-05-05 12:05           ` Mark Brown
2022-05-05 12:05             ` Mark Brown
2022-05-05  8:33       ` Krzysztof Kozlowski
2022-05-04  6:52 ` [PATCH 3/6] regulator: core: Add error flags to sysfs attributes Zev Weiss
2022-05-04  6:52   ` Zev Weiss
2022-05-04  6:52 ` [PATCH 4/6] regulator: core: Add external-output support Zev Weiss
2022-05-04  6:52   ` Zev Weiss
2022-05-04 13:06   ` Mark Brown
2022-05-04 13:06     ` Mark Brown
2022-05-04  6:52 ` [PATCH 5/6] regulator: core: Add external get type Zev Weiss
2022-05-04  6:52   ` Zev Weiss
2022-05-04  6:52 ` [PATCH 6/6] regulator: core: Add external-consumer driver Zev Weiss
2022-05-04  6:52   ` Zev Weiss
2022-05-04 12:36 ` [PATCH 1/6] dt-bindings: regulator: Add regulator-external-output property Mark Brown
2022-05-04 12:36   ` Mark Brown
2022-05-04 20:54 ` (subset) " Mark Brown
2022-05-04 20:54   ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YnLmyHwMGnRL18LD@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=openbmc@lists.ozlabs.org \
    --cc=robh+dt@kernel.org \
    --cc=zev@bewilderbeest.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.