> On Sep 15, 2015, at 2:17 PM, Alex Williamson
> wrote:
>
> Also, rather than clearing the flag, can we move the tests done by
> pci_vpd_f0_dev_check() into the
> quirk setup function? It seems like function 0 should be sufficiently
> configured by the time we're probing non-zero functions that
On Tue, 2015-09-15 at 20:47 +, Rustad, Mark D wrote:
> > On Sep 15, 2015, at 12:04 PM, Alex Williamson
> > wrote:
> >
> >
> > FRU-type information is only one of the use cases of VPD, the spec also
> > defines (PCI rev 3.0, 6.4):
> >
> >... a mechanism for storing information such
> On Sep 15, 2015, at 12:04 PM, Alex Williamson
> wrote:
>
>
> FRU-type information is only one of the use cases of VPD, the spec also
> defines (PCI rev 3.0, 6.4):
>
>... a mechanism for storing information such as performance and
>failure data on the device being monitored.
>
On Tue, 2015-09-15 at 18:39 +, Rustad, Mark D wrote:
> > On Sep 15, 2015, at 11:19 AM, Alex Williamson
> > wrote:
> >
> > In addition to the (PCI_SLOT() != devfn) issue, I'm concerned about
> > topologies like we see on Skylake. IIRC, the integrated NIC appears at
> > something like 00:1f.6
> On Sep 15, 2015, at 11:19 AM, Alex Williamson
> wrote:
>
> In addition to the (PCI_SLOT() != devfn) issue, I'm concerned about
> topologies like we see on Skylake. IIRC, the integrated NIC appears at
> something like 00:1f.6. I don't know if that specific NIC has VPD, nor
> am I sure it real
On Mon, 2015-07-13 at 11:40 -0700, Mark D Rustad wrote:
> From: Mark Rustad
>
> Add a dev_flags bit, PCI_DEV_FLAGS_VPD_REF_F0, to access VPD through
> function 0 to provide VPD access on other functions. This is for
> hardware devices that provide copies of the same VPD capability
> registers in
From: Mark Rustad
Add a dev_flags bit, PCI_DEV_FLAGS_VPD_REF_F0, to access VPD through
function 0 to provide VPD access on other functions. This is for
hardware devices that provide copies of the same VPD capability
registers in multiple functions. Because the kernel expects that
each function ha
