Re: [PATCH V3 2/2] PCI: handle CRS returned by device after FLR

2017-03-01 Thread Sinan Kaya
On 2/21/2017 9:37 PM, Sinan Kaya wrote: >> SR-IOV spec rev 1.1, 3.4.1.1 & 3.4.1.2, Vendor ID and Device ID fields >> for the VF return 0x when read. The "Virtualization Intermediary" >> is supposed to use the vendor ID from the PF and the device ID defined >> in the PF SR-IOV capability. > >

Re: [PATCH V3 2/2] PCI: handle CRS returned by device after FLR

2017-03-01 Thread Sinan Kaya
On 2/21/2017 9:37 PM, Sinan Kaya wrote: >> SR-IOV spec rev 1.1, 3.4.1.1 & 3.4.1.2, Vendor ID and Device ID fields >> for the VF return 0x when read. The "Virtualization Intermediary" >> is supposed to use the vendor ID from the PF and the device ID defined >> in the PF SR-IOV capability. > >

Re: [PATCH V3 2/2] PCI: handle CRS returned by device after FLR

2017-02-21 Thread Sinan Kaya
On 2/21/2017 3:51 PM, Alex Williamson wrote: > On Tue, 21 Feb 2017 12:04:24 -0500 > Sinan Kaya wrote: > >> Hi Alex, >> >> I'm coming back to work on this. >> >> On 10/3/2016 1:37 AM, Sinan Kaya wrote: >>> An endpoint is allowed to issue CRS following an FLR request to

Re: [PATCH V3 2/2] PCI: handle CRS returned by device after FLR

2017-02-21 Thread Sinan Kaya
On 2/21/2017 3:51 PM, Alex Williamson wrote: > On Tue, 21 Feb 2017 12:04:24 -0500 > Sinan Kaya wrote: > >> Hi Alex, >> >> I'm coming back to work on this. >> >> On 10/3/2016 1:37 AM, Sinan Kaya wrote: >>> An endpoint is allowed to issue CRS following an FLR request to indicate >>> that it is

Re: [PATCH V3 2/2] PCI: handle CRS returned by device after FLR

2017-02-21 Thread Alex Williamson
On Tue, 21 Feb 2017 12:04:24 -0500 Sinan Kaya wrote: > Hi Alex, > > I'm coming back to work on this. > > On 10/3/2016 1:37 AM, Sinan Kaya wrote: > > An endpoint is allowed to issue CRS following an FLR request to indicate > > that it is not ready to accept new requests.

Re: [PATCH V3 2/2] PCI: handle CRS returned by device after FLR

2017-02-21 Thread Alex Williamson
On Tue, 21 Feb 2017 12:04:24 -0500 Sinan Kaya wrote: > Hi Alex, > > I'm coming back to work on this. > > On 10/3/2016 1:37 AM, Sinan Kaya wrote: > > An endpoint is allowed to issue CRS following an FLR request to indicate > > that it is not ready to accept new requests. Changing the polling

Re: [PATCH V3 2/2] PCI: handle CRS returned by device after FLR

2017-02-21 Thread Sinan Kaya
Hi Alex, I'm coming back to work on this. On 10/3/2016 1:37 AM, Sinan Kaya wrote: > An endpoint is allowed to issue CRS following an FLR request to indicate > that it is not ready to accept new requests. Changing the polling mechanism > in FLR wait function to go read the vendor ID instead of

Re: [PATCH V3 2/2] PCI: handle CRS returned by device after FLR

2017-02-21 Thread Sinan Kaya
Hi Alex, I'm coming back to work on this. On 10/3/2016 1:37 AM, Sinan Kaya wrote: > An endpoint is allowed to issue CRS following an FLR request to indicate > that it is not ready to accept new requests. Changing the polling mechanism > in FLR wait function to go read the vendor ID instead of

[PATCH V3 2/2] PCI: handle CRS returned by device after FLR

2016-10-02 Thread Sinan Kaya
An endpoint is allowed to issue CRS following an FLR request to indicate that it is not ready to accept new requests. Changing the polling mechanism in FLR wait function to go read the vendor ID instead of the command/status register. A CRS indication will only be given if the address to be read

[PATCH V3 2/2] PCI: handle CRS returned by device after FLR

2016-10-02 Thread Sinan Kaya
An endpoint is allowed to issue CRS following an FLR request to indicate that it is not ready to accept new requests. Changing the polling mechanism in FLR wait function to go read the vendor ID instead of the command/status register. A CRS indication will only be given if the address to be read