linux-kernel - Re: [PATCH] drm/panfrost: Fix regulator_get

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]

Date:   Thu, 5 Sep 2019 10:37:53 +0100
From:   Steven Price <steven.price@....com>
To:     Rob Herring <robh@...nel.org>, Mark Brown <broonie@...nel.org>
Cc:     David Airlie <airlied@...ux.ie>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Tomeu Vizoso <tomeu.vizoso@...labora.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/panfrost: Fix regulator_get_optional() misuse

On 05/09/2019 09:21, Rob Herring wrote:
> +Steven
> 
> On Wed, Sep 4, 2019 at 1:30 PM Mark Brown <broonie@...nel.org> wrote:
>>
>> The panfrost driver requests a supply using regulator_get_optional()
>> but both the name of the supply and the usage pattern suggest that it is
>> being used for the main power for the device and is not at all optional
>> for the device for function, there is no meaningful handling for absent
>> supplies.  Such regulators should use the vanilla regulator_get()
>> interface, it will ensure that even if a supply is not described in the
>> system integration one will be provided in software.
> 
> I guess commits e21dd290881b ("drm/panfrost: Enable devfreq to work
> without regulator") and c90f30812a79 ("drm/panfrost: Add missing check
> for pfdev->regulator")
> in -next should be reverted or partially reverted?

Ah, I didn't realise that regulator_get() will return a dummy regulator
if none is provided in the DT. In theory that seems like a nicer
solution to my two commits. However there's still a problem - the dummy
regulator returned from regulator_get() reports errors when
regulator_set_voltage() is called. So I get errors like this:

[  299.861165] panfrost e82c0000.mali: Cannot set voltage 1100000 uV
[  299.867294] devfreq devfreq0: dvfs failed with (-22) error

(And therefore the frequency isn't being changed)

Ideally we want a dummy regulator that will silently ignore any
regulator_set_voltage() calls.

Steve