pci_enable_device（）在删除/重新扫描后失败

我在这里有一个Linux 4.4（我曾经工作在一个较旧的内核上，它以相同的方式失败）与一个PCIe连接的FPGA设备和驱动程序，它们都是我自己设计的。这些在正常情况下运行良好，但现在我尝试使它们在热插拔条件下工作。这不是实际的硬件热插拔，我一直在尝试的是设备的sysfs目录中的通常的echo 1 >remove以及之后的echo 1 >/sys/bus/pci/rescan。pci_enable_device（）在删除/重新扫描后失败

设备再次出现后，我的驱动程序的初始化调用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都是无人认领的。）

“这里没有声称”表示struct resource存在但没有父母，从我收集的是由request_resource()引起的，从来没有被调用过。我不认为这是一个驱动程序问题，因为初始化例程在由于未能启用设备而中止之前不会执行很多操作。

这使得FPGA（Altera Cyclone V具有硬IP PCIe内核）以及某些我可能在那里做错的事情，比如错误地处理总线复位。该计算机中的其他PCIe设备在通过sysfs重新插入时工作。

我一直在挖掘一段时间，仍然没有弄清楚为什么我的设备被不同的Linux对待。我的设备有什么可能的属性可能让Linux决定不在设备的BAR上拨打request_resource()？

来源

2017-09-28 Andreas Bombe

我过去自己也见过同样的问题，并认为它可能与资源的大小有关（我有一个512KiB的区域）。但你的身材更小。我从来没有深究过。 –

它看起来像我找到了原因。我在PCIe内核配置中将类代码设置为0（这是无效的），在引导时存在该设备时可以正常工作。投入一个合理的价值（0x40000在我的情况下为多媒体视频设备，0xff0000“未注册设备”也工作）也使它在热插拔工作。

看来Linux只能部分处理类型码为0的设备。

来源

2017-09-29 22:49:14

pci_enable_device（）在删除/重新扫描后失败

回答

相关问题