resultant key listing
when using json to format keys returned from libnetpgp, also prepare for
machine-readable format ("mr") as well as human ("human"), even though
it's not yet used.
-cardbus doesn't use multiple interrupt lines like PCI, and it doesn't
use machanisms like interrupt line register and swizzling -- no need
to carry around dummy information, this is all dealt with by the
bridge
(I'm asking myself how "rbus_ppb" can work -- a bridge attached to
cardbus just can't work like a normal PCI bridge as far as interrupts
are concerned. I thing that should be a hardware specific driver
because behavior is not covered by a standard.)
-cardbus always uses 3.3V -- no need for a variable to keep track
of the voltage
Interrupts). Successfully tested with hdaudio and "wpi" wireless
ethernet.
notes:
-There seem to be buggy chips around which announce MSI support
but don't correctly implement it. Thus the final word whether MSIs
can be used should be by the driver.
-Only a single vector is supported. For multiple vectors, the IDT
allocation code would have to be changed. (And we would possibly
run into problems due to the limited number of vectors supported
by the current code.)
-The code is "#if NIOAPIC > 0" because it uses the ioapic_edge
interrupt stubs. These actually don't touch any ioapic, so this
is somewhat a misnomer.
-MSIs can't be identified by a "pin" but only by a cpu/vector
pair. Common intr code soesn't deal well with this yet.
-Drivers need to take care of saving/restoring MSI data in the device's
config space on suspend/resume.
if it is "-1" -- this is a hack to allow MSIs which don't have a concept
of pin numbers, and are generally not shared
(This doesn't give us sensible event names for statistics display. The
whole abstraction has more exceptions than regular cases, it should
be redesigned imho.)
agc