Re: [PATCH 0/3] regulator: userspace-consumer: Add regulator event uevents

[Mark Brown]

On Mon, Apr 07, 2025 at 02:17:10PM +0000, Johann Neuhauser wrote:
> From: Mark Brown <broonie@xxxxxxxxxx>
> >On Fri, Apr 04, 2025 at 03:40:06PM +0200, Johann Neuhauser wrote:

> >> This series adds support for regulator event reporting via uevents to the
> >> userspace-consumer regulator driver. The goal is to provide userspace with
> >> a straightforward mechanism to monitor and respond to important regulator
> >> events such as overcurrent conditions, voltage changes, and enable/disable
> >> transitions.

> >This sounds like you're trying to use userspace-consumer in production
> >rather than as a test bodge...   what's the actual use case here?

> We have a hardware setup where the USB-A port is directly connected (D+/D-
> lines) to the SoC, while its VBUS line is driven by an external I²C-based PMIC.
> If a connected USB device attempts to draw more than approximately 800mA,
> the PMIC detects an overcurrent condition, automatically disables the output,
> and communicates an overcurrent event via the regulator framework.

You absolutely should not be using the userspace consumer for this.

> Currently, the generic USB HCD drivers lack a built-in mechanism for handling
> or recovering from such regulator-related events, particularly for reporting or
> re-enabling regulator outputs after an OC condition occurs. The DA8xx OHCI
> driver is one exception, as it indeed provides such functionality, but
> integrating similar support into the generic USB HCD drivers seemed unlikely to
> be accepted upstream.

Why not?  This seems like a perfectly reasonable thing to want to do, if
only as far as generating notifications to userspace.

> While I was aware that using the userspace-consumer driver might be seen as
> somewhat of a workaround for special cases, I did not fully consider that it
> was intended primarily as a temporary testing solution and perhaps not suitable
> for this kind of production usage. I'd be grateful for any suggestions or advice you
> might have on the appropriate approach or alternative solutions you could
> recommend for upstream integration.

I'd expect the consumer driver to be listening for events and offering
some sort of handling and/or interface for this that's joined up with
whatever the consumer is doing.  That basically means that your initial
thought above sounds about right to me.

Attachment: signature.asc
Description: PGP signature