[v2,0/3] regulator: Add DT support for regulator-output connectors

Hello,

This is v2 of my recent series adding support for userspace-controlled
regulator-supplied power outputs [2].  This is an important feature
for some kinds of BMC (baseboard management controller) systems where
the BMC provides an operator with manual control of a set of DC power
outputs.

As in a broadly similar patchset that was recently almost merged [0],
this takes the approach of providing support by extending the existing
userspace-consumer regulator driver.  A couple questions about the
userspace-consumer driver came up along the way, however.

First, how (if at all) is it currently being used?  It appears the
last in-tree use of it was removed a bit over two years ago in commit
9d3239147d6d ("ARM: pxa: remove Compulab pxa2xx boards").  Aside from
just adding DT support I've made a couple small tweaks to the driver
in patch 3 that I hope are compatible with any current usage, but
without any extant examples to look at it's kind of hard to say.

Second, how critical is its support for controlling multiple
regulators?  (i.e. its use of regulator_bulk_data and friends instead
of a single struct regulator.)  As far as I can see every in-tree use
of it that's ever existed has used num_supplies = 1.  If it's not
important to retain, patch 1 of this series could be supplanted by one
that instead simplifies the driver slightly by removing that
functionality.

The DT binding added in patch 2 is essentially identical to one I
posted in a previous patchset that had an R-B from Rob [1], but has
had some minor rewording and been moved from the extcon subsystem to
the regulator subsystem.

Changes since v1 [2]:
 - removed 'regulator-leave-on' DT property
 - added .is_visible method to hide sysfs 'name' property when it's
   NULL


Thanks,
Zev

[0] https://lore.kernel.org/all/20220707081826.953449-4-Naresh.Solanki@9elements.com/
[1] https://lore.kernel.org/linux-kernel/20220505232557.10936-2-zev@bewilderbeest.net/
[2] https://lore.kernel.org/openbmc/20220925220319.12572-1-zev@bewilderbeest.net/

Zev Weiss (3):
  regulator: devres: Add devm_regulator_bulk_get_exclusive()
  dt-bindings: regulator: Add regulator-output binding
  regulator: userspace-consumer: Handle regulator-output DT nodes

 .../bindings/regulator/regulator-output.yaml  | 39 +++++++++++
 drivers/regulator/core.c                      | 42 +++++++-----
 drivers/regulator/devres.c                    | 66 ++++++++++++++-----
 drivers/regulator/internal.h                  |  2 +
 drivers/regulator/userspace-consumer.c        | 60 +++++++++++++++--
 include/linux/regulator/consumer.h            |  2 +
 include/linux/regulator/userspace-consumer.h  |  1 +
 7 files changed, 169 insertions(+), 43 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/regulator/regulator-output.yaml

On Mon, 31 Oct 2022 16:37:01 -0700, Zev Weiss wrote:
> This is v2 of my recent series adding support for userspace-controlled
> regulator-supplied power outputs [2].  This is an important feature
> for some kinds of BMC (baseboard management controller) systems where
> the BMC provides an operator with manual control of a set of DC power
> outputs.
> 
> As in a broadly similar patchset that was recently almost merged [0],
> this takes the approach of providing support by extending the existing
> userspace-consumer regulator driver.  A couple questions about the
> userspace-consumer driver came up along the way, however.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[1/3] regulator: devres: Add devm_regulator_bulk_get_exclusive()
      commit: fd1845069711cdf1b1aaaa0f22311b7736396331
[2/3] dt-bindings: regulator: Add regulator-output binding
      commit: 14b8ad4c2580231fc45c2313ef822a15bb12f63f
[3/3] regulator: userspace-consumer: Handle regulator-output DT nodes
      commit: 5c51d4afcf3fd36159713556402e16cfab794ae9

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark