Introduce d_version field in struct cdevsw, this must always be
initialized to D_VERSION.
Flip sense of D_NOGIANT flag to D_NEEDGIANT, this involves removing
four D_NOGIANT flags and adding 145 D_NEEDGIANT flags.
pain and suffering. Attempt to back it out by removing the 'if the
requested range is larger than the window, clip to the window' code.
This is a band-aide until the issues are better understood and the
issues with the lazy allocation patches are resolved.
signals to addresses to the child busses. Typically, ProgIf of 1
means a subtractive bridge. However, Intel has a whole lot of ones
with a ProgIf of 80 that are also subtractive. We cope with these
bridges too. This eliminates hw.pci.allow_unsupported_io_range
because that had almost the same effect as these patches (almost means
'buggy'). Remove the bogus checks for ISA bus locations: these cycles
aren't special and are only passed by transparent bridges.
We allow any range to succeed. If the range is a superset of the
range that's decoded, trim the resource to that range. Otherwise,
pass the range unchanged. This will change the location that PC Card
and CardBus cards are attached. This might bogusly cause some
overlapping allocation that wasn't present before, but the overlapping
fixes need to be in the pci level.
There's also a few formatting changes here.
- This is heavily derived from John Baldwin's apic/pci cleanup on i386.
- I have completely rewritten or drastically cleaned up some other parts.
(in particular, bootstrap)
- This is still a WIP. It seems that there are some highly bogus bioses
on nVidia nForce3-150 boards. I can't stress how broken these boards
are. I have a workaround in mind, but right now the Asus SK8N is broken.
The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed.
- Most of my testing has been with SCHED_ULE. SCHED_4BSD works.
- the apic and acpi components are 'standard'.
- If you have an nVidia nForce3-150 board, you are stuck with 'device
atpic' in addition, because they somehow managed to forget to connect the
8254 timer to the apic, even though its in the same silicon! ARGH!
This directly violates the ACPI spec.
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
