03/01/2018 04:29, Yang, Zhiyong: > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > 29/12/2017 08:55, Zhiyong Yang: > > > --- a/drivers/bus/pci/linux/pci.c > > > +++ b/drivers/bus/pci/linux/pci.c > > > @@ -723,7 +723,6 @@ pci_ioport_map(struct rte_pci_device *dev, int bar > > __rte_unused, > > > if (!found) > > > return -1; > > > > > > - dev->intr_handle.type = RTE_INTR_HANDLE_UNKNOWN; > > > > There is the same assignment in pci_vfio_map_resource_primary(), > > pci_vfio_map_resource_secondary() and pci_uio_map_resource(). > > > > Please could you check why there is such assignments? > > In general, the operation in the three functions intends to initialize the > "intr_handle.type", > For example, > For pci_uio_map_resource(), it wants to get "unknown" status once the code > returns abnormally after initializing. > If the code goes smoothly, dev->intr_handle.type must be assigned to > "RTE_INTR_HANDLE_UIO" for bsd environment, > Or must be assigned to "RTE_INTR_HANDLE_UIO" or " RTE_INTR_HANDLE_UIO_INTX" > for linux environment > In consideration of the "memset" in pci_scan_one, it can be removed to has no > harm to the existing logic.
So what do you think of doing a v3 which removes it everywhere? It would remove inconsistencies and avoid future questions. > Of course, keeping it is ok. > > pci_vfio_map_resource_primary() and pci_vfio_map_resource_secondary() are > similar. > > The author was emphasizing that intr_handle.type should be initialized (0) > and can be assigned to a right value after it. > Once fails, we can read a status "unknown". I guess. > > Turn back to the patch, it is crude to assign "unknown" directly since > pci_ioport_map is not only used by real "unknown" > But also is used to handle uio_pci_generic driver on X86 platform. It is a > special case to cause error for uio_pci_generic.
