On Sat, Sep 16, 2023 at 03:36:50PM +0200, Lukas Wunner wrote:
> 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;
> > > > > > +}
> ...
> The "pcie_find_root_port(child) != pdev" check is always false:
If we were using pci_walk_bus() and only looking at devices below
pdev, I would agree, but since we're using pci_get_class(), which
searches all PCI devices in the system, I'm confused about why it
would always be false.
I don't really see the point of checking for USB4, because the commit
log doesn't say anything about why this would be specific to USB4.
I know Mario has mentioned something about how "internal interrupt
routing works with the USB4 controller connected to this root port,"
but I don't understand what that means.
Is the USB4 controller integrated into the Root Port? Or is this
interrupt routed via some non-PCIe mechanism? If the USB4 controller
is connected via standard PCIe, I don't see why the issue sould be
specific to USB4.
I could believe that BIOS configures the Root Port differently based
on whether the downstream device is USB4, but I haven't heard anything
about that.
Bjorn
