[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK7fddCG6-Q0s-jh5GE7LG+Kf6nON8u9BS4Ame9Xa7VF1=ujiw@mail.gmail.com>
Date: Fri, 7 Mar 2025 19:10:03 +0800
From: Tsai Sung-Fu <danielsftsai@...gle.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Jingoo Han <jingoohan1@...il.com>,
Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
Lorenzo Pieralisi <lpieralisi@...nel.org>, Krzysztof WilczyĆski <kw@...ux.com>,
Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>, Andrew Chant <achant@...gle.com>,
Brian Norris <briannorris@...gle.com>, Sajid Dalvi <sdalvi@...gle.com>,
Mark Cheng <markcheng@...gle.com>, Ben Cheng <bccheng@...gle.com>, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org, Marc Zyngier <maz@...nel.org>
Subject: Re: [PATCH] PCI: dwc: Chain the set IRQ affinity request back to the parent
Thanks for your detailed explanation and feedback, I am a bit confused about the
#4 you mentioned here ->
> 4) Affinity of the demultiplex interrupt
Are you saying there is a chance to queue this demultiplexing IRQ event
to the current running CPU ?
would it fall into the first if clause ?
> if (desc->target_cpu == smp_processor_id()) {
> handle_irq_desc(desc);
And that's really an approach worth to try, I will work on it.
Thanks
Powered by blists - more mailing lists