From mboxrd@z Thu Jan 1 00:00:00 1970 From: matthias.bgg@gmail.com (Matthias Brugger) Date: Thu, 2 Nov 2017 19:47:34 +0100 Subject: [GIT PULL] Mediatek: 32-bit DT update for v4.15 In-Reply-To: References: <1509423579.10793.10.camel@mtkswgap22> Message-ID: <0c3f8521-e0a6-a0d2-45b9-62d7c824818d@gmail.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 11/02/2017 05:05 PM, Arnd Bergmann wrote: > On Thu, Nov 2, 2017 at 12:47 PM, Matthias Brugger > wrote: >> Hi Arnd, >> >> On 10/31/2017 05:19 AM, Ryder Lee wrote: >>> Hi Arnd, >>> >>> We have 3 root ports in MT7623, but this is a bug in this chip where the >>> HW designers wired the IRQs in a nonstandard way. We've tried to >>> statically assign the bus portion of the address part in the parent >>> interrupt-map before, but this approach cannot handle the case - if we >>> attach the device in random order. >>> >> >> Ryder, please don't top post :) >> >>> Thanks. >>> >>> On Mon, 2017-10-30 at 13:42 +0100, Arnd Bergmann wrote: >>>> On Mon, Oct 23, 2017 at 12:06 AM, Matthias Brugger >>>> wrote: >>>>> >>>>> ---------------------------------------------------------------- >>>>> - mt76233 add PCIe node >>>> >>>> Could you clarify what the subnodes in the PCI node are for? It seems odd >>>> to have "interrupt-map" properties in both the pcie controller and its child >>>> nodes, and I want to ensure this is following the standard PCIe binding before >>>> I pull it. >>>> >> >> Arnd, I didn't found the pull request in your next/dt branch. >> Is there more clarification needed from our side? > > I'm still unsure about it., this looks like exactly the thing that the top-level > interrupt-map is supposed to handle fine. > > Can you send a pull request for the series without the pci child nodes for the > moment while we figure out what the exact problem is? We can take > whatever fix we come up with during the v4.15 -rc cycle then. Sure. I'll provide a new tag v4.14-next-dts32-2 without the patch. I will send a pull request shortly. Regards, Matthias > > I would assume that either the parent interrupt-map is wrong, or something > broke the parser, but that it's not actually something that's wrong in the > hardware design in a way that we can't already handle in a standard way. > > Ryder, can you be more specific how the interrupts are wired up? > Is there one IRQ per slot that is connected to all of IntA/IntB/IntC/IntD > and gets propagated through the bridges like that, or is it something else? > > Arnd >