[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1359c52d-5194-7306-0e76-cde97b5aa31c@xen0n.name>
Date: Thu, 11 Aug 2022 08:58:15 +0800
From: WANG Xuerui <kernel@...0n.name>
To: Huacai Chen <chenhuacai@...nel.org>, Marc Zyngier <maz@...nel.org>
Cc: Huacai Chen <chenhuacai@...ngson.cn>,
Thomas Gleixner <tglx@...utronix.de>,
loongarch@...ts.linux.dev, Xuefeng Li <lixuefeng@...ngson.cn>,
Guo Ren <guoren@...nel.org>,
Jiaxun Yang <jiaxun.yang@...goat.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] LoongArch: Fix the !CONFIG_SMP build for irqchip drivers
On 8/10/22 23:38, Huacai Chen wrote:
> Hi, Marc,
>
> On Wed, Aug 10, 2022 at 7:01 PM Marc Zyngier <maz@...nel.org> wrote:
>> On 2022-08-10 11:31, Huacai Chen wrote:
>>> 1, Guard get_ipi_irq() in CONFIG_SMP;
>>> 2, Define cpu_logical_map() for the EIOINTC driver;
>>> 3, Make eiointc_set_irq_affinity() return early for !CONFIG_SMP.
>>>
>>> Signed-off-by: Huacai Chen <chenhuacai@...ngson.cn>
>> Frankly, the real question is why do you even bother? As far as
>> I can tell, LoongArch has no UP system.
>>
>> arm64 crossed that bridge a long time ago, and we never looked
>> back, because these systems hardly exist.
>>
>> I'd rather you simply have a CONFIG_SMP always set to 'y', and
>> be done with it forever.
> LoongArch also has low-end processors (even LoongArch64). Though we
> haven't translate all documents at
> https://loongson.github.io/LoongArch-Documentation/ in time, there are
> currently 4 LoongArch64 processors: Loongson-2K500 (single-core),
> Loongon-2K1000 (dual-core), Loongson-3A5000 (quad-core) and
> Loongson-3C5000 (16-core). So we indeed need a UP configuration.
> Thanks.
I remember seeing an alternatives mechanism in the works for LoongArch.
If such alternatives mechanism is to be upstreamed in short order, why
make SMP one more build-time time option that developers have to decide
upon? It's not like SMP code would break, or run with unacceptable
overhead, on UP systems AFAIK, so it's probably better to not
preemptively support so many *possibilities* that haven't been realized
so the *current* maintainability suffers. Practically one can't buy the
LoongArch 2K line of products anywhere right now, and the few companies
developing for it are likely not using upstream kernels anyway, so it's
not like we can't wait either.
--
WANG "xen0n" Xuerui
Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
Powered by blists - more mailing lists