in my tree for a long time. bde reviewed this once upon a time and
said it was OK, iirc. This also obviates the need to put ? in the
optstring argument to preclude the extra warning message which some
people think confuses users. When I made my getopt cleanups of a long
time ago, this was the compromise reached. I just neglected to commit
it until now.
PR kern/20895:
- Add FE_DAC new feature flag to distinguish between
64 bit PCI addressing (DAC cycles) and 64 bit PCI
interface (64 bit Memory BARs).
- Properly deal with chips that have a 32 bit PCI
interface but support and may generate DAC.
(Only SYM53C895A for now).
PR misc/17584 (at least partially addressed):
- Try detecting hardware combinations that trigger
spurious PCI master parity error detections by the
PCI chip. This work-around is implemented in the
`snooptest' routine and consists in retrying with
PCI master parity checking disabled if such an
error is reported by the PCI chip during this test.
Other:
- Fix a tiny bug in WIDE negotiation that was very
unlikely to be triggerred. The BUS width was wrongly
compared against chip's max. offset.
In the nexus case, there are no ivars for children of nexus devices,
and we were passing data in from before the device existed, hence ivars
are convenient as the softc doesn't really exist yet.
However, for pci->pci bridges, the pcib occupies a pci device itself,
which *does* already have ivars. However, softc is available and stable
at this point since we've been identified and are locating the bus during
attach. So, use softc for this version of pcib devices for storing the
physical bus number in.
function which may lead to stack lossage and clobbered variables.
This isn't the case here, but there is no way to tell gcc that.
Work around this in a kinda bizzare way, but it shuts gcc up.
This is kinda important since the bzero symbol on i386 is not a function
but a function pointer.. If memset() tried to call it as though it were
a function, things would be less than satisfactory. In reality though
this was not an actual problem and just caused compile warnings.
#includes "smbus.h". There is still some bogus (but harmless) stuff
here surrounding the #include <sys/bus.h> includes here and elsewhere in
the bktr code.
