linux-kernel - Re: [PATCH v1 0/2] userspace-consumer: adding is

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAOC4097gBTJWAYLTO9c9-NgJmZ1Vvq7KzUxkuoOvByhm5fOQuA@mail.gmail.com>
Date: Wed, 28 May 2025 14:15:34 -0700
From: Daniel Okazaki <dtokazaki@...gle.com>
To: Mark Brown <broonie@...nel.org>
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 12:20 PM Mark Brown <broonie@...nel.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.