linux-kernel - Re: [PATCH] PCI: controller: dwc: Make PCI

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]

Date:   Thu, 6 Dec 2018 15:41:02 -0600
From:   Robert Hancock <hancock@...systems.ca>
To:     Lucas Stach <l.stach@...gutronix.de>,
        Baruch Siach <baruch@...s.co.il>,
        Andrey Smirnov <andrew.smirnov@...il.com>
Cc:     linux-pci@...r.kernel.org, "A.s. Dong" <aisheng.dong@....com>,
        Richard Zhu <hongxing.zhu@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-imx@....com, bhelgaas@...gle.com,
        Leonard Crestez <leonard.crestez@....com>, cphealy@...il.com,
        Trent Piepho <tpiepho@...inj.com>
Subject: Re: [PATCH] PCI: controller: dwc: Make PCI_IMX6 depend on PCIEPORTBUS

On 2018-12-06 10:10 a.m., Robert Hancock wrote:
> On 2018-12-06 9:50 a.m., Lucas Stach wrote:
>> Am Donnerstag, den 06.12.2018, 09:45 -0600 schrieb Robert Hancock:
>>> On 2018-12-06 2:10 a.m., Baruch Siach wrote:
>>>> Hi Andrey,
>>>>
>>>> Adding Robert Hancock who reported[1] on a PCIe MSI issue with i.MX6.
>>>>
>>>> Andrey Smirnov writes:
>>>>
>>>>> Building a kernel with CONFIG_PCI_IMX6=y, but CONFIG_PCIEPORTBUS=n
>>>>> produces a system where built-in PCIE bridge (16c3:abcd) isn't bound
>>>>> to pcieport driver. This, in turn, results in a PCIE bus that is
>>>>> capable of enumerating attached PCIE device, but lacks functional
>>>>> interrupt support.
>>>>
>>>> Robert, does that fix your issue?
>>>
>>> Unfortunately, no.. in fact the situation on my setup is even worse with
>>> CONFIG_PCIEPORTBUS enabled: Not only does MSI still not function, but
>>> now INTx interrupts are somehow broken as well - no interrupts are
>>> received. The IRQ information shown in /proc/interrupts is correct, but
>>> the count remains stubbornly at 0.
>>
>> That's expected. The port services will use an MSI IRQ when available
>> and due to a design issue with the DWC PCIe it will not forward any
>> legacy IRQs if any MSI is in use. If any of the PCIe devices in your
>> system are unable to work with MSI IRQs, you must boot with "nomsi" on
>> the kernel command line set.
> 
> That seems like an unfortunate design choice on their part.. well that
> would probably argue against adding this as a hard dependency then, if
> non-MSI-supporting PCIe devices can't work with default boot options
> with that set.
> 
> I'm looking into testing with an NXP Smart Devices board and some PCIe
> cards to see if I can verify whether MSI works on those or not, since we
> currently don't have a way to independently verify that the MSI
> implementation in our FPGA is working or whether another PCIe device
> works with MSI (the FPGA is integrated on the system board).

I've now done some tests with a NXP SabreSD reference board and an Intel
wireless card:

-With the standard imx_v6_v7 defconfig, MSI does not work, INTx works

-With CONFIG_PCIEPORTBUS=y, MSI does work

So it seems like enabling PCIEPORTBUS should fix our MSI issue on the
CPU side, and our remaining problem is likely on the FPGA device side.
However, there's still the issue that enabling that option breaks INTx
support - I don't have a PCIe card handy that the kernel doesn't enable
MSI for in order to test that on the Sabre board, but based on Lucas's
comment and my results on our board, it definitely seems to be an issue.
I would hope there must be a way to handle that..

-- 
Robert Hancock
Senior Software Developer
SED Systems
Email: hancock@...systems.ca