> > > > > > > +Another reason to provide bind/unbind action is programmble > > > > +devices, like FPGA, are not identified driver by 'vendor ID' and > > > > +'device ID', they might not be changed in all the ways, even FPGA > > > > +is fully programmed. So, it depends on internal mechanism of > > > > +FPGA, not 'vendor ID' and 'device ID' to identify proper drivers, > > > > +either a register value or signature, depending on FPGA hardware > > > > +design. In this case, EAL or other bus driver doesn't have the > > > > +capability to identify proper driver for FPGA device. With prgdev > > > > +introduced, while FPGA is always a prgdev, FPGA can use prgdev as > > > > +primary driver, to find proper > > > function driver. > > > > > > You mean prgdev should help the bus layer to map the right driver > interface? > > > It looks weird and dangerous. The standard way to identify a PCI > > > device is to look at its IDs. Other unknown methods must be strongly > discussed. > > > > For programmable Ethernet device, it's not truce. But for FPGA, it's. > > When FPGA is produced, the device ID indicate what model it is and > > won't be changed anyway, even being reprogrammed. It used some > > not-generic mechanism, like AFU id to distinguish the personalities. > > So, for FPGA, a prgdev driver can be used as primary driver to identify > personalities and then register to specific devices. > > Sounds like we would need an FPGA bus driver in that case. I think that would > be a better solution than having a specific device driver loading other > drivers. >
I don't object to introduce a pseudo bus for FPGA, but it's a matter of work that FPGA driver needs to consider, not in scope of prgdev. Besides that, I can see DPDK EAL will do other bus probe first, then PCI bus probe, which is not friendly to introduce pseudo bus for an actual PCI device. > /Bruce
