linux-kernel - Re: [PATCH v3] rust: regulator: add a bare minimum regulator abstraction

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aCRti2d5x2bL0mj6@finisterre.sirena.org.uk>
Date: Wed, 14 May 2025 12:16:43 +0200
From: Mark Brown <broonie@...nel.org>
To: Benno Lossin <lossin@...nel.org>
Cc: Daniel Almeida <daniel.almeida@...labora.com>,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <benno.lossin@...ton.me>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	Danilo Krummrich <dakr@...nel.org>,
	Boris Brezillon <boris.brezillon@...labora.com>,
	Sebastian Reichel <sebastian.reichel@...labora.com>,
	Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org,
	rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v3] rust: regulator: add a bare minimum regulator
 abstraction

On Wed, May 14, 2025 at 11:37:46AM +0200, Benno Lossin wrote:
> On Wed May 14, 2025 at 9:46 AM CEST, Mark Brown wrote:
> > On Tue, May 13, 2025 at 10:01:05PM +0200, Benno Lossin wrote:

> >> This isn't fully clear what it's supposed to mean to me. Maybe mention
> >> the `regulator_enable` function?

> > I suspect this is adequately clear to someone with the domain specific
> > knowledge required to be using the API.

> I still think it's useful to name the exact function that is meant by
> "enabled".

It's not clear to me that it's helpful to have to refer to the C API, as
opposed to just being free standing.

> >> Why don't we drop the refcount if the `regulator_disable` call fails?

> > If you fail to disable the regulator then the underlying C code won't
> > drop it's reference count.

> So if it fails, the regulator should stay alive indefinitely? Would be
> useful to explain that in the comment above the `ManuallyDrop`.

Practically speaking if the regulator disable fails the system is having
an extremely bad time and the actual state of the regulator is not clear.
Users might want to try some attempt at retrying, one of which could
possibly succeed in future, but realistically if this happens there's
something fairly catastrophic going on.  Some critical users might want
to care and have a good idea what makes sense for them, but probably the
majority of users of the API aren't going to have a good strategy here.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)