linux-kernel - Re: [PATCH] acpi: handle ACPI0007 Device in acpi_early_set

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, 10 Sep 2010 16:45:56 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Bjorn Helgaas <bjorn.helgaas@...com>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	"Brown, Len" <len.brown@...el.com>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] acpi: handle ACPI0007 Device in acpi_early_set_pdc

On Fri, 10 Sep 2010 12:20:36 -0700
Yinghai Lu <yinghai@...nel.org> wrote:

> 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@...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@...nel.org
>     Cc: Tony Luck <tony.luck@...el.com>
>     Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>
>     Signed-off-by: Alex Chiang <achiang@...com>
>     Signed-off-by: Len Brown <len.brown@...el.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
> 

Maybe.  But first can you please address Bjorn's suggestions below?

> 
> > 
> >> Signed-off-by: Yinghai Lu <yinghai@...nel.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/