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 <[email protected]>
---
arch/loongarch/include/asm/smp.h | 8 ++++++++
arch/loongarch/kernel/irq.c | 2 ++
drivers/irqchip/irq-loongson-eiointc.c | 5 +++++
3 files changed, 15 insertions(+)
diff --git a/arch/loongarch/include/asm/smp.h b/arch/loongarch/include/asm/smp.h
index 71189b28bfb2..9ee5a309df5b 100644
--- a/arch/loongarch/include/asm/smp.h
+++ b/arch/loongarch/include/asm/smp.h
@@ -12,6 +12,8 @@
#include <linux/threads.h>
#include <linux/cpumask.h>
+#ifdef CONFIG_SMP
+
extern int smp_num_siblings;
extern int num_processors;
extern int disabled_cpus;
@@ -112,4 +114,10 @@ static inline void __cpu_die(unsigned int cpu)
extern void play_dead(void);
#endif
+#else /* !CONFIG_SMP */
+
+#define cpu_logical_map(cpu) 0
+
+#endif
+
#endif /* __ASM_SMP_H */
diff --git a/arch/loongarch/kernel/irq.c b/arch/loongarch/kernel/irq.c
index 1ba19c76563e..d83623bc59fa 100644
--- a/arch/loongarch/kernel/irq.c
+++ b/arch/loongarch/kernel/irq.c
@@ -87,6 +87,7 @@ static void __init init_vec_parent_group(void)
acpi_table_parse(ACPI_SIG_MCFG, early_pci_mcfg_parse);
}
+#ifdef CONFIG_SMP
static int __init get_ipi_irq(void)
{
struct irq_domain *d = irq_find_matching_fwnode(cpuintc_handle, DOMAIN_BUS_ANY);
@@ -96,6 +97,7 @@ static int __init get_ipi_irq(void)
return -EINVAL;
}
+#endif
void __init init_IRQ(void)
{
diff --git a/drivers/irqchip/irq-loongson-eiointc.c b/drivers/irqchip/irq-loongson-eiointc.c
index 80d8ca6f2d46..17f94f3c11af 100644
--- a/drivers/irqchip/irq-loongson-eiointc.c
+++ b/drivers/irqchip/irq-loongson-eiointc.c
@@ -18,6 +18,8 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
+#include <asm/smp.h>
+
#define EIOINTC_REG_NODEMAP 0x14a0
#define EIOINTC_REG_IPMAP 0x14c0
#define EIOINTC_REG_ENABLE 0x1600
@@ -96,6 +98,9 @@ static int eiointc_set_irq_affinity(struct irq_data *d, const struct cpumask *af
struct cpumask intersect_affinity;
struct eiointc_priv *priv = d->domain->host_data;
+ if (!IS_ENABLED(CONFIG_SMP))
+ return -EPERM;
+
raw_spin_lock_irqsave(&affinity_lock, flags);
cpumask_and(&intersect_affinity, affinity, cpu_online_mask);
--
2.31.1
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 <[email protected]>
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.
M.
--
Jazz is not dead. It just smells funny...
Hi, Marc,
On Wed, Aug 10, 2022 at 7:01 PM Marc Zyngier <[email protected]> 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 <[email protected]>
>
> 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.
Huacai
>
> M.
> --
> Jazz is not dead. It just smells funny...
On 8/10/22 23:38, Huacai Chen wrote:
> Hi, Marc,
>
> On Wed, Aug 10, 2022 at 7:01 PM Marc Zyngier <[email protected]> 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 <[email protected]>
>> 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/
On Thu, 11 Aug 2022 01:58:15 +0100,
WANG Xuerui <[email protected]> wrote:
>
> On 8/10/22 23:38, Huacai Chen wrote:
>
> > Hi, Marc,
> >
> > On Wed, Aug 10, 2022 at 7:01 PM Marc Zyngier <[email protected]> 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 <[email protected]>
> >> 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).
M.
--
Without deviation from the norm, progress is not possible.
Hi, Marc and Xuerui,
On Thu, Aug 11, 2022 at 2:56 PM Marc Zyngier <[email protected]> wrote:
>
> On Thu, 11 Aug 2022 01:58:15 +0100,
> WANG Xuerui <[email protected]> wrote:
> >
> > On 8/10/22 23:38, Huacai Chen wrote:
> >
> > > Hi, Marc,
> > >
> > > On Wed, Aug 10, 2022 at 7:01 PM Marc Zyngier <[email protected]> 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 <[email protected]>
> > >> 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.