Re: [patch 2.5] tg3.c: pci_{save,restore}_extended_state

["Wiedemeier, Jeff" <Jeff.Wiedemeier@hp.com>]

On Fri, Jan 24, 2003 at 12:51:21PM -0800, David S. Miller wrote:
>    From: "Wiedemeier, Jeff" <Jeff.Wiedemeier@hp.com>
>    Date: Fri, 24 Jan 2003 15:46:35 -0500
> 
>    On Fri, Jan 24, 2003 at 03:34:02PM -0500, Jeff Garzik wrote:
>    > AFAICS, this is a per-driver decision, and needs to be done at the
>    > driver level, in the tg3 driver source.
>    
>    The last sentence in the quote above indicates that it is not intended
>    (by the PCI spec) to be a per-driver decision, but rather a system
>    decision. The messages used are also a per-bus system resource and how
>    an MSI goes from the PCI bus to the rest of the system (i.e. the CPU(s))
>    is implementation dependent.
> 
> Yes, this is understood.
> 
> But the tg3 hw designers have decided to do something which makes this
> not possible.

True. 
 
> So, for tg3's case, it has to become a driver specific decision
> whether to support MSI or not.

But right now, the driver does not have enough information to make it a
driver specific decision. INT_LINE may not be enough to determine the
vector to claim for LSIs and "Message Data" may not be enough to
determine the vector to claim for MSIs. What is there is the irq field
in struct pci_dev.

The intent I had in making sure that MSGINT_MODE was set to match
PCI_MSI_FLAGS_ENABLE and making sure the capability was saved and
restored was to come as close as possible to the spec.

If it needs to be made a driver decision, there needs to be some way to
communicate the correct vector information for whichever option the
driver is using (if there already is and I missed it, please let me
know). Otherwise, it seems that trying to match spec behavior given the
hardware design or disabling MSI at config time for these devices (such
as through quirks) are the options.

/jeff