> Date: Wed, 14 Nov 2012 22:30:48 -0500 > From: Brad Smith <b...@comstyle.com> > > On Fri, Sep 28, 2012 at 12:07:31AM -0400, Brad Smith wrote: > > On Fri, Sep 28, 2012 at 04:06:32AM +0200, Mark Kettenis wrote: > > > > Date: Mon, 24 Sep 2012 03:49:41 -0400 > > > > From: Brad Smith <b...@comstyle.com> > > > > > > > > I've always wondered why this workaround was not removed once MSI > > > > support was added. This was added before we had MSI support to > > > > workaround some Intel azalia(4) being setup by the BIOS as far > > > > as I know to use MSI and thus interrupts on system that were > > > > affected by this did not work at all for azalia(4). > > > > > > Because there still are conditions under which we would not be able to > > > use MSI. > > > > I had 6 people reply off list indicating their Intel azalia controllers > > didn't seem to have any regressions with the previous diff applied. > > > > Can you expand upon this and explain what you mean. What are these > > conditions? It would be nice to mention what those conditions are > > within the comment. > > > > > Perhaps we should change the generic PCI code to explicitly disable > > > MSIs if they are turned on. But until we do that, this workaround > > > needs to stay in place. > > > > Since MSI is being disabled for the Intel azalia controller and the > > datasheet does confirm that is what this code is doing shouldn't > > we be telling the PCI layer MSI is disabled too like so? It doesn't > > make sense to have MSI disabled for the controller and then the > > PCI layer still thinking MSI should be used.
You clearly don't understand how the code works. The flag indicates whether MSIs are supported by the host bridge (and the device). Not whether MSIs are actually enabled on the device. The PCI layer will turn MSIs back on if it decides to use them. We just want to make sure MSIs aren't accidentally enabled when we decide not to use them. Something that apparently happened on some machines with Intel HD Audio.
