Re: ARMv8 SError, panic around msi_set_mask_bit during suspend-to-RAM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 29 Sep 2022 21:07:50 +0100,
Kevin Rowland <kevin.p.rowland@xxxxxxxxx> wrote:
> 
> On Thu, Sep 29, 2022 at 2:08 AM Marc Zyngier <maz@xxxxxxxxxx> wrote:
> >
> > On Wed, 28 Sep 2022 17:56:01 -0400,
> > Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:
> > >
> > > > At this point I'm wondering why we mask MSIs so late in the suspend
> > > > process (right when the last non-boot CPU is taken offline). Shouldn't
> > > > we disable/mask these IRQs as part of host controller suspend?
> >
> > This is what we do for *all* interrupts. The question is really
> > whether there is any form of PM involved when accessing the device
> > implementing the masking.
> I'm afraid I didn't understand this part. What is it that we do for
> all interrupts? Mask them when the last CPU in their affinity mask is
> taken offline, or mask them as part of the suspend process of the
> owning device?

Sorry, I wasn't clear at all: *managed* interrupts (which are per-CPU
interrupts) are disabled when the corresponding CPU goes down. If you
have some extra logic to pull the plug on the RC when the last CPU
goes away, it must happen after this disabling phase.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux