[dpdk-dev] [PATCH] bus/pci: fix wrong intr_handle.type with uio_pci_generic

[Thomas Monjalon]

28/12/2017 10:37, Yang, Zhiyong:
> Hi Thomas,
> 
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas at monjalon.net]
> > Sent: Thursday, December 28, 2017 5:05 PM
> > To: Yang, Zhiyong <zhiyong.yang at intel.com>
> > Cc: dev at dpdk.org; Yigit, Ferruh <ferruh.yigit at intel.com>; stable at 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.