All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Mario Limonciello <mario.limonciello@amd.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Hans de Goede <hdegoede@redhat.com>,
	iain@orangesquash.org.uk,
	Shyam Sundar S K <Shyam-sundar.S-k@amd.com>,
	"open list:PCI SUBSYSTEM" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH v19 2/2] PCI: Add a quirk for AMD PCIe root ports w/ USB4 controllers
Date: Sat, 16 Sep 2023 15:36:50 +0200	[thread overview]
Message-ID: <20230916133650.GA26241@wunner.de> (raw)
In-Reply-To: <a2db379c-b5e4-4ccb-9f5d-15dd94600c84@amd.com>

On Sat, Sep 16, 2023 at 08:09:19AM -0500, Mario Limonciello wrote:
> On 9/15/2023 23:48, Lukas Wunner wrote:
> > On Fri, Sep 15, 2023 at 07:04:11AM -0500, Mario Limonciello wrote:
> > > On 9/15/2023 02:08, Lukas Wunner wrote:
> > > > On Thu, Sep 14, 2023 at 09:33:54PM -0500, Mario Limonciello wrote:
> > > > > +static bool child_has_amd_usb4(struct pci_dev *pdev)
> > > > > +{
> > > > > +	struct pci_dev *child = NULL;
> > > > > +
> > > > > +	while ((child = pci_get_class(PCI_CLASS_SERIAL_USB_USB4, child))) {
> > > > > +		if (child->vendor != PCI_VENDOR_ID_AMD)
> > > > > +			continue;
> > > > > +		if (pcie_find_root_port(child) != pdev)
> > > > > +			continue;
> > > > > +		return true;
> > > > > +	}
> > > > > +
> > > > > +	return false;
> > > > > +}
> > > > 
> > > > What's the purpose of the pcie_find_root_port() check?  PCI is a hierarchy,
> > > > not a graph, so a device cannot have any other Root Port but the one below
> > > > which you're searching.
> > > > 
> > > > If the purpose is to check that the port is a Root Port (if the PCI IDs
> > > > you're using in the DECLARE_PCI_FIXUP_* clauses match non-Root Ports),
> > > > check for pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT.  (No need to
> > > > check for that in every loop iteration obviously, just check once in
> > > > the fixup.)
> > > > 
> > > > Thanks,
> > > > 
> > > > Lukas
> > > 
> > > The reason to look for it the way that I did was that there are multiple
> > > root ports with the exact same PCI ID.
> > > 
> > > The problem only occurs on the root port that happens to have an AMD USB4
> > > controller connected.
> > 
> > Yes but what's the purpose of the pcie_find_root_port(child) check
> > quoted above?
> 
> You're right that if you look at this system alone that the check isn't
> strictly necessary.  It's to future proof the quirk.  If a discrete USB4
> controller was connected to the system it would be connected to a different
> root port (the one that is used for PCI tunneling).
> 
> AMD doesn't have any of these devices, but if some day one was created it
> could trip this codepath.
> 
> If you feel it's better to remove the check unless such a device is created
> sure I can drop it.

PCIe ports used for Thunderbolt tunneling are Downstream Ports or
Upstream Ports (depending on which of the two ends of the tunnel
you're looking at).

The "pcie_find_root_port(child) != pdev" check is always false:

You're searching for a USB controller below a Root Port and
check whether the Root Port in the USB controller's ancestry
is the Root Port below which you're searching.  That's a
tautology.

I'm guessing what you really mean is:

		if (pci_upstream_bridge(child)) != pdev)
			continue;

Thanks,

Lukas

  reply	other threads:[~2023-09-16 13:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-15  2:33 [PATCH v19 0/2] Add quirk for PCIe root port on AMD systems Mario Limonciello
2023-09-15  2:33 ` [PATCH v19 1/2] PCI: Move the `PCI_CLASS_SERIAL_USB_USB4` definition to common header Mario Limonciello
2023-09-15  2:33 ` [PATCH v19 2/2] PCI: Add a quirk for AMD PCIe root ports w/ USB4 controllers Mario Limonciello
2023-09-15  7:08   ` Lukas Wunner
2023-09-15 12:04     ` Mario Limonciello
2023-09-16  4:48       ` Lukas Wunner
2023-09-16 13:09         ` Mario Limonciello
2023-09-16 13:36           ` Lukas Wunner [this message]
2023-09-16 14:00             ` Mario Limonciello
2023-09-17 21:40             ` Bjorn Helgaas
2023-09-18  1:02               ` Mario Limonciello
2023-09-18  7:01               ` Lukas Wunner
2023-09-17 21:56   ` Bjorn Helgaas
2023-09-18  1:08     ` Mario Limonciello
2023-09-18 11:59   ` Ilpo Järvinen

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=20230916133650.GA26241@wunner.de \
    --to=lukas@wunner.de \
    --cc=Shyam-sundar.S-k@amd.com \
    --cc=bhelgaas@google.com \
    --cc=hdegoede@redhat.com \
    --cc=iain@orangesquash.org.uk \
    --cc=linux-pci@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rjw@rjwysocki.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.