search for: pci_match_one_device

On 2020/6/8 ??5:45, Michael S. Tsirkin wrote: > On Mon, Jun 08, 2020 at 05:43:58PM +0800, Jason Wang wrote: >>>> Looking at >>>> pci_match_one_device() it checks both subvendor and subdevice there. >>>> >>>> Thanks >>> But IIUC there is no guarantee that driver with a specific subvendor >>> matches in presence of a generic one. >>> So either IFC or virtio pci can win, whichever binds first. >...

On 2020/6/8 ??5:45, Michael S. Tsirkin wrote: > On Mon, Jun 08, 2020 at 05:43:58PM +0800, Jason Wang wrote: >>>> Looking at >>>> pci_match_one_device() it checks both subvendor and subdevice there. >>>> >>>> Thanks >>> But IIUC there is no guarantee that driver with a specific subvendor >>> matches in presence of a generic one. >>> So either IFC or virtio pci can win, whichever binds first. >...

On 2020/6/8 ??5:54, Michael S. Tsirkin wrote: > On Mon, Jun 08, 2020 at 05:46:52PM +0800, Jason Wang wrote: >> On 2020/6/8 ??5:45, Michael S. Tsirkin wrote: >>> On Mon, Jun 08, 2020 at 05:43:58PM +0800, Jason Wang wrote: >>>>>> Looking at >>>>>> pci_match_one_device() it checks both subvendor and subdevice there. >>>>>> >>>>>> Thanks >>>>> But IIUC there is no guarantee that driver with a specific subvendor >>>>> matches in presence of a generic one. >>>>> So either IFC or virtio...

On 2020/6/8 ??5:54, Michael S. Tsirkin wrote: > On Mon, Jun 08, 2020 at 05:46:52PM +0800, Jason Wang wrote: >> On 2020/6/8 ??5:45, Michael S. Tsirkin wrote: >>> On Mon, Jun 08, 2020 at 05:43:58PM +0800, Jason Wang wrote: >>>>>> Looking at >>>>>> pci_match_one_device() it checks both subvendor and subdevice there. >>>>>> >>>>>> Thanks >>>>> But IIUC there is no guarantee that driver with a specific subvendor >>>>> matches in presence of a generic one. >>>>> So either IFC or virtio...

...> Does it actually work if you bind a virtio driver to it? It works. > I'm guessing no otherwise they wouldn't need IFC driver, right? > Looking at the driver, they used a dedicated bar for dealing with virtqueue state save/restore. It > > >> Looking at >> pci_match_one_device() it checks both subvendor and subdevice there. >> >> Thanks > > But IIUC there is no guarantee that driver with a specific subvendor > matches in presence of a generic one. > So either IFC or virtio pci can win, whichever binds first. I'm not sure I get there. But I t...

...> Does it actually work if you bind a virtio driver to it? It works. > I'm guessing no otherwise they wouldn't need IFC driver, right? > Looking at the driver, they used a dedicated bar for dealing with virtqueue state save/restore. It > > >> Looking at >> pci_match_one_device() it checks both subvendor and subdevice there. >> >> Thanks > > But IIUC there is no guarantee that driver with a specific subvendor > matches in presence of a generic one. > So either IFC or virtio pci can win, whichever binds first. I'm not sure I get there. But I t...

...0 } >> }; >> >> Thanks >> > Then regular virtio will still bind to it. It has > > drivers/virtio/virtio_pci_common.c: { PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) }, > > IFCVF use this to avoid the binding to regular virtio device. Looking at pci_match_one_device() it checks both subvendor and subdevice there. Thanks

...0 } >> }; >> >> Thanks >> > Then regular virtio will still bind to it. It has > > drivers/virtio/virtio_pci_common.c: { PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) }, > > IFCVF use this to avoid the binding to regular virtio device. Looking at pci_match_one_device() it checks both subvendor and subdevice there. Thanks

...Ow. Indeed: #define IFCVF_VENDOR_ID 0x1AF4 Which is of course not an IFCVF vendor id, it's the Red Hat vendor ID. I missed that. Does it actually work if you bind a virtio driver to it? I'm guessing no otherwise they wouldn't need IFC driver, right? > Looking at > pci_match_one_device() it checks both subvendor and subdevice there. > > Thanks But IIUC there is no guarantee that driver with a specific subvendor matches in presence of a generic one. So either IFC or virtio pci can win, whichever binds first. I guess we need to blacklist IFC in virtio pci probe code. Ugh....

On Mon, Jun 08, 2020 at 05:43:58PM +0800, Jason Wang wrote: > > > > > Looking at > > > pci_match_one_device() it checks both subvendor and subdevice there. > > > > > > Thanks > > > > But IIUC there is no guarantee that driver with a specific subvendor > > matches in presence of a generic one. > > So either IFC or virtio pci can win, whichever binds first. >...

On Mon, Jun 08, 2020 at 05:46:52PM +0800, Jason Wang wrote: > > On 2020/6/8 ??5:45, Michael S. Tsirkin wrote: > > On Mon, Jun 08, 2020 at 05:43:58PM +0800, Jason Wang wrote: > > > > > Looking at > > > > > pci_match_one_device() it checks both subvendor and subdevice there. > > > > > > > > > > Thanks > > > > But IIUC there is no guarantee that driver with a specific subvendor > > > > matches in presence of a generic one. > > > > So either IFC or virtio pc...

...wrote: > > On Mon, Jun 08, 2020 at 05:46:52PM +0800, Jason Wang wrote: > > > On 2020/6/8 ??5:45, Michael S. Tsirkin wrote: > > > > On Mon, Jun 08, 2020 at 05:43:58PM +0800, Jason Wang wrote: > > > > > > > Looking at > > > > > > > pci_match_one_device() it checks both subvendor and subdevice there. > > > > > > > > > > > > > > Thanks > > > > > > But IIUC there is no guarantee that driver with a specific subvendor > > > > > > matches in presence of a generic one. > &...

...search for a PCI device with this base class code + * @from: Previous PCI device found in search, or %NULL for new search. + * + * Iterates through the list of known PCI devices. If a PCI device is found + * with a matching base class code, the reference count to the device is + * incremented. See pci_match_one_device() to figure out how does this works. + * A new search is initiated by passing %NULL as the @from argument. + * Otherwise if @from is not %NULL, searches continue from next device on the + * global list. The reference count for @from is always decremented if it is + * not %NULL. + * + * Returns: + *...

On 2020/6/7 ??9:51, Michael S. Tsirkin wrote: > On Fri, Jun 05, 2020 at 04:54:17PM +0800, Jason Wang wrote: >> On 2020/6/2 ??3:08, Jason Wang wrote: >>>>> +static const struct pci_device_id vp_vdpa_id_table[] = { >>>>> +??? { PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) }, >>>>> +??? { 0 } >>>>> +}; >>>> This

On 2020/6/7 ??9:51, Michael S. Tsirkin wrote: > On Fri, Jun 05, 2020 at 04:54:17PM +0800, Jason Wang wrote: >> On 2020/6/2 ??3:08, Jason Wang wrote: >>>>> +static const struct pci_device_id vp_vdpa_id_table[] = { >>>>> +??? { PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) }, >>>>> +??? { 0 } >>>>> +}; >>>> This

From: Sui Jingfeng <suijingfeng at loongson.cn> There is no function that can be used to get all PCI(e) devices in a system by matching against its the PCI base class code only, while keep the sub-class code and the programming interface ignored. Therefore, add the pci_get_base_class() function to suit the need. For example, if an application want to process all PCI(e) display devices in a