我在这里使用Linux 4.4（我曾经使用过相同方式失败的旧内核），使用PCIe连接的FPGA器件和驱动程序，这些都是我自己设计的。这些在正常条件下运行良好，但现在我尝试使它们在热插拔条件下工作。这不是实际的硬件热插拔，我一直在尝试的是设备的sysfs目录中的echo 1 >remove和之后的echo 1 >/sys/bus/pci/rescan。
设备重新出现后，我的驱动程序的初始化调用pci_enable_device()在记录时失败：
otscan 0000:02:00.0: can't enable device: BAR 0 [mem 0xf7e01000-0xf7e013ff] not claimed
otscan 0000:02:00.0: can't enable device: BAR 1 [mem 0xf7e00000-0xf7e00fff] not claimed
otscan 0000:02:00.0: can't enable device: BAR 2 [mem 0xf0200000-0xf020ffff 64bit pref] not claimed
（通常它会在第一个无人认领的资源之后停止，但我已将其修改为继续并确认实际上所有的BAR都是无人认领的。）
＆＃34;未声明＆＃34;这意味着struct resource存在，但没有父母，我收集的内容是request_resource()从未被调用过的。我不认为这是一个驱动程序问题，因为初始化例程在由于未能启用设备而中止之前不会做很多事情。
这使得FPGA（Altera Cyclone V具有硬IP PCIe内核）以及我可能在那里做错的事情，例如以某种方式错误处理总线复位。该计算机中的其他PCIe设备在通过sysfs重新插入时工作。
我一直在挖掘一段时间，但仍然无法弄清楚为什么我的设备被Linux处理得与众不同。我的设备的哪些可能属性可能让Linux决定不在我的设备的BAR上调用request_resource()？
答案 0 :(得分：2)
看起来我找到了原因。我在PCIe核心配置中将类代码保留为0（这是无效的），当设备在引导时出现时，该配置工作正常。在我的情况下，0x40000为多媒体视频设备设置了合理的值，0xff0000用于“未注册的设备”也有效）也使其适用于hotplug。
Linux似乎只部分处理具有0类代码的设备。
答案 1 :(得分：1)
该问题似乎是在FPGA的PCIe核心的PCIe配置空间中错误地定义了类。确保CLASS REGISTER的高字节为st而不是0
通过dmesg查看时，我们遇到了类似的问题： “无法启用设备：BAR 0 ...没声明” 其次是 “ pci_enable_device失败”