[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZoaeEYdEmEBl6R7J@alpha.franken.de>
Date: Thu, 4 Jul 2024 15:05:21 +0200
From: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
To: Jiaxun Yang <jiaxun.yang@...goat.com>
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
On Thu, Jul 04, 2024 at 04:08:09AM +0800, Jiaxun Yang wrote:
>
>
> 在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.
don't add dead code, so drop mips_smp_ipi_disable() for now.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
Powered by blists - more mailing lists