[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1265161887.16916.569.camel@localhost.localdomain>
Date: Tue, 02 Feb 2010 17:51:27 -0800
From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
To: Alex Chiang <achiang@...com>
Cc: "lenb@...nel.org" <lenb@...nel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/12] ACPI: processor driver vs. core
Hi Alex,
Sorry for not responding on this one. Just finished up looking through
all the patches in the series. It makes things very clean and patches
are neatly split up. Thanks for doing this.
Only thing I wanted to mention was, it would have been a bit cleaner to
keep _pdc stuff in a separate file. But, it is OK as you have done it as
well.
Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>
On Tue, 2010-02-02 at 15:17 -0800, Alex Chiang wrote:
> Hi Venki,
>
> Do you have any opinions on this patchset? If so, I'd like to
> address them.
>
> Thanks,
> /ac
>
> * Alex Chiang <achiang@...com>:
> > This series cleans up some of the mess I made when introducing
> > early _PDC.
> >
> > The major change is renaming processor_core.c to processor_driver.c,
> > and then renaming processor_pdc.c to processor_core.c.
> >
> > The idea is that the code in processor_core.c will always be built
> > statically into the kernel (as long as ACPI is configured), while
> > allowing the ACPI processor driver to remain modular (if so desired).
> >
> > We do this because part of the cleanups involves teaching the
> > early _PDC evaluation code how to determine if a processor is
> > physically present or not -- aka enumeration -- and that sort
> > of code doesn't really belong in a file named processor_pdc.
> >
> > There are quite a few checkpatch errors in the first rename patch,
> > and I'll look at cleaning those up in a later series.
> >
> > /ac
> >
> > ---
> >
> > Alex Chiang (12):
> > ACPI: processor: mv processor_core.c processor_driver.c
> > ACPI: processor: mv processor_pdc.c processor_core.c
> > ACPI: processor: export acpi_get_cpuid()
> > ACPI: processor: move acpi_get_cpuid into processor_core.c
> > ACPI: processor: add internal processor_physically_present()
> > ACPI: processor: remove early _PDC optin quirks
> > ACPI: processor: driver doesn't need to evaluate _PDC
> > ACPI: processor: refactor internal map_lapic_id()
> > ACPI: processor: refactor internal map_x2apic_id()
> > ACPI: processor: refactor internal map_lsapic_id()
> > ACPI: processor: push file static MADT pointer into internal map_madt_entry()
> > ACPI: processor core: style and sparse cleanups
> >
> >
> > Documentation/kernel-parameters.txt | 4
> > arch/ia64/kernel/acpi.c | 3
> > arch/x86/kernel/acpi/boot.c | 3
> > drivers/acpi/Makefile | 4
> > drivers/acpi/processor_core.c | 1149 +++++------------------------------
> > drivers/acpi/processor_driver.c | 976 ++++++++++++++++++++++++++++++
> > drivers/acpi/processor_pdc.c | 209 ------
> > include/acpi/processor.h | 10
> > 8 files changed, 1172 insertions(+), 1186 deletions(-)
> > create mode 100644 drivers/acpi/processor_driver.c
> > delete mode 100644 drivers/acpi/processor_pdc.c
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo@...r.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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/
Powered by blists - more mailing lists