History log of /dragonfly/sys/dev/pccard/pccbb/pccbb_pci.c (Results 1 – 7 of 7)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.2.1, v6.2.0, v6.3.0, v6.0.1, v6.0.0, v6.0.0rc1, v6.1.0, v5.8.3, v5.8.2, v5.8.1, v5.8.0, v5.9.0, v5.8.0rc1, v5.6.3, v5.6.2, v5.6.1, v5.6.0, v5.6.0rc1, v5.7.0, v5.4.3, v5.4.2, v5.4.1, v5.4.0, v5.5.0, v5.4.0rc1, v5.2.2, v5.2.1, v5.2.0, v5.3.0, v5.2.0rc, v5.0.2, v5.0.1, v5.0.0, v5.0.0rc2, v5.1.0, v5.0.0rc1, v4.8.1, v4.8.0, v4.6.2, v4.9.0, v4.8.0rc, v4.6.1, v4.6.0, v4.6.0rc2, v4.6.0rc, v4.7.0, v4.4.3, v4.4.2, v4.4.1, v4.4.0, v4.5.0, v4.4.0rc, v4.2.4, v4.3.1, v4.2.3, v4.2.1, v4.2.0, v4.0.6, v4.3.0, v4.2.0rc, v4.0.5, v4.0.4, v4.0.3, v4.0.2, v4.0.1, v4.0.0, v4.0.0rc3, v4.0.0rc2, v4.0.0rc, v4.1.0, v3.8.2, v3.8.1, v3.6.3, v3.8.0, v3.8.0rc2, v3.9.0, v3.8.0rc, v3.6.2, v3.6.1, v3.6.0, v3.7.1, v3.6.0rc, v3.7.0, v3.4.3, v3.4.2, v3.4.0, v3.4.1, v3.4.0rc, v3.5.0
# d3c9c58e 20-Feb-2013 Sascha Wildner <saw@online.de>

kernel: Use DEVMETHOD_END in the drivers.


Revision tags: v3.2.2, v3.2.1, v3.2.0, v3.3.0, v3.0.3, v3.0.2, v3.0.1, v3.1.0, v3.0.0
# 86d7f5d3 26-Nov-2011 John Marino <draco@marino.st>

Initial import of binutils 2.22 on the new vendor branch

Future versions of binutils will also reside on this branch rather
than continuing to create new binutils branches for each new version.


Revision tags: v2.12.0, v2.13.0
# aa2b9d05 24-Jun-2011 Sascha Wildner <saw@online.de>

kernel: Use NULL for DRIVER_MODULE()'s evh & arg (which are pointers).

This is just cosmetics for easier reading.


Revision tags: v2.10.1, v2.11.0, v2.10.0, v2.9.1, v2.8.2, v2.8.1, v2.8.0, v2.9.0, v2.6.3, v2.7.3, v2.6.2, v2.7.2, v2.7.1, v2.6.1, v2.7.0, v2.6.0, v2.5.1, v2.4.1, v2.5.0, v2.4.0, v2.3.2
# 54bc92c6 11-Jul-2009 Sepherosa Ziehau <sephe@dragonflybsd.org>

Get rid of PCI_MAP_FIXUP and opt_pci.h


# bb3d3555 05-Jul-2009 Sepherosa Ziehau <sephe@dragonflybsd.org>

cbb(4): Rework secondary bus number setup; aware of PCI domain

Obtained-from: FreeBSD


Revision tags: v2.3.1, v2.2.1, v2.2.0, v2.3.0, v2.1.1, v2.0.1
# ecb86ab5 14-Aug-2007 Sepherosa Ziehau <sephe@dragonflybsd.org>

If PCI_MAP_FIXUP is defined, we can no longer do the reallocation magic;
at least it breaks following case:

1) BIOS does not assign cbb IO memory.
2) ipw and cbb are on the same PCI bus.
3) If ipw w

If PCI_MAP_FIXUP is defined, we can no longer do the reallocation magic;
at least it breaks following case:

1) BIOS does not assign cbb IO memory.
2) ipw and cbb are on the same PCI bus.
3) If ipw was loaded, it would use 0xd0000000-0xd0000fff as its IO memory.
4) ipw was not loaded at boot time.
5) At boot time, cbb tried to attach, system assigned IO memory 0xd0000000
-0xd0000fff to it. But later on, due to incorrect IRQ assignment, cbb
attaching failed. The assigned IO memory was freed properly. However,
the resource list entry (rle) was not freed.
6) ipw was loaded after booting and successfully attached. It occupied IO
memory 0xd0000000-0xd0000fff.
7) Since ipw and cbb are on the same PCI bus, cbb got a second chance re-
probe and re-attach. But this time, no rle would be allocated by PCI bus
code, since old rle was still there. Old rle had 0xd0000000-0xd0000fff
as start/end, so this allocation failed -- same IO memory segment was
already used by ipw.
8) The reallocation magic was performed then. It succeeded, but this left
cbb's rle in an uninitalized state.

As pointed out in 5), cbb attaching failed again. Reallocated IO memory
was going to be freed: assertion in pci_release_resource(), since cbb's rle
was not initialized in 8).

If PCI_MAP_FIXIP is not defined, we depend on the current mechanism to find
the PCI IO memory for cbb, given some goofy BIOSes do not assign cbb's IO
memory. This seems to be the only way to make things working without
PCI_MAP_FIXUP, though it is vulnerable to the case described above.

Reported-by: Michael Neumann <mneumann@ntecs.de>

show more ...


# 3aef8050 05-Jul-2007 Sepherosa Ziehau <sephe@dragonflybsd.org>

Update cardbus/pccard support.

The original patch was done by joerg@; I seemed to "maintain"
it for quite a long time :P

Obtained-from: FreeBSD
Tested-by: many (intermittently tho)