parameter in the read and write case dereferenced an unitialized
pointer and can't possibly ever have catched an actual invalid
argument.
This was apparently true for the read/write and getconf cases. The
latter does not even receive the paramter that is to be verified.
I'm surprised that this did not cause kernel panics, but it seems
that the uninitialized local variable happens to contain data that
may be used as a pointer to memory that satisfies the test condition.
Make the code work as intended by moving the test inside the switch
case where the pointer has been properly initialized.
Since the read and write case shared just about all code (except
for the single call to PCIB_READ_CONFIG resp. PCIB_WRITE_CONFIG) I
have merged both cases.
Noticed by: trhodes@FreeBSD.org (Tom Rhodes)
and replace it with the more intuitive name PCIR_BARS.
- Add a PCIR_BAR(x) macro that returns the config space register offset of
the 32-bit BAR x.
MFC after: 3 days
- Add a new PCIM_HDRTYPE constant for the field in PCIR_HDRTYPE that holds
the header type.
- Replace several magic numbers with appropriate constants for the header
type register and a couple of PCI_FUNCMAX.
- Merge to amd64 the fix to the i386 bridge code to skip devices with
unknown header types.
Requested by: imp (1, 2)
- Factor out code common to all ISA bridge drivers attach methods into a
isab_attach() function.
- Rename the PCI-ISA bridge driver's attach function to pci_isab_attach()
and have it call isab_attach().
interrupt to be used for a device. This is intended solely for internal
use of PCI bus implementations, and exists so that PCI bus drivers
implementing special interrupt assignment methods which require
additional work at the bus level to work right can be easily derived
from the generic driver (or any other one) without resorting to hacks.
It will be used in the sparc64 ofw_pcibus driver, which will be
committed shortly.
Make use of this method in the generic implementation, and add it to
the method table of bus drivers derived from the PCI one.
Reviewed by: imp, -hackers
are some Sun PCI devices around which bogusly set intpin to 0, although
they use the intline mechanism; this allows the device driver to correct
that.
Reviewed by: imp
read permision only required for listing, read/write required for
read/write to registers
fix a possible memory leak
clean up error handling a bit
Reviewed by: silence
Reorder how the pci probing in handled. before adding devices, check to
see if the slot is a multi-function device to see if we should probe all
the functions.
Original idea by: imp
ia64-specific.
- When trying to re-route interrupts, don't change cfg->intline if the
re-route fails by returning an invalid vector. This fixes machines
without any way of routing interrupts such as older PC's without a
$PIR table.
We do not currently write the new intline value back to the hardware, but
we should. That will likely be added in a later commit.
Always route PCI interrupts on i386 UP machines. I was planning to enable
this for i386 anyways once SMP support is done. Having this enabled fixes
problems on many people's laptops.
Requested by: imp
(with other names) in the USB driver sources, but I felt that pcireg.h
should have a complete list - at least of classes and interfaces that we
know about and use.
command config register. At the present, this represents a nop
because these bits should have been set earlier in the process. In
the future, we'll only set these bits when the driver requests the
resource, not when the bus code detects the resource.
Reviewed by: mdodd
branches:
Initialize struct cdevsw using C99 sparse initializtion and remove
all initializations to default values.
This patch is automatically generated and has been tested by compiling
LINT with all the fields in struct cdevsw in reverse order on alpha,
sparc64 and i386.
Approved by: re(scottl)
pci busses implement this.
Also minor comment smithing in cardbus. Fix copyright to this year
with my name on it since I've been doing a lot to this file.
Reviewed by: jhb
We allow the request to go through if it matches either a prefetchable
or a non-prefetchable part of the bridge. We do not check to make
sure it is the right kind of memory because most drivers to not yet
properly set RF_PREFETCHABLE (only cardbus seems to do so, and I'm not
entirely sure it does it right). RF_PREFETCHABLE was invented for
cardbus, so hasn't been properly documented yet.
This is still overridable by hw.pci.allow_unsupported_io_ranges, but
the need for that is greatly reduced, especially for the nvida driver.
Approved by: re
Reviewed by: jhb and many testers
Submitted by: Matt Emmerton (although this has been reworked somewhat)
buses support querying the MAC address in a standard-for-that-bus way.
The base pci bus returns NULL for this IVAR always.
Submitted by: sam
Approved by: re (blanket for NEWCARD)
- If a PCI device is not present, then a 32-bit read_config() is going to
return 0xffffffff not 0xffff.
- For the 82454NX chipset, the MIOC that we read the bus numbers of the
various host-PCI bridges from is at function (slot) 0x10 not 0x0.
Approved by: re (rwatson)
