On 11/02/2017 05:05 PM, Arnd Bergmann wrote: > On Thu, Nov 2, 2017 at 12:47 PM, Matthias Brugger > <matthias.bgg@xxxxxxxxx> 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 >>>> <matthias.bgg@xxxxxxxxx> 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 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
