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
next 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).