linux-kernel - Re: Linux Kernel Regression: HAPS quirk breaks PCIe on i.MX6QP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <30102591E157244384E984126FC3CB4F639BEC73@us01wembx1.internal.synopsys.com>
Date:   Thu, 31 Jan 2019 22:50:09 +0000
From:   Thinh Nguyen <thinh.nguyen@...opsys.com>
To:     Bjorn Helgaas <bhelgaas@...gle.com>,
        "Lukas F. Hartmann" <lukas@...mn.com>
CC:     "thinh.nguyen@...opsys.com" <thinh.nguyen@...opsys.com>,
        "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        Lucas Stach <l.stach@...gutronix.de>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        John Youn <john.youn@...opsys.com>
Subject: Re: Linux Kernel Regression: HAPS quirk breaks PCIe on i.MX6QP

Hi Lukas,

Bjorn Helgaas wrote:
> [+cc linux-pci, linux-kernel]
>
> On Thu, Jan 31, 2019 at 11:21 AM Lukas F. Hartmann <lukas@...mn.com> wrote:
>> Hi Thinh,
>>
>> I'm writing you because you're the author in this commit:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_torvalds_linux_commit_03e6742584af8866ba014874669d0440bed3a623&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=VKipRJmm95P2RbIxyKKYrcUCOGNlQtjlV-5zhrVhIik&m=2sOrowYXlsC3rl0LfHQhIZzImag0jFZXGvR6NIQDsh8&s=oJoBWRE8_LGAYbX2alh6QnjYZTTmzcgLw4MtOMToNyo&e=
>>
>> This quirk workaround breaks the PCIe on i.MX6QP, at least on my test
>> devices. The reason is because the Synposys PCIe IP in i.MX6QP has the
>> same device ID as the HAPS USB3 controller you are targeting in the
>> commit: 0xabcd.
>>
>> Definition:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_torvalds_linux_blob_master_include_linux_pci-5Fids.h-23L2364&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=VKipRJmm95P2RbIxyKKYrcUCOGNlQtjlV-5zhrVhIik&m=2sOrowYXlsC3rl0LfHQhIZzImag0jFZXGvR6NIQDsh8&s=-FVCwe81XNjJsYHYk1w-kdAzSOLunTGeNc73azO2QYw&e=
>>
>> Here is a bit of lspci output on my i.MX6QP machine (without the problem):
>>
>> mntmn@...orm:~/code/linux$ lspci -v
>> 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00
>>                                           ^^^^
>> [Normal decode])
>>         Flags: bus master, fast devsel, latency 0, IRQ 307
>>         Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
>>         Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
>> ...
>>
>> The failure mode is that the PCIe controller shows up as a USB
>> controller and my ath9k wireless PCIe card cannot be assigned the
>> proper resources anymore (-ENOMEM even for very small BARs).
>>
>> Reverting this commit fixes the problem for me. I suggest to make the
>> check more specific to the platform/chipset you are targeting.
> So Synopsys apparently re-used Device ID 0xabcd?  That's a pretty bad problem.
>
> It looks like we merged 03e6742584af ("PCI: Override Synopsys USB 3.x
> HAPS device class") for v5.0, and v5.0-final hasn't been released yet,
> so if we don't hear from Thinh with a resolution, we can still revert
> it.
>
> I set myself a reminder to revert this on Feb 11, but hopefully we'll
> have a better resolution before then.
>
> Bjorn
>

This is really odd that the PID for the PCIe controller in i.MX6QP is
the same as PID Synopsys use for USB controller. We use a different set
of PIDs for PCIe controllers and track VID and PID in our releases.

Is the Root Complex (00:00.0) part of the SoC? Or is this a Synopsys
prototype connected to your board? If it is the latter, then the FPGA
configuration needs to be updated to other PID.

We're investigating the workaround in case this is on a taped-out SoC.

Thanks,
Thinh