From: Casey Leedom
> Sent: 04 August 2017 21:49
...
> Whenever our Hardware Designers implement new functionality in our hardware,
> they almost always put in A. several "knobs" which can control fundamental
> parameters of the new Hardware Feature, and B. a mechanism of completely
> disabling it
| From: Raj, Ashok
| Sent: Friday, August 4, 2017 1:21 PM
|
| On Fri, Aug 04, 2017 at 08:20:37PM +, Casey Leedom wrote:
| > ...
| > As I've noted a number of times, it would be great if the Intel Hardware
| > Engineers who attempted to implement the Relaxed Ordering
On Fri, Aug 04, 2017 at 08:20:37PM +, Casey Leedom wrote:
> | From: Raj, Ashok
> | Sent: Thursday, August 3, 2017 1:31 AM
> |
> | I don't understand this completely.. So your driver would know not to send
> | RO TLP's to root complex. But you want to send RO to the NVMe
| From: Raj, Ashok
| Sent: Thursday, August 3, 2017 1:31 AM
|
| I don't understand this completely.. So your driver would know not to send
| RO TLP's to root complex. But you want to send RO to the NVMe device? This
| is the peer-2-peer case correct?
Yes, this is the "heavy
On 2017/8/3 17:13, Raj, Ashok wrote:
> Hi Ding
>
> patch looks good, except would reword the patch description for clarity
>
> here is my crack at it, feel free to use.
>
> On Thu, Jul 13, 2017 at 10:21:31PM +0800, Ding Tianhong wrote:
>> The PCIe Device Control Register use the bit 4 to
Hi Ding
patch looks good, except would reword the patch description for clarity
here is my crack at it, feel free to use.
On Thu, Jul 13, 2017 at 10:21:31PM +0800, Ding Tianhong wrote:
> The PCIe Device Control Register use the bit 4 to indicate that
> whether the device is permitted to enable
Hi Casey
On Wed, Aug 02, 2017 at 05:53:52PM +, Casey Leedom wrote:
> Okay, here you go. As you can tell, it's almost a trivial copy of the
> cxgb4 patch.
>
> By the way, I realized that we have yet another hole which is likely not
> to be fixable. If we're dealing with a problematic
Okay, here you go. As you can tell, it's almost a trivial copy of the
cxgb4 patch.
By the way, I realized that we have yet another hole which is likely not
to be fixable. If we're dealing with a problematic Root Complex, and we
instantiate Virtual Functions and attach them to a Virtual
On 2017/7/28 1:49, Alexander Duyck wrote:
> On Wed, Jul 26, 2017 at 6:08 PM, Ding Tianhong
> wrote:
>>
>>
>> On 2017/7/27 2:26, Casey Leedom wrote:
>>> By the way Ding, two issues:
>>>
>>> 1. Did we ever get any acknowledgement from either Intel or AMD
>>> on
On 2017/7/28 2:42, Raj, Ashok wrote:
> Hi Casey
>
>> | Still no Intel and AMD guys has ack this, this is what I am worried about,
>> | should I ping some man again ?
>
>
> I can ack the patch set for Intel specific changes. Now that the doc is made
> public :-).
>
Good, Thanks. :)
> Can
On 2017/7/28 1:44, Casey Leedom wrote:
> | From: Ding Tianhong
> | Sent: Wednesday, July 26, 2017 6:01 PM
> |
> | On 2017/7/27 3:05, Casey Leedom wrote:
> | >
> | > Ding, send me a note if you'd like me to work that [cxgb4vf patch] up
> | > for you.
> |
> | Ok, you
Hi Casey
> | Still no Intel and AMD guys has ack this, this is what I am worried about,
> | should I ping some man again ?
I can ack the patch set for Intel specific changes. Now that the doc is made
public :-).
Can you/Ding resend the patch series, i do have the most recent v7, some
of the
On Wed, Jul 26, 2017 at 6:08 PM, Ding Tianhong wrote:
>
>
> On 2017/7/27 2:26, Casey Leedom wrote:
>> By the way Ding, two issues:
>>
>> 1. Did we ever get any acknowledgement from either Intel or AMD
>> on this patch? I know that we can't ensure that, but it sure
| From: Ding Tianhong
| Sent: Wednesday, July 26, 2017 6:01 PM
|
| On 2017/7/27 3:05, Casey Leedom wrote:
| >
| > Ding, send me a note if you'd like me to work that [cxgb4vf patch] up
| > for you.
|
| Ok, you could send the change log and I could put it in the v8 version
On 2017/7/27 2:26, Casey Leedom wrote:
> By the way Ding, two issues:
>
> 1. Did we ever get any acknowledgement from either Intel or AMD
> on this patch? I know that we can't ensure that, but it sure would
> be nice since the PCI Quirks that we're putting in affect their
>
On 2017/7/27 3:05, Casey Leedom wrote:
> | From: Alexander Duyck
> | Sent: Wednesday, July 26, 2017 11:44 AM
> |
> | On Jul 26, 2017 11:26 AM, "Casey Leedom" wrote:
> | |
> | | I think that the patch will need to be extended to modify
> | |
| From: Alexander Duyck
| Sent: Wednesday, July 26, 2017 11:44 AM
|
| On Jul 26, 2017 11:26 AM, "Casey Leedom" wrote:
| |
| | I think that the patch will need to be extended to modify
| | drivers/pci.c/iov.c:sriov_enable() to explicitly
By the way Ding, two issues:
1. Did we ever get any acknowledgement from either Intel or AMD
on this patch? I know that we can't ensure that, but it sure would
be nice since the PCI Quirks that we're putting in affect their
products.
2. I just realized that there's still a small
On Sat, 22 Jul 2017 12:19:38 +0800
Ding Tianhong wrote:
> Hi Sinan, Bjorn:
>
> On 2017/7/14 21:54, Sinan Kaya wrote:
> > On 7/13/2017 9:26 PM, Ding Tianhong wrote:
> >> There is no code to enable the PCIe Relaxed Ordering bit in the
> >> configuration space,
> >> it
Hi Sinan, Bjorn:
On 2017/7/14 21:54, Sinan Kaya wrote:
> On 7/13/2017 9:26 PM, Ding Tianhong wrote:
>> There is no code to enable the PCIe Relaxed Ordering bit in the
>> configuration space,
>> it is only be enable by default according to the PCIe Standard
>> Specification, what we
>> do is to
On 7/13/2017 9:26 PM, Ding Tianhong wrote:
> There is no code to enable the PCIe Relaxed Ordering bit in the configuration
> space,
> it is only be enable by default according to the PCIe Standard Specification,
> what we
> do is to distinguish the RC problematic platform and clear the Relaxed
On 2017/7/14 5:09, Sinan Kaya wrote:
> On 7/13/2017 10:21 AM, Ding Tianhong wrote:
>> static void pci_configure_relaxed_ordering(struct pci_dev *dev)
>> +{
>> +/* We should not alter the relaxed ordering bit for the VF */
>> +if (dev->is_virtfn)
>> +return;
>> +
>> +/* If
On 7/13/2017 10:21 AM, Ding Tianhong wrote:
> static void pci_configure_relaxed_ordering(struct pci_dev *dev)
> +{
> + /* We should not alter the relaxed ordering bit for the VF */
> + if (dev->is_virtfn)
> + return;
> +
> + /* If the releaxed ordering enable bit is not
23 matches
Mail list logo