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
