linux-kernel - Re: [PATCH 2/2] regulator: core: Replace _regulator_enable

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: <YmB3HWEIv8m+BP1w@sirena.org.uk>
Date:   Wed, 20 Apr 2022 22:11:57 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Brian Norris <briannorris@...omium.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Matthias Kaehlcke <mka@...omium.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] regulator: core: Replace _regulator_enable_delay()
 with fsleep()

On Wed, Apr 20, 2022 at 11:24:08AM -0700, Brian Norris wrote:
> On Wed, Apr 20, 2022 at 05:28:46PM +0100, Mark Brown wrote:

> > Did the issue with the delay functions preferring delays on the higher
> > end of the allowed range get fixed?  That might be an issue for larger
> > usleep() values.

> Hmm, good question. I had a faint memory of this problem, and searching
> around, I couldn't find that anybody *thought* they fixed it, and I
> found evidence to the contrary (some reports complaining about, e.g.,
> boot-time performance issues in drivers/usb due to the same, with no
> indication that anybody truly fixed the problem).

That's what I feared :/

> So maybe it's better to retain the regulator core helper
> (_regulator_enable_delay()) and rename/repurpose it for my patch 1?

Sounds like a plan.

> I feel like there's some room for improvement in either fsleep() or
> usleep_range() or both, but I'm not sure exactly how to go about that
> right now.

It's really difficult to design an API that's both tasteful and clear
about intent - it's relatively easy for something like a driver that
just has a single hard coded value so you can just use usleep_range()
directly but it gets awkward once you start being generic and the code
really has no idea what the actual delay it's dealing with is.

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