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（）在刪除/重新掃描後失敗

回答

相關問題