From: Alexander Duyck <alexander.h.duyck@intel.com>
To: Don Dutile <ddutile@redhat.com>
Cc: Stefan Assmann <sassmann@kpanic.de>,
linux-pci@vger.kernel.org, bhelgaas@google.com,
yu.zhao@intel.com
Subject: Re: return value for "if (!dev->is_physfn)"
Date: Mon, 29 Jul 2013 14:40:26 -0700 [thread overview]
Message-ID: <51F6E14A.8070100@intel.com> (raw)
In-Reply-To: <51F6D519.3010506@redhat.com>
On 07/29/2013 01:48 PM, Don Dutile wrote:
> On 07/26/2013 12:43 PM, Alexander Duyck wrote:
>> 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.
>>
> +1. returning enosys hangs the caller (echo/cat of sysfs) IIRC.
>
>> 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
>>
I am pretty sure it is safe to return ENOSYS since that is the return
value used if you try to write to sriov_numvfs but do not have
sriov_configure defined. That was one of the things that gave me the
idea since it points to incomplete support for SR-IOV and returns a
message along the lines of "echo: write error: Function not implemented"
when trying to update those values.
Thanks,
Alex
next prev parent reply other threads:[~2013-07-29 21:40 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
2013-07-29 20:48 ` Don Dutile
2013-07-29 21:40 ` Alexander Duyck [this message]
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=51F6E14A.8070100@intel.com \
--to=alexander.h.duyck@intel.com \
--cc=bhelgaas@google.com \
--cc=ddutile@redhat.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).