> I think the conclusion is that a hard-wired ACS capability is a
> positive indication of isolation for a multifunction device, the code
> is intended to support this and appears to do so, and Roland was going
> to investigate the sightings that inspired this patch in more detail.
> Dropping for n
On Fri, 4 Aug 2017 13:28:32 +
David Laight wrote:
> From: Bjorn Helgaas
> > Sent: 03 August 2017 22:49
> > On Thu, Jul 20, 2017 at 02:41:01PM -0700, Roland Dreier wrote:
> > > From: Roland Dreier
> > >
> > > Add one more variant of the 82599 plus the device IDs for X540 and X550
> > > vari
From: Bjorn Helgaas
> Sent: 03 August 2017 22:49
> On Thu, Jul 20, 2017 at 02:41:01PM -0700, Roland Dreier wrote:
> > From: Roland Dreier
> >
> > Add one more variant of the 82599 plus the device IDs for X540 and X550
> > variants. Intel has confirmed that none of these devices does peer-to-peer
On Thu, 3 Aug 2017 16:49:11 -0500
Bjorn Helgaas wrote:
> On Thu, Jul 20, 2017 at 02:41:01PM -0700, Roland Dreier wrote:
> > From: Roland Dreier
> >
> > Add one more variant of the 82599 plus the device IDs for X540 and X550
> > variants. Intel has confirmed that none of these devices does peer
On Thu, Jul 20, 2017 at 02:41:01PM -0700, Roland Dreier wrote:
> From: Roland Dreier
>
> Add one more variant of the 82599 plus the device IDs for X540 and X550
> variants. Intel has confirmed that none of these devices does peer-to-peer
> between functions. The X540 and X550 have added ACS cap
On Mon, 24 Jul 2017 12:31:39 -0700
Roland Dreier wrote:
> > Is there a misunderstanding of the code flow here? We're never setting
> > EC. In the first code block we're just masking out requested
> > capabilities where unimplemented capabilities is the same as
> > implemented + enabled. We're
> Is there a misunderstanding of the code flow here? We're never setting
> EC. In the first code block we're just masking out requested
> capabilities where unimplemented capabilities is the same as
> implemented + enabled. We're not adding EC to the request, we're
> just not removing it based o
On Mon, 24 Jul 2017 10:18:56 -0700
Roland Dreier wrote:
> > I think that the device implementing ACS and not implementing certain
> > features that are "must be implemented if..." is a positive indication
> > that the device does not have that behavior and therefore the ability
> > to control tha
> I think that the device implementing ACS and not implementing certain
> features that are "must be implemented if..." is a positive indication
> that the device does not have that behavior and therefore the ability
> to control that behavior is unnecessary. pci_acs_flags_enabled() is
> coded wit
On Thu, 20 Jul 2017 15:53:04 -0700
Roland Dreier wrote:
> On Thu, Jul 20, 2017 at 3:15 PM, Alex Williamson
> wrote:
>
> > Most of the ACS capabilities are worded as "Must be implemented by
> > devices that implement ..." Shouldn't a hard-wired ACS capability
> > sufficiently describe that, or
On Thu, Jul 20, 2017 at 3:15 PM, Alex Williamson
wrote:
> Most of the ACS capabilities are worded as "Must be implemented by
> devices that implement ..." Shouldn't a hard-wired ACS capability
> sufficiently describe that, or is there something wrong with how
> they're hard wired?
Interesting q
>-Original Message-
>From: Roland Dreier [mailto:rol...@purestorage.com] On Behalf Of Roland
>Dreier
>Sent: Thursday, July 20, 2017 2:41 PM
>To: Bjorn Helgaas
>Cc: linux-...@vger.kernel.org; netdev@vger.kernel.org; Tantilov, Emil S
>
>Subject: [PATCH] PCI: Update ACS quirk for more Intel 1
On Thu, 20 Jul 2017 14:41:01 -0700
Roland Dreier wrote:
> From: Roland Dreier
>
> Add one more variant of the 82599 plus the device IDs for X540 and X550
> variants. Intel has confirmed that none of these devices does peer-to-peer
> between functions. The X540 and X550 have added ACS capabili
13 matches
Mail list logo
