[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALNFmy1tnrJWKwGjdGOjjqB9XDS2DhAPq1rcDPgMdY3xXNoXAw@mail.gmail.com>
Date: Thu, 29 Sep 2022 08:29:19 +0200
From: Patrick Rudolph <patrick.rudolph@...ements.com>
To: Zev Weiss <zev@...ilderbeest.net>
Cc: Mark Brown <broonie@...nel.org>,
Liam Girdwood <lgirdwood@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Naresh Solanki <naresh.solanki@...ements.com>,
Laxman Dewangan <ldewangan@...dia.com>,
Mike Rapoport <rppt@...nel.org>, openbmc@...ts.ozlabs.org
Subject: Re: [PATCH 0/3] regulator: Add DT support for regulator-output connectors
Hi Zev,
Thanks for picking this up.
I cannot answer the first question, but the second:
It's sufficient for us to just have one supply per userspace-consumer instance.
The optional property is fine and could be useful in the future.
Regards,
Patrick
On Mon, Sep 26, 2022 at 12:04 AM Zev Weiss <zev@...ilderbeest.net> wrote:
>
> Hello,
>
> This series is another attempt at implementing support for
> userspace-controlled regulator-supplied power outputs. 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 very similar to one I posted in a
> previous patchset that had an R-B from Rob [1], but has had some minor
> rewording and gained one new (optional) property.
>
> Laxman, Naresh, Patrick -- please let me know if there are any aspects
> of this implementation that would be incompatible with your needs.
>
>
> 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/
>
> 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 | 47 +++++++++++++
> drivers/regulator/core.c | 42 +++++++-----
> drivers/regulator/devres.c | 66 ++++++++++++++-----
> drivers/regulator/internal.h | 2 +
> drivers/regulator/userspace-consumer.c | 43 ++++++++++--
> include/linux/regulator/consumer.h | 2 +
> include/linux/regulator/userspace-consumer.h | 1 +
> 7 files changed, 162 insertions(+), 41 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/regulator/regulator-output.yaml
>
> --
> 2.37.3
>
Powered by blists - more mailing lists