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/[email protected]/
[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
On Tue, May 03, 2022 at 11:50:35PM PDT, Zev Weiss wrote:
>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.
>
<snip>
Sorry for the broken threading here (missed a comma in the CC list on
patch 1 that 'git send-email --dry-run' didn't catch, then forgot to add
the necessary flags on the second attempt to tack it onto this cover
letter from the first).
In case it's not obvious, the patches corresponding to this are here:
https://lore.kernel.org/openbmc/[email protected]/T/
Zev
On Wed, May 04, 2022 at 05:56:13AM PDT, Mark Brown wrote:
>On Tue, May 03, 2022 at 11:50:35PM -0700, Zev Weiss wrote:
>
>> 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.
>
>Nothing in the series articulates what the purpose of the redundancy is
>- your description of this is a consumer, why would the regulator itself
>care what's connected to it?
Hi Mark, thanks for the review.
To some extent that was an additional (maybe excessive) protective
measure against regulators ending up userspace-controllable when they
shouldn't be, since I had previously gotten the impression that there
was some concern about that possibility.
More functionally though, it was also basically a hack to allow the
'state' sysfs attribute's mode to get set properly in
regulator_register(), before the consumer is known. Though if things
are rearranged based on what you said in another message about putting
the enable/disable control in a consumer driver instead of the regulator
itself, it should be easy to get rid of.
Thanks,
Zev
On Wed, May 04, 2022 at 01:28:11PM -0700, Zev Weiss wrote:
> To some extent that was an additional (maybe excessive) protective measure
> against regulators ending up userspace-controllable when they shouldn't be,
> since I had previously gotten the impression that there was some concern
> about that possibility.
The problem there is that userspace shouldn't be controlling the
regulator, it should be controlling the things using the regulator so
that whatever happens is coordinated with the rest of the management of
the device.
On Tue, May 03, 2022 at 11:50:35PM -0700, Zev Weiss wrote:
> 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.
Nothing in the series articulates what the purpose of the redundancy is
- your description of this is a consumer, why would the regulator itself
care what's connected to it?