[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f1084652-9a1d-4d2c-a7c7-9f40e380f5a6@sirena.org.uk>
Date: Wed, 28 May 2025 20:20:28 +0100
From: Mark Brown <broonie@...nel.org>
To: Daniel Okazaki <dtokazaki@...gle.com>
Cc: Liam Girdwood <lgirdwood@...il.com>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Zev Weiss <zev@...ilderbeest.net>, kernel-team@...roid.com,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v1 0/2] userspace-consumer: adding is_shared flag
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.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists