Aren/NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Comment-out calls to pci_disable_retry() and cardbus_disable_retry().

Browse Source 
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.
This commit is contained in:
dyoung 2007-12-14 03:18:46 +00:00
parent 84f60004f0
commit 9a075a9c73
2 changed files with 44 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
sys/dev/cardbus/if_ath_cardbus.c
View File

@ -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 <ichiro@ichiro.org>.
@ -36,7 +36,7 @@
*/
#include <sys/cdefs.h>
__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;

25
sys/dev/pci/if_ath_pci.c
View File

@ -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