Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220810103156.1214996-1-chenhuacai@loongson.cn>
 <f92fc4f34784217206b53a3709538d5c@kernel.org> <CAAhV-H7DbvjEcms9Y81t_=WyDnKu5vuB4x7g7vU3f9CUhZykHQ@mail.gmail.com>
 <1359c52d-5194-7306-0e76-cde97b5aa31c@xen0n.name> <87lervb74u.wl-maz@kernel.org>
In-Reply-To: <87lervb74u.wl-maz@kernel.org>
From:   Huacai Chen <chenhuacai@kernel.org>
Date:   Thu, 11 Aug 2022 16:44:08 +0800
Message-ID: <CAAhV-H5D+zHRaAPUqRQOkrv_ae+9UUEt9Cqcpcqd2cWhSiSbiw@mail.gmail.com>
Subject: Re: [PATCH] LoongArch: Fix the !CONFIG_SMP build for irqchip drivers
To:     Marc Zyngier <maz@kernel.org>
Cc:     WANG Xuerui <kernel@xen0n.name>,
        Huacai Chen <chenhuacai@loongson.cn>,
        Thomas Gleixner <tglx@linutronix.de>,
        loongarch@lists.linux.dev, Xuefeng Li <lixuefeng@loongson.cn>,
        Guo Ren <guoren@kernel.org>,
        Jiaxun Yang <jiaxun.yang@flygoat.com>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi, Marc and Xuerui,

On Thu, Aug 11, 2022 at 2:56 PM Marc Zyngier <maz@kernel.org> wrote:
>
> On Thu, 11 Aug 2022 01:58:15 +0100,
> WANG Xuerui <kernel@xen0n.name> wrote:
> >
> > On 8/10/22 23:38, Huacai Chen wrote:
> >
> > > Hi, Marc,
> > >
> > > On Wed, Aug 10, 2022 at 7:01 PM Marc Zyngier <maz@kernel.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@loongson.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.
>
> And that's exactly my point. Yes, it is always possible to build a UP
> system. But is it worth *maintaining* a configuration option for this?
> I seriously doubt it.
>
> My advise is to stick to SMP only for now (it will run just fine on a
> UP machine), and only if upstream users find it completely
> unacceptable should a !SMP option be introduced, or make it a runtime
> decision (32bit ARM has had SMP_ON_UP support for a long time).
OK, I will drop this patch and follow the ARM64 method, thanks.

Huacai
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.