When one is trying to allocate a resource with unspecified range, read already configured BAR values (by UEFI or whatever). This is necessary to make VFs working and to allow them to be properly allocated.
Details
Details
- Reviewers
zbb - Group Reviewers
arm64 - Commits
- rS289966: Add support for unspecified ranges on ThunderX system
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
I think this is OK, but I don't know much about VF
| sys/arm64/cavium/thunder_pcie.c | ||
|---|---|---|
| 465 ↗ | (On Diff #8994) | You're supposed to write all f's to the BAR to size it. The bits for the decode lines will be 0's, the address range it occupies are 1's. So this flips the upper bits that are set and adds 1 to get the size. The masking above masks out the low-order bits that contain attributes for the mapping. |
| 472 ↗ | (On Diff #8994) | 0, 2 and 4 are valid valid values for 3 64-bit BARs. 5 is the first invalid one. |
| sys/arm64/cavium/thunder_pcie.c | ||
|---|---|---|
| 472 ↗ | (On Diff #8994) | Alternatively, 6 is the 4th 64-bit BAR? |
| sys/arm64/cavium/thunder_pcie.c | ||
|---|---|---|
| 472 ↗ | (On Diff #8994) | PCI supports up to 6 BAR registers. They can be used either as 6x 32-bit regs, or 3x 64-bit. Anyway, PCIR_BAR(5) is the last valid entry inside configuration header, so anything above means we're accessing VFs. |