linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.h.duyck@intel.com>
To: Stefan Assmann <sassmann@kpanic.de>
Cc: linux-pci@vger.kernel.org, bhelgaas@google.com, yu.zhao@intel.com
Subject: Re: return value for "if (!dev->is_physfn)"
Date: Fri, 26 Jul 2013 09:43:33 -0700	[thread overview]
Message-ID: <51F2A735.2010405@intel.com> (raw)
In-Reply-To: <51F24788.6010505@kpanic.de>

On 07/26/2013 02:55 AM, Stefan Assmann wrote:
> Looking at drivers/pci/iov.c I see at least 3 different return values
> for if (!dev->is_physfn).
>
> sriov_enable() and pci_enable_sriov()
> [...]
> 	if (!dev->is_physfn)
> 		return -ENODEV;
> pci_num_vf() and pci_vfs_assigned()
> [...]
> 	if (!dev->is_physfn)
> 		return 0;
> pci_sriov_set_totalvfs() and pci_sriov_get_totalvfs()
> [...]
> 	if (!dev->is_physfn)
> 		return -EINVAL;
>
> I'd like to make this consistently return one of the above. Question is,
> which one should it be? I'd lean towards -ENODEV, other opinions?
>
>   Stefan

It all depends on how the results are meant to be interpreted.

In the case of pci_num_vf and pci_vfs_assigned the return of 0 is
preferred since there are no VFs if the device is not a physical
function.  I really think pci_sriov_get_totalvfs should probably just
return 0 as well since it is simply supposed to return the total number
of VFs supported on the device and 0 would be valid in this case.  Also
that way the behavior is consistent if CONFIG_PCI_IOV is enabled or
disabled in the kernel.

As for the rest my preference is ENOSYS rather than EINVAL or ENODEV. 
The issue is that the SR-IOV functionality is not implemented for the
device or in the OS when we return the error so it would make sense to
return that as an error code in these cases.

Thanks,

Alex





  reply	other threads:[~2013-07-26 16:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-26  9:55 return value for "if (!dev->is_physfn)" Stefan Assmann
2013-07-26 16:43 ` Alexander Duyck [this message]
2013-07-29 20:48   ` Don Dutile
2013-07-29 21:40     ` Alexander Duyck
2013-07-29 21:47       ` Don Dutile

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=51F2A735.2010405@intel.com \
    --to=alexander.h.duyck@intel.com \
    --cc=bhelgaas@google.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=sassmann@kpanic.de \
    --cc=yu.zhao@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).