削除/再スキャン後にpci_enable_device（）が失敗する

Question

私はここで、同じ方法で失敗した古いカーネルで動作する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 

（通常はそれが最初の引き取り手のないリソースの後に停止するだろうが、私は上に行くと、実際にそれを確認するために、それを変更しました

「ここでは主張していません」とは、struct resourceが存在しますが、母親がいないことを意味します。これは、私が収集したものがrequest_resource()によって呼び出されたことはありません。私はこれがドライバの問題ではないと思います。なぜなら、初期化ルーチンは、デバイスを有効にすることができなかったために中止される前に多くのことをすることができないからです。

これは、FPGA（ハードIP PCIeコアを備えたアルテラのCyclone V）と、何らかの形でバスリセットの誤操作など、私が間違っていた可能性があるものです。そのコンピュータの他のPCIeデバイスは、sysfsを介して再接続されたときに動作します。

私はしばらく掘り下げていましたが、私のデバイスがLinuxで扱いが異なるのはなぜなのか分かりませんでした。私のデバイスの可能性のあるプロパティは、私のデバイスのBARにrequest_resource()と呼ぶことを決断できませんでしたか？

Answer 1

原因を見つけたようです。私は0（無効です）のクラスコードを、起動時にデバイスが存在するときにうまくいったPCIeコア構成に残しました。わかりやすい値（私の場合はマルチメディアビデオデバイスの場合は0x40000、「未登録のデバイス」の場合は0xff0000も有効）を入れて、ホットプラグでも動作させました。

Linuxは、0クラスコードのデバイスを部分的にしか処理していません。