.../bindings/regulator/regulator-output.yaml | 5 +++ drivers/regulator/userspace-consumer.c | 39 ++++++++++++------- 2 files changed, 29 insertions(+), 15 deletions(-)
Hi, Currently this userspace regulator driver requires exclusive control of the regulator to operate. This patch adds an optional flag to remove that constraint, and allow the regulator to be shared by other modules. This allows for userspace to share control over a regulator with kernel space. There is a boot time behavior change when this flag is set. Before, if the gpio was enabled before this driver probes, it would stay enabled. This change allows regulator_init_complete_work to disable the regulator on completion. The regulator state reported by this driver is changed from the absolute state to the local state of the driver. This abstracts away the regulator state of other consumers from this driver. Daniel Okazaki (2): regulator: Add regulator-output is_shared property regulator: userspace-consumer add shared supply functionality .../bindings/regulator/regulator-output.yaml | 5 +++ drivers/regulator/userspace-consumer.c | 39 ++++++++++++------- 2 files changed, 29 insertions(+), 15 deletions(-) -- 2.49.0.1204.g71687c7c1d-goog
On Wed, May 28, 2025 at 05:44:23PM +0000, Daniel Okazaki wrote: > Currently this userspace regulator driver requires exclusive control > of the regulator to operate. This patch adds an optional flag to > remove that constraint, and allow the regulator to be shared by other > modules. This allows for userspace to share control over a regulator > with kernel space. What is the use case here? This is a debug tool intended mainly for when you're developing a regulator driver and have something like a development board with no consumers at all.
> What is the use case here? The request is for a regulator to be controlled by two different subsystems. One is a userspace HAL and the other is a kernel driver. Alternatively I could expose sysfs nodes in the kernel driver for the HAL layer to connect to, but it would add coupling between userspace and the kernel driver that might not otherwise be necessary. The userspace regulator driver would add some abstraction between the actual hardware and the sysfs interface. On Wed, May 28, 2025 at 11:16 AM Mark Brown <broonie@kernel.org> wrote: > > On Wed, May 28, 2025 at 05:44:23PM +0000, Daniel Okazaki wrote: > > > Currently this userspace regulator driver requires exclusive control > > of the regulator to operate. This patch adds an optional flag to > > remove that constraint, and allow the regulator to be shared by other > > modules. This allows for userspace to share control over a regulator > > with kernel space. > > What is the use case here? This is a debug tool intended mainly for > when you're developing a regulator driver and have something like a > development board with no consumers at all.
On Wed, May 28, 2025 at 11:32:19AM -0700, Daniel Okazaki wrote: Please don't top post, reply in line with needed context. This allows readers to readily follow the flow of conversation and understand what you are talking about and also helps ensure that everything in the discussion is being addressed. > > What is the use case here? > The request is for a regulator to be controlled by two different > subsystems. One is a userspace HAL and the other is > a kernel driver. > Alternatively I could expose sysfs nodes in the kernel driver > for the HAL layer to connect to, but it would add coupling > between userspace and the kernel driver that might not > otherwise be necessary. The userspace regulator driver > would add some abstraction between the actual hardware > and the sysfs interface. Presumably the HAL is working through some driver since otherwise it would have no access to the hardware, that driver should extend it's interface to cover managing the supplies. This coupling seems desirable, we end up with one kernel thing which knows about the whole device and the firmware description is not dependent on the fact that there's a HAL.
On Wed, May 28, 2025 at 12:20 PM Mark Brown <broonie@kernel.org> wrote: > > On Wed, May 28, 2025 at 11:32:19AM -0700, Daniel Okazaki wrote: > > Please don't top post, reply in line with needed context. This allows > readers to readily follow the flow of conversation and understand what > you are talking about and also helps ensure that everything in the > discussion is being addressed. > > > > What is the use case here? > > > The request is for a regulator to be controlled by two different > > subsystems. One is a userspace HAL and the other is > > a kernel driver. > > > Alternatively I could expose sysfs nodes in the kernel driver > > for the HAL layer to connect to, but it would add coupling > > between userspace and the kernel driver that might not > > otherwise be necessary. The userspace regulator driver > > would add some abstraction between the actual hardware > > and the sysfs interface. > > Presumably the HAL is working through some driver since otherwise it > would have no access to the hardware, that driver should extend it's > interface to cover managing the supplies. The HAL communicates directly with another subsystem via a mailbox interface and doesn't have a kernel driver. > This coupling seems > desirable, we end up with one kernel thing which knows about the whole > device and the firmware description is not dependent on the fact that > there's a HAL. I see, I can make a local sysfs node from the kernel driver to be exposed to the system.
© 2016 - 2026 Red Hat, Inc.