CVS commit: [netbsd-4] src/sys/dev/pci

["Liam J. Foy" <liamjfoy%netbsd.org@localhost>]

Module Name:    src
Committed By:   liamjfoy
Date:           Mon Jul 30 21:52:31 UTC 2007

Modified Files:
        src/sys/dev/pci [netbsd-4]: pccbb.c pccbbvar.h pcireg.h

Log Message:
Pull up following revision(s) (requested by dyoung in ticket #739):
        sys/dev/pci/pccbb.c: revision 1.140
        sys/dev/pci/pccbb.c: revision 1.141
        sys/dev/pci/pccbb.c: revision 1.142
        sys/dev/pci/pccbb.c: revision 1.143
        sys/dev/pci/pccbb.c: revision 1.144
        sys/dev/pci/pccbbvar.h: revision 1.28
        sys/dev/pci/pcireg.h: revision 1.53
        sys/dev/pci/pccbb.c: revision 1.139
Name magic numbers PCI_PMCSR_PME_EN and PCI_PMCSR.

Fix grammar in comment.  From Patrick Welche.

Use the right subroutine name for the debug message.

Convert the rather long and backslash-ridden DELAY_MS macro to a
much shorter static subroutine, delay_ms().

Cosmetic: KNF indentation, curly braces, and argument declarations.

sc_pwrcycle is shared between the interrupt handler and Cardbus
event thread, so make it volatile.

Fix a bug in Cardbus power activation.

Most Cardbus bridges supported by pccbb(4) fire a power-cycle
interrupt when the power state of a cardslot changes from 'off' to
'on'.  TI bridges fire a power-cycle interrupt on both on->off and
off->on changes.

When pccbb_power() powered-down a cardslot, it did not wait around
for the power-cycle interrupt.  When pccbb_power() powered-up a
cardslot, it did wait for the interrupt.  If a pccbb_power(UP)
followed a pccbb_power(DOWN) very closely, pccbb_power() used to
interpret the power-cycle interrupt for the up->down transition as
"power-up complete," read the power-state bit and, finding that
power had NOT been activated, complain, "cbb0:  power on failed?"
Then pccbb_power() exited before power-activation was complete,
falsely indicating that the power-activation *was* complete.  After
that, a driver attach/enable routine would blithely configure a
card that was not fully powered-up.  An operator who ran a command
such as 'ifconfig rtw0 down up' or 'ifconfig ath0 down up' would
read 'cbb0: power on failed?' in the system log, and their NIC
would misbehave.

This excerpt from a comment in the source should suffice to explain
how I fixed the bug,

         /*
          * Wait as long as 200ms for a power-cycle interrupt.  If
          * interrupts are enabled, but the socket has already
          * changed to the desired status, keep waiting for the
          * interrupt.  "Consuming" the interrupt in this way keeps
          * the interrupt from prematurely waking some subsequent
          * pccbb_power call.

And this explains why this patch will work for Ricoh bridges that
do not fire an interrupt on the on->off transition:

          * XXX Not every bridge interrupts on the ->OFF transition.
          * XXX That's ok, we will time-out after 200ms.
          *
          * XXX The power cycle event will never happen when attaching
          * XXX a 16-bit card.  That's ok, we will time-out after
          * XXX 200ms.
          */

M. Warner Losh and Charles M. Hannum provided valuable input on
this patch.


To generate a diff of this commit:
cvs rdiff -r1.137 -r1.137.2.1 src/sys/dev/pci/pccbb.c
cvs rdiff -r1.26 -r1.26.8.1 src/sys/dev/pci/pccbbvar.h
cvs rdiff -r1.52 -r1.52.2.1 src/sys/dev/pci/pcireg.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.