Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Thinh Nguyen <thinh.nguyen@synopsys.com>
To:     Bjorn Helgaas <bhelgaas@google.com>,
        "Lukas F. Hartmann" <lukas@mntmn.com>
CC:     "thinh.nguyen@synopsys.com" <thinh.nguyen@synopsys.com>,
        "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
        Lucas Stach <l.stach@pengutronix.de>,
        "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        John Youn <john.youn@synopsys.com>
Subject: Re: Linux Kernel Regression: HAPS quirk breaks PCIe on i.MX6QP
Thread-Topic: Linux Kernel Regression: HAPS quirk breaks PCIe on i.MX6QP
Thread-Index: AQHUuYlvOcIoiyxgC0SXEBumWw7cKQ==
Date:   Thu, 31 Jan 2019 22:50:09 +0000
Message-ID: <30102591E157244384E984126FC3CB4F639BEC73@us01wembx1.internal.synopsys.com>
References: <87o97wrbef.fsf@mntmn.com>
 <CAErSpo4T91kbXXuMSCqrDk=_HD+6GZ64WVZsvhSOtW=L89Pf0g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Lukas,=0A=
=0A=
Bjorn Helgaas wrote:=0A=
> [+cc linux-pci, linux-kernel]=0A=
>=0A=
> On Thu, Jan 31, 2019 at 11:21 AM Lukas F. Hartmann <lukas@mntmn.com> wrot=
e:=0A=
>> Hi Thinh,=0A=
>>=0A=
>> I'm writing you because you're the author in this commit:=0A=
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_torval=
ds_linux_commit_03e6742584af8866ba014874669d0440bed3a623&d=3DDwIBaQ&c=3DDPL=
6_X_6JkXFx7AXWqB0tg&r=3DVKipRJmm95P2RbIxyKKYrcUCOGNlQtjlV-5zhrVhIik&m=3D2sO=
rowYXlsC3rl0LfHQhIZzImag0jFZXGvR6NIQDsh8&s=3DoJoBWRE8_LGAYbX2alh6QnjYZTTmzc=
gLw4MtOMToNyo&e=3D=0A=
>>=0A=
>> This quirk workaround breaks the PCIe on i.MX6QP, at least on my test=0A=
>> devices. The reason is because the Synposys PCIe IP in i.MX6QP has the=
=0A=
>> same device ID as the HAPS USB3 controller you are targeting in the=0A=
>> commit: 0xabcd.=0A=
>>=0A=
>> Definition:=0A=
>>=0A=
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_torval=
ds_linux_blob_master_include_linux_pci-5Fids.h-23L2364&d=3DDwIBaQ&c=3DDPL6_=
X_6JkXFx7AXWqB0tg&r=3DVKipRJmm95P2RbIxyKKYrcUCOGNlQtjlV-5zhrVhIik&m=3D2sOro=
wYXlsC3rl0LfHQhIZzImag0jFZXGvR6NIQDsh8&s=3D-FVCwe81XNjJsYHYk1w-kdAzSOLunTGe=
Nc73azO2QYw&e=3D=0A=
>>=0A=
>> Here is a bit of lspci output on my i.MX6QP machine (without the problem=
):=0A=
>>=0A=
>> mntmn@reform:~/code/linux$ lspci -v=0A=
>> 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00=0A=
>>                                           ^^^^=0A=
>> [Normal decode])=0A=
>>         Flags: bus master, fast devsel, latency 0, IRQ 307=0A=
>>         Memory at 01000000 (32-bit, non-prefetchable) [size=3D1M]=0A=
>>         Bus: primary=3D00, secondary=3D01, subordinate=3Dff, sec-latency=
=3D0=0A=
>> ...=0A=
>>=0A=
>> The failure mode is that the PCIe controller shows up as a USB=0A=
>> controller and my ath9k wireless PCIe card cannot be assigned the=0A=
>> proper resources anymore (-ENOMEM even for very small BARs).=0A=
>>=0A=
>> Reverting this commit fixes the problem for me. I suggest to make the=0A=
>> check more specific to the platform/chipset you are targeting.=0A=
> So Synopsys apparently re-used Device ID 0xabcd?  That's a pretty bad pro=
blem.=0A=
>=0A=
> It looks like we merged 03e6742584af ("PCI: Override Synopsys USB 3.x=0A=
> HAPS device class") for v5.0, and v5.0-final hasn't been released yet,=0A=
> so if we don't hear from Thinh with a resolution, we can still revert=0A=
> it.=0A=
>=0A=
> I set myself a reminder to revert this on Feb 11, but hopefully we'll=0A=
> have a better resolution before then.=0A=
>=0A=
> Bjorn=0A=
>=0A=
=0A=
This is really odd that the PID for the PCIe controller in i.MX6QP is=0A=
the same as PID Synopsys use for USB controller. We use a different set=0A=
of PIDs for PCIe controllers and track VID and PID in our releases.=0A=
=0A=
Is the Root Complex (00:00.0) part of the SoC? Or is this a Synopsys=0A=
prototype connected to your board? If it is the latter, then the FPGA=0A=
configuration needs to be updated to other PID.=0A=
=0A=
We're investigating the workaround in case this is on a taped-out SoC.=0A=
=0A=
Thanks,=0A=
Thinh=0A=