mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai@kernel.org>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Brown, Len" <len.brown@intel.com>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] acpi: handle ACPI0007 Device in acpi_early_set_pdc
Date: Fri, 10 Sep 2010 12:20:36 -0700	[thread overview]
Message-ID: <4C8A8504.9000606@kernel.org> (raw)
In-Reply-To: <201009101210.31942.bjorn.helgaas@hp.com>

On 09/10/2010 11:10 AM, Bjorn Helgaas wrote:
> On Thursday, September 09, 2010 07:56:59 pm Yinghai Lu wrote:
>>
>> When bios switch to use Device object instead of Processor statement.
>>
>> the SSDT for Pstate/Cstate/Tstate can not be loaded dynamically.
>>
>> So try to scan ACPI0007 in addition to Processor.
>>
>> this fix regression: 2.6.32 is ok.
> 
> Can you include the URL of the regression bug report?  And maybe
> the commit that introduced the regression?

the commit should be

commit d8191fa4a33fdc817277da4f2b7f771ff605a41c
Author: Alex Chiang <achiang@hp.com>
Date:   Mon Feb 22 12:11:39 2010 -0700

    ACPI: processor: driver doesn't need to evaluate _PDC
    
    Now that the early _PDC evaluation path knows how to correctly
    evaluate _PDC on only physically present processors, there's no
    need for the processor driver to evaluate it later when it loads.
    
    To cover the hotplug case, push _PDC evaluation down into the
    hotplug paths.
    
    Cc: x86@kernel.org
    Cc: Tony Luck <tony.luck@intel.com>
    Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
    Signed-off-by: Alex Chiang <achiang@hp.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

that is between 2.6.34-rc1 and 2.6.34-rc2.

So we need put this patch in stable tree for 2.6.34, .35, .36

Yinghai

> 
>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>>
>> ---
>>  drivers/acpi/processor_core.c |    1 +
>>  1 file changed, 1 insertion(+)
>>
>> Index: linux-2.6/drivers/acpi/processor_core.c
>> ===================================================================
>> --- linux-2.6.orig/drivers/acpi/processor_core.c
>> +++ linux-2.6/drivers/acpi/processor_core.c
>> @@ -352,4 +352,5 @@ void __init acpi_early_processor_set_pdc
>>  	acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
>>  			    ACPI_UINT32_MAX,
>>  			    early_init_pdc, NULL, NULL, NULL);
>> +	acpi_get_devices("ACPI0007", early_init_pdc, NULL, NULL);
> 
> I hate having to walk the namespace.  Usually that's a clue that
> there's something wrong with our ACPI device model, because it'd
> be better to handle everything in a driver .add() method.  But
> maybe this early _PDC thing is so special that it can't be helped
> in this case.
> 
> But I do think you could probably fix this to walk the namespace
> once rather than twice.  Maybe you could use something like
> acpi_walk_namespace(ACPI_TYPE_ANY, ...) with a callback that
> recognizes both ACPI_TYPE_PROCESSOR and "ACPI_TYPE_DEVICE with
> HID ACPI0007".
> 
> Bjorn


       reply	other threads:[~2010-09-10 19:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4C89906B.1050406@kernel.org>
     [not found] ` <201009101210.31942.bjorn.helgaas@hp.com>
2010-09-10 19:20   ` Yinghai Lu [this message]
2010-09-10 23:45     ` Andrew Morton
2010-09-11  2:06       ` Yinghai Lu
2010-09-13 17:28         ` Bjorn Helgaas
2010-09-17  7:21           ` Yinghai Lu
2010-09-17 13:56             ` Bjorn Helgaas
2010-09-17 18:37               ` Yinghai Lu
2010-09-18  6:26               ` [PATCH -v4] acpi: Handle " Yinghai Lu
2010-10-01  6:07                 ` Len Brown

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=4C8A8504.9000606@kernel.org \
    --to=yinghai@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=bjorn.helgaas@hp.com \
    --cc=hpa@zytor.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome