All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Yang, Zhiyong" <zhiyong.yang@intel.com>
Cc: dev@dpdk.org, "Yigit, Ferruh" <ferruh.yigit@intel.com>
Subject: Re: [PATCH v2] bus/pci: fix wrong intr_handle.type with uio_pci_generic
Date: Tue, 09 Jan 2018 16:34:09 +0100	[thread overview]
Message-ID: <2439576.5uxvrGeh2E@xps> (raw)
In-Reply-To: <E182254E98A5DA4EB1E657AC7CB9BD2A8B01D835@BGSMSX101.gar.corp.intel.com>

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. 

  reply	other threads:[~2018-01-09 15:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-28  6:12 [PATCH] bus/pci: fix wrong intr_handle.type with uio_pci_generic Zhiyong Yang
2017-12-28  9:05 ` Thomas Monjalon
2017-12-28  9:37   ` Yang, Zhiyong
2017-12-28 10:49     ` Thomas Monjalon
2017-12-29  2:10       ` Yang, Zhiyong
2017-12-29  7:55 ` [PATCH v2] " Zhiyong Yang
2017-12-29 11:07   ` Thomas Monjalon
2017-12-30 14:19     ` Yang, Zhiyong
2018-01-03  3:29     ` Yang, Zhiyong
2018-01-09 15:34       ` Thomas Monjalon [this message]
2018-01-10  1:28         ` Yang, Zhiyong
2018-01-10  2:32   ` [PATCH v3] " Zhiyong Yang
2018-01-12  0:04     ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2439576.5uxvrGeh2E@xps \
    --to=thomas@monjalon.net \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=zhiyong.yang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.