>> Can someone please confirm if my assumptions below are correct:
>> 1) Unless someone specifically tampered with my driver's device
>> since the OS bootup, the mapping of the PCI base address registers
>> to virtual memory will remain the same (just as seen in /proc/pci,
>> and as reflected in <subj>)? If not, is there a way to freeze it
>> for the time I want to access it?
>
> This is not a safe assumption, because the OS may reprogram the
> PCI BARs at certain times. The rule is: ALWAYS read from
> dev->resource[] unless you are a bus driver (PCI bridges, for
> example, need to assign resources).
Well, I have a bus driver. Just how do I get a bus number?
My hardware comes up as a regular device, then mutates into
a bridge when I flip a bit in a config register. The header
even changes from type 1 to type 2. The class code is always
the same, a bridge device, but not PCI-to-PCI. It's kind of
like hot-plug PCI over a network, with all sorts of extra
alignment restrictions on address space allocation.
So maybe this card is on bus 42. I need a secondary bus number,
plus a few more in case there are more bridges downstream.
I can't just grab 42..44 because they might be used elsewhere,
and I can't just grab 253..255 either because that upsets the
whole system of bus number assignment being done by carving up
the space granted to upstream bridges.
BTW, is there any reason why the primary bus register of a
bridge would have to be set correctly? I have to set mine equal
to the secondary bus register to keep the hardware happy.
> Further, access to PCI BARs -and- dev->resource[] in a driver is
> wrong until you have called pci_enable_device. Resource and IRQ
> assignment potentially occurs at pci_enable_device time, so BAR
> is [potentially] undefined before then.
Hmmm. I can use device-specific config space registers to change
the size of a BAR. (or limit & base, whatever) Say I want to have
512 MB, but the bridge upstream only has 128 MB allotted to it.
How do I fix this?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/