openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Zev Weiss <zev@bewilderbeest.net>
To: Mark Brown <broonie@kernel.org>, Liam Girdwood <lgirdwood@gmail.com>
Cc: devicetree@vger.kernel.org, Zev Weiss <zev@bewilderbeest.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	openbmc@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Subject: [PATCH 0/6] regulator: core: Add support for external outputs
Date: Tue,  3 May 2022 23:50:35 -0700	[thread overview]
Message-ID: <20220504065041.6718-1-zev@bewilderbeest.net> (raw)

Hello,

This patch series is a new approach at implementing some functionality
I previously attempted as a separate driver in drivers/misc [0], but I
think (as suggested by Greg in that thread) ultimately makes more
sense being built into the regulator subsystem.

The hardware arrangement essentially amounts to a regulator whose
output doesn't supply any devices within the system, but instead
simply feeds a "dumb" external output -- picture a typical power
distribution unit (PDU), but with DC outputs instead of AC.  (The
specific system I'm targeting at the moment is the Delta AHE-50DC
Open19 power shelf [1], for which I'm working on a port of OpenBMC.)

Supporting this doesn't require much in the way of new functionality,
just some plumbing so that userspace (typically a human operator
manually switching outlets on and off) can access the necessary bits
of the regulator subsystem, and some DT bindings to describe this sort
of setup.

The DT bindings changes (patches 1 and 2) consist of a boolean
regulator property to mark it as supplying an external output, and a
reg-external-output binding to act as a downstream device representing
that output.  The redundancy between the two maybe isn't entirely
ideal, but it was the cleanest approach I've been able to come up with
so far in terms of working with the regulator subsystem; I'm certainly
open to suggestions for better ways of going about this.

Within the regulator core, patch 3 exposes the REGULATOR_ERROR_* flags
(for regulators that define a get_error_flags() operation) to
userspace as a set of read-only sysfs attributes, so that operators
can diagnose the cause of faults that may occur, such as current or
thermal limits being exceeded.

Patch 4 adds support for the regulator-external-output property with a
couple of small functional tweaks, making the 'state' sysfs attribute
writable and skipping the auto-disabling in regulator_late_cleanup().
Patch 5 adds a special-purpose regulator_get_type (EXTERNAL_GET), and
patch 6 adds a tiny driver acting as a placeholder for an external
output, using EXTERNAL_GET.

Review/feedback appreciated!


Thanks,
Zev

[0] https://lore.kernel.org/openbmc/20220308011811.10353-1-zev@bewilderbeest.net/
[1] https://www.open19.org/marketplace/delta-16kw-power-shelf/

Zev Weiss (6):
  dt-bindings: regulator: Add regulator-external-output property
  dt-bindings: regulator: Add reg-external-output
  regulator: core: Add error flags to sysfs attributes
  regulator: core: Add external-output support
  regulator: core: Add external get type
  regulator: core: Add external-consumer driver

 .../ABI/testing/sysfs-class-regulator         |  85 ++++++++++++
 .../regulator/reg-external-output.yaml        |  37 +++++
 .../bindings/regulator/regulator.yaml         |   6 +
 drivers/regulator/Kconfig                     |   9 ++
 drivers/regulator/core.c                      | 130 ++++++++++++++++--
 drivers/regulator/devres.c                    |   7 +
 drivers/regulator/internal.h                  |   3 +
 drivers/regulator/of_regulator.c              |   2 +
 include/linux/regulator/machine.h             |   1 +
 9 files changed, 272 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/regulator/reg-external-output.yaml

-- 
2.36.0


             reply	other threads:[~2022-05-04  6:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-04  6:50 Zev Weiss [this message]
2022-05-04  7:22 ` [PATCH 0/6] regulator: core: Add support for external outputs Zev Weiss
2022-05-04 12:56 ` Mark Brown
2022-05-04 20:28   ` Zev Weiss
2022-05-04 20:35     ` 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=20220504065041.6718-1-zev@bewilderbeest.net \
    --to=zev@bewilderbeest.net \
    --cc=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 \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).