svn commit: r189367 - head/sys/dev/pci

[Robert Noland]

On Wed, 2009-03-04 at 22:30 -0700, Scott Long wrote:
> M. Warner Losh wrote:
> > In message: <1236224629.1384.22.camel at widget.2hip.net>
> >             Robert Noland <rnoland at FreeBSD.org> writes:
> > : On Wed, 2009-03-04 at 19:41 -0700, M. Warner Losh wrote:
> > : > In message: <1236218572.1384.19.camel at widget.2hip.net>
> > : >             Robert Noland <rnoland at FreeBSD.org> writes:
> > : > : On Wed, 2009-03-04 at 13:56 -0700, M. Warner Losh wrote:
> > : > : > In message: <200903041823.n24INmcc049524 at svn.freebsd.org>
> > : > : >             Robert Noland <rnoland at freebsd.org> writes:
> > : > : > : Author: rnoland
> > : > : > : Date: Wed Mar  4 18:23:48 2009
> > : > : > : New Revision: 189367
> > : > : > : URL: http://svn.freebsd.org/changeset/base/189367
> > : > : > : 
> > : > : > : Log:
> > : > : > :   Extend the management of PCIM_CMD_INTxDIS.
> > : > : > :   
> > : > : > :   We now explicitly enable INTx during bus_setup_intr() if it is needed.
> > : > : > :   Several of the ata drivers were managing this bit internally.  This is
> > : > : > :   better handled in pci and it should work for all drivers now.
> > : > : > :   
> > : > : > :   We also mask INTx during bus_teardown_intr() by setting this bit.
> > : > : > :   
> > : > : > :   Reviewed by:	jhb
> > : > : > :   MFC after:	3 days
> > : > : > 
> > : > : > Note: the INTxDIS bit is new in PCI 3.0, and has no effect on earlier
> > : > : > devices.  This should be highlighted in the comments somewhere...
> > : > : 
> > : > : It is documented in 2.3 as well, I'm not sure about previous versions of
> > : > : the spec though.
> > : > 
> > : > It isn't in 2.2, and even after 2.3 it is "optional".
> > : 
> > : The bit should be unused if it isn't supported by a given piece of
> > : hardware.  If it doesn't do anything, we are no worse off than before.
> > : I don't think this will cause any harm, only goodness when it is
> > : supported.
> > 
> > Yes.  I agree.  This is just the sort of bit, however, that people
> > looking for an interrupt storm would latch on to as being just the
> > ticket...  Which is why I suggested a comment...
> 
> Well, the other risk is that devices that claim strict PCI 2.0, 2.1, or
> 2.2 compatibility might treat this bit as "undefined" and thus eligible
> for a SERR condition, or even reassign it for proprietary use.  I think
> that this risk is small, but non-zero.  I think that as long as we only
> manipulate this bit in conjunction with MSI, we should be fine.  But
> yes, it must be stressed that this bit is not some magical cure-all for
> interrupt storms, nor is it an appropriate mechanism for handling
> arbitrary interrupts in an interrupt handler.

I'm happy to add a comment, I'm just not certain what that comment
should be.  I don't find where it is marked as optional in the 2.3 spec,
though I do find the part about interrupt pins being optional...

robert.

> Scott
-- 
Robert Noland <rnoland at FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20090305/55b52a5e/attachment.pgp