From: Tudor Laurentiu <b10716@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: Scott Wood <scottwood@freescale.com>,
Laurentiu.Tudor@freescale.com,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
Stuart Yoder <stuart.yoder@freescale.com>
Subject: Re: [PATCH] powerpc: move epapr paravirt init of power_save to an initcall
Date: Mon, 5 May 2014 15:35:33 +0300 [thread overview]
Message-ID: <53678595.4090707@freescale.com> (raw)
In-Reply-To: <53678236.7060206@suse.de>
On 05/05/2014 03:21 PM, Alexander Graf wrote:
> On 05/05/2014 02:17 PM, Tudor Laurentiu wrote:
>> On 04/30/2014 11:09 PM, Alexander Graf wrote:
>>>
>>> On 30.04.14 22:03, Stuart Yoder wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Alexander Graf [mailto:agraf@suse.de]
>>>>> Sent: Wednesday, April 30, 2014 2:56 PM
>>>>> To: Yoder Stuart-B08248; benh@kernel.crashing.org; Wood Scott-B07421
>>>>> Cc: linuxppc-dev@lists.ozlabs.org
>>>>> Subject: Re: [PATCH] powerpc: move epapr paravirt init of
>>>>> power_save to
>>>>> an initcall
>>>>>
>>>>>
>>>>> On 30.04.14 21:54, Stuart Yoder wrote:
>>>>>> From: Stuart Yoder <stuart.yoder@freescale.com>
>>>>>>
>>>>>> some restructuring of epapr paravirt init resulted in
>>>>>> ppc_md.power_save being set, and then overwritten to
>>>>>> NULL during machine_init. This patch splits the
>>>>>> initialization of ppc_md.power_save out into a postcore
>>>>>> init call.
>>>>>>
>>>>>> Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
>>>>>> ---
>>>>>> arch/powerpc/kernel/epapr_paravirt.c | 25
>>>>>> ++++++++++++++++++++-----
>>>>>> 1 file changed, 20 insertions(+), 5 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/powerpc/kernel/epapr_paravirt.c
>>>>> b/arch/powerpc/kernel/epapr_paravirt.c
>>>>>> index 6300c13..c49b69c 100644
>>>>>> --- a/arch/powerpc/kernel/epapr_paravirt.c
>>>>>> +++ b/arch/powerpc/kernel/epapr_paravirt.c
>>>>>> @@ -52,11 +52,6 @@ static int __init
>>>>>> early_init_dt_scan_epapr(unsigned
>>>>> long node,
>>>>>> #endif
>>>>>> }
>>>>>>
>>>>>> -#if !defined(CONFIG_64BIT) || defined(CONFIG_PPC_BOOK3E_64)
>>>>>> - if (of_get_flat_dt_prop(node, "has-idle", NULL))
>>>>>> - ppc_md.power_save = epapr_ev_idle;
>>>>>> -#endif
>>>>>> -
>>>>>> epapr_paravirt_enabled = true;
>>>>>>
>>>>>> return 1;
>>>>>> @@ -69,3 +64,23 @@ int __init epapr_paravirt_early_init(void)
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> +static int __init epapr_idle_init_dt_scan(unsigned long node,
>>>>>> + const char *uname,
>>>>>> + int depth, void *data)
>>>>>> +{
>>>>>> +#if !defined(CONFIG_64BIT) || defined(CONFIG_PPC_BOOK3E_64)
>>>>>> + if (of_get_flat_dt_prop(node, "has-idle", NULL))
>>>>>> + ppc_md.power_save = epapr_ev_idle;
>>>>>> +#endif
>>>>>> + return 0;
>>>>>> +}
>>>>>> +
>>>>>> +static int __init epapr_idle_init(void)
>>>>>> +{
>>>>>> + if (epapr_paravirt_enabled)
>>>>>> + of_scan_flat_dt(epapr_idle_init_dt_scan, NULL);
>>>>> Doesn't this scan all nodes? We only want to match on
>>>>> /hypervisor/has-idle, no?
>>>> I cut/pasted from the approach the existing code in that file
>>>> took, but yes you're right we just need the one property.
>>>> Let me respin that to look at the hypervisor node only.
>>>
>>> Yeah, the same commit that introduced the breakage on has-idle also
>>> removed the explicit check for /hypervisor.
>>>
>>> Laurentiu, was this change on purpose?
>>>
>>
>> Alex,
>>
>> IIRC, at that time i had to switch from the normal "of" functions to a
>> completely different api that's available in early init stage. This
>> early "of" api is pretty limited (e.g. doesn't have a way to address a
>> specific node) and i had to use that function that scans the whole tree.
>
> Ok, so it is an accident. Could you please post a patch that checks that
> the node we're looking at is called "hypervisor"? The simple API should
> give you enough information for that at least. Maybe you could even
> check that the parent node is the root node.
>
Just had a quick look and it looks that that early fdt api was improved
with a function that allows specifying a starting path for the scan
(of_scan_flat_dt_by_path() added in commit
57d74bcf3072b65bde5aa540cedc976a75c48e5c). So i think we can simply use
that instead.
---
Best Regards, Laurentiu
prev parent reply other threads:[~2014-05-05 12:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-30 19:54 [PATCH] powerpc: move epapr paravirt init of power_save to an initcall Stuart Yoder
2014-04-30 19:56 ` Alexander Graf
2014-04-30 20:03 ` Stuart Yoder
2014-04-30 20:06 ` Alexander Graf
2014-04-30 20:09 ` Alexander Graf
2014-05-05 12:17 ` Tudor Laurentiu
2014-05-05 12:21 ` Alexander Graf
2014-05-05 12:35 ` Tudor Laurentiu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53678595.4090707@freescale.com \
--to=b10716@freescale.com \
--cc=Laurentiu.Tudor@freescale.com \
--cc=agraf@suse.de \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=scottwood@freescale.com \
--cc=stuart.yoder@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.