linux-kernel - Re: [PATCH 7/7] regulator: core: Remove loop disabling supplies in regulator_force

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: <CAD=FV=VncEViv-mUJzUdjA8qvEouHHtiVfV2EpYi6bLAMW7S7Q@mail.gmail.com>
Date:   Tue, 20 Nov 2018 08:57:32 -0800
From:   Doug Anderson <dianders@...omium.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Evan Green <evgreen@...omium.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Dmitry Osipenko <digetx@...il.com>, ryandcase@...omium.org,
        David Collins <collinsd@...eaurora.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 7/7] regulator: core: Remove loop disabling supplies in regulator_force_disable()

Hi,

On Tue, Nov 20, 2018 at 8:25 AM Mark Brown <broonie@...nel.org> wrote:
>
> If something has been forced off the system is in very serious trouble
> and had a cricial safety problem, though the fact that there's error
> handling code that did the force disable might mean that there's some
> ability to recover the situation - for example, this might be part of
> thermal management or something like charger management.  Other drivers
> do get notified if something gets forced off so a well written system
> will ensure that other users of a regulator that can get force disabled
> will have handling for this as should userspace.  We don't have any such
> full systems in mainline, though - it is a really uncommon case.

OK.  I guess for now I'll just change this to disable the parent
supply as many times as this individual consumer enabled it and call
it good enough?  It can be for someone else to figure out how to make
it really usable for system recovery.

...I originally only ended up here since I was auditing all this code
while moving the enable count to the individual consumers...


> The usage in the Adreno drivers just looks to be another completely
> out of expectation regulator API usage in the QC code.

Yeah, looks like it.


> I do wish there
> were a way to flag API calls as needing review :(

Would it be worth adding a WARN_ON(1) splat here or at least a
"dev_warn" so people knew it wasn't really an API for general use?
...or is that going overboard?

-Doug