public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Suresh Siddha <suresh.b.siddha@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: enable x2apic early at the first point
Date: Fri, 20 Feb 2009 10:51:27 +0100	[thread overview]
Message-ID: <20090220095127.GK24555@elte.hu> (raw)
In-Reply-To: <499DD40F.40102@kernel.org>


* Yinghai Lu <yinghai@kernel.org> wrote:

> Impact: fix bug.
> 
> otherwise will get panic from early_acpi_boot_init()
> also make disable_x2apic global, so could use it it x2_apic_xxx.c
> and can get warning if preenabled system using nox2apic.
> 
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> 
> ---
>  arch/x86/kernel/apic/apic.c           |    3 +--
>  arch/x86/kernel/apic/x2apic_cluster.c |    5 ++++-
>  arch/x86/kernel/apic/x2apic_phys.c    |    5 ++++-
>  arch/x86/kernel/apic/x2apic_uv_x.c    |    4 +++-
>  drivers/pci/dmar.c                    |    3 ++-
>  5 files changed, 14 insertions(+), 6 deletions(-)

I've applied it because it fixes a real bug, but this code 
really needs a cleanup. Look at the repeat patterns:

> Index: linux-2.6/arch/x86/kernel/apic/x2apic_cluster.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/apic/x2apic_cluster.c
> +++ linux-2.6/arch/x86/kernel/apic/x2apic_cluster.c
> @@ -14,8 +14,11 @@ DEFINE_PER_CPU(u32, x86_cpu_to_logical_a
>  
>  static int x2apic_acpi_madt_oem_check(char *oem_id, char *oem_table_id)
>  {
> -	if (cpu_has_x2apic)
> +	if (cpu_has_x2apic && !disable_x2apic) {
> +		x2apic = 1;
> +		enable_x2apic();
>  		return 1;
> +	}
>  
>  	return 0;
>  }
> Index: linux-2.6/arch/x86/kernel/apic/x2apic_phys.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/apic/x2apic_phys.c
> +++ linux-2.6/arch/x86/kernel/apic/x2apic_phys.c
> @@ -21,8 +21,11 @@ early_param("x2apic_phys", set_x2apic_ph
>  
>  static int x2apic_acpi_madt_oem_check(char *oem_id, char *oem_table_id)
>  {
> -	if (cpu_has_x2apic && x2apic_phys)
> +	if (cpu_has_x2apic && !disable_x2apic && x2apic_phys) {
> +		x2apic = 1;
> +		enable_x2apic();
>  		return 1;
> +	}
>  
>  	return 0;
>  }
> Index: linux-2.6/arch/x86/kernel/apic/x2apic_uv_x.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/apic/x2apic_uv_x.c
> +++ linux-2.6/arch/x86/kernel/apic/x2apic_uv_x.c
> @@ -41,8 +41,10 @@ static int uv_acpi_madt_oem_check(char *
>  			uv_system_type = UV_LEGACY_APIC;
>  		else if (!strcmp(oem_table_id, "UVX"))
>  			uv_system_type = UV_X2APIC;
> -		else if (!strcmp(oem_table_id, "UVH")) {
> +		else if (!strcmp(oem_table_id, "UVH") && !disable_x2apic) {
>  			uv_system_type = UV_NON_UNIQUE_APIC;
> +			x2apic = 1;
> +			enable_x2apic();
>  			return 1;
>  		}
>  	}

Such repeat patterns with small variations are always the sign 
of an inefficient code structure.

The clean approach would be to have one generic helper function 
concentrated into enable_x2apic(). So instead of:

 static int x2apic_acpi_madt_oem_check(char *oem_id, char *oem_table_id)
 {
	if (cpu_has_x2apic && !disable_x2apic && x2apic_phys) {
		x2apic = 1;
		enable_x2apic();
		return 1;
	}

	return 0;
 }

We'd have:

 static int x2apic_acpi_madt_oem_check(char *oem_id, char *oem_table_id)
 {
	if (!x2apic_phys)
		return 0;

	return x86_enable_x2apic();
 }

That way all the repeat and common functionality (and the return 
code logic) is concentrated into enable_x2apic(), and the 
x2apic_acpi_madt_oem_check() function has _only_ its own special 
check open-coded. (namely, whether physical ID delivery mode is 
forced off.)

Okay?

	Ingo

  parent reply	other threads:[~2009-02-20  9:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-19 21:50 [PATCH] x86: enable x2apic early at the first point Yinghai Lu
2009-02-19 22:13 ` Suresh Siddha
2009-02-19 22:42   ` Yinghai Lu
2009-02-19 23:28     ` Suresh Siddha
2009-02-20  8:35       ` Ingo Molnar
2009-02-20  9:09         ` Gleb Natapov
2009-02-20  9:41           ` Ingo Molnar
2009-02-20 10:58             ` Gleb Natapov
2009-02-20 11:06               ` Ingo Molnar
2009-02-20 11:06                 ` Gleb Natapov
2009-02-20 12:33                 ` Gleb Natapov
2009-02-20 12:59                   ` Ingo Molnar
2009-02-20  9:51 ` Ingo Molnar [this message]
2009-02-20  9:55   ` Ingo Molnar
2009-02-21 22:23     ` Suresh Siddha
2009-02-21 22:43       ` Yinghai Lu
2009-02-21 23:33         ` Suresh Siddha
2009-02-22 17:21       ` Ingo Molnar

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=20090220095127.GK24555@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=yinghai@kernel.org \
    /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