删除/重新扫描后pci_enable_device()失败

Question

我这里有Linux4.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

(通常情况下，它会在第一个未被声明的资源之后停止，但我已经修改了它以继续，并确认实际上所有的条都是无人认领的。)

这里的"Not“意味着struct resource存在，但没有父级，据我所收集到的，这是因为request_resource()从未被调用过。我不认为这是一个驱动程序问题，因为初始化例程由于无法启用设备而无法在其中止之前完成大量操作。

这使得FPGA (Altera有硬IP PCIe核)和一些我可能做错了的事情，比如不正确地处理总线复位。该计算机中的其他PCIe设备在通过sysfs进行填充时工作。

我已经挖了一段时间了，至今还没有弄清楚为什么Linux对我的设备有不同的对待。我的设备的哪些属性可以让Linux决定不在我的设备条上调用request_resource()？

Answer 1

看来我找到原因了。我将类代码保留为0 (这是无效的)在PCIe核心配置中，该配置在设备启动时运行良好。把一个合理的值(在我的例子中，多媒体视频设备的0x40000，用于“未注册设备”的0xff0000也起作用)也使它在热插拔上工作。

看起来Linux只部分地使用0类代码处理设备。

Answer 2

这个问题似乎是在PCIe的PCIe核的配置空间中被错误定义的类。确保类寄存器的上字节与0不同。

我们在查看dmesg时也遇到了类似的问题：“无法启用设备: BAR 0. not”，后面跟着"pci_enable_device failed“

Answer 3

实际上，没有正确设置的是类代码。我建议设置对应于内存控制器的0x058000。