> We should also be leaving the INTx irqs disabled. So no irq
> should be generated.
>
> If you have a mask bit implemented you are required to be
> able to refire it after the msi is enabled. I don't recall
> the requirements for when both intx and msi irqs are both
> disabled. Intuitively I would expect no irq message to
> be generated, and at most the card would need to be polled
> manually to recognize a device event happened.
>
> Certainly firing an irq and having it get completely lost is
> unfortunate, and a major pain if you are trying to use the
> card.
>
> As for the previous no-op behavior that was a bug.
Well, yes and no ... A valid option here would be to use soft-masking,
which is possible because MSIs are edge interrupts. That is, basically,
when masked, just ignore them and set IRQF_PENDING, and when unmasked,
replay (which can be done with softirq if there is no HW mechanism for
that). The genirq code contains all the necessary infrastructure for
doing that stuff, it's fairly trivial, and would probably avoid stepping
in HW lalaland (how much do you bet HW generally get that masking thing
wrong ?)
> The PCI spec requires disabling/masking the msi when reprogramming it.
> So as a general rule we can not do better. Further because we are
> writing to multiple pci config registers the only way we can safely
> reprogram the message is with the msi disabled/masked on the card in
> some fashion.
Hrm... all right, that will be an issue, so migration need a real
masking.
> I suspect what needs to happen is a spec search to verify that the
> current linux behavior is at least reasonable within the spec.
>
> Once we have verified that the generic code can not do better.
> We can look at work-arounds. One possibility is for the generic
> code to provide some overrides for the methods for masking and
> reading/writing to a msi message.
>
> I don't want to break anyones hardware, but at the same time I want us
> to be careful and in spec for the default case.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
