From 9a075a9c7376666377f4dfdbe814a2b0c27a744d Mon Sep 17 00:00:00 2001 From: dyoung Date: Fri, 14 Dec 2007 03:18:46 +0000 Subject: [PATCH] Comment-out calls to pci_disable_retry() and cardbus_disable_retry(). They do not seem well-justified according to anyone's understanding of what they really do, and it seems especially inappropriate to call them at attach- and resume-time. --- sys/dev/cardbus/if_ath_cardbus.c | 23 +++++++++++++++++++++-- sys/dev/pci/if_ath_pci.c | 25 +++++++++++++++++++++++-- 2 files changed, 44 insertions(+), 4 deletions(-) diff --git a/sys/dev/cardbus/if_ath_cardbus.c b/sys/dev/cardbus/if_ath_cardbus.c index 7ac2f0b28a20..8b6016bd4a62 100644 --- a/sys/dev/cardbus/if_ath_cardbus.c +++ b/sys/dev/cardbus/if_ath_cardbus.c @@ -1,4 +1,4 @@ -/* $NetBSD: if_ath_cardbus.c,v 1.21 2007/12/09 20:27:55 jmcneill Exp $ */ +/* $NetBSD: if_ath_cardbus.c,v 1.22 2007/12/14 03:18:46 dyoung Exp $ */ /* * Copyright (c) 2003 * Ichiro FUKUHARA . @@ -36,7 +36,7 @@ */ #include -__KERNEL_RCSID(0, "$NetBSD: if_ath_cardbus.c,v 1.21 2007/12/09 20:27:55 jmcneill Exp $"); +__KERNEL_RCSID(0, "$NetBSD: if_ath_cardbus.c,v 1.22 2007/12/14 03:18:46 dyoung Exp $"); #include "opt_inet.h" #include "bpfilter.h" @@ -129,7 +129,26 @@ ath_cardbus_resume(device_t dv) cardbus_chipset_tag_t cc = ct->ct_cc; cardbus_function_tag_t cf = ct->ct_cf; + /* Insofar as I understand what the PCI retry timeout is + * (it does not appear to be documented in any PCI standard, + * and we don't have any Atheros documentation), disabling + * it on resume does not seem to be justified. + * + * Taking a guess, the DMA engine counts down from the + * retry timeout to 0 while it retries a delayed PCI + * transaction. When it reaches 0, it ceases retrying. + * A PCI master is *never* supposed to stop retrying a + * delayed transaction, though. + * + * Incidentally, while I am hopeful that cardbus_disable_retry() + * does disable retries, because that would help to explain + * some ath(4) lossage, I suspect that writing 0 to the + * register does not disable *retries*, but it disables + * the timeout. That is, the device will *never* timeout. + */ +#if 0 cardbus_disable_retry(cc, cf, csc->sc_tag); +#endif ath_resume(&csc->sc_ath); return true; diff --git a/sys/dev/pci/if_ath_pci.c b/sys/dev/pci/if_ath_pci.c index a5a119a9cf18..a74ebfe4e662 100644 --- a/sys/dev/pci/if_ath_pci.c +++ b/sys/dev/pci/if_ath_pci.c @@ -1,4 +1,4 @@ -/* $NetBSD: if_ath_pci.c,v 1.24 2007/12/14 02:57:22 mjf Exp $ */ +/* $NetBSD: if_ath_pci.c,v 1.25 2007/12/14 03:18:46 dyoung Exp $ */ /*- * Copyright (c) 2002-2005 Sam Leffler, Errno Consulting @@ -41,7 +41,7 @@ __FBSDID("$FreeBSD: src/sys/dev/ath/if_ath_pci.c,v 1.11 2005/01/18 18:08:16 sam Exp $"); #endif #ifdef __NetBSD__ -__KERNEL_RCSID(0, "$NetBSD: if_ath_pci.c,v 1.24 2007/12/14 02:57:22 mjf Exp $"); +__KERNEL_RCSID(0, "$NetBSD: if_ath_pci.c,v 1.25 2007/12/14 03:18:46 dyoung Exp $"); #endif /* @@ -120,7 +120,26 @@ ath_pci_resume(device_t dv) { struct ath_pci_softc *sc = device_private(dv); + /* Insofar as I understand what the PCI retry timeout is + * (it does not appear to be documented in any PCI standard, + * and we don't have any Atheros documentation), disabling + * it on resume does not seem to be justified. + * + * Taking a guess, the DMA engine counts down from the + * retry timeout to 0 while it retries a delayed PCI + * transaction. When it reaches 0, it ceases retrying. + * A PCI master is *never* supposed to stop retrying a + * delayed transaction, though. + * + * Incidentally, while I am hopeful that pci_disable_retry() + * does disable retries, because that would help to explain + * some ath(4) lossage, I suspect that writing 0 to the + * register does not disable *retries*, but it disables + * the timeout. That is, the device will *never* timeout. + */ +#if 0 pci_disable_retry(sc->sc_pc, sc->sc_pcitag); +#endif ath_resume(&sc->sc_sc); return true; @@ -147,7 +166,9 @@ ath_pci_setup(struct ath_pci_softc *sc) return 0; } +#if 0 pci_disable_retry(sc->sc_pc, sc->sc_pcitag); +#endif /* * XXX Both this comment and code are replicated in