From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id CBC7325A1; Thu, 28 Dec 2017 11:49:26 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4FFDF219E2; Thu, 28 Dec 2017 05:49:26 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 28 Dec 2017 05:49:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=Kndpum5nkOPgz4CSaN40Ebw39D 77wnFbtB2mOxfRRYk=; b=d/xzta3ce2zTT4WUms8KGViznbRTUXoL8JcQHFw1FD 26ZwM4PWzp5nuzAPfUXyo36sYFt60eqgk4kpiQdWPqBFDrkAQupJKIlUVAgEb1Sv WObZbQuUIcpmOxpaOk0OzQw1OeIP6ZtqTsmQdo7DOwHHp8aPrTP+gL/oo6jZKTsu w= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Kndpum 5nkOPgz4CSaN40Ebw39D77wnFbtB2mOxfRRYk=; b=f1Dj0AUAVEbdfidi5DSl5Q RnW2gEj71OagZCHkE59W9+gM5MRH8/KjJTGJePf9poUA4gmO4LZFu8EvVYSQtOQ/ j8Nrf8YXDNhTl7+sBbaoDn1hTr8fUoN4jsSA66K7NHEkOJns6CkozZO3c6lF6m+q jx7xe7OG7TlG3ql0J9264hmvizZMmxn4wKXOgk+34fvm6FcbHfMWhOQWpl8xG2VV 5IN0+BR3qKVNKY4KKOELwRatqIT6ll5maagqgy2Ojpxp6VK7ANY4evyk5HttzFfS yoOna9lEYgV+W7HalJac9xPpsivLfzP1+ZleLoAoEW8XkkWWSGxWxDpc4lyL9hkA == X-ME-Sender: Received: from xps.localnet (gra86-3-88-182-229-223.fbx.proxad.net [88.182.229.223]) by mail.messagingengine.com (Postfix) with ESMTPA id ACF4224235; Thu, 28 Dec 2017 05:49:25 -0500 (EST) From: Thomas Monjalon To: "Yang, Zhiyong" Cc: "dev@dpdk.org" , "Yigit, Ferruh" , "stable@dpdk.org" Date: Thu, 28 Dec 2017 11:49:13 +0100 Message-ID: <6678594.XHcc9ld5bA@xps> In-Reply-To: References: <20171228061210.64767-1-zhiyong.yang@intel.com> <3562024.UbNHMEjv39@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] bus/pci: fix wrong intr_handle.type with uio_pci_generic X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 10:49:27 -0000 28/12/2017 10:37, Yang, Zhiyong: > Hi Thomas, > > > -----Original Message----- > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > Sent: Thursday, December 28, 2017 5:05 PM > > To: Yang, Zhiyong > > Cc: dev@dpdk.org; Yigit, Ferruh ; stable@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.