From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 954893772 for ; Tue, 9 Jan 2018 16:34:34 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 34A1620B85; Tue, 9 Jan 2018 10:34:34 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 09 Jan 2018 10:34:34 -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=+e2ekrtEKzR94jSoSsBC/ubmGH gOccENePhIdCPfoxs=; b=KURHkYfE1Ff7rmz9S6BCG/UnBvlAh3pI7YRa0ESrC8 mL75QBCmBG2XJWjoS2HrdCAyDWVDaCPI+EnbtgAt2mOYBosgsNzdJmtxbfNVDmiu tPV9DPD7dNO0g+WEI23DdMfbohR2nT1Czq8rnd4nk3b23fOA0zvLkZtvP/XO4SEb 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=+e2ekr tEKzR94jSoSsBC/ubmGHgOccENePhIdCPfoxs=; b=BdxO/Hawy+PJ+m92yrQYgZ xa0GFTfE/VsnPzH3dVjkC/MXR1eb1n82G8DlTT4mfYcWelfL5AbMWL4cDNp4nYsa +K52gjNRak635JIuD/zgOcbn9GcOd4/YZOzvzX1cMW0G7NSAsbOLGaY7SJhlFogt kqQVTttyIc3Hq8m1Txko3siVrqW7k5P92NbHDQ84vuybjPkqzMJmyOMqfg3EqJ0Z gLUiZp9mHimwq6ViY9lwsuefNymTQ9H4qj6ZlhEiBDxVKnRm7U4bJ2JGRRjnZ/+k ksW34DNHXlwmRZiC0mw30uN2iHoqvvHnV06CvNUb6uBqf5P0XU2qB62mXVOZcqNA == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id D13A02470D; Tue, 9 Jan 2018 10:34:33 -0500 (EST) From: Thomas Monjalon To: "Yang, Zhiyong" Cc: dev@dpdk.org, "Yigit, Ferruh" Date: Tue, 09 Jan 2018 16:34:09 +0100 Message-ID: <2439576.5uxvrGeh2E@xps> In-Reply-To: References: <20171228061210.64767-1-zhiyong.yang@intel.com> <2110508.9oViqIghhz@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] 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: Tue, 09 Jan 2018 15:34:34 -0000 03/01/2018 04:29, Yang, Zhiyong: > From: Thomas Monjalon [mailto:thomas@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.