linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Logan Gunthorpe <logang@deltatee.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	Shlomo Pongratz <shlomopongratz@gmail.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	andrew.maier@eideticom.com, bhelgaas@google.com,
	Shlomo Pongratz <shlomop@pliops.com>
Subject: Re: [PATCH V4 1/1] Intel Sky Lake-E host root ports check.
Date: Wed, 30 Mar 2022 13:46:54 -0600	[thread overview]
Message-ID: <363307ae-bfc9-9c24-0b1c-39e09663dbb4@deltatee.com> (raw)
In-Reply-To: <20220330193832.GF2120790@nvidia.com>



On 2022-03-30 13:38, Jason Gunthorpe wrote:
> On Wed, Mar 30, 2022 at 01:36:25PM -0600, Logan Gunthorpe wrote:
> 
>> Checking simply for PCI_EXP_TYPE_ROOT_PORT instead of a zero devfn is
>> probably a good idea, assuming it works for all existing systems. I'd
>> expect it would be set for all the devices currently allowed.
> 
> I think if we find a PCI ID in the white list as we go up the PCI
> hierarchy we should just declare success?

Well, in older hardware we also have to ensure that the devices are on
the same host bridge. (See REQ_SAME_HOST_BRIDGE). So it's a bit more
complicated than that...
> Does it matter if it is the top of the tree or if it is a root port or
> host bridge? The IDs in this list only exist as part of SOCs, so
> seeing them at all should confirm the whole SOC..

Not sure if that will always hold with multi-socket systems. The code
currently uses pci_find_host_bridge() for each device, then uses
pci_host_bridge_dev() simply to find identifying information about the
host bridge. It doesn't really matter where in the tree things are, but
it would be add for the host bridge not to be at the top, I would have
thought.

Logan

      reply	other threads:[~2022-03-30 19:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-30 14:08 [PATCH V4 0/1] Intel Sky Lake-E host root ports check Shlomo Pongratz
2022-03-30 14:08 ` [PATCH V4 1/1] " Shlomo Pongratz
2022-03-30 15:20   ` Logan Gunthorpe
2022-03-30 15:37   ` Jason Gunthorpe
2022-03-30 19:10     ` Bjorn Helgaas
2022-03-30 19:11       ` Jason Gunthorpe
2022-03-30 19:36         ` Logan Gunthorpe
2022-03-30 19:38           ` Jason Gunthorpe
2022-03-30 19:46             ` Logan Gunthorpe [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=363307ae-bfc9-9c24-0b1c-39e09663dbb4@deltatee.com \
    --to=logang@deltatee.com \
    --cc=andrew.maier@eideticom.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=jgg@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=shlomop@pliops.com \
    --cc=shlomopongratz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).