Re: [PATCH RESEND] PCI: Check for USB xHCI class for HAPS platform

[Bjorn Helgaas <helgaas@kernel.org>]

On Tue, Feb 05, 2019 at 05:01:18PM -0800, John Youn wrote:
> On 02/05/2019 03:32 PM, Bjorn Helgaas wrote:
> > On Tue, Feb 05, 2019 at 01:04:28PM -0800, Thinh Nguyen wrote:
> > > The Synopsys HAPS USB controller has a VID PID (16c3,abcd) that matches
> > > to an existing PCIe controller. This quirk is intended for USB HAPS
> > > devices only. To fix this, check for the PCI class USB xHCI to prevent
> > > matching the PCIe controllers.
> > 
> > So there are at least three different parts with the same Vendor &
> > Device ID ([16c3:abcd]):
> > 
> >    1) Synopsys HAPS USB3 controller
> >    2) Synopsys PCIe IP in the NXP i.MX6QP (reported by Lukas)
> >    3) Synopsys PCIe IP in the NXP i.MX7D (reported by Trent)
> > 
> > I don't know if Synopsys is to blame for 2 & 3, or if NXP was expected
> > to change the Vendor ID when incorporating the Synopsys IP into the
> > i.MX designs.  But even leaving the default Device ID of the PCIe IP
> > the same as another Synopsys device was probably a bad idea.
> 
> Hi Bjorn,
> 
> From talking with our PCIe folks, our best guess is a vendor
> misconfiguration. The PCIe IP ships with a different PID by default
> and does not collide with USB.

If that's true, your vendor was very unlucky in choosing 0xabcd.  They
also have a pretty serious misunderstanding of how PCI IDs work, which
will cause you major headaches if they continue allocating Device IDs
from the Synopsys space.

In this particular case it's probably not a disaster because the
i.MX6QP and i.MX7D devices are both bridges (Root Ports, I think), and
we don't currently have any drivers that claim those by ID.  The
portdrv claims them by Class Code.

> > dwc3-haps claims by Vendor & Device ID; it doesn't look at the Class
> > Code.  What happens when it tries to claim the PCIe IP in i.MX?
> 
> We can add the class code to dwc3-haps to account for this.

I think that'd be a good idea.  I think portdrv will claim the Root
Port first, before dwc3-haps has a chance, so the driver core won't
even call dwc3_haps_probe().

But if you unset CONFIG_PCIEPORTBUS or boot with "pcie_ports=compat",
I bet dwc3-haps *will* claim it, and things will fail a little less
gracefully.

Bjorn