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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
