28/12/2017 10:37, Yang, Zhiyong: > Hi Thomas, > > > -----Original Message----- > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > Sent: Thursday, December 28, 2017 5:05 PM > > To: Yang, Zhiyong <zhiyong.y...@intel.com> > > Cc: dev@dpdk.org; Yigit, Ferruh <ferruh.yi...@intel.com>; sta...@dpdk.org > > Subject: Re: [PATCH] bus/pci: fix wrong intr_handle.type with > > uio_pci_generic > > > > 28/12/2017 07:12, Zhiyong Yang: > > > In the function rte_pci_ioport_map, if uio_pci_generic is used on X86 > > > platform, pci_ioport_map() is invoked, the operation > > > ev->intr_handle.type = RTE_INTR_HANDLE_UNKNOWN; is execused directly, > > > it causes the wrong assignment for uio_pci_generic, the patch fixes it. > > [...] > > > --- a/drivers/bus/pci/linux/pci.c > > > +++ b/drivers/bus/pci/linux/pci.c > > > @@ -723,7 +723,9 @@ pci_ioport_map(struct rte_pci_device *dev, int bar > > __rte_unused, > > > if (!found) > > > return -1; > > > > > > - dev->intr_handle.type = RTE_INTR_HANDLE_UNKNOWN; > > > + if (dev->kdrv == RTE_KDRV_NONE) > > > + dev->intr_handle.type = RTE_INTR_HANDLE_UNKNOWN; > > > > I don't understand the logic. > > NONE is different of UNKNOWN. > > > > Your are talking about uio_pci_generic. In this case, it should be > > RTE_KDRV_UIO_GENERIC. > > If we use uio_pci_generic, dev->intr_handle.type has already been assigned to > The right value RTE_INTR_HANDLE_UIO_INTX before it, but in the function > pci_ioport_map > the wrong value is assigned to dev->intr_handle.type = > RTE_INTR_HANDLE_UNKNOWN; > Two cases both call pci_ioport_map on x86 platform. > one is RTE_KDRV_UIO_GENERIC > the other is RTE_KDRV_NONE > if I understand right, for uio_generic, it should not be assigned to > RTE_INTR_HANDLE_UNKNOWN; > This case has already the right value, don't need to assign again. > The original code should be considered to handle RTE_KDRV_NONE case only.
OK thanks for the explanation. I had overlooked your patch. Please, could add some of this text in v2? I think it is good to explain that the right value is already set, and we must avoid overwriting the default "UNKNOWN" value. One more question, why is it needed to set the value to "UNKNOWN" in this function? It should already be set to this value (0) at init.
