linux-kernel - Re: [PATCH 1/3] PM: domains: Drop the performance state vote for a device at detach

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:   Fri, 3 Sep 2021 09:01:00 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        linux-pm@...r.kernel.org
Cc:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Stephan Gerhold <stephan@...hold.net>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] PM: domains: Drop the performance state vote for a
 device at detach

02.09.2021 13:16, Ulf Hansson пишет:
> When a device is detached from its genpd, genpd loses track of the device,
> including its performance state vote that may have been requested for it.
> 
> Rather than relying on the consumer driver to drop the performance state
> vote for its device, let's do it internally in genpd when the device is
> getting detached. In this way, we makes sure that the aggregation of the
> votes in genpd becomes correct.

This is a dangerous behaviour in a case where performance state
represents voltage. If hardware is kept active on detachment, say it's
always-on, then it may be a disaster to drop the voltage for the active
hardware.

It's safe to drop performance state only if you assume that there is a
firmware behind kernel which has its own layer of performance management
and it will prevent the disaster by saying 'nope, I'm not doing this'.

The performance state should be persistent for a device and it should be
controlled in a conjunction with runtime PM. If platform wants to drop
performance state to zero on detachment, then this behaviour should be
specific to that platform.