On Mon, 12 Mar 2018 09:01:54 -0700
Alexander Duyck wrote:
> On Mon, Mar 12, 2018 at 12:59 AM, Christoph Hellwig wrote:
> > On Sun, Mar 11, 2018 at 09:59:09PM -0600, Alex Williamson wrote:
> >> I still struggle to understand why we need this "unmanaged"
> >> complication and how a user of the s
On Mon, Mar 12, 2018 at 12:59 AM, Christoph Hellwig wrote:
> On Sun, Mar 11, 2018 at 09:59:09PM -0600, Alex Williamson wrote:
>> I still struggle to understand why we need this "unmanaged"
>> complication and how a user of the sysfs API is expected to have any
>> idea whether a PF is managed or un
On Sun, Mar 11, 2018 at 09:59:09PM -0600, Alex Williamson wrote:
> I still struggle to understand why we need this "unmanaged"
> complication and how a user of the sysfs API is expected to have any
> idea whether a PF is managed or unmanaged and why they should care.
> Can't we just have a pci_simp
On Thu, 08 Mar 2018 11:02:29 -0800
Alexander Duyck wrote:
> From: Alexander Duyck
>
> This patch is meant to add some basic functionality to support for SR-IOV
> on devices when the VFs are not managed by some other entity in the device
> other than the kernel.
>
> A new sysfs value called sri
From: Alexander Duyck
This patch is meant to add some basic functionality to support for SR-IOV
on devices when the VFs are not managed by some other entity in the device
other than the kernel.
A new sysfs value called sriov_unmanaged_autoprobe has been added. This
value is used as the drivers_a