Received-SPF: pass (google.com: domain of linux-kernel+bounces-101135-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240130082722.2912576-1-maobibo@loongson.cn> <20240130082722.2912576-4-maobibo@loongson.cn>
 <87a5o4iti4.ffs@tglx>
In-Reply-To: <87a5o4iti4.ffs@tglx>
From: Huacai Chen <chenhuacai@kernel.org>
Date: Wed, 13 Mar 2024 14:20:58 +0800
Message-ID: <CAAhV-H6Qqz54yQ8uehjx+jEhwCzNzeFfN=gHttLaq_xYQJZchg@mail.gmail.com>
Subject: Re: [PATCH v5 3/3] irqchip/loongson-eiointc: Refine irq affinity
 setting during resume
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Bibo Mao <maobibo@loongson.cn>, Jiaxun Yang <jiaxun.yang@flygoat.com>, 
	linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, 
	Sergey Shtylyov <s.shtylyov@omp.ru>, lvjianmin@loongson.cn
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi, Thomas,

On Tue, Feb 13, 2024 at 5:49=E2=80=AFPM Thomas Gleixner <tglx@linutronix.de=
> wrote:
>
> On Tue, Jan 30 2024 at 16:27, Bibo Mao wrote:
> > During suspend and resume, CPUs except CPU0 can be hot-unpluged and IRQ=
s
> > will be migrated to CPU0. So it is not necessary to restore irq affinit=
y
> > for eiointc irq controller when system resumes.
>
> That's not the reason. The point is that eiointc_router_init() which is
> invoked in the resume path affines all interrupts to CPU0, so the
> restore operation is redundant, no?
I'm sorry for the late response but I think this is a little wrong.
When irq_migrate_all_off_this_cpu() is called at hot-unplug, if an
irqdesc is irqd_affinity_is_managed() then its affinity is untouched
(doesn't change to CPU0). Then after resume we should not keep its
affinity on CPU0 set by eiointc_router_init() , but need to restore
its old affinity.

Huacai

>
> > This patch removes this piece of code about irq affinity restoring in
> > function eiointc_resume().
>
> Again. 'This patch' is pointless because we already know that this is a
> patch, no?
>