linux-kernel - Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling

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: <dd26eb18-8ac4-22a6-29b0-dbbe5fa6075b@gmail.com>
Date:   Thu, 12 Nov 2020 19:59:36 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Alan Stern <stern@...land.harvard.edu>,
        Peter Chen <Peter.Chen@....com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Lee Jones <lee.jones@...aro.org>,
        Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Peter Geis <pgwipeout@...il.com>,
        Nicolas Chauvet <kwizart@...il.com>,
        linux-samsung-soc@...r.kernel.org, devel@...verdev.osuosl.org,
        linux-usb@...r.kernel.org, linux-pwm@...r.kernel.org,
        linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linux-media@...r.kernel.org, linux-tegra@...r.kernel.org
Subject: Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage
 scaling

11.11.2020 14:55, Mark Brown пишет:
> On Wed, Nov 11, 2020 at 12:23:41AM +0300, Dmitry Osipenko wrote:
>> 10.11.2020 23:32, Mark Brown пишет:
> 
>>>>> +	if (!device_property_present(dc->dev, "core-supply"))
>>>>> +		return;
> 
>>>> This is a potentially heavy operation, so I think we should avoid that
>>>> here. How about you use devm_regulator_get_optional() in ->probe()? That
>>>> returns -ENODEV if no regulator was specified, in which case you can set
>>>> dc->core_reg = NULL and use that as the condition here.
> 
>>> Or enumerate the configurable voltages after getting the regulator and
>>> handle that appropriately which would be more robust in case there's
>>> missing or unusual constraints.
> 
>> I already changed that code to use regulator_get_optional() for v2.
> 
> That doesn't look entirely appropriate given that the core does most
> likely require some kind of power to operate.

We will need to do this because older DTBs won't have that regulator and
we want to keep them working.

Also, some device-trees won't have that regulator anyways because board
schematics isn't available, and thus, we can't fix them.

>> Regarding the enumerating supported voltage.. I think this should be
>> done by the OPP core, but regulator core doesn't work well if
>> regulator_get() is invoked more than one time for the same device, at
>> least there is a loud debugfs warning about an already existing
> 
> I don't understand why this would be an issue - if nothing else the core
> could just offer an interface to trigger the check.

It's not an issue, I just described what happens when device driver
tries to get a regulator twice.

There was an issue once that check is added to the regulator core code.
But perhaps not worth to discuss it for now because I don't remember
details.

>> directory for a regulator. It's easy to check whether the debug
>> directory exists before creating it, like thermal framework does it for
>> example, but then there were some other more difficult issues.. I don't
>> recall what they were right now. Perhaps will be easier to simply get a
>> error from regulator_set_voltage() for now because it shouldn't ever
>> happen in practice, unless device-tree has wrong constraints.
> 
> The constraints might not be wrong, there might be some board which has
> a constraint somewhere for 
> 

In this case board's DT shouldn't specify unsupportable OPPs.