[openib-general] [PATCH 5/6] Use pci_find_ht_capability() in drivers/pci/quirks.c

[Michael Ellerman]

On Thu, 2006-11-09 at 15:43 +0100, Segher Boessenkool wrote:
> > While yes, we should not in general add new workarounds before we need
> > them, for this quirk, you should keep the original functionality,  
> > unless
> > you wrote the quirk, or unless you have the hardware that needs it and
> > you can verify that the change works properly.
> >
> > Are any of these last two options true for you?
> 
> This new code only runs on HyperTransport devices and
> none of those _existed_ when the quirk was first written.
> I cannot claim I know for sure it is never needed there
> of course, but it's quite improbable at least.
> 
> > If not, I suggest that you put the TTL logic back in just to be safe.
> 
> I'm fine with that -- but I'm not writing the code here,
> Michael is, and I just hope he has more spine than I do ;-)

Nah no spine here.

I will quote Rusty though, who has plenty of spine ...
http://www.ozlabs.com/~rusty/ols-2003-keynote/img53.html

pci_find_next_capability() scores a 14 IMHO.

Of three callers, we currently have two that don't use a TTL and so are
vulnerable to bodgy PCI cap lists.

</end-whinge>
<begin-constructive-suggestion>

What if we had:

extern int pci_find_next_capability(struct pci_dev *dev, u8 pos, int cap, int *ttl)
...

int pos, ttl = 0;

pos = pci_find_capability(dev, PCI_CAP_FOO);
while (pos) {
	...
	stuff();
	...
	pos = pci_find_next_capability(dev, pos, PCI_CAP_FOO, *ttl);
}

It's not pretty I admit. pci_find_next_ht_capability() would also take a
ttl, and pass it through to pci_find_next_capability(). AFAICT that
would avoid any infinite hang scenarios?

cheers
 
-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20061113/413322c0/attachment.sig>