[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <adbe8114-45b9-2869-3906-a9c5745eb749@cn.fujitsu.com>
Date: Mon, 3 Jul 2017 10:34:40 +0800
From: Dou Liyang <douly.fnst@...fujitsu.com>
To: Thomas Gleixner <tglx@...utronix.de>
CC: <x86@...nel.org>, <linux-kernel@...r.kernel.org>,
<xen-devel@...ts.xenproject.org>, <mingo@...nel.org>,
<hpa@...or.com>, <ebiederm@...ssion.com>, <bhe@...hat.com>,
<boris.ostrovsky@...cle.com>, <peterz@...radead.org>,
<izumi.taku@...fujitsu.com>
Subject: Re: [PATCH v5 07/12] x86/apic: Unify interrupt mode setup for UP
system
Hi Thomas,
At 07/03/2017 02:19 AM, Thomas Gleixner wrote:
> On Fri, 30 Jun 2017, Dou Liyang wrote:
>> static inline int apic_force_enable(unsigned long addr)
>> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
>> index 0601054..9bf7e95 100644
>> --- a/arch/x86/kernel/apic/apic.c
>> +++ b/arch/x86/kernel/apic/apic.c
>> @@ -1198,6 +1198,10 @@ static int __init apic_intr_mode_select(int *upmode)
>> }
>> #endif
>>
>> +#ifdef CONFIG_UP_LATE_INIT
>> + *upmode = true;
>> +#endif
>
> This is really wrong. The upmode decision, which is required for calling
> apic_bsp_setup() should not happen here, really. As I told you in the
> previous patch, use the return code and then you can make further decisions
> in apic_intr_mode_init().
Really thanks for your detail explaining, I learned more than i read
from books about the programming skill.
>
> And you do it there w/o any ifdeffery:
>
> static void apic_intr_mode_init(void)
> {
> bool upmode = IS_ENABLED(CONFIG_UP_LATE_INIT);
>
> switch (....) {
> case XXXX:
> upmode = true;
> ....
> }
> apic_bsp_setup(upmode);
> }
This looks more beautiful than mine. I will use it in the next version.
Thanks,
dou.
>
> Thanks,
>
> tglx
>
>
>
Powered by blists - more mailing lists