linux-kernel - Re: [PATCH v6 20/25] drivers: firmware: psci: Introduce psci_dt_topology

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPDyKFpJQZ87ViwZxX_yBnKPzgRv5YxbLz=qxScBTMCvY6e2vw@mail.gmail.com>
Date:   Tue, 10 Apr 2018 09:19:26 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Mark Rutland <mark.rutland@....com>
Cc:     "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Sudeep Holla <sudeep.holla@....com>,
        Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
        Linux PM <linux-pm@...r.kernel.org>,
        Kevin Hilman <khilman@...nel.org>,
        Lina Iyer <ilina@...eaurora.org>,
        Lina Iyer <lina.iyer@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Stephen Boyd <sboyd@...nel.org>,
        Juri Lelli <juri.lelli@....com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-arm-msm@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 20/25] drivers: firmware: psci: Introduce psci_dt_topology_init()

On 14 March 2018 at 18:38, Mark Rutland <mark.rutland@....com> wrote:
> On Wed, Mar 14, 2018 at 05:58:30PM +0100, Ulf Hansson wrote:
>> In case the hierarchical layout is used in DT, we want to initialize the
>> corresponding PM domain topology for the CPUs, by using the generic PM
>> domain (aka genpd) infrastructure.
>>
>> At first glance, it may seem feasible to hook into the existing
>> psci_dt_init() function, although because it's called quite early in the
>> boot sequence, allocating the dynamic data structure for a genpd doesn't
>> work.
>>
>> Therefore, let's export a new init function for PSCI,
>> psci_dt_topology_init(), which the ARM machine code should call from a
>> suitable initcall.
>>
>> Succeeding to initialize the PM domain topology, which means at least one
>> instance of a genpd becomes created, allows us to continue to enable the
>> PSCI OS initiated mode for the platform. If everything turns out fine,
>> let's print a message in log to inform the user about the changed mode.
>>
>> In case of any failures, we stick to the default PSCI Platform Coordinated
>> mode.
>
> For kexec/kdump we'll need to explicitly set the suspend mode to
> platform coordinated if for whatever reason we choose not to use OSI.

Could you please elaborate on this? I am not really understanding what
you are suggesting me to do and why.

>
>>
>> Cc: Lina Iyer <ilina@...eaurora.org>
>> Co-developed-by: Lina Iyer <lina.iyer@...aro.org>
>> Signed-off-by: Ulf Hansson <ulf.hansson@...aro.org>
>> ---
>>  drivers/firmware/psci.c | 31 +++++++++++++++++++++++++++++++
>>  include/linux/psci.h    |  2 ++
>>  2 files changed, 33 insertions(+)
>>
>> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
>> index 463f78c..45d55fc 100644
>> --- a/drivers/firmware/psci.c
>> +++ b/drivers/firmware/psci.c
>> @@ -723,6 +723,37 @@ int __init psci_dt_init(void)
>>       return ret;
>>  }
>>
>> +int __init psci_dt_topology_init(void)
>> +{
>> +     struct device_node *np;
>> +     int ret;
>> +
>> +     if (!psci_has_osi_support())
>> +             return 0;
>> +
>> +     np = of_find_matching_node_and_match(NULL, psci_of_match, NULL);
>> +     if (!np)
>> +             return -ENODEV;
>> +
>> +     /* Initialize the CPU PM domains based on topology described in DT. */
>> +     ret = psci_dt_init_pm_domains(np);
>> +     if (ret <= 0)
>> +             goto out;
>> +
>> +     /* Enable OSI mode. */
>> +     ret = invoke_psci_fn(PSCI_1_0_FN_SET_SUSPEND_MODE,
>> +                          PSCI_1_0_SUSPEND_MODE_OSI, 0, 0);
>
> IIUC, this patch will need to be moved after the subsequent two patches
> to ensure that this series bisects cleanly.

Actually not.

$subject patch adds a new init function, which purpose is to
initialize the PSCI PM domains. At this point none is calling it.

The following changes, builds on top, making it possible to add CPU
devices to the PSCI PM domains (if the PM domains has been created and
OSI mode successfully enabled) and also to properly deal CPU hotplug
when OSI mode is enabled.

The purpose doing it this way is to keep changes small and
review-able, but in principle I can squash 20, 21 and 22 - if you
prefer.

Again, thanks for reviewing!

Kind regards
Uffe