[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <fdedcd38-4688-4938-9184-2eaa5dedeb43@app.fastmail.com>
Date: Thu, 04 Jul 2024 04:08:09 +0800
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Thomas Bogendoerfer" <tsbogend@...ha.franken.de>
Cc: "Florian Fainelli" <florian.fainelli@...adcom.com>,
"Broadcom internal kernel review list" <bcm-kernel-feedback-list@...adcom.com>,
"Huacai Chen" <chenhuacai@...nel.org>,
"Thomas Gleixner" <tglx@...utronix.de>,
"Serge Semin" <fancer.lancer@...il.com>,
"paulburton@...nel.org" <paulburton@...nel.org>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/10] MIPS: smp: Manage IPI interrupts as percpu_devid interrupts
在2024年7月3日七月 下午11:03,Thomas Bogendoerfer写道:
[...]
>
> there is no user of mips_smp_ipi_disable() (at least I didn't see one),
> so do we need this patch at all ? Just looking like ARM or RiscV isn't
> a justification for code churn.
Hi Thomas,
The per-cpu enablement process is necessary for IPI_MUX and
my upcoming IPI driver.
The disablement, I'm not really sure, maybe it's a good idea to call it at
platform's __cpu_disable to prevent spurious IPI after IRQ migration.
Thanks
- Jiaxun
>
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea. [ RFC1925, 2.3 ]
--
- Jiaxun
Powered by blists - more mailing lists